解鎖即時資料的奧秘：深入淺出 CDC (Change Data Capture)

發表於 分類於

在現代的資料工程與軟體架構中，時常面臨一個挑戰：如何即時、高效地同步不同系統之間的資料？

過去，我們可能習慣於每天半夜執行批次任務 (Batch Job)，將資料庫的資料整批匯出、轉換再載入到另一個系統。但這種方式延遲高、對資料庫壓力大，而且難以捕捉到「刪除」操作。

這篇文章要來聊聊解決這個問題的優雅方案：CDC (Change Data Capture)。它就像是為資料庫請了一位全天候的速記員，精準記錄下每一筆變更，徹底改變了處理資料流動的方式。

核心概念：CDC 是一種設計模式，用於識別與捕捉資料庫中的資料變更（包含新增、修改、刪除），並將這些變更以事件的形式，提供給其他系統或應用程式使用。

這篇文章將帶你深入了解：

  • 什麼是 CDC？它的核心價值是什麼？
  • 為什麼需要它？傳統做法有哪些痛點？
  • CDC 的幾種主流實現方式及其優劣分析。
  • CDC 在真實世界的應用場景。

為什麼需要 CDC？傳統做法的痛點

想像一下，如果沒有 CDC，要如何將線上交易資料庫 (OLTP) 的資料同步到資料倉儲 (Data Warehouse) 進行分析？

最直觀的方式是定期輪詢 (Polling)：

  1. 每隔 5 分鐘，向資料庫下 SELECT * FROM orders WHERE updated_at > ? 這樣的查詢。
  2. 將查到的新資料送到下游系統。

這種做法會帶來幾個難以忽視的痛點：

  • 高延遲 (High Latency)：資料永遠不是即時的。在查詢間隔中發生的變更，下游系統無法立刻感知。
  • 高資源消耗 (High Resource Consumption)：頻繁的 SELECT 查詢會對生產資料庫造成巨大壓力，尤其是在資料表非常大的情況下。
  • 遺漏刪除操作 (Missed Deletes)：DELETE 操作很難透過 updated_at 這樣的欄位來追蹤。除非採用「軟刪除」（將資料標記為已刪除，而非物理刪除），否則很難同步刪除事件。
  • 處理中間狀態的複雜性：如果在輪詢間隔內，一筆資料被修改了三次，可能只會拿到最後的狀態，而錯失了中間的變化過程。

CDC 的出現，正是為了解決以上所有問題。它不再是「拉取」(Pull) 資料，而是由資料源「推送」(Push) 變更，實現了真正的事件驅動架構。

CDC 的核心實現方式

CDC 的實現方式主要有三種，每種都有其獨特的優缺點。了解它們的差異，有助於根據場景做出最佳選擇。

1. 基於交易日誌 (Transaction Log-Based)

這是目前最受推崇、也是最高效的方式。

現代資料庫（如 MySQL、PostgreSQL、Oracle）都有一個稱為「交易日誌」(Transaction Log) 的內部機制（MySQL 的 Binlog、PostgreSQL 的 WAL）。這個日誌記錄了所有會改變資料庫狀態的操作，其目的是為了資料庫的備份、還原與複寫。

工作原理：
CDC 工具偽裝成一個從資料庫 (Slave)，去讀取主資料庫 (Master) 的交易日誌。它解析日誌中的 INSERT, UPDATE, DELETE 操作，並將它們轉換成結構化的事件流。

  • 優點：

    • 低侵入性：對源資料庫的性能影響極小，因為它只是非同步地讀取日誌檔。
    • 高準確性：能捕捉到所有變更，包括 DELETE 和模式變更 (Schema Change)。
    • 近乎即時：延遲非常低，可以達到秒級甚至毫秒級。

  • 缺點：

    • 設置複雜：需要資料庫的管理權限來開啟和存取交易日誌。
    • 日誌格式依賴：日誌格式可能隨資料庫版本更新而改變，CDC 工具需要跟著升級。

代表工具：Debezium、Maxwell’s Daemon、Oracle GoldenGate。

2. 基於觸發器 (Trigger-Based)

這是一種相對傳統但非常可靠的方式。

工作原理：
在需要追蹤的資料表上建立觸發器 (Triggers)，分別對應 INSERT, UPDATE, DELETE 操作。當這些操作發生時，觸發器會被啟動，將變更的內容（舊資料、新資料）寫入一個額外的「歷史紀錄表」或「事件表」中。下游的應用程式再從這個事件表讀取資料。

  • 優點：

    • 實現簡單直觀：完全使用資料庫的標準功能，容易理解與部署。
    • 捕捉所有變更：可以精準記錄每一筆操作的細節。

  • 缺點：

    • 高侵入性：對源資料庫性能有顯著影響。每一次寫入操作都會額外觸發一次寫入（到歷史紀錄表），增加了交易的延遲與負載。
    • 管理成本：需要在每張要監控的表上都建立和維護觸發器。

3. 基於查詢 (Query-Based)

這就是一開始提到的輪詢方式，但它也是一種廣義的 CDC。

工作原理：
透過定期查詢資料庫來識別變更。通常依賴一個「最後更新時間」的欄位（例如 last_updated）。

  • 優點：

    • 實現最簡單：不需要任何資料庫管理權限或特殊設置。
    • 對資料庫結構無侵入。

  • 缺點：

    • 無法捕捉 DELETE。
    • 延遲高，非即時。
    • 性能開銷：對資料庫的查詢壓力取決於輪詢頻率與表的大小。

三種方式比較

特性 基於交易日誌 (Log-Based) 基於觸發器 (Trigger-Based) 基於查詢 (Query-Based)
對源庫性能影響 極低 高 中等
資料延遲 近乎即時 低 高
實現複雜度 較高 中等 低
是否能抓取 DELETE 是 是 否
侵入性 低（需日誌權限） 高（修改 Schema） 無

CDC 的常見應用場景

當掌握了 CDC 後，就能建構出許多強大的即時資料應用：

  1. 即時資料倉儲 (Real-time Data Warehousing)
    將線上交易資料庫的變更即時串流到 Snowflake、BigQuery 或 ClickHouse 等分析型資料庫中，讓商業智慧 (BI) 報表和儀表板永遠呈現最新鮮的數據。

  2. 微服務資料同步 (Microservices Data Synchronization)
    在微服務架構中，不同服務常有自己的資料庫。當 用戶服務 的資料更新時，可以透過 CDC 將變更事件廣播出去，讓 訂單服務 或 通知服務 能即時更新相關的用戶資訊快取，而無需透過同步 API 呼叫。

  3. 快取與搜尋引擎同步 (Cache/Search Index Synchronization)
    當資料庫中的商品資訊變更時，透過 CDC 將變更事件推送到 Redis 快取或 Elasticsearch 搜尋引擎中，確保用戶總是能看到和搜尋到最新的商品狀態。

  4. 零停機資料庫遷移 (Zero-Downtime Database Migration)
    在遷移資料庫時，可以先進行一次全量同步，然後利用 CDC 持續同步增量資料。當時機成熟時，只需將應用程式的連線切換到新資料庫，即可實現幾乎無感的平滑遷移。

  5. 資料稽核與監控 (Auditing & Monitoring)
    將所有資料庫的變更日誌記錄到一個不可變的儲存中，用於安全稽核、追蹤異常操作或資料恢復。

主流的 CDC 工具

  • Debezium: 目前最流行的開源 CDC 工具，基於 Kafka Connect 架構。它為主流資料庫（MySQL, PostgreSQL, MongoDB, SQL Server等）提供了豐富的連接器 (Connector)，能將資料變更無縫地串流到 Kafka 中。
  • Maxwell’s Daemon: 另一個專為 MySQL 設計的開源工具，可以將 Binlog 變更即時轉換為 JSON 格式並發送到 Kafka、Kinesis 等訊息佇列。
  • 雲端平台服務:
    • AWS DMS (Database Migration Service): 不僅用於遷移，其 CDC 功能也十分強大。
    • Google Cloud Datastream: Google Cloud 上的無伺服器 CDC 和複寫服務。
    • Alibaba Cloud DTS (Data Transmission Service): 阿里雲提供的資料傳輸服務，支援 CDC。

結論

CDC (Change Data Capture) 已不再是一個小眾技術，而是建構現代、事件驅動資料架構的基石。

它讓我們告別了高延遲、高開銷的批次處理模式，轉向了更高效、更即時的資料流。無論是為了打造即時分析儀表板、實現微服務間的解耦，還是進行平滑的資料庫遷移，CDC 都提供了強而有力的支持。

下次當設計資料管線時，不妨問問自己：需要即時資料嗎？需要可靠地捕捉所有變更嗎？如果答案是肯定的，那麼 CDC 很可能就是正在尋找的那個關鍵鑰匙。