前言

Spark Streaming是構建在Spark上的實時計算框架，它擴展了Spark處理大規(guī)模流式數(shù)據(jù)的能力。

Spark Streaming可結合批處理和交互式查詢，因此，可以適用于一些需要對歷史數(shù)據(jù)和實時數(shù)據(jù)進行結合分析的應用場景。

流計算是一種典型的大數(shù)據(jù)計算模式，可以實現(xiàn)對源源不斷到達的流數(shù)據(jù)的實時處理分析。

一、靜態(tài)數(shù)據(jù)和流數(shù)據(jù)

1.靜態(tài)數(shù)據(jù)

如果把數(shù)據(jù)存儲系統(tǒng)比作一個“水庫”，那么，存儲在數(shù)據(jù)存儲系統(tǒng)中的靜態(tài)數(shù)據(jù)就像水庫中的水一樣，是靜止不動的。

很多企業(yè)為了支持決策分析而構建的數(shù)據(jù)倉庫系統(tǒng)（見圖6-1），其中存放的大量歷史數(shù)據(jù)就是靜態(tài)數(shù)據(jù)，這些數(shù)據(jù)來自不同的數(shù)據(jù)源，利用ETL（Extract-Transform-Load）工具加載到數(shù)據(jù)倉庫中，并且不會發(fā)生更新，技術人員可以利用數(shù)據(jù)挖掘和OLAP（On-LineAnalytical Processing）分析工具從這些靜態(tài)數(shù)據(jù)中找到對企業(yè)有價值的信息。

2.流數(shù)據(jù)

流數(shù)據(jù)（或數(shù)據(jù)流）是指在時間分布和數(shù)量上無限的一系列動態(tài)數(shù)據(jù)集合體；數(shù)據(jù)記錄是流數(shù)據(jù)的最小組成單元。流數(shù)據(jù)具有如下特征。

（1）數(shù)據(jù)快速持續(xù)到達，潛在大小也許是無窮無盡的。

（2）數(shù)據(jù)來源眾多，格式復雜。

（3）數(shù)據(jù)量大，但是不十分關注存儲，一旦流數(shù)據(jù)中的某個元素經(jīng)過處理，要么被丟棄，要么被歸檔存儲。

（4）注重數(shù)據(jù)的整體價值，不過分關注個別數(shù)據(jù)。

（5）數(shù)據(jù)順序顛倒，或者不完整，系統(tǒng)無法控制將要處理的新到達的數(shù)據(jù)元素的順序。

二、流計算

1.流計算的基本概念

流計算是數(shù)據(jù)的價值隨著時間的流逝而降低。

因此，當事件出現(xiàn)時就應該立即進行處理，而不是緩存起來進行批量處理。

為了及時處理流數(shù)據(jù)，就需要一個低延遲、可擴展、高可靠的處理引擎。對于一個流計算系統(tǒng)來說，

流計算的特性：

（1）高性能。處理大數(shù)據(jù)的基本要求，如每秒處理幾十萬條數(shù)據(jù)。

（2）海量式。支持TB級甚至是PB級的數(shù)據(jù)規(guī)模。

（3）實時性。必須保證一個較低的延遲時間，達到秒級別，甚至是毫秒級別。

（4）分布式。支持大數(shù)據(jù)的基本架構，必須能夠平滑擴展。

（5）易用性。能夠快速進行開發(fā)和部署。

（6）可靠性。能可靠地處理流數(shù)據(jù)。

2.流計算處理流程

（1）數(shù)據(jù)實時采集

數(shù)據(jù)實時采集階段通常采集多個數(shù)據(jù)源的海量數(shù)據(jù)，需要保證實時性、低延遲與穩(wěn)定可靠。以日志數(shù)據(jù)為例，由于分布式集群的廣泛應用，數(shù)據(jù)分散存儲在不同的機器上，因此需要實時匯總來自不同機器上的日志數(shù)據(jù)。

數(shù)據(jù)采集系統(tǒng)的基本架構一般有3個部分：

1）Agent：主動采集數(shù)據(jù)，并把數(shù)據(jù)推送到Collector部分。

2）Collector：接收多個Agent的數(shù)據(jù)，并實現(xiàn)有序、可靠、高性能的轉發(fā)。

3）Store：存儲Collector轉發(fā)過來的數(shù)據(jù)。

（2）數(shù)據(jù)實時計算

數(shù)據(jù)實時計算階段對采集的數(shù)據(jù)進行實時的分析和計算。流處理系統(tǒng)接收數(shù)據(jù)采集系統(tǒng)不斷發(fā)來的實時數(shù)據(jù)，實時地進行分析計算，并反饋實時結果。經(jīng)流處理系統(tǒng)處理后的數(shù)據(jù)，可視情況進行存儲，以便之后再進行分析計算。在時效性要求較高的場景中，處理之后的數(shù)據(jù)也可以直接丟棄。

（3）實時查詢服務

流計算的第三個階段是實時查詢服務，經(jīng)由流計算框架得出的結果可供用戶進行實時查詢、展示或儲存。

傳統(tǒng)的數(shù)據(jù)處理流程，用戶需要主動發(fā)出查詢才能獲得想要的結果。

而在流處理流程中，實時查詢服務可以不斷更新結果，并將用戶所需的結果實時推送給用戶。

雖然通過對傳統(tǒng)的數(shù)據(jù)處理系統(tǒng)進行定時查詢，也可以實現(xiàn)不斷更新結果和結果推送，但通過這樣的方式獲取的結果，仍然是根據(jù)過去某一時刻的數(shù)據(jù)得到的結果，與實時結果有著本質的區(qū)別。

流處理系統(tǒng)與傳統(tǒng)的數(shù)據(jù)處理系統(tǒng)的區(qū)別

1）流處理系統(tǒng)處理的是實時的數(shù)據(jù)，而傳統(tǒng)的數(shù)據(jù)處理系統(tǒng)處理的是預先存儲好的靜態(tài)數(shù)據(jù)。

2）用戶通過流處理系統(tǒng)獲取的是實時結果，而通過傳統(tǒng)的數(shù)據(jù)處理系統(tǒng)獲取的是過去某一時刻的結果。并且，流處理系統(tǒng)無需用戶主動發(fā)出查詢，實時查詢服務可以主動將實時結果推送給用戶。

三、Spark Streaming

1.Spark Streaming的定義

Spark Streaming 是個批處理的流式（實時）計算框架。其基本原理是把輸入數(shù)據(jù)以某一時間間隔批量的處理，當批處理間隔縮短到秒級時，便可以用于處理實時數(shù)據(jù)流。

支持從多種數(shù)據(jù)源獲取數(shù)據(jù)，包括Kafk、Flume、Twitter、ZeroMQ、Kinesis以及TCP sockets，從數(shù)據(jù)源獲取數(shù)據(jù)之后，可以使用諸如map、reduce、join等高級函數(shù)進行復雜算法的處理。

最后還可以將處理結果存儲到文件系統(tǒng)，數(shù)據(jù)庫等數(shù)據(jù)持久化系統(tǒng)。

2.Spark Streaming與Storm的對比

Spark Streaming和Storm最大的區(qū)別在于，Spark Streaming無法實現(xiàn)毫秒級的流計算，而Storm可以實現(xiàn)毫秒級響應。

Spark Streaming無法實現(xiàn)毫秒級的流計算，是因為其將流數(shù)據(jù)分解為一系列批處理作業(yè)，在這個過程中，會產生多個Spark作業(yè)，且每一段數(shù)據(jù)的處理都會經(jīng)過Spark DAG圖分解、任務調度等過程，需要一定的開銷，因此，無法實現(xiàn)毫秒級響應。

Spark Streaming難以滿足對實時性要求非常高（如高頻實時交易）的場景，但足以勝任其他流式準實時計算場景。

相比之下，Storm處理的數(shù)據(jù)單位為元組，只會產生極小的延遲。 Spark Streaming構建在Spark上，一方面是因為Spark的低延遲執(zhí)行引擎（100ms+）可以用于實時計算，另一方面，相比于Storm，RDD數(shù)據(jù)集更容易做高效的容錯處理。

此外，SparkStreaming采用的小批量處理的方式，使得它可以同時兼容批量和實時數(shù)據(jù)處理的邏輯和算法，因此，方便了一些需要歷史數(shù)據(jù)和實時數(shù)據(jù)聯(lián)合分析的特定應用場合。

3.Spark Streaming 優(yōu)缺點

與傳統(tǒng)流式框架相比，Spark Streaming 最大的不同點在于它對待數(shù)據(jù)是粗粒度的處理方式，即一次處理一小批數(shù)據(jù)，而其他框架往往采用細粒度的處理模式，即依次處理一條數(shù)據(jù)。

Spark Streaming 這樣的設計實現(xiàn)既為其帶來了顯而易見的優(yōu)點，又引入了不可避免的缺點。

優(yōu)點

1）Spark Streaming 內部的實現(xiàn)和調度方式高度依賴 Spark 的 DAG 調度器和 RDD，這就決定了 Spark Streaming 的設計初衷必須是粗粒度方式的，同時，由于 Spark 內部調度器足夠快速和高效，可以快速地處理小批量數(shù)據(jù)，這就獲得準實時的特性。

2）Spark Streaming 的粗粒度執(zhí)行方式使其確保“處理且僅處理一次”的特性，同時也可以更方便地實現(xiàn)容錯恢復機制。

3）由于 Spark Streaming 的 DStream 本質是 RDD 在流式數(shù)據(jù)上的抽象，因此基于 RDD 的各種操作也有相應的基于 DStream 的版本，這樣就大大降低了用戶對于新框架的學習成本，在了解 Spark 的情況下用戶將很容易使用 Spark Streaming。

4）由于 DStream 是在 RDD 上的抽象，那么也就更容易與 RDD 進行交互操作，在需要將流式數(shù)據(jù)和批處理數(shù)據(jù)結合進行分析的情況下，將會變得非常方便。

缺點

Spark Streaming 的粗粒度處理方式也造成了不可避免的延遲。

在細粒度處理方式下，理想情況下每一條記錄都會被實時處理，而在 Spark Streaming 中，數(shù)據(jù)需要匯總到一定的量后再一次性處理，這就增加了數(shù)據(jù)處理的延遲，這種延遲是由框架的設計引入的，并不是由網(wǎng)絡或其他情況造成的。

到此這篇關于關于Hadoop中Spark Streaming的基本概念的文章就介紹到這了,更多相關Spark Streaming的基本概念內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論