基於 Flink CDC 的現代資料棧實踐

摘要：本文整理自阿里雲技術專家，Apache Flink PMC Member & Committer, Flink CDC Maintainer 徐榜江和阿里雲高階研發工程師，Apache Flink Contributor & Flink CDC Maintainer 阮航，在 Flink Forward Asia 2022 資料整合專場的分享。本篇內容主要分為四個部分：
深入解讀 Flink CDC 2.3 版本
基於 Flink CDC 構建現代資料棧
阿里雲內部實踐和改進
Demo & 未來規劃

點選檢視直播回放和演講 PPT

一、深入解讀 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。極大降低了使用者的開發難度和開發時間。