flink Checkpoint優化

1、設置最小時間間隔

當flink應用開啓Checkpoint功能，並配置Checkpoint時間間隔，應用中就會根據指定的時間間隔週期性地對應用進行Checkpoint操做。默認狀況下Checkpoint操做都是同步進行，也就是說，當前面觸發的Checkpoint動做沒有徹底結束時，以後的Checkpoint操做將不會被觸發。在這種狀況下，若是Checkpoint過程持續的時間超過了配置的時間間隔，就會出現排隊的狀況。若是有很是多的Checkpoint操做在排隊，就會佔用額外的系統資源用於Checkpoint，此時用於任務計算的資源將會減小，進而影響到整個應用的性能和正常執行。

在這種狀況下，若是大狀態數據確實須要很長的時間來進行Checkpoint，那麼只能對Checkpoint的時間間隔進行優化，能夠經過Checkpoint之間的最小間隔參數進行配置，讓Checkpoint之間根據Checkpoint執行速度進行調整，前面的Checkpoint沒有徹底結束，後面的Checkpoint操做也不會觸發。

• streamExecutionEnvironment.getCheckpointConfig().setMinPauseBetweenCheckpoints(milliseconds)

經過最小時間間隔參數配置，能夠下降Checkpoint對系統的性能影響，但須要注意的事，對於很是大的狀態數據，最小時間間隔只能減輕Checkpoint之間的堆積狀況。若是不能有效快速地完成Checkpoint，將會致使系統Checkpoint頻次愈來愈低，當系統出現問題時，沒有及時對狀態數據有效地持久化，可能會致使系統丟失數據。所以，對於很是大的狀態數據而言，應該對Checkpoint過程進行優化和調整，例如採用增量Checkpoint的方法等。

用戶也能夠經過配置CheckpointConfig中setMaxConcurrentCheckpoints()方法設定並行執行的checkpoint數量，這種方法也能有效下降checkpoint堆積的問題，但會提升資源佔用。同時，若是開始了並行checkpoint操做，當用戶以手動方式觸發savepoint的時候，checkpoint操做也將繼續執行，這將影響到savepoint過程當中對狀態數據的持久化

2、預估狀態容量

除了對已經運行的任務進行checkpoint優化，對整個任務須要的狀態數據量進行預估也很是重要，這樣才能選擇合適的checkpoint策略。對任務狀態數據存儲的規劃依賴於以下基本規則：

1.正常狀況下應該儘量留有足夠的資源來應對頻繁的反壓。

2.須要儘量提供給額外的資源，以便在任務出現異常中斷的狀況下處理積壓的數據。這些資源的預估都取決於任務中止過程當中數據的積壓量，以及對任務恢復時間的要求。

3.系統中出現臨時性的反壓沒有太大的問題，可是若是系統中頻繁出現臨時性的反壓，例以下游外部系統臨時性變慢致使數據輸出速率降低，這種狀況就須要考慮給予算子必定的資源

4.部分算子致使下游的算子的負載很是高，下游的算子徹底是取決於上游算子的輸出，所以對相似於窗口算子的估計也將會影響到整個任務的執行，應該儘量給這些算子留有足夠的資源以應對上游算子產生的影響。

3、異步Snapshot

默認狀況下，應用中的checkpoint操做都是同步執行的，在條件容許的狀況下應該儘量地使用異步的snapshot，這樣講大幅度提高checkpoint的性能，尤爲是在很是複雜的流式應用中，如多數據源關聯、co-functions操做或windows操做等，都會有較好的性能改善。

在使用異步快照須要確認應用遵循如下兩點要求：

1.首先必須是flink託管狀態，即便用flink內部提供的託管狀態所對應的數據結構，例如經常使用的有ValueState、ListState、ReducingState等類型狀態。

2.StateBackend必須支持異步快照，在flink1.2的版本以前，只有RocksDB完整地支持異步的Snapshot操做，從flink1.3版本之後能夠在heap-based StateBackend中支持異步快照功能

四.壓縮狀態數據

flink中提供了針對checkpoint和savepoint的數據進行壓縮的方法，目前flink僅支持經過用snappy壓縮算法對狀態數據進行壓縮，在將來的版本中flink將支持其餘壓縮算法。在壓縮過程當中，flink的壓縮算法支持key-group層面壓縮，也就是不一樣的key-group分別被壓縮成不一樣的部分，所以解壓縮過程能夠併發執行，這對大規模數據的壓縮和解壓縮帶來很是高的性能提高和較強的可擴展性。flink中使用的壓縮算法在ExecutionConfig中進行指定，經過將setUseSnapshotCompression方法中的值設定爲true便可。

五.觀察checkpoint延遲時間

checkpoint延遲啓動時間並不會直接暴露在客戶端中，而是須要經過如下公式計算得出。若是改時間過長，則代表算子在進行barrier對齊，等待上游的算子將數據寫入到當前算子中，說明系統正處於一個反壓狀態下。checkpoint延遲時間能夠經過整個端到端的計算時間減去異步持續的時間和同步持續的時間得出。