本講內容：
a. ReceiverBlockTracker容錯安全性
b. DStreamGraph和JobGenerator容錯安全性
注：本講內容基於Spark 1.6.1版本（在2016年5月來說是Spark最新版本）講解。
上節回顧
上一講中，我們從安全角度來講解Spark Streaming，由於Spark Streaming會不斷的接收數據、不斷的產生job、不斷的提交job。所以數據的安全性至關重要。
首先我們來談談，對於數據安全性的考慮：
a. Spark Streaming是基於Spark Core之上的，如果能夠確保數據安全可好的話，在Spark Streaming生成Job的時候裏面是基於RDD，即使運行的時候出現問題，那麼Spark Streaming也可以藉助Spark Core的容錯機制自動容錯
b. 對於executor的安全容錯主要是數據的安全容錯。Executor計算時候的安全容錯是藉助Spark core的RDD的，所以天然是安全的
那麼Executor容錯方式是什麼呢？
a. 最簡單的容錯是副本方式，基於底層BlockManager副本容錯，也是默認的容錯方式
b. 接收到數據之後不做副本，支持數據重放，所謂重放就是支持反覆讀取數據
開講
本講我們從Spark Streaming源碼解讀Driver容錯安全性：那麼什麼是Driver容錯安全性呢？
a. 從數據層面：ReceivedBlockTracker爲整個Spark Streaming應用程序記錄元數據信息
b. 從調度層面：DStreamGraph和JobGenerator是Spark Streaming調度的核心，記錄當前調度到哪一進度，和業務有關
c. 從運行角度: 作業生存層面，JobGenerator是Job調度層面
談Driver容錯性我們需要考慮Driver中有那些需要維持狀態的運行
a. ReceivedBlockTracker跟蹤了數據，因此需要容錯。通過WAL方式容錯
b. DStreamGraph表達了依賴關係，恢復狀態的時候需要根據DStream恢復計算邏輯級別的依賴關係。通過checkpoint方式容錯
c. JobGenerator表面是基於ReceiverBlockTracker中的數據，以及DStream構成的依賴關係不斷的產生Job的過程。也可以這麼理解這個過程中消費了那些數據，並且跟蹤進行到了一個怎樣的程度
具體分析如下圖：
ReceivedBlockTracker
ReceivedBlockTracker會管理Spark Streaming運行過程中所有的數據。並且把數據分配給需要的batches，所有的動作都會被WAL寫入到Log中，Driver失敗的話，就可以根據歷史恢復tracker狀態，在ReceivedBlockTracker創建的時候，使用checkpoint保存歷史目錄
下面我們就走進Receiver，解密在收到數據之後，有事怎麼處理的？
Receiver接收到數據，把元數據信息彙報上來，然後通過ReceiverSupervisorImpl就將數據彙報上來，就直接通過WAL進行容錯
當Receiver的管理者，ReceiverSupervisorImpl把元數據信息彙報給Driver的時候，正在處理是交給ReceiverBlockTracker. ReceiverBlockTracker將數據寫進WAL文件中，然後纔會寫進內存中，被當前的Spark Streaming程序的調度器使用的，也就是JobGenerator使用的。JobGenerator不可能直接使用WAL。WAL的數據在磁盤中，這裏JobGenerator使用的內存中緩存的數據結構
ReceiverBlockTracker.addBlock源碼
此時的數據結構就是streamIdToUnallocatedBlockQueues，Driver端接收到的數據保存在streamIdToUnallocatedBlockQueues中
allocateBlocksToBatch把接收到的數據但是沒有分配，分配給batch，根據streamId取出Block，由此就知道Spark Streaming處理數據的時候可以有不同的batchTime（batchTime是上一個Job分配完數據之後，開始再接收到的數據的時間）
timeToAllocatedBlocks可以有很多的時間窗口的Blocks，也就是Batch Duractions的Blocks。這裏面就維護了很多Batch Duractions分配的數據
根據streamId獲取Block信息
cleanupOldBatches：因爲時間的推移會不斷的生成RDD，RDD會不斷的處理數據，
因此不可能一直保存歷史數據
writeToLog源碼
總結：
WAL對數據的管理包括數據的生成，數據的銷燬和消費。上述在操作之後都要先寫入到WAL的文件中
JobGenerator
Checkpoint會有時間間隔Batch Duractions，Batch執行前和執行後都會進行checkpoint
doCheckpoint被調用的前後流程
generateJobs源碼
processEvent接收到消息
對當前的狀態進行Checkpoint
DStream中的updateCheckpointData源碼（最終導致RDD的Checkpoint）
doCheckpoint中的shouldCheckpoint是狀態變量
JobGenerator容錯安全性
總結
a. ReceivedBlockTracker是通過WAL方式來進行數據容錯的。
b. DStreamGraph和JobGenerator是通過checkpoint方式來進行數據容錯的。
