開啟資料整合微服務化 – 淺談 Change Data Capture (CDC) 及重要性，它如何實現資料同步？

Change Data Capture (CDC) 是什麼？又為何重要？

CDC 的原文是 Change Data Capture，常被稱為「異動資料擷取」，在資料庫的領域裡，它是一組軟體設計模式，目的是在資料庫發生變更異動時，能夠時序式地記錄追蹤狀態和變動內容，然後達到資料同步的效果，甚至再應用到資料轉移、資料庫備份、災難復原的場合。

特別是在資料倉儲的環境裡，企業在數據整合的維運過程，針對異質資料來源，進行資料狀態的記錄和辨識，依照時序追蹤資料異動，引導後續的資料梳理和應用，這些正是資訊部門的日常核心作業。以金融或製造業為例，日常作業流程必須要不斷昇級優化，同時間內，必須對既有核心系統效減少衝擊，這樣才能滿足數位轉型下，大數據營運和商務分析的需求挑戰。

資料同步是我們想要的結果，但實作方法和工具卻不只一種，資訊部門需要考量多種面向的需求，像是資料庫功能的支援狀況、對現有資料庫壓力衝擊的耐受度、同步的即時性要求，依據這些限制條件，再決定出最適合自己的技術方案和佈署路徑。現在有越來越多資料庫支援進階的 CDC 功能，促使大家重新思考：是否有機會導入更好的資料同步方案和工具？

3 個實現 CDC 的方法與實作困境

在介紹 CDC 推薦方案之前，讓我們先檢視資料同步最常見的幾種形式，以及它們遇到哪些挑戰。為了做到 CDC 的功能，我們會先監控資料庫，並確保每筆交易變動都有日期時間的記錄資訊。第一種方式，是透過應用程式來記錄交易日誌檔，再方便事後的查找比對。第二種方式，是透過資料庫 Trigger 功能，在每次變動發生時，觸發更新記錄。第三種方式，是透過資料庫來讀取或查詢日誌檔，像 Postgres 的 Write-Ahead Log、MySQL 的 BinLog、MongoDB 的 oplog 等，我們可以完整地取得特定時序裡的變動資料。

第一種編寫程式方式，不管是在應用程式端，或是撰寫小型的腳本程式，能夠得到最大的客製化精準度和彈性，缺點就是每次遇到新的需求，都需要找人來編修程式。第二種 Trigger 屬於侵入式作法，通常是針對資料表單的異動事件去觸發記錄動作，因此會產生資料庫額外留下許多交易記錄的困擾，除了儲存和運算的成本外，如果遇到 Trigger 忘了被啟用，反而會讓整個流程變得複雜。第三種 Log 方式相對比較可靠，但不同資料庫有各自的管理方式，而且 Initial Log 需要的資源，還有交易記錄透過訪查 redo 的配套機制，也需要被審慎考量。

使用開源方案實現 CDC

那麼，關心數據整合議題的企業，該怎樣著手下一步的評估呢？我們先看商業版本資料庫的方案，例如 Oracle Golden Gate 和 Greenplum Streaming Server 都有支援 CDC 功能或配套機制，如果移植前經過各方面評估和熟悉開源軟體，希望透過開源方案來橋接，那麼 Kafka 和 Debezium 是值得導入評估的工具。

Kafka 開源事件串流平台

Kafka 是一套開源版本的事件串流平台，它提供大規模的訊息佇列服務，透過分散式應用程式的架構，每分鐘可處理多達數十億個串流事件，達到建置即時資料處理平台的效果。由於它具備下列的功能特性，應用在 CDC 基礎服務也是相當適合的場景：

• 支援 Key-Value 時序式的連續資料
• Pull-based 拉取資料來源後可引導至後端資料庫 
• 支援橫向延展擴充以避免單節點錯誤的威脅

Debezium 資料流輸出開源工具

Debezium 是一個專門處理 CDC 功能的軟體專案，提供 Oracle、SQL Server、MySQL、Postgres、MongoDB 在內的眾多連結器，透過連結器可以串接不同的前台資料源，將數據資料餵進 Kafka 集群裡，再引導或調度資料到 Greenplum、Elasticsearch、MongoDB 之類的後端資料庫，達到資料同步或數據整合的效果。

結語

強化後的 CDC 功能，不僅讓資料同步和數據遷移變得更容易、更有效，它開啟更多資料整合微服務化的可能性，透過 Kafka 和 Debezium 這類開源工具，我們可以嘗試體驗和驗證這些可能性，而奠基在這類開源工具之上的商業產品生態系，它們的日益成長，也見證了這個潮流趨勢正受到企業機構的關注和重視。

本文章由歐立威技術顧問撰寫而成，轉載請註明出處，內容若有侵權請來信告知