第3課：經過案例對SparkStreaming 透徹理解三板斧之三：解密SparkStreaming

第3課：經過案例對SparkStreaming 透徹理解三板斧之三：解密SparkStreaming

    一、DT大數據夢工廠微信公衆號DT_Spark

    二、IMF晚8點大數據實戰YY直播頻道號：68917580

    三、新浪微博：http://www.weibo.com/ilovepains

內容：

1，解密Spark Streaming Job架構和運行機制

 先經過運行在線單詞統計這個例子，觀察Spark Streaming在控制檯上輸出的日誌信息。

如下代碼爲在9999端口監聽客戶端鏈接請求，而後不斷向客戶端發送單詞。

先啓動SocketServer，而後在啓動SparkStreaming在線統計單詞的程序，代碼以下

運行過程總結以下

1，StreamingContext啓動後會ReceiverTracker，根據建立時指定的batchDuration時間，啓動RecurringTimer定時器，間隔Interval發送JobGenerator消息，會啓動JobGenerator和JobScheduler和BlockGenerator。

2，ReceiverTracker接收到Receiver(Stream 0)的註冊消息，而後RecevierSupervisorImpl啓動Receiver來接收數據。

3，SocketServer鏈接到localhost:9999開始接收數據，將接收到的數據經過BlockGenerator存放到BlockManager中。

4，JobScheduler接收到按期發送的JobGenerator消息後，提交一個Job，DStreamGraph從ReceiverTracker中獲取數據生成RDD，DAGScheduler調度Job的執行，讓TaskSchedulerImpl向Executor發送TaskSet，讓Executor執行。

5，Task運行完後將結果發送給Driver，DAGScheduler和JbScheduler打印Job完成和耗時信息，最後在控制檯輸出單詞統計結果。

 

能夠看到隨着時間的流逝會有不斷的Job生成而且運行，那麼，Spark Streaming中Job是如何生成的？

在StreamingContext調用start方法的內部實際上是會啓動JobScheduler的start方法，進行消息循環，在JobScheduler的start內部會構造JobGenerator和ReceiverTracker，而且調用JobGenerator和ReceiverTracker的start方法

    1，JobGenerator啓動後不斷的根據batchDuration生成一個個的Job

    2，ReceiverTracker啓動後首先在Spark集羣中啓動Receiver(其實在Executor中先啓動ReceiverSupervisor)在Receiver接收到數據後會經過ReceiverSupervisor將數據存儲到Executor的BlockManager中，而且把數據的Metadata信息發送給Driver的ReceiverTracker，在ReceiverTracker內部經過ReceivedBlockTracker來管理接收到的元數據信息

 

每一個BatchInterval會產生一個具體的Job，其實這裏的Job不是SparkCore中的Job，它只是基於DStreamGraph而生成的RDD的DAG而已，從Java角度講，相等於Runnable接口實例，此時要向運行Job須要提交給JobScheduler，在JobScheduler中經過線程池中單獨的線程

來提交Job到集羣運行(實際上是在線程中基於RDD的Action觸發真正的做業的運行)

爲何使用線程池？

1，做業不斷生成，因此爲了提高效率，咱們須要線程池。這和Executor中經過線程池執行Task有殊途同歸之妙

2，有可能設置了Job的FAIR公平調度的方式，這個時候也須要多線程的支持

 

 

2，解密Spark Streaming容錯架構和運行機制

 

容錯分爲Driver級別的容錯和Executor級別的容錯。

 

在Executor級別的容錯具體爲接收數據的安全性和任務執行的安全性。在接收數據安全性方面，一種方式是Spark Streaming接收到數據默認爲MEMORY_AND_DISK_2的方式，在兩臺機器的內存中，若是一臺機器上的Executor掛了，當即切換到另外一臺機器上的Executor，這種方式通常狀況下很是可靠且沒有切換時間。另一種方式是WAL（Write Ahead Log），在數據到來時先經過WAL機制將數據進行日誌記錄，若是有問題則從日誌記錄中恢復，而後再把數據存到Executor中，再進行其餘副本的複製，這種方式對性能有影響。在生產環境中通常使用Kafka存儲，Spark Streaming接收到數據丟失時能夠從Kafka中回放。在任務執行的安全性方面，靠RDD的容錯。

 

在Driver級別的容錯具體爲DAG生成的模板，即DStreamGraph，RecevierTracker中存儲的元數據信息和JobScheduler中存儲的Job進行的進度狀況等信息，只要經過checkpoint就能夠了，每一個Job生成以前進行checkpoint，在Job生成以後再進行checkpoint，若是出錯的話就從checkpoint中恢復。