Flink狀態一致性檢查點
一致性檢查點：是指在某一個時刻所有算子將同一個任務都完成的情況下進行的一個快照（方便后續計算出錯時，提供一個資料恢復的快照），Flink有狀態的流處理，內部每個算子任務都可以有自己的狀態，對于流處理器內部來說，所謂的狀態一致性，其實就是我們所說的計算結果要保證準確，
1、Spark & Flink 的CheckPoint
–
Spark的CheckPoint也容錯機制，對RDD的狀態進行保存切斷血緣關系，而Spark在map->reduce程序中寬窄依賴劃分出的stage會又臨時中間結果，所以我們可以拿此中間結果進行CP,這樣就實作了Spark的容錯機制，即便后面計算出現錯誤也可以通過CP重新計算，
–Flink的CheckPoint也是容錯機制（是狀態一致性檢查點），因為Flink的算子大部分都是有狀態的，所以在某個時刻所有算子都完成了同一個任務時，進行一個快照，此時則是一個CheckPoint,其中涉及到了一個barrier（柵欄）的概念來實作快照時資料的混亂以及系統的暫停，
一個完整的快照包含=Source狀態+算子狀態+Sink事務/兩次提交機制
2、單資料源快照流程
流程：
— 圖1：首先由圖看出資料源此時狀態是資料4，此時由JobManager發送柵欄到資料中，隨資料流動（特殊的一條資料），當柵欄到達source時則保存source的狀態到存盤系統中（HDFS、DB等），
— 圖2：柵欄經過Source之后準備進入SUM_even和SUM_odd兩個算子，此處柵欄到達到算子，則對算子保存當前狀態到存盤器中，
— 圖3：算子狀態保存完畢，柵欄則回傳給JobManager，此時JobManager形成映射圖，并保存CheckPoint ID (柵欄ID）
Sink對外輸出資料，也需要控制其發送的情況，保證狀態一致性，其中包含兩個策略：① 事務輸入 ② 兩次提交策略
3、并行資料源快照 流程
由圖可知兩個資料源并行發送資料
流程：
– 圖一 、也是JM發送我們的柵欄，當柵欄到達我們的Source時，對狀態進行保存，也就是狀態4，3.
– 圖二、我們的柵欄跟隨資料流向算子，算子SUM_even需要接收到Source1的柵欄和Source2的柵欄都接受到后，才能對自己本身狀態進行一個保存，如圖二，算子狀態分別為8，8，
– 圖三、表現得是一種特殊情況，就是當我們的Source1的柵欄已經到達算子，但我們的Source2的柵欄處理慢，此時Source1發出資料5，導致資料5到Source2的柵欄前面，一旦算子5處理后在進行保存狀態，會導致算子的狀態不一致，故此會將資料5放入快取區中，等我們的算子接收到Source2的柵欄保存完狀態后在進行處理資料，（算子與算子之間保存狀態不需要等待，在多個資料源的情況下，算子需要等待每個資料源的快照到達，才能對狀態保存）
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/438669.html
標籤：其他
上一篇：kafka手動調整磁區副本數