Data Platform 元件#01：CDC 的選擇思考

在 Data Platform 筆記#01 中，我們介紹了初版的技術架構，其中資料接收的核心策略是 CDC（Change Data Capture）。這篇聊聊當時的選擇脈絡。

初心

在 Data Platform POC 階段，我們就開始設想未來接資料該怎麼處理。在以往的資料交換經驗中，很常見到的是：來源系統透過 ETL 將資料整理到中繼區，Data Center 再透過 ETL 從中繼區將尚未接收的資料接進來。也就是說，每多一個資料來源，就要多寫一支 ETL 程式，可預想的是維運量也隨之增加。

除了儘量地定義出一致的規範以減少客製，也在思考有沒有機會做到：只要來源系統將準備好的資料提供出來，Data Platform 做好相應設定就能自動接上，不用再寫一堆程式。在 Data Platform 角度而言，儘量避免為每一個來源資料寫客製的 ETL 程式，有效運用開發能量，也降低維運成本。

可能的工具

在作出選擇之前，我們思考了幾個選項：

Spring Cloud Data Flow

Spring Cloud Data Flow 支持批次處理也支持 Streaming，功能強大，學習曲線有點高，是曾經的選項，但在 2025 年公告停止維護開源版，投入學習的資源有但不多，於是就放下了。
https://spring.io/projects/spring-cloud-dataflow

Apache Airflow

很強的排程引擎，適合批次處理，而不是即時的資料變更同步，略不符我們的需求。
https://airflow.apache.org/

Apache Flink

Apache Flink 是很成熟的即時處理引擎之一，技術含量很高，維運複雜度相對也高。但對於我們「只要把資料接進來」的需求，有點殺雞用牛刀了。
https://flink.apache.org/

Airbyte

很讓人心動的資料整合工具，支援許多 Connector，可以快速接很多來源。因為時程的關係，加上當時我們已經有了 Kafka + Debezium 的 POC，有些可惜地沒有再繼續投入了解。
https://airbyte.com/

Debezium

Debezium 是專注於 CDC 的老牌專案，搭配 Kafka 作為緩衝與解耦層。兩者都是經過大規模驗證的開源專案，社群活躍、文件充足。維運雖然有難度，但我們後來透過 Helm Chart 簡化部署配置，並且找到了 UI 來輔助管理。
https://debezium.io/

為什麼選擇 CDC

CDC 的核心是 「事件驅動」：只要資料庫發生變更（Insert/Update/Delete），CDC 工具就會自動把變更記錄抓出來，送到下游。這跟我們的期待很接近：

• 不需要排程：資料變更時才觸發，不是輪詢
• 幾乎不需要寫程式：設定好來源與目標，資料流就自動跑
• 可以一次監控多張表

相較於傳統 ETL（定時撈資料、透過註記標記處理狀態），CDC 更有機會能達成「來源給資料就能自動接」的樣貌。

在應用的場景中，我們選擇不處理 Delete 事件。原因是不易區分來源是「刪除異常資料」還是「正常的歷史資料 Purge」。如果把刪除動作也同步過來，萬一來源誤刪，Data Platform 也跟著刪掉，資料就沒了。

沒有最好，只有當下合適

CDC 主要是監控資料庫的變化，如果來源提供資料的方式是 API、檔案等方式，仍是需要尋找合適的方式來接入資料。

在我們的需求場景中，資料庫佔大宗，八二法則思考下，自然而然就成為了尋找解決方案的最優先級。用 CDC 不是絕對，在尋找解決方案的過程中，也看過不少推薦 Apache Flink 解決方案，選擇會因需求場景、環境、團隊而有不同，重點還是在於想解的問題是什麼。

能解決問題的，就是好的選擇。