前言：

主要講解了技術原理，入門與生產實踐，主要功能：全增量一體化數據集成、實時數據入庫入倉、最詳細的教程。Flink CDC 是Apache Flink的一個重要組件，主要使用了CDC技術從各種數據庫中獲取變更流并接入到Flink中，Apache Flink作為一款非常優秀的流處理引擎，其SQL API又提供了強大的流式計算能力，因此結合Flink CDC能帶來非常廣闊的應用場景。例如，Flink CDC可以代替傳統的Data X和Canal工具作為實時數據同步，將數據庫的全量和增量數據同步到消息隊列和數據倉庫中。也可以做實時數據集成，將數據庫數據實時入湖入倉。還可以做實時物化視圖，通過SQL對數據做實時的關聯、打寬、聚合，并將物化結果寫入到數據湖倉中。

作為新一代的數據集成框架，Flink CDC希望解決的問題很簡單：成為數據從源頭連接到數據倉庫的管道，屏蔽過程中的一切復雜問題，讓用戶專注于數據分析，但是為了讓數據集成變得簡單，其中的難點仍然很多，比如說百億數據如何高效入湖入倉？千表數據如何穩定入湖入倉，以及如何一鍵式的數據同步處理，表結構頻繁變更 ，如何自動同步表結構變更到湖和倉中？本文將作為一一進行介紹

CDC概念

CDC的全稱是Change Data Capture，在廣義的概念上，只要是能夠捕獲數據變更的技術，都可以成為是CDC。目前通常描述的CDC技術主要面向數據庫的變更，是一種用于捕獲數據庫中數據變更的技術，CDC的應用非常廣泛。

數據遷移：常用于數據庫備份、容災等

數據分發：將一個數據源分發給多個下游，常用語業務的解耦、微服務的使用場景

數據采集：將分散異構的數據源集成到數據倉中，消除數據孤島，便于后續的分析，監控

目前主要的CDC有兩種：

基于查詢的CDC

離線調度查詢作業，批處理。依賴表中的更新時間字段，每次執行查詢去捕獲表中的最新數據

無法捕獲的是刪除事件，從而無法保證數據一致性問題

無法保障實時性，基于離線調度存在天然的延遲

基于日志的CDC

實時消費日志，流處理。比如說MySQL里面的BinLog日志完整記錄數據庫中的數據變更，可以把binLog文件作為流的數據源

保障數據一致性，因為binLog文件中包含了所有歷史變更明細

保障實時性，因為類似binLog的日志文件可以流式消費的，提供的實時數據

常見開源CDC方案比較

從這張圖可以看出來，在數據加工能力上，CDC工具是夠能夠方便地對數據做一些清洗、過濾、聚合，甚至關聯拓寬。Flink CDC依托強大的Flink SQL流式計算能力，可以非常方便對數據進行加工。Apache Flink的一個組件具有非常靈活的水平擴展能力。而DataX 和Canal是單體架構，在大數據場景下容易面臨性能瓶頸的問題。

從生態方面，這個是上下游存儲的支持。Flink CDC上下游非常豐富，支持對接MySQL、Post供熱SQL等數據源，還支持寫入到HBase、Kafka、Hudi等各種存儲系統中，也支持靈活的自定義connector

Flink CDC 項目

Flink有兩個基礎概念，Dynamic Table和Changelog Stream

Dynamic Table就是Flink SQL定義的動態表，動態表和流的概念是對等的，意思是流可以轉換為動態表，動態表也可以轉換成流

在Flink SQL中數據從 一個算子流向另一個算子時都是以Changelog Stream的形式，任意時刻的Changelog Stream可以翻譯為一個表，也可以翻譯成一個流

MySql中的表和binlog日志，就會發現MySql數據庫的一張表所有的變更都記錄在binlog日志中，如果一直對表進行更新，binlog日志流也會一直增加，數據庫中的表就相當于binlog日志流在某個時刻點物化的形式；日志流就是將表的變更數據持續捕獲的結果。說明Flink SQL的Dynamic Table是可以非常自然地表示一張不斷變化的MySql數據庫表

Debezium支持全量同步，也支持增量同步，也支持全量+增量的同步，非常靈活，同時日志的CDC技術使得提供Exactly-Once稱為可能。

每條RowData都有一個元數據RowKind，包括4種類型，分別是插入、更新前鏡像、更新后鏡像、刪除，這四種類型和數據庫里面的binlog概念保持一致

而Debezium的數據結構，也有一個類似的元數據字段op，op字段的取值也是四種，分別是c、u、d、r，各自對應create、update、delete、read，對于代表更新操作的u，其數據部分包含了前鏡像(before)和后鏡像(after)

Flink CDC分析

傳統的基于CDC的ETL分析中，數據采集工具是必須的，國外用戶常用的Debezium，國內用戶常用的阿里開源的Canal，采集工具負責采集數據庫的增量數據，一些采集工具也支持全量數據同步。采集到的數據一般輸出到消息中間件如kafka，然后Flink計算引擎再去消費數據并寫入到目的端，目標端可以是各種數據庫、數據倉庫、數據湖和消息隊列。

Flink提供了changelog-json format，可以使changelog數據寫入到離線數據倉庫(Hive)；對于消息隊列Kafka，Flink支持通過changelog的upset-kafka connector直接寫入到kafka的compacted topic。

一致性就是業務正確性，在“流系統中間件”這個業務領域，端到端一致性就代表 Exacly Once

Msg Processing(簡稱 EOMP)，即一個消息只被處理一次，造成一次效果。即使機器或軟件出現故

障，既沒有重復數據，也不會丟數據。

冪等就是一個相同的操作，無論重復多少次，造成的效果和只操作一次相等。流系統端到端鏈路較

長，涉及到上游 Source 層、中間計算層和下游 Sink 層三部分，要實現端到端的一致性，需要實

現以下條件：

上游可以 replay，否則中間計算層收到消息后未計算，卻發生 failure 而重啟，消息就會丟失。

記錄消息處理進度，并保證存儲計算結果不出現重復，二者是一個原子操作，或者存儲計算結果

是個冪等操作，否則若先記錄處理進度，再存儲計算結果時發生 failure，計算結果會丟失，或者

是記錄完計算結果再發生 failure，就會 replay 生成多個計算結果。

中間計算結果高可用，應對下游在接到計算結果后發生 failure，并未成功處理該結果的場景，可

以考慮將中間計算結果放在高可用的 DataStore 里。

下游去重，應對下游處理完消息后發生 failure，重復接收消息的場景，這種可通過給消息設置

SequcenceId 實現去重，或者下游實現冪等

?

總結

以上是生活随笔為你收集整理的Flink CDC 新一代数据集成框架的全部內容，希望文章能夠幫你解決所遇到的問題。

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