大數(shù)據(jù)中Spark Streaming的架構(gòu)及原理是什么

本篇文章給大家分享的是有關(guān)大數(shù)據(jù)中Spark Streaming的架構(gòu)及原理是什么，小編覺得挺實用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

流式計算

數(shù)據(jù)的時效性

日常工作中，我們一般會先把數(shù)據(jù)儲存在一張表中，然后對這張表的數(shù)據(jù)進行加工、分析。既然數(shù)據(jù)要儲存在表中，就有時效性這個概念。
如果我們處理的是年級別的數(shù)據(jù)，比如人口分析、宏觀經(jīng)濟分析，那么數(shù)據(jù)最新日期距今晚個一兩周、甚至一兩個月都沒什么關(guān)系。
如果我們處理的是天級別的數(shù)據(jù)，比如各大網(wǎng)站的用戶偏好分析、零售供銷分析，一般晚個幾天也是可以的，即 T+N 更新。
如果是小時級別的數(shù)據(jù)，對時效性要求就更高了，比如金融風(fēng)控，涉及到資金的安全，必須有一張小時級別的數(shù)據(jù)。
那么還有沒有要求更高的？當(dāng)然有了，比如風(fēng)險監(jiān)測，網(wǎng)站必須有實時監(jiān)測系統(tǒng)，一旦有攻擊，就必須立刻采取措施，雙十一或者周年慶的時候，各大電商平臺都經(jīng)歷著嚴(yán)峻的流量考驗，也必須對系統(tǒng)進行實時的監(jiān)測。此外，網(wǎng)站的實時個性化推薦、搜索引擎中也對實時性有極高的要求。
在這種場景下，傳統(tǒng)的數(shù)據(jù)處理流程——先收集數(shù)據(jù)，然后放到DB中，再取出來分析——就無法滿足這么高的實時要求。
流式計算，在實時或者準(zhǔn)實時的場景下，應(yīng)運而生。

(1)與批量計算那樣慢慢積累數(shù)據(jù)不同，流式計算將大量數(shù)據(jù)平攤到每個時間點上，連續(xù)地進行小批量的進行傳輸，數(shù)據(jù)持續(xù)流動，計算完之后就丟棄。
(2) 批量計算是維護一張表，對表進行實施各種計算邏輯。流式計算相反，是必須先定義好計算邏輯，提交到流式計算系統(tǒng)，這個計算作業(yè)邏輯在整個運行期間是不可更改的。
(3) 計算結(jié)果上，批量計算對全部數(shù)據(jù)進行計算后傳輸結(jié)果，流式計算是每次小批量計算后，結(jié)果可以立刻投遞到在線系統(tǒng)，做到實時化展現(xiàn)。

(1) 流式計算流程
① 提交流計算作業(yè)。
② 等待流式數(shù)據(jù)觸發(fā)流計算作業(yè)。
③ 計算結(jié)果持續(xù)不斷對外寫出。

(2) 流式計算特點
① 實時、低延遲
② 無界，數(shù)據(jù)是不斷無終止的
③ 連續(xù)，計算持續(xù)進行，計算完之后數(shù)據(jù)即丟棄

Apache Storm

在Storm中，先要設(shè)計一個用于實時計算的圖狀結(jié)構(gòu)，我們稱之為拓?fù)洌╰opology）。這個拓?fù)鋵惶峤唤o集群，由集群中的主控節(jié)點（master node）分發(fā)代碼，將任務(wù)分配給工作節(jié)點（worker node）執(zhí)行。一個拓?fù)渲邪╯pout和bolt兩種角色，其中spout發(fā)送消息，負(fù)責(zé)將數(shù)據(jù)流以tuple元組的形式發(fā)送出去；而bolt則負(fù)責(zé)轉(zhuǎn)換這些數(shù)據(jù)流，在bolt中可以完成計算、過濾等操作，bolt自身也可以隨機將數(shù)據(jù)發(fā)送給其他bolt。由spout發(fā)射出的tuple是不可變數(shù)組，對應(yīng)著固定的鍵值對。

Apache Flink

Flink 是一個針對流數(shù)據(jù)和批數(shù)據(jù)的分布式處理引擎。它主要是由 Java 代碼實現(xiàn)。對 Flink 而言，其所要處理的主要場景就是流數(shù)據(jù)，批數(shù)據(jù)只是流數(shù)據(jù)的一個極限特例而已。再換句話說，F(xiàn)link 會把所有任務(wù)當(dāng)成流來處理，這也是其最大的特點。Flink 可以支持本地的快速迭代，以及一些環(huán)形的迭代任務(wù)。并且 Flink 可以定制化內(nèi)存管理。在這點，如果要對比 Flink 和 Spark 的話，F(xiàn)link 并沒有將內(nèi)存完全交給應(yīng)用層。這也是為什么 Spark 相對于 Flink，更容易出現(xiàn) OOM 的原因（out of memory）。就框架本身與應(yīng)用場景來說，F(xiàn)link 更相似與 Storm。

Apache Spark Streaming

Spark Streaming是核心Spark API的一個擴展，它并不會像Storm那樣一次一個地處理數(shù)據(jù)流，而是在處理前按時間間隔預(yù)先將其切分為一段一段的批處理作業(yè)。Spark針對持續(xù)性數(shù)據(jù)流的抽象稱為DStream（DiscretizedStream），一個DStream是一個微批處理（micro-batching）的RDD（彈性分布式數(shù)據(jù)集）；而RDD則是一種分布式數(shù)據(jù)集，能夠以兩種方式并行運作，分別是任意函數(shù)和滑動窗口數(shù)據(jù)的轉(zhuǎn)換。

Storm, Flink, Spark Streaming的對比圖

Storm, Flink, Spark Streaming的選擇

如果你想要的是一個允許增量計算的高速事件處理系統(tǒng)，Storm會是最佳選擇。

如果你必須有狀態(tài)的計算，恰好一次的遞送，并且不介意高延遲的話，那么可以考慮Spark Streaming，特別如果你還計劃圖形操作、機器學(xué)習(xí)或者訪問SQL的話，Apache Spark的stack允許你將一些library與數(shù)據(jù)流相結(jié)合(Spark SQL，Mllib，GraphX)，它們會提供便捷的一體化編程模型。尤其是數(shù)據(jù)流算法(例如：K均值流媒體)允許Spark實時決策的促進。

Flink支持增量迭代，具有對迭代自動優(yōu)化的功能，在迭代式數(shù)據(jù)處理上，比Spark更突出，F(xiàn)link基于每個事件一行一行地流式處理，真正的流式計算，流式計算跟Storm性能差不多，支持毫秒級計算，而Spark則只能支持秒級計算。

Spark Streaming 簡介

Spark Streaming 是Spark 核心API的一個擴展，可以實現(xiàn)高吞吐量的、具備容錯機制的實時流數(shù)據(jù)的處理。支持多種數(shù)據(jù)源獲取數(shù)據(jù)，包括Kafka、Flume、Zero MQ，Kinesis以及TCP Sockets，從數(shù)據(jù)源獲取數(shù)據(jù)之后，可以使用諸如map、reduce、join和window等高級函數(shù)進行復(fù)雜算法的處理。最后還可以將處理結(jié)果存儲到文件系統(tǒng)，數(shù)據(jù)庫和現(xiàn)場儀表盤。

在”O(jiān)ne Stack rule them all”的基礎(chǔ)上，可以使用Spark的其他子框架，如集群學(xué)習(xí)、圖計算等，對流數(shù)據(jù)進行處理。

Spark的各個子框架都是基于Spark Core的，Spark Streaming在內(nèi)部的處理機制是，接收實時流的數(shù)據(jù)，并根據(jù)一定的時間間隔拆分成一批批的數(shù)據(jù)，然后通過Spark Enging處理這些批數(shù)據(jù)，最終得到處理后的一批批結(jié)果數(shù)據(jù)。

對應(yīng)的批數(shù)據(jù)，在Spark內(nèi)核對應(yīng)一個RDD實例，因此，對應(yīng)流數(shù)據(jù)的DStream可以看成是一組RDDS，即RDD的一個序列。通俗點理解的話，在流數(shù)據(jù)分成一批一批后，通過一個先進先出的隊列，然后Spark Enging從該隊列中依次取出一個個批數(shù)據(jù)，把批數(shù)據(jù)封裝成一個個RDD，然后進行處理，這是一個典型的生產(chǎn)者/消費者模型，對應(yīng)的就有生產(chǎn)者消費者模型的問題，即如何協(xié)調(diào)生產(chǎn)速率和消費速率。

離散流（discretized stream）或DStream
這是SparkStraming對內(nèi)部持續(xù)的實時數(shù)據(jù)流的抽象描述，即我們處理的一個實時數(shù)據(jù)流，在Spark Streaming中對應(yīng)于一個DStream實例。

批數(shù)據(jù)（batch data）
這是化整為零的第一步，將實時流數(shù)據(jù)以時間片為單位進行分批，將流處理轉(zhuǎn)化為時間片數(shù)據(jù)的批處理。隨著持續(xù)時間的推移，這些處理結(jié)果就形成了對應(yīng)的結(jié)果數(shù)據(jù)流了。

時間片或批處理時間間隔（batch interval）
這是人為地對數(shù)據(jù)流進行定量的標(biāo)準(zhǔn)，以時間片作為我們拆分?jǐn)?shù)據(jù)流的依據(jù)。一個時間片的數(shù)據(jù)對應(yīng)一個RDD實例。

窗口長度（window length）
一個窗口覆蓋的流數(shù)據(jù)的時間長度。必須是批處理時間間隔的倍數(shù)。

滑動時間間隔
前一個窗口到后一個窗口所經(jīng)過的時間長度。必須是批處理時間間隔的倍數(shù)。

Input DStream
一個input DStream是一個特殊的DStream，將Spark Streaming連接到一個外部數(shù)據(jù)源來讀取數(shù)據(jù)。

Spark Streaming 架構(gòu)

在Spark Streaming中，數(shù)據(jù)處理是按批進行的，而數(shù)據(jù)采集是逐條進行的，因此在Spark Streaming中會事先設(shè)置好批處理間隔（batch duration），當(dāng)超過批處理間隔的時候就會把采集到的數(shù)據(jù)匯總起來稱為一批數(shù)據(jù)交個系統(tǒng)區(qū)處理。

對于窗口操作而言，在其窗口內(nèi)部會有N個批處理數(shù)據(jù)，批處理數(shù)據(jù)的大小由窗口間隔（window duration）決定，而窗口間隔指的就是窗口的持續(xù)時間，在窗口操作中，只有窗口的長度滿足了才會觸發(fā)批處理的處理。除了窗口的長度，窗口操作還有另一個重要的參數(shù)就是滑動間隔（slide duration），它指的是經(jīng)過多長時間窗口滑動一次形成新的窗口，滑動窗口默認(rèn)情況下和批次間隔的相同，而窗口間隔一般設(shè)置的要比它們兩個大。在這里必須注意的一點是滑動間隔和窗口間隔的大小一定得設(shè)置為批處理間隔的整數(shù)倍。

Spark Streaming是一個對實時數(shù)據(jù)流進行高通量、容錯處理的流式處理系統(tǒng)，可以對多種數(shù)據(jù)源（如Kafka、Flume、Zero MQ和TCP套接字）進行類似Map、Reduce和Join等復(fù)雜操作，并將結(jié)果保存到外部文件系統(tǒng)、數(shù)據(jù)庫或應(yīng)用到實時儀表盤。

計算流程

Spark Streaming是將流式計算分解成一系列短小的批處理作業(yè)。這里的批處理引擎是Spark Core，也就是把Spark Streaming的輸入數(shù)據(jù)按照batch size（如1秒）分成一段一段的數(shù)據(jù)（Discretized Stream），每一段數(shù)據(jù)都轉(zhuǎn)換成Spark中的RDD（Resilient Distrbute Dataset），然后將Spark Streaming中對DStream的Transformation操作變?yōu)獒槍park中對RDD的Transformation操作，將RDD經(jīng)過操作變成中間結(jié)果保存在內(nèi)存中。整個流式計算根據(jù)業(yè)務(wù)的需求可以對中間的結(jié)果進行疊加或者存儲到外部設(shè)備。

容錯性

對于流式計算來說，容錯性至關(guān)重要。首先我們要明確一下Spark中RDD的容錯性機制。每一個RDD都是一個不可變的分布式可重算的數(shù)據(jù)集，其記錄著確定性的操作繼承關(guān)系（lineage），所以只要輸入數(shù)據(jù)是可容錯的，那么任意一個RDD的分區(qū)（Partition）出錯或不可用，都是可以利用原始輸入數(shù)據(jù)通過轉(zhuǎn)換操作而重新算出的。

對于Spark Streaming來說，其RDD的傳承關(guān)系如下圖所示，圖中的每一個橢圓形表示一個RDD，橢圓形中的每個圓形代表一個RDD中的一個Partition，圖中的每一列的多個RDD表示一個DStream（圖中有三個DStream），而每一行最后一個RDD則表示每一個Batch Size鎖產(chǎn)生的中間結(jié)果RDD。我們可以看到圖中的每一個RDD都是通過lineage相連接的，由于Spark Streaming輸入數(shù)據(jù)可以來自磁盤，例如HDFS（多份拷貝）或是來自與網(wǎng)絡(luò)的數(shù)據(jù)流（Spark Streaming會將網(wǎng)絡(luò)輸入數(shù)據(jù)的每一個數(shù)據(jù)流拷貝兩份到其他的機器）都能保證容錯性，所以RDD中任意的Partition出錯，都可以并行地在其他機器上將缺失的Partition計算出來。這個容錯恢復(fù)方式比連續(xù)計算模型（如Storm）的效率更高。

實時性

對于實時性的討論，會牽涉到流式處理框架的應(yīng)用場景。Spark Streaming將流式計算分解成多個Spark Job，對于每一段數(shù)據(jù)的處理都會經(jīng)過Spark DAG圖分解以及Spark的任務(wù)集的調(diào)度過程。對于目前版本的Spark Streaming而言，其最小的Batch Size的選取在0.5 ~ 2秒之間（Stom目前最小的延遲在100ms左右），所以Spark Streaming能夠滿足除對實時性要求非常高（如高頻實時交易）之外的所有流式準(zhǔn)實時計算場景。

擴展性與吞吐量

Spark目前在EC2上已經(jīng)能夠線性擴展到100個節(jié)點（每個節(jié)點4Core），可以以數(shù)秒的延遲處理6GB/s的數(shù)據(jù)量（60M records/s），其吞吐量也比流行的Storm高2~5倍，以下是Berkeley利用WordCount和Grep兩個用例所做的測試。

Spark Streaming 持久化

與RDD一樣，DStream同樣也能通過persist()方法將數(shù)據(jù)流存放在內(nèi)存中，默認(rèn)的持久化方法是MEMORY_ONLY_SER，也就是在內(nèi)存中存放數(shù)據(jù)同時序列化的方式，這樣做的好處是遇到需要多次迭代計算的程序時，速度優(yōu)勢十分的明顯。而對于一些基于窗口的操作，如reduceByWindow、reduceByKeyAndWindow，以及基于狀態(tài)的操作，如updateStateByKey，其默認(rèn)的持久化策略就是保存在內(nèi)存中。

對于來自網(wǎng)絡(luò)的數(shù)據(jù)源（Kafka、Flume、sockets等），默認(rèn)的持久化策略是將數(shù)據(jù)保存在兩臺機器上，這也是為了容錯性而設(shè)計的。

另外，對于窗口和有狀態(tài)的操作必須checkpont，通過StreamingContext的checkpoint來指定目錄，通過DStream的checkpoint指定間隔時間，間隔必須是滑動間隔（slide interval）的倍數(shù)。

Spark Streaming 性能優(yōu)化

1，優(yōu)化運行時間

增加并行度 
確保使用整個集群的資源，而不是把任務(wù)集中在幾個特定的節(jié)點上。對于包含shuffle的操作，增加其并行度以確保更為充分的使用集群資源。

減少數(shù)據(jù)序列化，反序列化的負(fù)擔(dān) 
Spark Streaming默認(rèn)將接受到的數(shù)據(jù)序列化后存儲，以減少內(nèi)存的使用。但是序列化和反序列化需要更多的CPU時間，因此更加高效的序列化方式和自定義的序列化接口以更高效的使用CPU。

設(shè)置合理的batch duration（批處理時間）
在Spark Streaming中，Job之間有可能存在依賴關(guān)系，后面的Job必須確保前面的作業(yè)執(zhí)行結(jié)束后才能提交。若前面的Job執(zhí)行的時間超出了批處理時間間隔，那么后面的Job就無法按時提交，這樣就會進一步拖延接下來的Job，造成后續(xù)Job的阻塞。因此設(shè)置一個合理的批處理間隔以確保作業(yè)能夠在這個批處理間隔內(nèi)結(jié)束是必須的。

2，優(yōu)化內(nèi)存使用
控制batch size（批處理間隔內(nèi)的數(shù)據(jù)量）
Spark Streaming會把批處理間隔內(nèi)接收到的所有數(shù)據(jù)存放在Spark內(nèi)部的可用內(nèi)存區(qū)域中，因此必須確保當(dāng)前節(jié)點Spark的可用內(nèi)存中至少能容納這個批處理時間間隔內(nèi)的所有數(shù)據(jù)，否則必須增加新的資源以提高集群的處理能力。

及時清理不再使用的數(shù)據(jù) 
前面講到Spark Streaming會將接受的數(shù)據(jù)應(yīng)及時清理，以確保Spark Streaming有富余的可用內(nèi)存空間。通過設(shè)置合理的spark.cleaner.ttl時長來及時清理超時的無用數(shù)據(jù)，這個參數(shù)需要小心設(shè)置以免后續(xù)操作中所需要的數(shù)據(jù)被超時錯誤處理。

觀察及適當(dāng)調(diào)整GC策略 
GC會影響Job的正常運行，可能延長Job的執(zhí)行時間，引起一系列不可預(yù)料的問題。觀察GC的運行情況，采用不同的GC策略以進一步減小內(nèi)存回收對Job運行的影響。

以上就是大數(shù)據(jù)中Spark Streaming的架構(gòu)及原理是什么，小編相信有部分知識點可能是我們?nèi)粘９ぷ鲿姷交蛴玫降摹ＯＭ隳芡ㄟ^這篇文章學(xué)到更多知識。更多詳情敬請關(guān)注億速云行業(yè)資訊頻道。