Pinterest 在全球擁有超過 4.6 億的月活躍使用者，平台上每一次 Pin 的收藏、搜尋、推薦回饋都會衍生大量的事件資料。要在這樣的規模下維持即時的內容推送與廣告投遞精準度，後端資料平台必須將使用者與內容變更可靠地傳遞到推薦系統、實驗平台以及商業分析環境。Change Data Capture（CDC）正是 Pinterest 近年投入大量資源強化的關鍵環節，2025 年最新版的 CDC 平台聚焦在「低延遲」、「高可見性」與「自動回填」三項能力，確保每一筆資料變動都能在數秒內反映到各個下游應用。
為什麼 Pinterest 要重新打造 CDC 平台？
Pinterest 早期的資料同步主要倚賴批次 ETL（Extract-Transform-Load），即便透過 Airflow 分散排程，仍需要 15～30 分鐘才能將核心 MySQL 叢集的資料搬到分析倉儲。對於需要即時回饋的推薦模型而言，這樣的延遲造成以下痛點：
- 廣告競價延遲：數據更新過慢導致 CPA / ROAS 指標無法即時調整出價。
- 實驗平台訊號落後：A/B 測試收集的事件延遲，讓產品團隊難以快速迭代。
- 資料一致性不透明：批次搬遷容易漏掉刪除或更新記錄，下游只能依賴額外的 reconciliation 任務。
CDC 提供的即時 binlog 解析能力，讓 Pinterest 可以在秒級將 OLTP 的變更同步到 Kafka，再透過多個消費者群組推送到 Flink、Snowflake、Elasticsearch 與向量資料庫等系統。
2025 年 Pinterest CDC 平台的核心元件
新版 CDC 平台採用模組化架構，下列元件扮演關鍵角色：
- Debezium for MySQL / Aurora：Pinterest 將大部分交易資料搬遷到 AWS Aurora MySQL，並以 Debezium 連接器透過 Kafka Connect 解析 binlog。針對高流量表建立 Slot Sharing，避免單一 Connector 遭遇 backpressure。
- Kafka Fleet Manager：為了統一管理多個 Kafka 叢集，Pinterest 建立 Fleet Manager 監控客製化 SLA，包括延遲、lag 以及 message drop rate，並與 PagerDuty 整合形成 on-call 流程。
- Flink 低延遲處理：使用 Flink SQL 將 CDC 事件轉換為 Upsert Stream，提供去重、聚合與側輸出的能力。Flink 任務同時負責觸發「補償性回填（Compaction）」以處理長期離線節點。
- Iceberg + Snowflake 雙儲存策略：CDC 事件最終會寫入 Iceberg 資料湖，供 Data Scientist 建模。部分高查詢量的分析則即時同步到 Snowflake，並啟動 Materialized Views 確保查詢效能。
- Audit & Replay Platform：Pinterest 為了符合 GDPR 與 CCPA 的資料可追蹤要求，建置 Replay Pipeline，透過 Kafka Log Compaction 保存 7 天完整事件，並且能夠重播到任意環境進行調試。
架構流程圖（概念）
- 使用者行為寫入服務 → Aurora MySQL 產生 binlog。
- Debezium Connector 解析 binlog，轉換成 Kafka CDC topic。
- Flink Stream 處理 Topic，負責 schema 演進、欄位過濾與側輸出。
- 透過 Sink 將資料分發到：
- Snowflake：驅動近即時的商業儀表板。
- Elasticsearch：強化搜尋與探索體驗。
- Feature Store / 向量資料庫：支援個人化推薦與 AI 助理。
- S3 + Iceberg：作為歷史快照與資料科學訓練來源。
- Replay 平台監控 lag 指標，必要時啟動 backfill 工作重新同步缺漏資料。
Pinterest CDC 平台的技術亮點
1. Schema Registry 與契約測試
Pinterest 將所有 CDC Topic 的 Schema 註冊在 Confluent Schema Registry，並以 Pact-like 契約測試保證上下游兼容性。當資料庫 schema 變更時，Flink 任務會自動比對 schema 版本，若出現破壞性變更（如欄位刪除）即觸發 Slack 通知與 Canary Pipeline。
2. 延遲監控與自動調節
- Lag-based Autoscaling：CDC 消費者會根據 Kafka Consumer Lag 動態擴縮容器數量，確保高峰期仍維持秒級延遲。
- Adaptive Batching：Flink Sink 會根據 Snowflake Warehouse 負載自動調整 batch 大小與 commit 間隔，避免儲存成本暴增。
3. 回填（Backfill）策略
Pinterest 針對回填建立三種模式：
- Hot Backfill：針對短時間宕機（<30 分鐘），直接從 Kafka topic Replay。
- Warm Backfill：針對歷史資料變更，透過 Aurora Snapshot + Flink SQL Merge。
- Cold Backfill：針對超過 30 天的歷史資料，從 Iceberg Snapshot 重新發佈。
4. 隱私與合規
Pinterest 將 GDPR 的「Right to be Forgotten」流程整合到 CDC Pipeline：當收到刪除請求時，Flink 任務會發送 redact 事件，觸發各下游系統執行同步刪除。這使得資料刪除在 24 小時內可驗證完成。
與 2023 年版本的差異
| 項目 | 2023 年版 | 2025 年版 |
|---|---|---|
| 來源資料庫 | MySQL + HBase | Aurora MySQL + DynamoDB Streams |
| CDC 工具 | 自研 Binlog Parser | Debezium + Kafka Connect |
| 延遲 | 約 5～10 分鐘 | 平均 8 秒以內 |
| Backfill | 手動 Script | 自動化 Replay 平台 |
| Observability | 基本 Metrics | OpenTelemetry + Data Quality Dashboard |
對產品與營收的影響
- 精準廣告與商業搜尋：即時資料讓廣告競價系統能快速偵測高轉換族群，廣告主的 ROAS 提升 12%。
- 創作者分析：CDC 事件同步到 Creator Analytics，創作者可即時看到 Pin 表現，促進內容供給。
- AI 助理推薦：Pinterest 最新的 Vision-LLM 助理需要即時取得圖像互動記錄，CDC Pipeline 確保模型特徵不落後。
實作建議給企業架構師
- 從資料契約開始：在導入 CDC 前，先定義 schema 版本與欄位命名規範，避免日後整合成本。
- 建立回放能力：沒有 Replay 就無法快速補救錯誤，建議保留至少 7 天的原始事件。
- 觀測性優先：Lag、吞吐、錯誤率應納入 SLO，並建立自動化告警與 Runbook。
- 混合儲存策略：以湖倉並行（Iceberg + Cloud DW）兼顧成本與查詢效能。
- 隱私治理整合：將資料刪除、遮蔽流程整合到 CDC，確保合規要求不被忽略。
結語
Pinterest 2025 年的 CDC 平台示範了大型社群產品如何在雲端上維持低延遲、高可靠度的資料同步。即便你的企業規模不及 Pinterest，也可以借鏡其模組化架構與觀測性策略：從 Debezium／Flink 等開源工具起步，搭配嚴謹的資料契約與回放機制，就能打造一個可擴展、可維護的即時資料平台。
參考資料
- Pinterest Engineering. (2025). Keeping Pins Fresh: Real-time Change Data Capture at Scale.
- AWS Architecture Blog. (2024). Building Resilient CDC Pipelines with Aurora and Kafka.
- Confluent. (2025). Designing Multi-tenant Kafka Connect for Global Brands.