增量式Checkpoint實驗(碰到bug沒有搞定)

Applied Sciences發表於2020-10-01

根據[1]:

'''這裡面的核心就是 checkpoint 機制，Flink 使用 checkpoint 機制來進行狀態保證，在 Flink 中 checkpoint 是一個定時觸發的全域性非同步快照，並持久化到持久儲存系統上（通常是分散式檔案系統）。發生故障後，Flink 選擇從最近的一個快照進行恢復。有使用者的作業狀態達到 GB 甚至 TB 級別，對這麼大的作業狀態做一次 checkpoint 會非常耗時，耗資源，因此我們在 Flink 1.3 中引入了增量 checkpoint 機制。

在增量 checkpoint 之前，Flink 的每個 checkpoint 都包含作業的所有狀態。我們在觀察到狀態在 checkpoint 之間的變化並沒有那麼大之後，支援了增量 checkpoint。增量 checkpoint 僅包含上次 checkpoint 和本次 checkpoint 之間狀態的差異（也就是“增量”）。'''

"

從 checkpoint 恢復以及效能

開啟增量 checkpoint 之後，不需要再進行其他額外的配置。如果 Job 異常，Flink 的 JobMaster 會通知所有 task 從上一個成功的 checkpoint 進行恢復，不管是全量 checkpoint 還是增量 checkpoint。每個 TaskManager 會從持久化儲存下載他們需要的狀態檔案。

儘管增量 checkpoint 能減少大狀態下的 checkpoint 時間，但是天下沒有免費的午餐，我們需要在其他方面進行捨棄。增量 checkpoint 可以減少 checkpoint 的總時間，但是也可能導致恢復的時候需要更長的時間。如果叢集的故障頻繁，Flink 的 TaskManager 需要從多個 checkpoint 中下載需要的狀態檔案（這些檔案中包含一些已經被刪除的狀態），作業恢復的整體時間可能比不使用增量 checkpoint 更長。

另外在增量 checkpoint 情況下，我們不能刪除舊 checkpoint 生成的檔案，因為新的 checkpoint 會繼續引用它們，這可能導致需要更多的儲存空間，並且恢復的時候可能消耗更多的頻寬。

關於控制便捷性與效能之間平衡的策略可以參考此文件：

https://ci.apache.org/projects/flink/flink-docs-release-1.9/ops/state/large_state_tuning.html

"

從上面兩段話也可以看出,如果頻繁故障的話,可能並不是適合採用增量check point

 

經過

 

 

步驟內容
①mvn clean scala:compile compile package
②

nc -lk 9999

flink run -c wordcount_increstate /home/appleyuchi/桌面/Flink_Code/flink_state/checkpoint/Scala/target/datastream_api-1.0-SNAPSHOT.jar
Job has been submitted with JobID df6d62a43620f258155b8538ef0ddf1b

 

連續4次故意輸入error來觸發job停止(模擬生產環境中的大資料框架崩潰)

 

before
error
error
error
error
 

③

選擇checkpoints然後複製頁面的中間一行

④flink run -s hdfs://Desktop:9000/tmp/flinkck/df6d62a43620f258155b8538ef0ddf1b/chk-22 -c StateWordCount /home/appleyuchi/桌面/Flink_Code/flink_state/checkpoint/Scala/target/datastream_api-1.0-SNAPSHOT.jar
⑤

在nc -lk 9999中輸入

after

after

after

目前碰到bug:

https://blog.csdn.net/appleyuchi/article/details/108896697

暫時無法解決.

先放著.

 

Reference:

[1]Apache Flink 管理大型狀態之增量 Checkpoint 詳解

相關文章