Pinterest 基于 CDC 的攝取系統(tǒng)將數(shù)據(jù)庫延遲從 24 小時縮短至 15 分鐘

作者 | Leela Kumili

譯者 | 平川

Pinterest 推出了新一代數(shù)據(jù)庫攝取框架，旨在突破傳統(tǒng)批處理系統(tǒng)的局限性，提升實時數(shù)據(jù)的可用性。舊有的基礎(chǔ)設(shè)施依賴于多條獨立維護的數(shù)據(jù)管道和全表批處理任務(wù)，導(dǎo)致延遲高、運維復(fù)雜且資源利用率低下。包括數(shù)據(jù)分析、機器學(xué)習(xí)和產(chǎn)品功能在內(nèi)的關(guān)鍵應(yīng)用場景亟需更快、更可靠的數(shù)據(jù)訪問能力。

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

正如 Pinterest 的一位工程師所強調(diào)的那樣：

基于 Change Data Capture（Debezium/TiCDC）、Kafka、Flink、Spark 和 Iceberg 構(gòu)建的統(tǒng)一數(shù)據(jù)庫攝取框架僅處理有變化的記錄，在幾分鐘內(nèi)（而不是幾小時或幾天）就可以提供對在線數(shù)據(jù)庫更改的訪問，顯著節(jié)省了基礎(chǔ)設(shè)施成本。

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

下一代數(shù)據(jù)庫攝取架構(gòu)概述（圖片來源：Pinterest 博客文章）

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

Spark 作業(yè)首先對 CDC 表中的最新更改去重，然后在基表上應(yīng)用更新或刪除。歷史數(shù)據(jù)最初通過引導(dǎo)管道加載，后續(xù)維護作業(yè)負責(zé)處理壓縮和快照過期。

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

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

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

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

聲明：本文由 InfoQ 翻譯，未經(jīng)許可禁止轉(zhuǎn)載。