摘要：本文整理自阿里雲技術專家，Apache Flink PMC Member & Committer, Flink CDC Maintainer 徐榜江和阿里雲高級研發工程師，Apache Flink Contributor & Flink CDC Maintainer 阮航，在 Flink Forward Asia 2022 數據集成專場的分享。本篇內容主要分爲四個部分：
1.深入解讀 Flink CDC 2.3 版本
2.基於 Flink CDC 構建現代數據棧
3.阿里雲內部實踐和改進
4.Demo & 未來規劃
一、深入解讀 Flink CDC 2.3 版本
1.1 Flink CDC
首先介紹一下 Flink CDC 技術。Flink CDC 是基於數據庫的日誌 CDC 技術，實現了全增量一體化讀取的數據集成框架。配合 Flink 優秀的管道能力和豐富的上下游生態，Flink CDC 可以高效實現海量數據的實時集成。
如上圖所示，在數據庫中，我們有歷史的全量數據，也有實時的增量數據。比如上游有業務系統在源源不斷實時寫入數據，Flink CDC 技術的能力就是將全量數據和增量數據無縫集成到 Flink 引擎中，爲下游應用提供實時的一致性快照。
1.2 Flink CDC 2.3 基本介紹
2022 年 11 月 10 日，Flink CDC 社區發佈了 2.3 版本。 此版本的貢獻者共有 49 位，解決了 126 個 issue，合併的 PR 達到 133 個；合併的 commits 達到 173 個。
在 Flink CDC 2.3 版本中，我們按代碼的貢獻模塊進行了劃分。其中 MySQL 佔比最高達到了 24%，Oracle 佔 15%，MongoDB 佔 7%，TiDB 佔 7%，包含全量框架的 Base 模塊佔比 11%。此外文檔的貢獻也佔有 22%的比例，其中包括新增了很多中文文檔和視頻教程，這些文檔的目的就是爲了幫助用戶特別是中文用戶更好地使用 Flink CDC。
1.3 Flink CDC 2.3 技術改進
以下是 Flink CDC 2.3 版本中主要新特性和改進，包括：
- 支持了 Db2 數據源。
- Oracle CDC 支持增量快照。
- MongoDB CDC 支持增量快照。
- MySQL CDC 支持指定位點。
- MySQL CDC 性能優化。
- OceanBase CDC 支持了 OceanBase 的全部數據類型。
- 兼容 Flink 1.15 & 1.16 兩個大版本。
- 提供中文文檔及視頻教程支持。
1.4 Flink CDC 2.3 核心特性解讀
在 Flink CDC 2.3 版本中，有四大核心特性值得深入介紹：
- 新增 Db2 數據源支持。
- MySQL CDC 穩定性提升。
- Oracle CDC 支持增量快照讀取。
- MongoDB CDC 支持增量快照讀取。
下面將爲大家進行詳細講解。
第一部分，Db2 CDC 連接器。Db2 數據庫在國內外都有很多用戶在使用，社區用戶反饋的聲音也比較大，所以在 Flink CDC 2.3 中版本中社區支持了 Db2。
Db2 CDC 的全量數據是通過 SQL 查詢的方式拉取；而增量數據是當表開啓了 Capture Mode 的時候，Db2 會把增量數據的 Changelog 寫到 Change Table 裏，在需要增量數據時，從 Change Table 中拉取 Changelog 即可。這樣 Db2 CDC 就實現了全量數據和增量數據的一致性讀取，在下游也提供了實時的一致性快照。
第二部分，MySQL CDC 穩定性提升，對它的提升主要包括以下四個方面。
- 支持指定位點啓動，包括 timestamp、binlog offset、binlog gtid、earliest-offset 這這幾種方式來指定位點。
- 穩定性提升，包括自動獲取服務器時區；支持全字符集；支持解析更寬容的默認值；邊界條件下的數據一致性問題修復等改進。
- 分片算法優化，包括支持異步分片；支持自定義切分列；分片過程支持 Checkpoint。
- 性能提升，包括 JM 內存優化；TM 全量階段內存優化；Binlog 讀取性能優化。
除了這兩大核心特性，另外兩個重點 Feature 就是 Oracle CDC 和 MongoDB CDC 均對接到了 Flink CDC 的增量快照框架。
Flink CDC 的增量快照框架的來源是 Flink CDC 2.0 版本提供的一個增量快照算法，它提供了無所讀取、併發讀取、斷點續傳三個核心特性。 但當時只支持 MySQL CDC Connector 接入，其他 Connector 接入成本較高，所以社區就把這套算法抽象成了一個框架，叫 Flink CDC 的增量快照框架，方便其他 Connector 接入。之後在 Flink CDC 2.3 版本中，社區便接入了 Oracle 和 MongoDB 兩個數據源。
現在，Oracle 和 MongoDB 都支持在全量階段進行並行讀取。全量讀取完之後，通過無所一致性切換到增量階段。 全量到增量的切換是全自動的，不需要人爲干預。
在接入 Oracle CDC 和 MongoDB CDC 到增量快照框架之後，Flink CDC 的增量快照框架支持的矩陣就變得相當豐富，覆蓋了包括 MySQL、MariaDB、PoloDB、ORACLE、MongoDB 等數據源。
二、基於 Flink CDC 構建現代數據棧
2.1 現代數據棧（Modern Data Stack）
數據棧這個概念在最近幾年比較火熱，特別是在海外數據集成的行業或者圈子裏。首先看一下數據棧相關的兩個概念。
數據棧是一組對原始數據進行採集、轉換和存儲(ETL)的技術或工具的組合，這些工具可以讓數據工程師和分析師能夠提取和清洗數據，將原始數據轉換爲有價值的數據並存儲，然後根據需要進行分析。
現代數據棧是在數據棧的基礎上，使用創新的(如 ELT)或基於雲上數倉/湖的工具或技術的組合，現代數據棧基於雲上構建的特點，具備傳統數據棧很難具備的彈性和擴容優勢，現代數據棧層次清晰有利於垂直領域的工具形成標準的 SaaS 服務，而 SaaS 服務極大地降低了運維和管理成本。
2.2 現代數據棧組件
在剛剛介紹現在數據棧概念的時候，提到了兩個詞，ETL 和 ELT。
ETL 是經典數據集成裏的一個處理過程，即採集、轉換、存儲。以 Flink CDC 爲例，在傳統的數據棧裏做 ETL。Flink CDC 做採集的時候，如果還需要進一步轉換，就通過 Flink 來做，然後 load 到下游存儲。
轉換到現代數據棧 ELT 的架構。還以 Flink CDC 爲例，它負責採集和 load，即幫助數據從數據源採集並 load 到存儲裏，這個存儲包括 Iceberg、Hudi 等等。而轉換一般都圍繞在數據湖或者數據倉庫上，所以可以用其他工具做一些轉換，從而把 E 和 L 提取出來。
2.3 開源現代數據棧
上圖是 State of Data Engineering 2022 map，在這個圖裏可以發現，有很多和現代數據棧或者數據集成領域相關的技術和組件。比如 Airbyte、Fivetran 等等，既有開源的，也有閉源的。
上圖是一個典型的開源現代數據棧，可以發現這個表裏每一行都代表一個垂直領域。比如我們要做數倉，就可以用 rudderstack、Airbyte 等開源數據集成工具來做等等。
2.4 基於 Flink CDC 的現代數據棧
如上圖所示，Flink CDC 是一個非常好的數據集成框架，它目前已經支持了 MySQL、MongoDB、Db2 等豐富的數據源，用戶可以針對自己的需求選擇並對數據進行加工。
那麼如何基於 Flink CDC 構建現代數據棧呢？如上圖所示，數據棧的最底層是數據源，比如 MySQL、PG、Oracle、MongoDB 等等。EL 由 Flink CDC 來做，它負責從數據源裏提取數據，load 到經典的數據倉庫或者數據湖這層。
Transformation 通過 Flink、Spark 在數倉之上做分析，然後通過 Superset、Metabase、Tabular 等等 BI 工具，對其結果進一步加工。加工完之後，最上層是面向終端用戶的，比如各種應用的報表分析、實時大屏、數據應用，這就構成了一個基於 Flink CDC 的現代數據棧。
三、阿里雲內部實踐和改進
3.1 常見業務場景的實踐
場景一，海量 CDC 數據實時 ETL。通過 Flink CDC 表實時讀取源表修改，用在實時作業裏進行一些計算和處理，最終寫入到下游數據倉庫中。比如使用 Flink CDC 源表和其他實時數據流進行 Join，打寬業務表並寫入下游數據庫中。在這樣的使用場景下，同一個作業可能會同時訪問數據庫中的多張表，經常一個作業包含多個 CDC 表，同時持有多個 Binlog Client。
隨着業務規模的不斷擴展，開發的作業數量也會持續增加。但每個作業的 Binlog Client 是獨佔的，無法進行復用，這會使連接到數據庫時 Binlog Client 也持續增加。最終導致數據庫側的壓力持續增加，甚至影響數據庫上承擔的線上業務。
場景二，日誌數據實時入湖入倉。用戶通常會將日誌先匯聚到消息隊列中，比如 Kafka，再從 Kafka 中消費進行分析、歸檔，比如通過 Flink 實時消費日誌數據後，歸檔到下游的數據倉庫或者數據湖中。
在這樣的場景下，用戶開發一個作業的時間會比較長，需要的人力也會很多。首先需要手動創建好下游的存儲表，在開發 SQL 作業時，需要編寫對應的 Source 表，Sink 表的 CREATE TABLE 語句，參照不同連接器的需求，自行定義好表的 Schema 和需要使用的配置，並且這樣的作業無法同步 Schema 的變更。
以上圖左側爲例，實現了從 Kafka_monitor_log 同步到 Hudi_monitor_log 的 Hudi 表的作業編寫。首先要通過 CRATE TABLE 語句創建一張 Kafka 表，並定義好表的三個字段 id、event、level，以及 WITH 參數裏表的一些配置。同樣，在 Hudi 表的定義時還要進行這樣重複的操作。
3.2 常見業務場景的擴展和改進
上圖是阿里雲內部基於 Flink CDC 的現代數據棧。除了前文介紹過的對開源部分的支持，阿里雲內部還進行了一些額外的改進和擴展。
數據源方面，我們不僅支持數據庫，還支持了 Kafka 消息隊列，並且在採集層可以在實時計算 Flink 版中，啓動 Flink CDC 作業進行採集，將數據採集到數據倉庫中。除了常見的開源倉庫對接，也提供了企業級實時數倉 Hologress 和消息隊列 Kafka 的支持。
在計算層，可以在實時計算 Flink 版中進行 SQL 作業的開發和數據分析處理。在分析層，可以藉助各種 BI 工具數據分析，最終對接終端完成報表分析、實時大屏，或其他數據應用。
藉助我們內部基於 Flink CDC 的現代數據棧，解決了數據庫 Flink CDC 數據集成和日誌數據集成兩大場景的痛點。
第一個場景是海量 CDC 數據的實時集成場景。在這個場景中，爲了解決數據庫壓力過大的問題，我們通過提供 Kafka JSON Catalog，結合 CTAS、CDAS 的整庫同步語法，將上游的數據庫的數據同步到 Kafka 中來進行解耦。將數據庫中的熱點表同步到 Kafka 後，後續使用到該表的作業可以直接消費對應的 Kafka Topic，從而降低了源頭數據庫的壓力。
在 CDAS 這樣一個整庫同步的過程中，可以對 Binlog Client 進行復用，這樣 Binlog Client 連接就不再隨着業務的擴展而增加，同時降低了 Binlog 的複製壓力。另外，這樣一個整庫同步的作業，啓動時只會進行一次全量的數據同步，不會每次作業啓動都進行一次全增量的同步，降低了全量階段產生的數據庫查詢壓力。
開發這樣一個整庫同步作業只需要如上圖所示。註冊 Kafka JSON Catalog 和 MySQL Catalog 後，只需要簡單的一條 SQL 就可以完成同步任務開發，節省了開發者的開發時間。
如上圖右側展示，MySQL 數據庫裏包含 Order、User、Address 三張數據表。在啓動了 CDAS 整庫同步作業後，Kafka JSON Catalog 會自動在 Kafka 集羣裏，創建 Order、User、Address 三個 Topic，然後進行 CDAS 作業的啓動，把數據同步到對應的 Topic 中。
在存儲時會以 JSON 格式存儲數據。在 key 部分會存儲對應的數據表主鍵，在 value 部分會存儲除了主鍵以外的其他字段。後續的作業可以直接使用 Kafka 集羣裏的 Kafka 表完成作業的分析和計算。
第二個場景是日誌數據實時入湖入倉。通過 Kafka JSON Catalog 可以簡單的使用 CTAS 或 CDAS 的整庫同步語法同步數據到數據倉庫，如數據湖 Hudi，這個過程極大地簡化日誌數據實時入湖入倉的開發難度，同時實現上我們也對 Kafka Source 進行了合併優化（Source Merge），減少了資源的使用。
上圖展示了從 Kafka_monitor_log 同步日誌數據到 Hudi 數據湖中的過程。在 Kafka_monitor_log 的 Topic 中，key 部分存在一個字段 id，value 部分有三個字段 id，event、level。同步作業會自動解析 Kafka 字段，並在 Hudi 中完成建表的操作，然後啓動作業進行同步。
爲了防止字段產生衝突，Kafka JSON Catalog 在解析 Schema 時，會在 key 的字段名前加 key_ 的前綴，在 value 字段添加 value_的前綴。同時會添加 Kafka 的元數據列，partition，offset 和 timestamp。
這樣一個同步作業開發，只需要像上圖右側這樣寫一條 SQL，即 CREATE TABLE AS 語句，定義好從 Kafka 的哪張表，同步到下游 Hudi 數據湖中的哪張表即可。作業啓動後，會自動在 Hudi 中創建表，並且會同步 Kafka 中的變化字段到 Hudi。極大降低了用戶的開發難度和開發時間。
四、Demo & 未來規劃
4.1 Demo
下面針對之前提到的兩個用戶痛點場景進行 demo 展示，第一個 demo 主要展示：如何將數據庫整庫同步到 Kafka 進行數據打寬，最終處理寫入到 Hudi 數據湖中。第二個 demo 主要展示：Kafka 中的日誌數據如何整庫同步到 Hudi 數據湖中。
Demo 演示：https://www.bilibili.com/video/BV1ej411c7jd
4.2 未來規劃
未來 Flink CDC 2.4 版本在社區中的規劃如下：
- 支持 Batch 模式，優化全量階段的讀取性能。
- 支持限流配置，減少全量階段對數據庫的影響。
- 提供更豐富的監控指標，如已處理的表數量，不同類型變更記錄的處理數量等。
- 後續也會持續提升 CDC Connector 的易用性和性能。如增量框架在全量階段結束後的 reader 資源釋放，更多的數據源應用增量快照框架等。
本文爲阿里雲原創內容，未經允許不得轉載。