CDC是（Change Data Capture 變更數(shù)據(jù)獲取）的簡稱。
核心思想是，監(jiān)測并捕獲數(shù)據(jù)庫的變動（包括數(shù)據(jù) 或 數(shù)據(jù)表的插入INSERT、更新UPDATE、刪除DELETE等），將這些變更按發(fā)生的順序完整記錄下來，寫入到消息中間件中以供其他服務(wù)進行訂閱及消費。
1）基于查詢的 CDC 和基于日志的 CDC
CDC 主要分為基于查詢和基于 Binlog 兩種方式
經(jīng)過以上對比，我們可以發(fā)現(xiàn)基于日志 CDC 有以下這幾種優(yōu)勢：
-
能夠捕獲所有數(shù)據(jù)的變化，捕獲完整的變更記錄。在異地容災(zāi)，數(shù)據(jù)備份等場景中得到廣泛應(yīng)用，如果是基于查詢的 CDC 有可能導(dǎo)致兩次查詢的中間一部分數(shù)據(jù)丟失
-
每次 DML 操作均有記錄無需像查詢 CDC 這樣發(fā)起全表掃描進行過濾，擁有更高的效率和性能，具有低延遲，不增加數(shù)據(jù)庫負載的優(yōu)勢
-
無需入侵業(yè)務(wù)，業(yè)務(wù)解耦，無需更改業(yè)務(wù)模型
-
捕獲刪除事件和捕獲舊記錄的狀態(tài)，在查詢 CDC 中，周期的查詢無法感知中間數(shù)據(jù)是否刪除
在實時性、吞吐量方面占優(yōu)，如果數(shù)據(jù)源是 MySQL、PostgreSQL、MongoDB 等常見的數(shù)據(jù)庫實現(xiàn)，建議使用 Debezium 來實現(xiàn)變更數(shù)據(jù)的捕獲（下圖來自 Debezium 官方文檔）。如果使用的只有 MySQL，則可以用 Canal。
2）Flink CDC
Flink 社區(qū)開發(fā)了 flink-cdc-connectors 組件，這是一個可以直接從 MySQL、PostgreSQL 等數(shù)據(jù)庫直接讀取全量數(shù)據(jù)和增量變更數(shù)據(jù)的 source 組件。目前也已開源，開源地址：https://github.com/ververica/flink-cdc-connectors
我們先從之前的數(shù)據(jù)架構(gòu)來看CDC的內(nèi)容
以上是之前的 mysql binlog 日志處理流程，例如 canal 監(jiān)聽 binlog 把日志寫入到 kafka 中。而 Flink 實時消費 Kafka 的數(shù)據(jù)實現(xiàn) mysql 數(shù)據(jù)的同步或其他內(nèi)容等。
拆分來說整體上可以分為以下幾個階段。
1、mysql 開啟 binlog
2、canal 同步 binlog 數(shù)據(jù)寫入到 kafka
3、flink 讀取 kakfa 中的 binlog 數(shù)據(jù)進行相關(guān)的業(yè)務(wù)處理。
整體的處理鏈路較長，需要用到的組件也比較多。Flink CDC可以直接從數(shù)據(jù)庫獲取到binlog供下游進行業(yè)務(wù)計算分析，從內(nèi)部實現(xiàn)上講，Flink CDC Connectors 內(nèi)置了一套 Debezium 和 Kafka 組件，但這個細節(jié)對用戶屏蔽，簡單來說鏈路會變成這樣。
也就是說數(shù)據(jù)不再通過 canal 與 kafka 進行同步，而 flink 直接進行處理 mysql 的數(shù)據(jù)。節(jié)省了 canal 與 kafka 的過程。
3）Flink CDC原理簡述
在最新 CDC 調(diào)研報告中，Debezium 和 Canal 是目前最流行使用的 CDC 工具，這些 CDC 工具的核心原理是抽取數(shù)據(jù)庫日志獲取變更。
在經(jīng)過一系列調(diào)研后，目前 Debezium (支持全量、增量同步，同時支持 MySQL、PostgreSQL、Oracle 等數(shù)據(jù)庫)，使用較為廣泛。
Flink SQL CDC 內(nèi)置了 Debezium 引擎，利用其抽取日志獲取變更的能力，將 changelog 轉(zhuǎn)換為 Flink SQL 認識的 RowData 數(shù)據(jù)。（以下右側(cè)是 Debezium 的數(shù)據(jù)格式，左側(cè)是 Flink 的 RowData 數(shù)據(jù)格式）。
RowData 代表了一行的數(shù)據(jù)，在 RowData 上面會有一個元數(shù)據(jù)的信息 RowKind，RowKind 里面包括了插入(+I)、更新前(-U)、更新后(+U)、刪除(-D)，這樣和數(shù)據(jù)庫里面的 binlog 概念十分類似。
通過 Debezium 采集的數(shù)據(jù)，包含了舊數(shù)據(jù)(before)和新數(shù)據(jù)行(after)以及原數(shù)據(jù)信息(source)，op 的 u 表示是update 更新操作標(biāo)識符（op 字段的值 c，u，d，r 分別對應(yīng) create，update，delete，reade），ts_ms 表示同步的時間戳。
4）基于 Flink SQL CDC 的數(shù)據(jù)同步方案實踐
4.1.案例 1 : Flink SQL CDC + JDBC Connector
這個案例通過訂閱我們訂單表（事實表）數(shù)據(jù)，通過 Debezium 將 MySQL Binlog 發(fā)送至 Kafka，通過維表 Join 和 ETL 操作把結(jié)果輸出至下游的 PG 數(shù)據(jù)庫。
4.2.案例 2 : CDC Streaming ETL
電商公司的訂單表和物流表，需要對訂單數(shù)據(jù)進行統(tǒng)計分析，對于不同的信息需要進行關(guān)聯(lián)后續(xù)形成訂單的大寬表后，交給下游的業(yè)務(wù)方使用 ES 做數(shù)據(jù)分析，這個案例演示了如何只依賴 Flink 不依賴其他組件，借助 Flink 強大的計算能力實時把 Binlog 的數(shù)據(jù)流關(guān)聯(lián)一次并同步至 ES。
例如如下的這段 Flink SQL 代碼就能完成實時同步 MySQL 中 orders 表的全量+增量數(shù)據(jù)的目的。
CREATE TABLE orders (
order_id INT,
order_date TIMESTAMP(0),
customer_name STRING,
price DECIMAL(10, 5),
product_id INT,
order_status BOOLEAN
) WITH (
'connector' = 'mysql-cdc',
'hostname' = 'localhost',
'port' = '3306',
'username' = 'root',
'password' = '123456',
'database-name' = 'mydb',
'table-name' = 'orders'
);
SELECT * FROM orders
4.3.案例 3 : Streaming Changes to Kafka
文章來源：http://www.zghlxwxcb.cn/news/detail-807949.html
參考阿里云：https://developer.aliyun.com/article/777502?utm_content=g_1000202135文章來源地址http://www.zghlxwxcb.cn/news/detail-807949.html
到了這里，關(guān)于【Flink-CDC】Flink CDC 介紹和原理概述的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
