作者：雷顏菲、夏瑞、俞航翔、梅源 ｜阿里雲 Flink 儲存引擎團隊
摘要：我們在 Flink 1.15 新功能架構解析：高效穩定的通用增量 Checkpoint [1] 一文介紹了通用增量 Checkpoint 的原理和背後的思考以及執行效能、空間放大等方面的初步測試結果。該功能在 Flink 1.16 中經過最佳化，已達到生產可用狀態。本文將從理論和實驗兩個部分詳細論述通用增量 Checkpoint 的收益與開銷，並分析其適用場景。
在進行詳細的效能分析之前，我們簡單回顧一下通用增量 Checkpoint 的設計思考。Flink Checkpoint 過程包括同步刷盤和非同步上傳檔案兩個部分，一個運算元的 Checkpoint 需要運算元的所有併發完成非同步過程並確認成功後才算完成。因此，在大規模作業中，Checkpoint 非同步耗時通常是影響 Checkpoint 穩定性和延遲的瓶頸點。非同步上傳檔案耗時部分有兩個不確定性因素：
1. 非同步上傳的檔案大小依賴於狀態儲存的具體實現
2. 非同步過程需要等到同步過程結束才能開始
第一個問題，以 RocksDB 為例，雖然 Flink 對 RocksDB 也支援增量 Checkpoint，但是非同步上傳檔案的資料量會受到 RocksDB Compaction 影響，因為在 Compaction 發生後可能會導致大量相對較大的新檔案需要重新上傳。目前，RocksDB Compaction 觸發不具有確定性，大規模作業在每次 Checkpoint 時，會經常出現部分節點非同步耗時過長而影響 Checkpoint 的完成速度。第二個問題，是因為在原先的 Checkpoint 架構下，同步快照結束前是沒法準備好需要上傳的檔案的，因此非同步過程需要等到同步過程結束後才能開始。這種情況下，兩個 Checkpoint 間隔之間很大一部分時間佔比就被浪費了。如果需要上傳的狀態比較大，會在很短時間內對 CPU 和網路產生較大的壓力。通用增量 Checkpoint 透過引入 State Changelog（狀態變化日誌）實現了在架構上 Checkpoint 執行過程與狀態儲存快照的解耦，很好的解決了上述兩個問題。在新架構下，狀態更新不僅會更新狀態表，而且會記錄狀態的變化日誌。狀態表會週期性持久化到遠端儲存，稱為物化過程（Materialization）。這個過長通常週期比較長（比如 10 分鐘），並獨立於 Flink 引擎的 Checkpoint 過程。另一方面，狀態的變化日誌也會持續上傳到遠端持久儲存，並且在執行 Checkpoint 時 Flush 剩餘全部日誌 [1]。這樣的設計就比較好的解決了前面提到的兩個問題：透過將 Checkpoint 過程和物化過程解耦，可以讓非同步上傳的檔案大小變得穩定；同時因為狀態變化更新是持續的，所以我們可以在觸發 Checkpoint 之前就一直持續的上傳增量的更新日誌，所以在 Flush 以後我們實際需要上傳的資料量就變得很小。因此，使用通用增量 Checkpoint 可以更穩定快速地完成 Checkpoint；從而達到更穩定更低的端到端延遲、更少的資料回追和更平穩的資源消耗；與此同時在開銷方面，通用增量 Checkpoint 帶來的極限效能下降幾乎可以忽略，所帶來的額外資源消耗也是可預估並且可控的。本文將從這幾個方面詳細分析通用增量 Checkpoint 的優勢和代價，並分享相應的實驗結論。2.1 更穩定更低的端到端延遲
端到端延遲是 Flink 流處理系統非常重要的效能指標。端到端延遲是指開始處理輸入資料到輸出該資料產生的結果所需的時間，而更低的端到端延遲則意味著下游系統可以更快的得到更新結果。Flink 基於 Checkpoint 機制可以提供 Exactly-once 語義保障，當 Source 支援重放、Sink 支援事務後，可以進一步提供端到端的 Exactly-once 語義保障。如圖 1 所示，Checkpoint 完成後，事務型 Sink 才可以更新提交位點。因此，Checkpoint 執行的速度越快、間隔越短，事務型 Sink 就可以更頻繁地提交，從而為作業提供更低的端到端延遲。圖 1：事務型 Sink 的端到端延遲示意圖
通用增量 Checkpoint 可以帶來更穩定更低的端到端延遲。如前所述，通用增量 Checkpoint 機制透過將狀態儲存快照與 Flink 引擎 Checkpoint 執行過程解耦，可以解決不同狀態儲存實現（例如 RocksDB Compaction）在 Checkpoint 期間非同步狀態上傳量對 Checkpoint 非同步耗時的影響。同時因為可以持續上傳 State Changelog，極大降低了 Checkpoint 觸發後需要上傳的資料量，Checkpoint 觸發後只需要上傳少量增量日誌即可，從而大幅提升了 Checkpoint 完成的穩定性和速度，降低作業端到端延遲，並且讓延遲穩定在一定範圍內。2.2 更少的資料回追
在沒有使用 Exactly-once Sink 的情況下，資料回追會導致重複輸出。如果下游不支援完全去重，會在一定程度上影響資料正確性。因此，如何保證流計算系統在故障恢復後回追更少的資料，儘快恢復到故障前的狀態是流計算系統設計需要考慮的問題。Flink 在從故障恢復時，首先會定位到最新的完整可用的 Checkpoint，每個運算元節點基於這個 Checkpoint 重建本地狀態後，從該 Checkpoint 保留的輸入位點開始回追資料。需要回追的資料越少，資料重複輸出也少，恢復也越快。
圖 2：以 RocksDB 狀態儲存為例，作業失敗後，資料回追示意圖（Checkpoint 簡寫為 CHK）。
通用增量 Checkpoint 可以減少作業恢復時的重放資料量。如圖 2 所示，資料回追量是作業失敗時間點到最近一次 Checkpoint 位點的資料量。由於通用增量 Checkpoint 可以加快 Checkpoint 的完成速度，因此可以將 Checkpoint 做得更高頻，需要回追的資料也會變得更少，減少資料重複輸出，加快恢復。這對於對資料重複度有較高要求的業務來說是很關鍵的提升。
2.3 更平穩的資源消耗
Flink 快照過程會引起 Flink 作業 CPU 和網路資源使用出現尖刺，這點對資源量消耗多的大狀態作業尤為明顯。我們仍以 RocksDB 作為狀態儲存為例，Flink Checkpoint 過程會間接地觸發 RocksDB Compaction 的執行條件，使 CPU 使用量在短時間內激增，形成尖刺（Compaction 是 RocksDB 狀態儲存主要的 CPU 消耗來源之一）。另外，Checkpoint 觸發快照製作之後，作業中全部運算元併發的狀態儲存會集中在這個時間段內向遠端儲存上傳資料，導致網路資源使用量在短時間內也出現激增，很容易達到網路頻寬上限。如圖 3 所示，Checkpoint 觸發之後，所有運算元中的 RocksDB 狀態儲存幾乎同時向遠端儲存上傳狀態。對於大狀態作業來說，CPU 尖刺會使得資源預留估算和實際使用出現較大偏差，影響作業正常執行。雖然現在叢集部署都採用容器化，但出於資源利用率的考慮，很多資源還是會共享的（比如 CPU 和網路），因此 CPU 和網路尖刺會影響叢集內其他作業的正常執行，進一步影響整個叢集的穩定性。圖 3：RocksDB 增量 Checkpoint 的 RocksDB 狀態儲存上傳過程
通用增量 Checkpoint 可以有效降低作業的 CPU 和網路流量的消耗，提升 Checkpoint 穩定性，平滑叢集 CPU 和網路資源使用。一方面，通用增量 Checkpoint 透過將增量狀態變化日誌（State Changelog）持續上傳到遠端持久化儲存，可以將網路流量的消耗均攤在整個 Checkpoint 過程中；另一方面 Checkpoint 過程與儲存後端快照過程解耦可以使得 RocksDB 低頻、錯峰執行物化過程，解決 RocksDB 頻繁執行 Compaction 操作和集中向遠端儲存上傳資料的問題，從而降低 CPU 和網路資源使用量和波動性。如圖 4 所示，不同運算元的 RocksDB 檔案上傳過程均勻打散到物化間隔內，使得 RocksDB 的物化過程可以低頻、錯峰。
圖 4：通用增量 Checkpoint 的 RocksDB 狀態儲存上傳過程
2.4 可控的效能與資源開銷
■ 狀態雙寫對效能影響很小（2～3%）
通用增量 Checkpoint 需要雙寫狀態資料（寫狀態儲存和 State Changelog），因此有額外的效能消耗。如圖 5 所示，通用增量 Checkpoint 引入 Durable Short-term Log（DSTL，短存 Log）管理 State Changelog，狀態變化日誌需要同時寫入狀態儲存和 DSTL 中。實測中，在網路頻寬不是瓶頸的情況下，其對極限吞吐量（作業能達到的最高 TPS）僅有很小（2～3%）的影響。狀態變化日誌以 log append 的形式順序寫入攢批上傳，影響微乎其微。
圖 5：以 RocksDB 狀態儲存為例，通用增量 Checkpoint 狀態雙寫示意圖
儲存空間方面，引入通用增量 Checkpoint 後，Checkpoint 由兩部分組成：狀態儲存的物化部分和 DSTL 中的增量狀態變化日誌。DSTL 在狀態儲存後端完成物化且 Checkpoint 過期（subsume） 後可以刪除 State Changelog 對應的部分。因此理論上來說，在狀態儲存即將完成物化、清理 State Changelog 之前，DSTL 佔用的遠端額外儲存空間最大。在作業穩定執行的情況下，運算元的讀寫模式基本固定，因此可以估算出在一個物化間隔中寫入 DSTL 的 State Changelog 資料規模，並透過引數調整其大小。例如，透過減小物化間隔，可以降低 DSTL 佔用遠端儲存的最大值。如圖 6 所示，在相鄰的兩個物化觸發點之間，Checkpoint 中狀態儲存的物化部分保持不變，而 State Changelog 部分持續增加。因此，State Changelog 累積最大值出現在清理 State Changelog 前。圖 6 中，CHK-7 是 MID-1 之後、MID-2 之前的最後一個 Checkpoint，包含了 t₁ 至 t₇ 之間全部的 State Changelog，此時 State Changelog 累積值最大。
圖 6：通用增量 Checkpoint 中，運算元 -1 的全量 Checkpoint 大小變化示意圖
另外值得一提的是遠端儲存的費用佔流式作業計費中的比例很小。以阿里雲 OSS 服務為例，其 1 GB 儲存空間的每月費用是 0.12 RMB 左右 [2] 。單運算元需要的 Checkpoint 儲存規模通常在 10 GB 以內，一個月折算 1.2 RMB，遠低於運算元的計算資源費用。網路流量方面，State Changelog 會有額外的網路流量開銷，但這個部分因為狀態儲存後端快照頻率（物化過程）降低會有一定的抵消，並且一般 Checkpoint 使用的是內網流量，費用幾乎可以忽略不計。得益於 Checkpoint 完成耗時的縮短，作業可以達到更低的端到端延遲，同時回追更少的資料，加快作業恢復；得益於 Checkpoint 完成的更穩定，整個叢集的資源消耗可以更平穩；得益於通用增量 Checkpoint 機制的輕量可控，其對極限吞吐量和空間資源的開銷是我們可以預估且接受的。因此，我們分成六組實驗驗證通用增量 Checkpoint 機制的收益與開銷。3.1 測試環境與配置
測試基於 Flink 1.16 版本，使用 K8s application 部署模式，state backend 選擇 RocksDB（FRocksDB 6.20.3 版本）並開啟 state backend 層面的增量 Checkpoint，遠端儲存使用阿里雲 OSS 標準儲存。Flink TM 和 JM 的配置使用 1 Core 4 GB RAM。測試作業預設併發度為 50。方便起見，下文將通用增量 Checkpoint （General Incremental Checkpoint）簡寫為 GIC。為了測量極致情況下 Checkpoint 完成的速度和穩定性，Checkpoint 間隔設定為 1 秒，從而端到端延遲和失效後的資料回追量可降為秒級。通用增量 Checkpoint 的物化間隔設定為 3 分鐘，該設定與 RocksDB 增量 Checkpoint 的常用 Checkpoint 間隔對齊。測試作業涵蓋了實際應用中常見的兩類有狀態作業，分別是指標聚合型和明細型作業。1. 指標聚合型作業的特徵是包含有聚合函式，例如，min、max、count等。本測試選擇 WordCount 作業作為典型的指標聚合型作業。我們將 WordCount 的單併發狀態規模控制在 500 MB 左右（中等狀態大小），每一個 Word 的長度設定為 200 Bytes（聚合型別作業 Key 的長度）。
2. 明細記錄型作業的特徵是需要儲存一段完整的原始資料流，例如，join、window。本測試選擇 Sliding window 作業（簡寫為 Window）作為典型的明細記錄型作業。我們將 Window 的單併發狀態規模控制在 2 GB 左右，Window 中每一個 record 的大小設定為 100 Bytes。3.2 更快速的 Checkpoint 製作
本實驗使用 Checkpoint 完成數量和完成時間來衡量 Checkpoint 製作速度。從表 1 中可以看到，開啟通用增量 Checkpoint，作業可以更高頻地完成 Checkpoint。在開啟 GIC 之後，WordCount 作業的 Checkpoint 完成數量提升了 4.23 倍，Sliding Window 作業的 Checkpoint 完成數量提升了近 40 倍。從表 2 中可以看到，開啟通用增量 Checkpoint 可以極大加速 Checkpoint 的完成。WordCount 和 Window 作業的 Checkpoint 平均完成時間分別下降 89.7% 和 98.8%。在狀態規模較大的 Window 測試作業中，開啟 GIC，Checkpoint 完成時間可以從分鐘級降為秒級。表 1：12 小時內成功完成 Checkpoint 數量
| 開啟 GIC | 關閉 GIC
| 增長倍率
|
WordCount
| 18936
| 3621
| 4.23 倍
|
Window
| 11580
| 294
| 38.39 倍 |
表 2：開啟/關閉通用增量 Checkpoint，Checkpoint 完成時間對比
| P50
| P99
| P99.9
|
WordCount
| -89.7% (10.21s -> 1.05s) | -79.5% (16.08s -> 3.30s) | -72.3% (17.76s -> 4.92s)
|
Window
| -98.8% (129.47s -> 1.58s) | -98.8% (383.63s -> 4.47s)
| -98.8% (408.79s -> 4.96s) |
Checkpoint 速度提升的主要原因是快照製作過程中非同步上傳到遠端儲存的資料量大幅降低。從圖 7 和圖 8 中可以看到，開啟通用增量 Checkpoint，增量快照的大小可以降低超過 95%。這是因為 State Changelog 會持續寫入到 DSTL 中。在觸發 Checkpoint 的時候，通用增量 Checkpoint 只需要把當前還未上傳的 State Changelog （小於 5MB）寫入到遠端儲存，因此通用增量 Checkpoint 在 Checkpoint 期間非同步上傳遠端儲存的資料量非常少，大幅提升了 Checkpoint 的製作速度。更快速的 Checkpoint 可以支援更短的 Checkpoint 間隔，從而降低作業執行時的端到端時延。為了保證資料處理的 Exactly-once 語義，事務性 Sink 運算元需要在 Checkpoint 完成之後才可以觸發事務提交。因此，通用增量 Checkpoint 可以將事務性運算元的端到端時延從分鐘級降至秒級。
圖 7：WordCount 執行時增量 Checkpoint 大小
圖 8：Window 執行時增量 Checkpoint 大小
3.3 更穩定的 Checkpoint 製作
本實驗使用 Checkpoint 完成時間的波動範圍來衡量 Checkpoint 製作的穩定性。從圖 9 和 圖 10 中可以看到，開啟通用增量 Checkpoint，Wordcount 和 Window 作業的 Checkpoint 完成時間能夠穩定在 1 - 5 秒內。相反沒有 GIC 時，RocksDB 增量快照的完成時間波動範圍大很多。在 Sliding Window 的情況，波動範圍超過100 秒，極端情況下會超過 400 秒。
圖 9：WordCount 作業 Checkpoint 完成時間
圖 10：Window 作業 Checkpoint 完成時間
Checkpoint 穩定性提升的主要原因是 Checkpoint 執行過程與儲存後端快照解耦。針對本實驗使用的 RocksDB 儲存後端，RocksDB 增量 Checkpoint 依賴於 RocksDB 的快照機制，而 RocksDB 內部的 Compaction 會影響 RocksDB 快照產生的增量快照大小。而 RocksDB Compaction 觸發受到多種因素影響，具有隨機性，這可能會導致 RocksDB 增量快照大小波動範圍很大。在開啟通用增量 Checkpoint 之後，Checkpoint 期間只需上傳增量 State Changelog，有效規避了 RocksDB Compaction 對增量快照製作的負面影響。3.4 更少的資料回追
本測試使用 Window 作業，並使用 Kafka Source 恢復後的業務延時 [3] 來衡量資料回追量。在作業執行時，透過向 Kafka 注入指定的 record，觸發作業失效。如圖 11 所示，開啟通用增量 Checkpoint，資料回追時間從 180 秒減少到 105 秒，減少 41.7%（狀態下載時間由於開啟了 local recovery 可以忽略）。資料回追量下降的主要原因是 Checkpoint 做得更快讓 Checkpoint Interval 可以設得更短。
圖 11：Window 作業中 Kafka Source 的業務延遲
值得一提的是 Source 的延遲和作業恢復速度也有關係，表 3 展示了 Window 作業在恢復中各個階段的 P99 耗時。通用增量 Checkpoint 恢復 State Changelog 需要額外使用 16 秒左右。由於開啟了 local recovery，無需從遠端儲存下載狀態檔案，所以下載部分時間可以忽略。對於 Window 作業，根據 3.2 節中的資料結果，Checkpoint 間隔可以從分鐘級降低到秒級。因此，綜合考慮上述兩個方面，通用增量 Checkpoint 以增加微小的額外恢復時間為代價（16 秒），將重放資料量從分鐘級降到秒級，因此整體上有更快的恢復速度。表 3：Window 作業恢復的各個階段 P99 耗時
| 狀態下載
| RocksDB 恢復
| Changelog Re-apply
|
開啟 GIC
| -
| 0.094 秒
| 16.7 秒
|
關閉 GIC
| -
| 0.129 秒
| - |
3.5 更平穩的資源消耗
本測試使用 WordCount 作業，單併發狀態大小設定在 2GB 左右，對比測試整個作業的 CPU 使用量和網路流量實時變化情況。透過調整 Checkpoint 間隔和通用增量 Checkpoint 的開關設定三個實驗：1. 關閉 GIC，間隔 10min：以 10min 為 Checkpoint 間隔，關閉通用增量 Checkpoint
2. 關閉 GIC，間隔 10s：以 10s 為 Checkpoint 間隔，關閉通用增量 Checkpoint
3. 開啟 GIC，間隔 10s：以 10s 為 Checkpoint 間隔，開啟通用增量 Checkpoint
圖 12：作業的全部 TM CPU 總使用率
圖 13：作業的網路流量
結合圖 14 對比三個實驗在 CPU 和網路流量上的資料，可以發現：1. 關閉 GIC，間隔 10min 的作業，其 CPU 使用率和網路流量有非常明顯的尖峰，每次的峰值資料相比平均值有數十倍的增長，且該波動具有一定週期性。週期性波動主要是由於所有節點在 Checkpoint 同步階段會觸發 RocksDB 強制 Flush，進而可能導致多個併發節點同時 Compaction，造成 CPU 和網路流量明顯增加。這種週期性會影響整個叢集作業的穩定性，也讓叢集資源的估算變得困難，導致資源浪費。2. 關閉 GIC，間隔 10s 的作業，其 CPU 使用率和網路流量的峰值相對關閉 GIC，間隔 10min 的作業下降了 37.8% 和 34.9%，但其均值提升了 128.9% 和 730.2%，且其波動性依然較大。峰值下降是因為 Checkpoint 間隔變短，在一個 Checkpoint 間隔期間消費的資料量也隨之變少，因此每次 Checkpoint 時參與 Compaction 的資料量也變少，要上傳的資料量也隨之變少；均值提升是因為 Compaction 的頻次會隨著 Checkpoint 間隔的減少而增加。
3. 開啟 GIC，間隔 10s 的作業，其 CPU 使用率和網路流量相對另外兩者明顯穩定和減少很多，其峰值相對關閉 GIC，間隔 10min 的作業下降了 62.2% 和 69.4%，相對關閉 GIC，間隔 10s 的作業下降了 39.3% 和53.0%；其均值相對關閉 GIC，間隔 10s 的作業下降了 46.8% 和 67.7%。峰值和均值下降主要來源於 Checkpoint 間隔減少和前文提到的錯峰的物化過程、執行時的持續上傳。
圖 14：三個實驗的峰值/均值對比結果
如 1.3 節所述，通用增量 Checkpoint 透過低頻、錯峰的 Checkpoint 特性，讓叢集的資源使用變得非常平穩。在降低 Checkpoint 間隔的同時開啟通用增量 Checkpoint，可以在降低 Flink 作業的 CPU 和網路流量的消耗的同時，提升 Flink 作業的 CPU 利用率和網路流量的穩定性。對單個作業來說，通用增量 Checkpoint 可以有效降低計算和流量成本，同時在資源受限的雲原生環境下，其更穩定的 CPU 利用率和網路流量也可以讓作業的 TPS 更加穩定；對整個 Flink 叢集來說， 穩定的 CPU 利用率和網路流量也使得作業間的資源競爭更加可控，進一步提升 Flink 叢集的穩定性，同時也更易於估算叢集資源，避免資源浪費。
3.6 微小的極限吞吐量影響
本測試使用 WordCount 作業，加大 Source 的流量，在作業達到反壓的情況下，對比測試不同 Key Length 和 State Size 下開啟/關閉通用增量 Checkpoint 後單個運算元的極限吞吐量。值得注意的是，Flink 1.16 的通用增量 Checkpoint 在序列化上有額外的開銷，經過 FLINK-30345 [4] 的最佳化後，由表 4 可以看到，運算元的極限吞吐量差異穩定在 3% 以內。進一步當開啟 Local Recovery 後，從表 5 中可以看到，運算元的極限吞吐量差異在 5% 以內。因此，開啟通用增量 Checkpoint 後，雙寫（state changelog）和三寫（local recovery）對極限效能的影響都很小，相對其他方面的提升，基本可以忽略不計。表 4：Flink 1.16 最佳化後開啟/關閉通用增量 Checkpoint 後極限吞吐量對比Setup
| 關閉 GIC
| 開啟 GIC
| 開啟 GIC 相比關閉時極限吞吐量下降
|
Key Len
| State Size
|
16
| 30 MB
| 102550
| 101865
| -0.7%
|
128
| 100 MB
| 52086
| 50838
| -2.4%
|
16
| 1.2 GB
| 25865
| 25620
| -0.9%
|
128
| 7.6 GB
| 2550
| 2495
| -2.2%
|
表 5：Flink-1.16 最佳化後開啟 Local Recovery 下開啟/關閉通用增量 Checkpoint 極限吞吐量對比Setup
| 關閉 GIC
| 開啟 GIC
| 開啟 GIC 相比關閉時極限吞吐量下降
|
Key Len
| State Size
|
16
| 30 MB
| 100829 | 98682
| -2.1%
|
128
| 100 MB
| 51125
| 48578
| -4.9%
|
16
| 1.2 GB
| 24898
| 24150
| -3.0%
|
128
| 7.6 GB
| 2434
| 2319
| -4.7% |
3.7 可預估的遠端儲存空間開銷
在開啟通用增量 Checkpoint 後，Flink Checkpoint 包括物化的狀態表部分加上增量的 State Changelog，因此需要額外的遠端儲存空間來儲存 State Changelog。[1]中“Benchmark 測試結果分析”一節有實驗得到的具體資料，這裡我們將從理論入手，根據作業的處理邏輯和引數，對增加的遠端儲存空間進行分析和估算。增加的空間主要來自 State Changelog。前面分析過，在狀態儲存即將完成物化、清理 State Changelog 之前，DSTL 佔用的遠端額外儲存空間最大。因此 DSTL 的最大值近似為相鄰物化之間的 State Changelog 總量，計算公式如下：全量 Checkpoint 增加量最大值 ≈ Changelog 寫操作速率 × 單次寫大小 × 物化間隔
我們使用 Sliding Window 作業驗證上述計算公式，Window 大小和滑動長度的比值設定為 10 和 5。根據 Sliding Window 運算元（Jave Flink 實現 [5] ）的執行邏輯，其全量 Checkpoint 增加量的預估值為：全量 Checkpoint 增加量 ≈ (Window + Timer 寫操作速率) × (Window + Timer 單次寫大小) × 物化間隔
如圖 15 和圖 16 所示，實際作業的全量 Checkpoint 增加量和上述公式計算的預估增量基本一致。同時，可以發現 Window 作業的全量 Checkpoint 增加量具有以下特點：當“Window 大小 / 滑動長度”固定的時候，全量 Checkpoint 增加量基本保持不變。在比例為 10 的情況下，增加量約為 1.74 GB；在比例為 5 的時候，增加量約為 887.4 MB。這是因為“Window 大小 / 滑動長度”決定了公式中的“寫操作速率”，同時，該作業的單次寫大小和物化間隔也是固定的，因此全量 Checkpoint 增加量也是固定的。
圖 15：Window 大小 / 滑動長度 = 10，全量 Checkpoint 大小
圖 16：Window 大小 / 滑動長度 = 5，全量 Checkpoint 大小
全量 Checkpoint 增加使得作業需要使用更多的遠端儲存空間，但在實際中對作業整體計費影響很小。以阿里雲 OSS 服務為例，儲存計費是 0.12 RMB/GB，單運算元需要的 Checkpoint 儲存規模通常在 10 GB 以內，一個月折算 1.2 RMB，遠低於運算元的計算資源費用。開啟通用增量 Checkpoint 可以顯著提高 Checkpoint 的完成速度和穩定性，並以可控的效能與資源開銷為作業提供更低的端到端延遲、更少的資料回追和更平穩的資源消耗。在 Flink 1.16 後，通用增量 Checkpoint 已經達到了生產可用的狀態。後續版本中，在實現機制上，我們將重點關注其他可用的 DSTL 儲存元件，如 Apache Bookkeeper，來實現更短的延遲；在實踐落地上，我們將重點關注與其他技術，如 Unaligned Checkpoint、Buffer Debloating 的結合，打造一整套完整高效穩定的 Checkpoint 流程。參考
[1] Flink 1.15 新功能架構解析：高效穩定的通用增量 Checkpoint:[3] Flink Kafka Source 的業務延遲指標:https://nightlies.apache.org/flink/flink-docs-master/docs/connectors/datastream/kafka/#scope-of-metric#currentEmitEventTimeLag[4] [Flink-30345] Improve the serializer performance of state change of changelog:[5] Sliding Window 運算元的 Java Flink 實現:
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/70024923/viewspace-2939712/，如需轉載，請註明出處，否則將追究法律責任。
