基於 Flink CDC 打造企業級實時資料整合方案

首先介紹一下 CDC 技術，CDC 就是 Change Data Capture 的縮寫，意思是變更資料捕獲。如果有一個資料來源的資料隨著時間一直在變化，這種能夠捕獲變更資料的技術就稱之為 CDC。但是在真正的業務生產實踐過程中，通常說的 CDC 都是指面向資料庫的變更，用於捕獲資料庫中某一張表業務，不斷地寫入的新資料、更新的資料、甚至刪除的資料。我們在談到捕獲變更資料的技術時，之所以主要面向資料庫，主要是因為資料庫裡面的資料是業務價值最高的資料，資料庫的變更資料也是業務裡時效性最高、最寶貴的資料。

• 第一，資料同步，比如資料備份、系統容災會用到 CDC。
• 第二，資料分發，比如把資料庫裡面變化的資料分發到 Kafka 裡面，再一對多分發給多個下游。

• 第三，資料整合，不管是在數倉構建還是資料湖構建都需要做一個必要工作資料整合，也就是將資料入湖入倉，同時會有一些 ETL 加工，這個工作中 CDC 技術也是必不可少的應用場景。

從 CDC 底層的實現機制上可以將 CDC 技術分成兩類：基於查詢的 CDC 技術、基於日誌的 CDC 技術。

基於查詢的 CDC 技術。假設資料庫有一張表在不斷更新，我們可以每 5 分鐘查詢一次，查詢裡比如按照更新時間欄位對比一下看看有哪些新的資料，這樣就能獲取到 CDC 資料。這種技術需要基於離線排程查詢，是典型的批處理，沒法保證保障資料的強一致性，也不能夠保障實時性。一個離線排程從行業的實踐來看到 5 分鐘已經是極限了，很難做到分鐘級甚至秒級的離線排程。

基於日誌的 CDC 技術。這就是基於資料庫的變更日誌解析變更的技術，比如大家都知道 MySQL 的資料庫有 Binlog 的機制。基於資料庫的變更日誌的 CDC 技術可以做到實時消費日誌做流處理，上游只要更新一條資料，下游馬上就能感知到這一條資料，可以保障整個資料的強一致性，還可以提供實時的資料。基於日誌的 CDC 技術通常實現複雜度上會比基於查詢的方式更高一些。

• 第一，全增量一體化。
• 第二，實時化。
• 第三，自動化。

• 第四，智慧化。

全增量一體化是相對於全量和增量分別做資料整合，所以全量很好的例子就是一張 MySQL 的表有海量的歷史資料。但同時上游的業務系統源源不斷地在往裡面實時更新，實時更新的那部分就是增量資料，歷史的那部分就是全量資料。

往往這兩部分資料在早期採用不同的工具，比如說全量有國內開源的 DataX，海外有 Apache Sqoop 可以做全量的同步。增量部分比如說國內阿里巴巴開源的 Canal、MySQL、Debezium、InLong 等等開源專案。使用者一般會結合這兩種型別的工具分別做全量資料和增量資料整合，其代價是需要維護很多元件。全增量一體化就是把這些元件儘可能地減少，比如說採用 Flink CDC、InLong 這樣的方式來做一個全增量一體化降低運維壓力。

第二個就是實時化，大家都知道為什麼我們要提實時化，因為業務資料的時效性越高代表價值越高。比如說一些風控業務、策略配置業務如果能做秒級的處理，和兩天之後才能把資料準備好，其帶來的業務效果是完全不一樣的，所以實時化被日趨重視。

自動化是說我們在做全量和增量去結合的時候，全量完了之後需不需要人為干預，全量同步完了以後增量如何保障銜接，這是 CDC 框架提供的自動銜接能力還是需要運維人員手動操作，自動化就是將這類手動操作降低，自動化可以說是降低運維成本和產品體驗提升方面的訴求。

智慧化就是一張 MySQL 裡面的業務表，隨著業務的變化是不斷在變的，不僅是資料在變，裡面的表結構都會變。應對這些場景，資料整合的作業能不能保持健壯，進而能不能自動地、智慧地處理上游的這些變更，這是一個智慧化的訴求，這也是 CDC 資料整合的趨勢。

• 第一，歷史資料規模很大，一些 MySQL 單表能夠達到上億或者基幾十億的級別，在分庫分表的場景，甚至有更大的歷史資料規模。
• 第二，增量資料那部分實時性要求越來越高，比如說現在的湖倉場景都已經需要 5 分鐘級的低延遲。在一些更極端的場景中，比如說風控、CEP 規則引擎等等應用場景甚至需要秒級、亞秒級的延遲。
• 第三，CDC 資料有一個重要的保序性，全量和增量能不能提供一個跟原始的 MySQL 庫裡面一致性的快照，這樣的保序性需求對整個 CDC 的整合框架提出了很大的挑戰。

• 第四，表結構變更，包括新增欄位和已有欄位的型別變更，比如一個欄位業務開發長度升級了，這樣的變更框架能不能自動地支援，這都是 CDC 資料整合的技術挑戰。

針對這些挑戰，我挑選業界現有的主流開源技術方案，包括 Flink CDC、Debezium、Canal、Sqoop、Kettle，我們分別從一下幾個維度來分析，首先是 CDC 的機制，就是底層的機制來看它是日誌的還是查詢的。

其次是斷點續傳，斷點續傳就是全量資料歷史規模很大，同步到一半的時候能不能停下來再次恢復，而不是從頭開始重刷資料。全量同步維度就是框架支不支援歷史資料同步。全增量一體化維度澤是全量和增量過程是框架解決的還是要開發人員手動解決。架構維度則是評價  CDC 框架是可擴充套件的分散式架構，還是單機版。轉換維度衡量的是 CDC 資料在資料整合做ETL的時候往往要做一些資料清洗，比如說做一個大小寫轉換，這個框架能不能很好地支援，比如需要做一些資料的過濾，框架能不能很好地支援，以及另外一個就是這個工具的上下游生態，框架上游支援多少資料來源，下游的計算引擎能支援哪些，支援寫入的湖倉有哪些，因為在選擇一個 CDC 資料整合框架或者工具的時候肯定是結合整個大資料團隊其他產品的架構設計統一考慮的。從上述這幾個維度分析，Flink CDC 在這幾個維度下的表現都非常優秀。

Flink CDC 這個框架在全增量一體化、分散式架構上等維度下都有一些優勢，我們接下來就來解析一下框架底層的核心技術實現，帶著大家去理解 Flink CDC 如何具備這些優勢，以及我們設計的一些初衷。

Flink CDC 是基於資料庫日誌的 CDC 技術及實現了全增量一體化讀取的資料整合框架，配合 Flink 優秀的管道能力和豐富的上下游生態，Flink CDC 可以高效實現海量資料的實時整合。如圖所示，比如說 MySQL 有一張表有歷史的全量資料，也有源源不斷寫入的增量資料、業務更新的增量資料 MySQL 都會先存在自己的 Log 裡面，Flink CDC 既讀取全量資料，又透過基於日誌的 CDC 技術讀取增量資料，並且給下游提供實時一致性的快照，框架提供了全量和增量的自動對接，保證了不丟不重的資料傳輸語義，開發者不用關心底層的細節。

整體來說，Flink CDC 有兩個最為核心的設計；

第一個是增量快照框架。這是我在 Flink CDC 2.0 的時候提出的一個增量快照演算法，後面演變成增量快照框架。左邊的這些資料來源是現在 Flink CDC 社群已經支援或者已經接入的增量快照框架。增量快照框架體現的是什麼能力呢？在讀取資料一張表到全量資料的時候可以做並行讀取，這張表即使歷史資料規模很大，只要增加併發、擴資源，這個框架是具備水平擴容的能力，透過並行讀取可以達到擴容的需求。

第二個是全量和增量是透過無鎖一致性演算法來做到無鎖一致性切換。這其實在生產環境非常重要，在很多 CDC 的實現裡面是需要對 MySQL 的業務表加鎖來獲得資料一致性的，單這個加鎖會直接影響到上游的生產業務庫，一般 DBA 和業務同學是不會同意的，如果用增量快照框架是能夠對資料庫不加鎖的，這是對業務非常友好的設計。

切換到增量階段之後結合 Flink 框架可以做到資源自動釋放的，一般來說全量階段併發是需要很大的，因為資料量很多，增量階段其實寫入 MySQL 上游基本上都是一個單獨的日誌檔案寫入，所以一個併發往往就夠了，多餘的資源這個框架是可以支援自動釋放的。

總結起來如圖所示四個紅色的關鍵短語突出的就是增量快照框架給 Flink CDC 提供的核心能力。

第二個核心設計就是原生對接 Flink 生態。對接 Flink 生態最關心的就是能否無縫使用 Flink 的 SQL API、DataStream API 以及下游。Flink CDC 作為 Flink 作業的上游時，當前我們所有的 connect 都是支援 SQL API 和 DataStream API。

支援 SQL API 的好處是使用者不需要有底層 Java 開發基礎，會寫 SQL 就行了，這其實把一個難度係數很高的 CDC 資料整合交給 BI 開發同學就可以搞定了。DataStream API 則是面向一些更高階的開發者可能要實現一些更復雜、更高階的功能，我們同時提供了 DataStream API，讓更底層的開發者透過這種 DataStream API 可以透過  Java 程式設計的方式來實現整庫同步、Schema Evolution 等高階功能。

在原生對接到 Flink 的生態之後，Flink 上支援的所有下游，比如說訊息佇列、Kafka、Pulsar，資料湖 Paimon 或者傳統的資料庫，Flink CDC 都可以直接寫入。

• 第一，並行讀取。這個框架提供了分散式讀取的能力，Flink CDC 這個框架可以支援水平擴容，只要資源夠，讀取的吞吐可以線性擴充套件。
• 第二，無鎖讀取。對線上的資料庫和業務沒有侵入。
• 第三，全增量一體化。全量和增量之間的一致性保障、自動銜接是框架給解決的，無需人工介入。

• 第四，生態支援。我們可以原生支援 Flink 現有生態，使用者開發部署成本低。如果說開發者已經是一個 Flink 使用者，那他不需要安轉額外的元件，更不需要部署比如 Kafka 叢集，如果是 SQL 使用者只需要將一個 connector jar 包放到 Flink 的 lib 目錄下即可。

還有一個聽眾可能比較感興趣的點，Flink CDC 這個專案是完全開源的，並且從誕生的第一天就是從開源社群出來的，到現在已經從 0.x  版本發到最新的 2.4.2 版本，在全體社群貢獻者的維護下已經走過三年，作為個人興趣專案逐步打磨起來的開源專案，三年的時間這個社群的發展是非常迅速的。這裡講的發展並不只是說 Github Star 4500+ 的非常快速的發展，其實我們更看重的是程式碼 Fork 數和社群貢獻者數量。Fork 數指標表示了有多少組織、多少的開源社群貢獻者在使用 Flink CDC 倉庫，比如說 Apache InLong 這樣的頂級專案都是整合了 Flink CDC。

同時這裡面不乏海外和國內一些頂級的公司也在用我們的專案。最近我們的開源社群來自國內和海外的貢獻者數量超過 100+，這說明我們的開源社群發展還是非常健康的。

介紹完 Flink CDC 的開源社群，有一個點大家會關注到，就是它提供的能力還是偏底層引擎，是比較面向底層開發者，離我們最終的資料整合使用者中間還有一層 gap，這個 gap 就是引擎怎麼形成產品給最終的使用者。有一個事實需要注意到，資料整合的使用者其實不一定懂 Flink，不一定懂 Java，甚至不一定懂 SQL，那麼如何能讓他們使用這個框架？如何提面向使用者的產品來服務好這些使用者？其實很多參與開源的公司、組織都有一些最佳實踐方案。

在阿里雲上，我們 Flink CDC 最主要的業務場景就是CDC資料實時入湖入倉。比如說我的業務庫是 MySQL，當然其他資料庫也一樣，其實就是要把 MySQL 裡面的資料一鍵同步到湖倉裡面，比如說 Paimon、Hologres， 業務場景就是 CDC 資料實時入湖入倉，這個場景下使用者的核心訴求什麼？

我們大致整理了四個關鍵點：需要表結構自動發現，需要表結構的變更自動同步，需要支援整庫同步，需要支援動態加表。

Flink CDC 是一個資料整合框架，在阿里雲上並沒有單獨的 Flink CDC 產品，它是在我們 Serverless Flink，也就是阿里雲實時計算 Flink 版提供了上述的能力。除了在實時計算 Flink 版，在阿里雲另一款產品 Dataworks 上也提供了基於 Flink 的 CDC 資料整合方案。

按照現代資料棧的分層理念，Flink CDC 所在的是 EL 層，分工特別明確。最下面一層是資料來源，Flink CDC 專注於做資料整合，在 ELT 資料整合的模型裡面負責做 E 和 L，當然實踐裡面也會支援一些輕量級的 T，就是 Transform 操作。

在阿里雲實時計算 Flink 版我們設計兩個語法糖，分別是 CDAS（Create Database As Database）和 CTAS（Create Table As Table）。CDAS 就是透過一行 SQL 實現整庫同步，比如說 MySQL 裡面有一個 TPS DS 庫同步至 Paimon 的 ODS 庫就可以搞定。同時我也提供 CTAS，比如說在應對分庫分表的重點業務時，可能對單表要做一些分庫分表的合併，合併到 Paimon 裡面做一個大寬表等等，多個表合成一個表的邏輯。這個表還會做一些事情，比如要推導最寬的表結構，以及分表的表結構變化了之後，在下游最寬的表裡面也要看到對應表結構的同步，這些是透過 CTAS 實現的。

最終的效果是，使用者只需要在實時計算 Flink 裡面寫一行 SQL，當這行 SQL 下面其實做了很多的工作，最終的效果是拉起來了一個 Flink 資料整合作業。大家可以看到上圖中，作業的拓撲裡有四個節點，最前置的一個節點就是讀 MySQL 的 Source 節點，後面三個節點就是對應我們紅框裡面的三張表，自動生成了三個 Sink 節點。對於使用者來說就是寫一行 SQL，便可以實現全增量一體化的 CDC 資料整合。

實時計算 Flink 版裡面提供了預設支援全增量一體化同步。舉一個例子，我有一些歷史全量資料和增量資料，一個 CTAS 語法預設支援全量和增量的資料同步，當然你也可以選擇透過配置不同的引數選擇只同步全量或者只全部增量。

實時計算 Flink 版還支援表同步變更，比如說有一個分庫分表的場景，庫裡有一張名為 user03 的表，業務同學新加了一個欄位 age，後續插入的記錄裡面也多個了一個 age 的欄位，使用者想要的效果是在下游的湖倉裡中自動加列，新的資料能夠自動寫入。對於這樣的需求，CTAS/CDAS 語法均預設就支援。

實時計算 Flink 版支援整庫同步，對於單表同步，每一個表同步都需要寫一行 SQL 對使用者來說還是太費勁，使用者想要的就是儘可能簡單，功能儘可能強大，CDAS 語法糖就是幫使用者幹這件事。比如說原庫裡面有若干張表，只需要寫一行 SQL，我透過捕獲庫裡面所有的表，自動改寫多個 CTAS 語句，然後同步到下游，並且每一張表都支援表結構變更自動同步，源頭這三張表可以各自加列刪列，下游 Paimon 裡的資料自動加列刪列同步。

實時計算 Flink 版還支援同步作業動態加表，在當下 IT 行業降本增效的背景下，儘可能節省資源能大幅降低業務成本。在 CDC 資料整合的場景中，比如說我之前的一個作業裡面、業務庫裡面有 1000 張表，我用了 5CU 資源的作業來同步資料。如果說現在業務庫加了兩張表，這個時候我是新起一個作業還是在原有作業裡面加表呢？這就是我們開發的動態加表功能，它可以直接複用原有作業的 state 和資源，不用新開作業的資源，實現動態地給歷史作業加表。這個功能的效果如上圖所示：MySQL 庫裡面之前有三張表，現在加了一張表，這個歷史同步作業支援把新加的這一張表同步過去，這就是同步作業的動態加表。

上述這個功能是我們在阿里雲內部實踐下來業務效果不錯，資料整合的使用者反饋也比較好的一些企業級 CDC 資料實時整合的方案，分享出來希望可以和同行朋友交流，希望大家可以有收穫。

Demo 演示