Pinterest 基于 CDC 的攝取系統將數據庫延遲從 24 小時縮短至 15 分鐘

作者 | Leela Kumili

譯者 | 平川

Pinterest 推出了新一代數據庫攝取框架，旨在突破傳統批處理系統的局限性，提升實時數據的可用性。舊有的基礎設施依賴于多條獨立維護的數據管道和全表批處理任務，導致延遲高、運維復雜且資源利用率低下。包括數據分析、機器學習和產品功能在內的關鍵應用場景亟需更快、更可靠的數據訪問能力。

傳統系統面臨著幾個關鍵的挑戰。數據延遲經常超過 24 小時，拖慢了分析和機器學習工作流程。許多表每日的數據變化量不足 5%，但全表批處理會重復處理未更改的記錄，浪費計算和存儲資源。此外，傳統系統未提供對行級刪除的原生支持，管道之間的操作碎片化導致數據質量不一致且維護開銷高。

正如 Pinterest 的一位工程師所強調的那樣：

基于 Change Data Capture（Debezium/TiCDC）、Kafka、Flink、Spark 和 Iceberg 構建的統一數據庫攝取框架僅處理有變化的記錄，在幾分鐘內（而不是幾小時或幾天）就可以提供對在線數據庫更改的訪問，顯著節省了基礎設施成本。

該框架是一個配置驅動的通用框架，支持 MySQL、TiDB 和 KVStore，便于快速部署，集成了監控且提供至少有一次的送達保證。

下一代數據庫攝取架構概述（圖片來源：Pinterest 博客文章）

該架構將 CDC 表與基表分開。作為只追加賬本，CDC 表記錄每個變更事件的延遲通常低于五分鐘。基表維護完整的歷史快照，每 15 分鐘至 1 小時通過 Spark Merge Into 操作進行更新。Iceberg 的合并操作提供兩種更新策略：寫時復制（COW）和讀時合并（MOR）。寫時復制策略在更新時重寫整個數據文件，增加存儲和計算開銷。讀時合并策略將變更寫入獨立的文件并在讀取時應用，從而降低寫入放大效應。經過評估，Pinterest 最終采用了讀時合并策略，因為在多數工作負載中，寫時復制產生的存儲成本遠超它所帶來的收益。該方案既支持增量更新，又使基礎設施成本在 PB 級數據規模下仍然可控。

Spark 作業首先對 CDC 表中的最新更改去重，然后在基表上應用更新或刪除。歷史數據最初通過引導管道加載，后續維護作業負責處理壓縮和快照過期。

該框架的優化包括：使用 Iceberg 分桶通過主鍵哈希對基表進行分區，允許 Spark 并行化 upsert 操作，以及減少每次操作掃描的數據量。該框架還通過指示 Spark 按分區分布寫入來解決小文件問題，減少了每個任務多個小文件造成的開銷。

測量結果包括將數據可用性延遲從超過 24 小時降低到低至 15 分鐘，避免不必要的全表操作，僅處理每天變化的 5% 的記錄，降低基礎設施成本。該系統可以處理 PB 級規模的數據，跨數千個管道，同時支持增量更新和刪除。

Pinterest 基于 CDC 的攝取框架提供了對數據庫更改的實時訪問，其中，Iceberg 表存儲在 AWS S3 上，Flink-Spark 處理流和批處理工作負載。未來的改進將集中在自動化模式演變上，如何安全地將上游更改傳播到下游，增強大規模管道的可靠性和可維護性。

https://www.infoq.com/news/2026/02/pinterest-cdc-db-ingestion/

聲明：本文由 InfoQ 翻譯，未經許可禁止轉載。