1. spark steaming概述
在《spark 基礎(chǔ)（上篇）》中诬留，spark streaming是spark體系中的一個(gè)流式處理框架匠题。因此乳蓄，Spark streaming相對(duì)于其他流式處理框架就更有優(yōu)勢(shì)蚊逢，用途更加廣泛，它能夠與spark sql晴及、機(jī)器學(xué)習(xí)以及圖像處理框架無縫連接都办。spark streaming還能夠從多種數(shù)據(jù)源獲得數(shù)據(jù)，同時(shí)虑稼，能夠輸出到多種不同的數(shù)據(jù)平臺(tái)中琳钉，包括文件系統(tǒng)、數(shù)據(jù)庫和實(shí)時(shí)數(shù)據(jù)展示平臺(tái)dashboards蛛倦。spark streaming的流處理框架如下圖1所示：
詳細(xì)的處理流程如下圖2所示歌懒，spark streaming接收實(shí)時(shí)數(shù)據(jù)流輸入的數(shù)據(jù)流后，再將其劃分為一個(gè)個(gè)batch（小批次數(shù)據(jù)流）供后續(xù)Spark engine處理溯壶，所以實(shí)際上及皂，Spark Streaming是按一個(gè)個(gè)batch（小批次）來處理數(shù)據(jù)流的。
說到spark streaming就不得不提Dstream且改，Dstream是spark中繼spark core的RDD验烧、spark sql的DataFrame和DataSet后有一基礎(chǔ)的數(shù)據(jù)類型，是spark streaming特有的數(shù)據(jù)類型又跛。DStream代表了一系列連續(xù)的RDD噪窘，DStream中每個(gè)RDD包含特定時(shí)間間隔的數(shù)據(jù)，存儲(chǔ)方式為HashMap<Time,RDD>。其中倔监，Time為時(shí)間序列，而RDD我們都很熟悉菌仁，它是spark core的基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)浩习。Dstream的結(jié)構(gòu)如下圖3所示：
對(duì)連續(xù)不斷的streaming data流的多次切片，就會(huì)將流分成多個(gè)batch济丘，單個(gè)batch內(nèi)有一套針對(duì)多個(gè)Dstream的處理邏輯谱秽，每個(gè)batch的處理邏輯相同。這個(gè)處理邏輯相當(dāng)于spark core對(duì)RDD的處理邏輯摹迷。針對(duì)RDD的處理中疟赊，DAGScheduler將DAGGraph按照寬窄依賴劃分stage。每個(gè)batch內(nèi)部也存在DstreamGraph峡碉，對(duì)Dstream的處理也類似于對(duì)RDD的處理近哟。例如下圖4所示，針對(duì)一段代碼鲫寄，在單個(gè)batch內(nèi)部也會(huì)生成DstreamGraph和Dstream依賴吉执。
針對(duì)一個(gè)spark streaming的處理流中的多個(gè)batch，處理邏輯如下圖5所示地来。圖中用虛線將左側(cè)的streaming data流分成三個(gè)batch戳玫，每個(gè)batch的處理邏輯如右側(cè)所示。
2. spark streaming工作原理
根據(jù)如上圖5分析可知未斑，spark streaming的大致工作流程如下：
首先咕宿，需要一個(gè)DAG的靜態(tài)模板來定義batch內(nèi)的執(zhí)行邏輯。
其次蜡秽，如上圖2所示府阀，針對(duì)實(shí)時(shí)的數(shù)據(jù)流來說， 還需要有控制器载城，不間斷地將數(shù)據(jù)流分成多個(gè)batch肌似，同時(shí)在每個(gè)batch內(nèi)部應(yīng)用DAG靜態(tài)模板執(zhí)行處理邏輯。
再次诉瓦，要生成DStream川队，并不能像一般的數(shù)據(jù)源那樣從存儲(chǔ)介質(zhì)中去讀取，而是要從多種數(shù)據(jù)推送過來的數(shù)據(jù)睬澡，包括kafka固额、flume以及twitter等等。
最后煞聪，由于流式處理要不斷地循環(huán)執(zhí)行斗躏，保障任務(wù)的穩(wěn)定性就顯得尤其重要了。
因此昔脯，針對(duì)上述四種需要啄糙，spark streaming的整體執(zhí)行流程就是圍繞上述四個(gè)需求而設(shè)置的笛臣，其總體工作流程如下圖6所示。如圖中腳注隧饼，橙色部分顯示DAG的靜態(tài)定義部分沈堡，淡藍(lán)色為控制器部分，負(fù)責(zé)流的拆分燕雁，同時(shí)執(zhí)行橙色部分定義的靜態(tài)模板诞丽。綠色部分顯示了driver和executor的數(shù)據(jù)接收部分，最后的紫色部分拐格，顯示了spark streaming中很重要的穩(wěn)定性保障功能僧免，即checkpoint。
下面我們來簡(jiǎn)要介紹下每一部分的主要職責(zé)：
第一部分：如上圖4和圖5所示的步驟生成DstreamGraph和Dstream捏浊。
第二部分：JobScheduler是主要的控制器懂衩，負(fù)責(zé)動(dòng)態(tài)任務(wù)的調(diào)度，包括JobGenerator和ReceiveTracker兩個(gè)主要的成員呛伴。其中勃痴，JobGenerator主要負(fù)責(zé)將data streaming流按照程序中設(shè)置的時(shí)間間隔切分成多個(gè)batch，并按照靜態(tài)的DstreamGraph為以后的每一個(gè)batch生成DstreamGraph热康。而ReceiveTracker則負(fù)責(zé)數(shù)據(jù)流的接收跟蹤和控制沛申，具體的實(shí)現(xiàn)見第三部分。
第三部分：RecevieTracker啟動(dòng)多個(gè)job姐军，并分發(fā)到多個(gè)executor上铁材。Executor啟動(dòng)ReceiverSupervisor，ReceiverSupervisor啟動(dòng)Receiver來接收數(shù)據(jù)奕锌，ReceiverSupervisor接到數(shù)據(jù)后著觉，按塊的形式存儲(chǔ)，并將塊的meta信息上報(bào)給ReceiverTracker惊暴。
第四部分：ReceiverTracker接收到塊的meta信息后交給ReceivedBlockTracker去管理塊信息饼丘。ReceivedBlockTracker 也采用 WAL 冷備方式進(jìn)行備份，在 driver 失效后辽话，由新的 ReceivedBlockTracker 讀取 WAL 并恢復(fù) block 的 meta 信息肄鸽。
第四部分：這部分主要是處于穩(wěn)定性的考慮，設(shè)置的checkpoint機(jī)制油啤。因此典徘，checkpoint需要將整個(gè)處理流程中的關(guān)鍵節(jié)點(diǎn)都做checkpoint，包括DstreamGraph益咬，JobScheduler逮诲，數(shù)據(jù)塊的meta信息以及塊數(shù)據(jù)。
3. 與storm流處理框架對(duì)比
spark作為Apache spark開源框架的一部分，與當(dāng)前流程的storm開源框架相比梅鹦，主要存在以下差別：
1.處理時(shí)效
spark streaming處理的數(shù)據(jù)單位是某個(gè)時(shí)間窗口內(nèi)的數(shù)據(jù)流橡庞，而storm是針對(duì)單條記錄處理的檀头。因此,spark streaming可能存在幾秒鐘的延遲希痴，而storm的延遲能縮短到秒內(nèi)壳猜。
2.容錯(cuò)機(jī)制
spark streaming有較好的容錯(cuò)機(jī)制爱榕，當(dāng)單個(gè)節(jié)點(diǎn)發(fā)生故障后柄粹，它可以跟蹤每批被處理的數(shù)據(jù)流翰蠢，保證每批數(shù)據(jù)只被處理一次堤尾。storm則只能保證單條數(shù)據(jù)處理不會(huì)被遺漏芋绸，而卻允許數(shù)據(jù)有重復(fù)被處理的現(xiàn)象媒殉。
3.運(yùn)行平臺(tái)
spark streaming和storm都可以運(yùn)行在自己的集群上，spark streaming能同時(shí)運(yùn)行在Yarn和Mesos集群上摔敛，而storm只能運(yùn)行在Mesos上廷蓉。
