1、簡介

????????CDC全稱是Change Data Capture，是一種捕獲增量數據的技術統稱，目前主要應用在捕獲數據庫數據變更的技術。其中數據庫變更包括DDL,DML,DCL等語句觸發的變更。在數據備份容災、數據分發、面向數倉的數據集成等場景中廣泛應用。在增量數據識別中，增量捕獲能否實現更多依賴于源端系統。

????????使用場景：企業信息化建設中，有一個板塊是企業應用集成，根據集成深度的不同，可以分為界面集成、數據集成、控制集成、業務流程集成。其中界面集成是指統一入口，使分散的系統看起來產生整體的感覺，使最小化代價實現一體化操作的方法。控制集成和業務流程集成，是應用邏輯層的集成，通過通信的方式，調用其他系統方法或流程，來實現企業內外部的信息資產聯動。

????????數據集成：其中數據集成是應用系統通過中間件、API調用等方式進行數據交互，當下提到的數據集成，更多的是面向分析場景，通過數據集成實現企業內外部數據的匯聚。

????????在面向分析場景中，出于網絡壓力、對源端系統的壓力、以及效率等，重點考慮做增量數據的捕獲，這樣僅識別并獲得最近變化的數據，更方便后續得ETL操作。

????????首先我們先對增量數據進行定義：有變化的數據行都是增量數據，如新插入的數據、發生修改的數據、被刪除的數據。這些數據在數據集成的時候，都需要被準確識別和還原，這樣才能保證OLAP側和OLTP側的數據一致性。

2、CDC常見方法分類

????????常見的增量數據捕獲有基于時間戳、快照、觸發器和日志四種。分別如下：

時間戳方法：

????????需要源端數據庫中有相應的時間戳字段，并且這個字段在業務上代表更新時間，(某些情況下代表數據寫入變更等操作時間)。

快照方法：

????????一般是數據庫自帶的機制，如關系型數據庫的物化視圖技術，也可以自己實現相關邏輯，比如每天或定時某些時刻進行數據的備份等操作，但會比較復雜。

觸發器方法：

????????是傳統關系型數據庫自帶的機制，觸發器會在對表執行相關SQL語句如insert、delete、update的情況下觸發，并執行一定的業務邏輯，將變化的數據寫到另外一張表中，用于增量數據捕獲。通常情況，DBA或數據開發管理人員，會自己編寫或維護一套相關的觸發器。

日志方法：

????????是基于日志消費的模式，源端數據庫將庫表變更以日志的方式記錄到外存中，數據集成通過消費、解析日志進行增量數據捕獲。如MYSQL的binlog等。

CDC方法特點

特性	時間戳方法	快照方法	觸發器方法	日志方法
DBA執行	不是	不是	是	是
實時	不是	不是	是	是
監聽刪除	不是	是	是	是
依賴數據庫	不是	不是	是	是
周期內更新監聽多次	不是	不是	是	是
區分插入和更新	不是	是	是	是

????????DBA執行：是否需要DBA支持，在源端系統(一般是數據庫本身支持)做一些個性化配置。

????????不依賴數據庫：技術選型不依賴數據庫類型(例如關系數據庫和分關系數據庫包括大數據hadoop系列，redis,mongodb，memcache等)。（因為部分數據庫不支持這些個性化配置，導致部分增量同步方式非普適性）

3、主流實現方式

? ? ? ? 基于SQL：

????????主要是離線調度查詢作業，通過JDBC的方式，發起一次查詢請求，服務端根據查詢SQL進行解析、編譯、執行優化、返回結果集。這個缺點也很明顯，首先是增量捕獲過程中，對源端數據庫有侵入性，需要源端數據庫有增量字段，一般是更新時間字段。其次是基于離線調度的方式，無法保證實時性和數據一致性。比如在查的過程中，數據可能已經產生了多次變化。最后，這種查詢方式，對源端數據庫有一定的IO壓力，所以這種方法需要充分考慮源端系統壓力，協調時間窗口，或者考慮從備庫中進行數據集成。

? ? ? ? 基于數據庫日志：

????????源端數據庫通過啟用日志(如Mysql的binlog,oracle的binlog等)，將數據庫變更記錄完整、順序的記錄在日志中，我們把日志作為數據源，進行實時消費，并在下游進行數據還原。這樣做保證了數據的一致性和實時性。但整體架構相對復雜，設計的時候要充分考慮重跑重刷得情況導致數據重復，需要考慮exactly-once技術。

? 4、常見的CDC技術實現

? ? ? ? CDC技術實現可以從實時和離線大體兩個風向做區分：

????????實時：canal、maxwell、Debezium、FlinkCDC、FlinkX等開源技術。

????????離線：Sqoop、DataX。

? ? ? ? 以上這幾種開源數據的比較：

?5、數據庫BINLOG

????????binlog一般是關系數據庫的操作日志，如Mysql,oacle，記錄了數據的變更日志，定位一個LogEvent需要通過binlog fimename + binlog position。按照binlog生成方式，mysql支持三種配置：statement-based、row-based、mixed。一般建議使用ROW模式。

????????Statement：基于SQL語句的復制（statement-based replication, SBR），記錄的是修改數據的SQL、不記錄數據變化，減少日志量。但缺點是存在數據不一致的風險，如update t set create_date=now()，在binlog日志恢復時，會導致數據不一致。

????????Row：基于行的復制（row-based replication, RBR）：僅保存哪條記錄被修改，這種模式保證了數據的絕對一致性。缺點是，更新操作時，有多少記錄被變化就會記錄多少事件。

????????Mixed：混合模式復制（mixed-based replication, MBR）：一般的復制使用Statement模式保存binlog，對于Statement模式無法復制的操作使用Row模式保存binlog。節省空間的同時，兼顧了一致性，但極個別情況仍有不一致的情況。

6、實時增量數據集成

?Canal

????????主要用途是基于Mysql數據庫增量日志解析，提供增量數據訂閱和消費。目前支持MySQL 版本包括 5.1.x , 5.5.x , 5.6.x , 5.7.x , 8.0.x。

MaxWell

????????Maxwell同樣可以實時讀取Mysql的binlog，并生成Json信息，并作為生產者將數據同步給MQ，包括Kafka、Kinesis、RabbitMQ、Redis等。相比canal的優勢就是使用簡單，更輕量化，并且相比canal，支持初始化操作。

Debezium

????????Debezium最早是作為kafka連接器進行設計的，所以和kafka耦合性較強。消費binlog數據后，投遞到kafka中，在依賴kafka的connector能力輸出到其他存儲中。后續的FlinkCDC等技術底層都是基于Debezium進行抽象、改造的。

FlinkCDC

????????傳統的基于CDC的ETL分析中，通過先采集、然后依賴外部MQ進行數據投遞、在下游消費后進行計算，最后在進行數據存儲。整體的數據鏈路比較長，FlinkCDC的核心理念在于簡化數據鏈路，底層集成了Debezium進行binlog的采集、省去了MQ部分、最后通過Flink進行計算。全鏈路上都基于Flink生態，比較清晰。

FlinkX

????????Flinkx已經更名為Chunjun，是一個基于Flink的批流統一的數據同步工具，既可以采集靜態數據，也可以采集實時變化數據。功能上可以認為是擴展版的DataX（支持了實時變化數據采集）、從技術和架構上上也迎合了批流一體的概念，目前生態比較完善。

7、離線數據集成

?Sqoop
????????目前Sqoop已經從apache頂級項目中被剔除，sqoop支持兩個命令，import和export，分別完成關系型數據庫到hive（import）、以及hive到關系型數據庫（export）、任務觸發時，會被解析成MapReduce執行。從當下來看，生態完善性較差，尤其是對數據使用的實時性要求、以及hive本身upsert較弱的局限性等，后續會逐步退出歷史舞臺。

?Datax
????????阿里內被廣泛使用的離線數據同步工具/平臺，幾乎實現了所有常見數據存儲的擴展，支持各種異構數據源之間的數據同步。不在贅述
?

????????

總結

以上是生活随笔為你收集整理的大数据CDC技术的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。