Apache Flink：完整檢查點 vs 增量檢查點

Apache Flink 是一個即時數據流處理引擎。大多數流處理應用程序都是“有狀態”的。這意味著狀態被存儲並用於進一步處理。在 Apache Flink 中，狀態是通過配置的狀態後端來管理的。Flink 支持兩種生產中的狀態後端。一種是 HashMapStateBackend，另一種是 EmbeddedRocksDBStateBackend。

為了防止數據丟失並實現容錯性，Flink 可以將狀態的快照持久化到可靠的存儲中。Flink 可以配置為將整個狀態快照到可靠位置或自上次快照以來的增量快照。前者稱為完整檢查點，後者稱為增量檢查點。

在本文中，我們將比較帶有完整檢查點的 HashMapStateBackend 和帶有增量檢查點的 EmbeddedRocksDBStateBackend。本文假設讀者對Apache Flink具有工作知識或理論知識。

Flink 狀態後端概述

要理解 Flink 狀態後端，重要的是要了解在途狀態和狀態快照之間的區別。

在途狀態被稱為 Flink 的工作狀態，並存儲在本地。根據狀態後端配置，它可能位於堆內存或堆外存儲器中，並可能溢出到本地磁盤。

另一方面，狀態快照（檢查點或保存點）存儲在持久的遠程位置。這些快照用於在作業失敗時重建 Flink 作業狀態。

如果作業失敗，正在進行的狀態可能會丟失。如果作業中啟用了檢查點，則這不會影響作業恢復。當配置檢查點時，狀態將從持久存儲中檢索以進行恢復。

在生產環境中選擇哪種狀態後端取決於應用對吞吐量、延遲和可擴展性的需求。

Apache Flink 在生產環境中支持兩種狀態後端。

1. HashMapStateBackend

這是 Flink 中用於管理流處理期間的 Keyed State 和 Operator State 的輕量級狀態後端。狀態存儲在使用 HashMap 數據結構的 Java Heap 中。由於它存儲在內存中，這裡的主要限制是最大狀態大小受限於 Java Heap 大小。寫入狀態或從狀態讀取時不涉及序列化。因此，這適用於低延遲、高吞吐量和狀態不是很大的應用程序。

2. EmbeddedRocksDBStateBackend

此狀態後端將在內存中的RocksDB數據庫中存儲在飛數據。默認情況下，RocksDB將數據存儲在任務管理器的本地磁盤中。數據被序列化並存儲在非堆內存中，並溢出到與任務管理器相連的本地磁盤。序列化格式取決於應用程序中配置的類型序列化器。

使用此狀態後端，可以存儲的狀態量僅受限於與任務管理器相連的磁盤空間。如果應用程序具有龐大的狀態且無法包含在堆內存中，這是正確的狀態後端。由於涉及序列化，與HashMapStateBackend相比，應用程序的延遲會更高，吞吐量會更低。

快照狀態概述

快照代表Flink作業的全局狀態。這包括每個數據源的指針以及在處理到這些指針來自數據源的所有Flink有狀態運算符之後的狀態。Apache Flink中的檢查點是通過定期將狀態保存到耐用的遠程存儲來實現容錯的機制。

在作業失敗的情況下，Flink會從耐用的遠程存儲中檢索存儲的狀態，並從中斷點處開始處理流式數據。Flink使用異步屏障快照。這是Chandy-Lamport算法的一種變體。

Flink支持兩種類型的檢查點。

1. 完整檢查點

完整的檢查點是指將整個 Flink 作業的狀態捕獲並存儲在持久的遠程存儲中。在作業故障的情況下，作業會從之前存儲的狀態中恢復。存儲空間需求和執行檢查點所需的時間完全取決於應用程序狀態。完整的檢查點與 HashMapStateBackend 和 RocksDBStateBackend 一起使用。

2. 增量檢查點

增量檢查點是一種優化的方法。 Flink 不再對整個狀態進行快照，而是僅保存自上次檢查點以來對狀態進行的“增量”。這減少了網絡開銷，從而縮短了檢查點的時間。在這種情況下，檢查點是完全異步進行的。

只有 RocksDBStateBackend 支持增量檢查點。 Flink 利用 RocksDB 的內部機制來實現這一點。儘管檢查點所需的時間比完整檢查點少，但在作業故障的情況下，恢復時間取決於許多因素。如果網絡成為瓶頸，恢復時間可能會高於從完整檢查點恢復。

分析

管道詳情：Apache Beam 管道運行在具有固定窗口為 10 分鐘的 Flink 引擎上，並且配置了每 3 分鐘運行一次檢查點。配置的序列化類型是 AVRO。

• 集群類型：”m5dn.4xlarge”
• 最終檢查點存儲：S3
• 唯一鍵數量：2K

如您可以從上述實驗中看到，增量檢查點的持續時間減少。這對應用程式的性能非常有幫助。 

摘要

以下是實驗的摘要。