Flink 負責時間，Iceberg 負責記憶：Pinterest 如何最終確認數據分區？

作者 ｜ Leela Kumili

譯者 ｜ 田橙

Pinterest 為下一代數據庫攝取框架引入了 基於事件時間的分區最終確認機制，讓下游任務能夠判斷流式數據何時已經足夠完整，可以安全消費。該方案使用 Apache Flink 衡量事件時間的推進情況，並通過 Apache Iceberg 元數據發佈一個不會回退的最終確認水位線，解決持續變更數據捕獲（CDC）攝取中的一個難題：即使某個分區對應的自然時間區間已經結束，數據仍可能延迟到達。

Pinterest 的攝取框架使用 CDC、Kafka、Flink、Spark 和 Iceberg，將 MySQL、TiDB 和 KVStore 中的數據庫變更寫入分析表。Pinterest 表示，該平臺支持 PB 級數據和數千條流水線，線上變更通常可以在 15 分鍾到一小時內供分析使用。在此前基於批處理的方案中，任務完成意味着分區已經就緒；而流式攝取會持續提交變更，不存在與之對應的明確完成點。

Pinterest 架構：Kafka CDC 事件經過 Flink 流入 CDC Iceberg 表

Google 架構師 Nitesh Singhal 在 LinkedIn 帖子中介紹了這一設計，並 寫道：

其中最巧妙的部分，是這個不會回退的安全讀取水位線。

新機制運行在 Flink 到 Iceberg 的 Sink 內部。系統會從每條 CDC 記錄中提取一個預先配置的事件時間。在 Flink 執行檢查點時，系統會收集事件時間的最小值、最大值和百分位數統計信息。這些數據會存儲在 Iceberg 的快照摘要中，同時使用 t-digest 將事件時間分佈壓縮到幾百字節。

Iceberg 完成提交后，系統會根據近期檢查點統計信息計算分區最終確認水位線。默認策略會取可配置數量的近期提交中的最小事件時間，並向下取整到對應小時。該水位線單調遞增，可以防止延迟到達的記錄使已經發布的值向后回退。基於百分位數的策略則可以犧牲一部分完整性，換取更新鮮的數據。

Pinterest 表示，該水位線以 Iceberg 表屬性的形式存儲，因此下游傳感器無需單獨的協調服務即可讀取。Spark 在執行 CDC 更新插入提交時，也會將這些元數據傳播到基礎表。Pinterest 強調：

最終確認不再是任務結束所帶來的副產品。

該設計建立在 Flink 和 Iceberg 的現有能力之上。Flink 水位線用於追蹤亂序數據流中的事件時間進度，Iceberg 快照則提供持久化的表元數據。Pinterest 將兩者結合起來，推導出特定於數據表的完整性信號，並將其與數據存儲在一起。

時間線展示了延迟到達的 CDC 事件、Flink 檢查點、事件時間進度，以及單調遞增的最終確認水位線。

Salesforce 工程師 Tharun Kumar Reddy Polu 在 LinkedIn 評論中指出了流處理與批處理之間的權衡，並 寫道：

這項設計之所以令人信服，正是因為它準確呈現了流處理與批處理之間的取捨。既獲得數據新鮮度，又不丟失批處理曾經提供的保證，這纔是核心難題。

Pinterest 利用 Flink-to-Iceberg Sink 中的擴展點實現了這一機制。累加器負責收集記錄統計信息，提交處理器則圍繞 Iceberg 提交執行最終確認邏輯。另外，Apache Iceberg 的一項議題 正在討論如何擴展 IcebergSink，以支持下游集成，其中包括水位線信息等自定義可提交元數據。