Flink CDC+Kafka 加速業務實時化

摘要：本文整理自阿里巴巴開發工程師、Apache Flink Committer 任慶盛，在 9 月 24 日 Apache Flink Meetup 的分享。主要內容包括：

1. Flink CDC 技術對比與分析

2. Flink + Kafka 實時資料整合方案

3. Demo：Flink+Kafka 實現 CDC 資料的實時整合和實時分析

01

Flink CDC 技術對比與分析

1.1 變更資料捕獲（CDC）技術

 

廣義概念上，能夠捕獲資料變更的技術統稱為 CDC（Change Data Capture）。通常我們說的 CDC 主要面向資料庫的變更，是一種用於捕獲資料庫中資料變化的技術。

CDC 的主要應用有三個方面：

• 資料同步，透過 CDC 將資料同步到其他儲存位置來進行異地災備或備份。
• 資料分發，透過 CDC 將資料從一個資料來源抽取出來後分發給下游各個業務方做資料處理和變換。
  
  
• 數
  據採集，使用 CDC 將源端資料庫中的資料讀取出來後，經過 ETL 寫入資料倉儲或資料湖。
  
  

  
  

按照實現機制，CDC 可以分為兩種型別：基於查詢和基於日誌的 CDC。基於查詢的 CDC 透過定時排程離線任務的方式實現，一般為批處理模式，無法保證資料的實時性，資料一致性也會受到影響。基於日誌的 CDC 透過實時消費資料庫裡的日誌變化實現，如透過聯結器直接讀取 MySQL 的 binlog 捕獲變更。這種流處理模式可以做到低延遲，因此更好地保障了資料的實時性和一致性。

1.2 Flink CDC 的技術優勢

在上圖中，我們比較了幾種常見的 CDC 方案。相比於其他方案，Flink CDC 在功能上整合了許多優勢：

• 在實現機制方面，Flink CDC 透過直接讀取資料庫日誌捕獲資料變更，保障了資料實時性和一致性。
  
  
• 在同步能力方面，Flink CDC 支援全量和增量兩種讀取模式，並且可以做到無縫切換。
  
  
• 在資料連續性方面，Flink CDC 充分利用了 Apache Flink 的 checkpoint 機制，提供了斷點續傳功能，當作業出現故障重啟後可以從中斷的位置直接啟動恢復。
  
  
• 在架構方面，Flink CDC 的分散式設計使得使用者可以啟動多個併發來消費源庫中的資料。
  
  
• 在資料變換方面，Flink CDC 將從資料庫中讀取出來後，可以透過 DataStream、SQL 等進行各種複雜計算和資料處理。
  
  
• 在生態方面，Flink CDC 依託於強大的 Flink 生態和眾多的 connector 種類，可以將實時資料對接至多種外部系統。

1.3 Flink CDC 全增量一體化框架

自 2.0 版本起，Flink CDC 引入了增量快照框架，實現了資料庫全量和增量資料的一體化讀取，並可以在全量和增量讀取之間進行無縫切換。在讀取全量資料時，Flink CDC source 會首先將資料表中的已有資料根據主鍵分佈切分成多個 chunk（如上圖中的綠色方塊所示），並將 chunk 分發給多個 reader 進行併發讀取。

對於資料變化頻繁、已有資料較多的資料庫，在全量同步過程中已同步的資料可能會發生變化。一些資料整合工具的解決方案是在讀取前獲取表鎖阻止資料變更，再進行全量資料讀取，然而這種方案會對線上業務造成較大影響。為解決該問題，Flink CDC 的增量快照框架引入了水位線（watermark）的概念：在啟動全量同步前，首先獲取資料庫當前最新的 binlog 位點，記為低水位線（low watermark），如上圖中的藍色方塊所示，隨後啟動全量讀取。

在所有全量資料讀取完成後，CDC source 會再次獲取最新的 binlog 位點，並記為高水位線（high watermark），如上圖中第二個藍色方塊所示。位於高低水位線之間、與被捕獲表相關的 binlog 事件（上圖中的黃色方塊）即為全量資料在讀取階段發生的資料變化，CDC source 會將這部分增量資料合併至現有快照，合併完成後即可獲得與源資料庫完全一致的實時快照，並且在此過程中無需對資料庫進行加鎖，不會影響線上業務的正常執行。

業界常用的另一個 CDC 工具是 Debezium。與 Flink CDC 相比，Debezium 方案需要在全量讀取前為資料庫加鎖，且只能使用單併發讀取。如果在同步過程中任務發生失敗，需要從全量資料重新讀取才能夠保證一致性。Flink CDC 的增量快照框架方案在全量讀取前無需加鎖，並且可以使用多併發讀取。依託於 Flink checkpoint 機制，如果在同步過程中作業發生異常，可快速從最近一次成功的 checkpoint 恢復讀取。

1.4. Flink CDC 社群發展

Flink CDC 社群從 2020 年 7 月份創立至今受到了各位開發者的廣泛關注，整個社群蓬勃發展。截至 2023 年 1 月，專案 star 數量超過 3000 個，超過 70 位貢獻者提交了超過 500 個 commit，專案 fork 數量超過 1200 次。在此也特別感謝每一位參與 Flink CDC 的開發者為社群蓬勃發展做出的卓越貢獻！

2022 年 11 月，Flink CDC 社群釋出了最新的 2.3 版本，對 MySQL CDC 進行了諸多穩定性和穩定性改進，新增了 Db2 CDC 聯結器，MongoDB CDC 聯結器接入了增量快照框架。詳情可閱讀 Flink CDC 2.3 釋出公告。

02

Flink + Kafka 實時資料整合方案

上圖展示了一個典型的資料同步場景，源資料庫中的變更資料使用 Flink CDC 同步到下游。如果下游業務方較多、需要同步的資料庫表較多或資料處理邏輯較複雜，由於每張資料表都需要啟動一個 Flink 作業進行同步，這樣會對源資料庫造成極大壓力。此外，某些熱點表或資料庫會被多個 Flink CDC 同步任務頻繁訪問，同樣會加劇資料庫的訪問壓力。

為了解決以上業務痛點，一種可行的設計是在資料流水線中引入訊息佇列中介軟體的分散式能力，緩解資料庫壓力。比如先將源庫中的變更資料同步到 Kafka 中，再由各個業務方消費。但引入訊息佇列後依然存在許多需要人工介入的問題，比如配置 CDC source、配置 Kafka sink、手動建立 Kafka topic 和 partition 等。另外，基於目前 Flink CDC 的設計，每一張表都需要啟動一個同步作業，如果資料庫裡的表非常多，也會為源庫帶來很大的壓力。

針對以上問題，阿里雲實時計算平臺推出了 Flink + Kafka 實時資料整合解決方案，使用者使用一句 SQL 即可將資料庫快速同步到 Kafka。解決方案使用了 CREATE TABLE AS（CTAS）語法和 CREATE DATABASE AS（CDAS）語法，指定源表名或源資料庫名，以及目標表名或目標資料庫名，即可快速將源庫中的資料同步到目標 Kafka 中，無需手動配置配置任務和建立 Kafka topic / partition。

此外，解決方案還支援對源表的結構變更進行自動同步。如果源表中新加入可空列、刪除可空列或重新命名列，Kafka sink 會動態調整寫入時使用的 JSON format，按照變更後的表結構將資料寫入 Kafka 訊息中。

按照 Flink CDC 當前的設計，在進行整庫同步時，對資料庫中的每張資料表都需要啟動一個 Flink 作業進行消費，如果表數量非常多，Flink 作業數及其消耗的資源也會非常多。整庫同步解決方案針對該問題進行了最佳化，在 Flink 作業中對同一個資料庫複用一個 CDC source 例項，連線多個 sink 將不同表中的資料分發至不同的 Kafka topic，因此只需啟動一個 Flink 作業即可同步資料庫中的所有表。如果資料量非常大，也只需調節同步作業的併發，無需啟動多個作業來對同一個資料庫進行消費，大大降低 Flink 對於資料庫連線數的壓力。

Flink + Kafka 實時資料整合的解決方案有如下幾個優勢：

• 只需要一條 SQL（CTAS、CDAS）即可完成單表或整庫同步，無需反覆配置作業引數來啟動多個作業。
  
  
• 自動建立目標端 Kafka topic 和 partition，使用者無需在 Kafka 叢集中進行手動配置。
  
  
• 原生支援了新增可空列、刪除可空列以及重新命名列等表結構變更同步的策略，能夠支援更多資料同步的場景。

03

Demo：Flink+Kafka 實現 CDC 資料的

實時整合和實時分析

資料庫中有三張表，分別是產品、訂單、運輸表。透過 CDAS 整庫同步能力，將資料一次性同步到 Kafka 中，下游有多條業務線來消費 Kafka 裡資料。Flink 作業將前面三張表做 join，打成寬表。如果沒有中間的 Kafka 或同步能力，則需要起多個 Flink 作業，消費源庫中某兩個或多個資料表的變更資料，比如 order 表，本身可能變化非常快，會對資料庫產生非常大的壓力。