Spark Streaming揭秘 Day13

數據安全容錯(Driver篇)

書接上回，首先我們要考慮的是在Driver層面，有哪些東西需要維持狀態，只有在需要維持狀態的情況下才需要容錯，總的來說，一共有三個組件需要容錯：

• 數據層面:ReceiverBlockTracker,專門負責管理整個SparkStreaming運行數據的元數據，主要用來跟蹤數據，需要狀態。
• 邏輯層面:DStream和DStreamGraph，表達依賴關系，在恢復的時候需要恢復計算邏輯級別的依賴關系。
• 作業生成層面:JobGenerator,表明正在怎么基于RBT和DStreams的關系生成作業，消費了哪些數據，進行到了哪些程度，都需要容錯。

在Driver層面，主要也是采用checkpoint和WAL兩個容錯機制。

ReceiverBlockTracker容錯

ReceiverBlockTracker，會管理SparkStreaming運行過程中的所有數據，指針指向具體數據。所有操作都會保存在WAL中，所以當失敗后可以恢復。

在ReceiverBlockTracker中，核心是如下的兩個數據結構：

• 未分配隊列streamIdToUnallocatedBlockQueues：存儲所有已接收但是還沒有分配給具體Batch的Block，會被具體Receiver調用。
• 已分配隊列timeToAllocatedBlocks：表示已分配的Block，會被JobGenerator調用。需要注意的是，這是個HashMap，所以可以存很多Batch Duration的Blocks，可以支持window或者state操作。

所以，我們可以圍繞數據的三個階段展開：

階段一：addBlock方法主要負責收集數據寫入未分配隊列

我們可以看到，當收到Executor端傳過來的數據，第一步通過writeToLog方法進行元數據的容錯處理。需要注意，在這里并沒有判斷啥調用條件，具體的容錯方式是在writeToLog方法內部判斷的。

階段二：allocateBlocksToBatch方法主要負責將未分配隊列數據寫入已分配隊列

在獲取所有未分配數據的時候，采用dequeue方法，其中隱含的會進行一個union操作，按照streamID(表示不同的輸入數據來源)進行匯總。
同時，在獲取數據后，首先做writeToLog，在成功寫入WAL之后，才會把元數據放入已分配隊列中。

階段三：CleanUpOldBatchs將過期數據進行銷毀

我們可以看到，在實際執行銷毀前，也會調用writeToLog進行災備。

綜上所述，在數據管理層面，數據生成、消費、銷毀的時候都做災備!!!

writeToLog

這是進行容錯的核心方法，方法本身也是比較簡潔的。

首先，會通過isWriteAheadLogEnabled方法進行備份方式在判斷，我們發現，其最終是調用了如下的方法?？梢钥吹狡浜诵木褪鞘褂玫搅薱heckpoint目錄，也就是說備份其實是基于checkpoint機制進行的。

實際備份其實就是以WAL的方法進行文件寫入，writeToLog目前程序出錯時可以recover,但是程序升級時不行，可以通過覆寫代碼，將WAL保存在其他的地方。

總結來說，checkpoint提供了數據的存放位置，而WAL則是具體的數據組織方法。

欲知后事如何，且聽下回分解

DT大數據每天晚上20：00YY頻道現場授課頻道68917580

轉載于:https://www.cnblogs.com/dt-zhw/p/5514949.html

總結

以上是生活随笔為你收集整理的Spark Streaming揭秘 Day13 数据安全容错(Driver篇)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。