Flink CDC 在大健雲倉的實踐

本文整理自大健雲倉基礎架構負責人、Flink CDC Maintainer 龔中強在 5 月 21 日 Flink CDC Meetup 的演講。主要內容包括：

1. 引入 Flink CDC 的背景
2. 現今內部落地的業務場景
3. 未來內部推廣及平臺化建設
4. 社群合作

點選檢視直播回放 & 演講PDF

一、引入 Flink CDC 的背景

公司引入 CDC 技術，主要基於以下四個角色的需求：

• 物流科學家：需要庫存、銷售訂單、物流賬單等資料用於做分析。
• 開發：需要同步其他業務系統的基本資訊。
• 財務：希望財務資料能夠實時傳送到財務系統，而不是月結前才能看到。
• 老闆：需要資料大屏，通過大屏檢視公司的業務和運營情況。

CDC 是資料捕獲變更的技術。廣義上來說，但凡能夠捕獲資料變更的技術，都能被稱為 CDC。但通常我們說的 CDC 技術主要面向資料庫的變更。

CDC 的實現方式主要有兩種，分別是基於查詢和基於日誌：

• 基於查詢：查詢後插入、更新到資料庫即可，無須資料庫的特殊配置以及賬號許可權。它的實時性基於查詢頻率決定，只能通過提高查詢頻率來保證實時性，而這必然會對 DB 造成巨大壓力。此外，因為是基於查詢，所以它無法捕獲兩次查詢之間資料的變更記錄，也就無法保證資料的一致性。
• 基於日誌：通過實時消費資料的變更日誌實現，因此實時性很高。而且不會對 DB 造成很大的影響，也能夠保證資料的一致性，因為資料庫會將所有資料的變動記錄在變更日誌中。通過對日誌的消費，即可明確知道資料的變化過程。它的缺點是實現相對複雜，因為不同資料庫的變動日誌實現不一樣，格式、開啟方式以及特殊許可權都不一樣，需要針對每一種資料庫做相應的適配開發。

正如 Flink 的宣言 “實時即未來”，在如今的大背景下，實時性是亟待解決的重要問題。因此，我們將主流 CDC 基於日誌的技術做了對比，如上圖所示：

• 資料來源：Flink CDC 除了對傳統的關係型資料庫做到了很好的支援外，對文件型、NewSQL（TiDB、OceanBase） 等當下流行的資料庫都能夠支援；Debezium 對資料庫的支援相對沒有那麼廣泛，但是對主流的關係型資料庫都做到了很好的支撐；Canal 和 OGG 只支援單一的資料來源。
• 斷點續傳：四種技術都能夠支援。
• 同步模式：除了 Canal 只支援增量，其他技術均支援全量 + 增量的方式。而全量 + 增量的方式意味著第一次上線時全量到增量的切換過程全部可以通過 CDC 技術實現，無須人為地通過全量的任務加上增量的 job 去實現全量 + 增量資料的讀取。
• 活躍度：Flink CDC 擁有非常活躍的社群，資料豐富，官方也提供了詳盡的教程以及快速上手教程；Debezium 社群也相當活躍，但資料大多是英文的；Canal 的使用者基數特別大，資料也相對較多，但社群活躍度一般；OGG 是 Oracle 的大資料套件，需要付費，只有官方資料。
• 開發難度：Flink CDC 依靠 Flink SQL 和 Flink DataStream 兩種開發模式，尤其是 Flink SQL，通過非常簡單的 SQL 即可完成資料同步任務的開發，開發上手尤為簡單；Debezium 需要自己解析採集到的資料變更日誌進行單獨處理，Canal 亦是如此。
• 執行環境依賴：Flink CDC 是以 Flink 作為引擎，Debezium通常是將 Kafka connector 作為執行容器；而 Canal 和 OGG 都是單獨執行。
• 下游豐富程度：Flink CDC 依靠 Flink 非常活躍的周邊以及豐富的生態，能夠打通豐富的下游，對普通的關係型資料庫以及大資料儲存引擎 Iceberg、ClickHouse、Hudi 等都做了很好的支援；Debezium 有 Kafka JDBC connector， 支援 MySQL 、Oracle 、SqlServer；Canal 只能直接消費資料或將其輸出到 MQ 中進行下游的消費； OGG 因為是官方套件，下游豐富程度不佳。

二、現今內部落地的業務場景

• 2018 年之前，大健雲倉資料同步的方式為：通過多資料應用定時同步系統之間的資料。
• 2020 年之後，隨著跨境業務的飛速發展，多資料來源應用經常打滿 DB 影響線上應用，同時定時任務的執行順序管理混亂。
• 因此， 2021 年我們開始調研選型 CDC 技術，搭建了小型試驗場景，進行小規模的試驗。
• 2022 年，上線了基於 Flink CDC 實現的 LDSS 系統庫存場景同步功能。
• 未來，我們希望依託 Flink CDC 打造資料同步平臺，通過介面的開發和配置完成同步任務的開發、測試和上線，能夠全程線上管理同步任務的整個生命週期。

LDSS 庫存管理的業務場景主要有以下四種：

• 倉儲部門：要求倉庫的庫存容量和商品品類分佈合理，庫存容量方面，需要留一些 buffer 以防突如其來的入庫單導致爆倉；商品品類方面，季節性的商品庫存分配不合理導致熱點問題，這必將給倉庫的管理帶來巨大挑戰。
• 平臺客戶：希望訂單處理及時，貨物能夠快速、精準地交到客戶手上。
• 物流部門：希望能夠提升物流效率，降低物流成本，高效利用有限的運力。
• 決策部門：希望 LDSS 系統能夠對在何時何地新建倉庫提供科學的建議。

上圖為 LDSS 庫存管理分單場景架構圖。

首先，通過多資料來源同步的應用向下拉取倉儲系統、平臺系統以及內部 ERP 系統資料，將所需資料抽取到 LDSS 系統的資料庫中，以支撐 LDSS 系統訂單、庫存、物流三大模組的業務功能。

其次，需要產品資訊、訂單資訊以及倉庫資訊才能進行有效的分單決策。多資料來源定時同步任務基於 JDBC 查詢，通過時間做篩選，同步變更的資料到 LDSS 系統中。 LDSS 系統基於這些資料做分單決策，以獲得最優解。

定時任務同步的程式碼，首先需要定義定時任務、定義定時任務的類、執行方法以及執行間隔。

上圖左側為定時任務的定義，右側是定時任務的邏輯開發。首先，開啟 Oracle 資料庫進行查詢，然後 upsert 到 MySQL 資料庫，即完成了定時任務的開發。此處以接近原生 JDBC 的查詢方式，將資料依次塞到對應的資料庫表中，開發邏輯十分繁瑣，也容易出現 bug。

因此，我們基於 Flink CDC 對其進行了改造。

上圖為基於 Flink CDC 實現的實時同步場景，唯一的變化是將此前的多資料來源同步應用程式換成了 Flink CDC 。

首先，通過 SqlServer CDC、MySQL CDC、Oracle CDC 分別連線抽取對應倉儲平臺、 ERP 系統資料庫的表資料，然後通過 Flink 提供的 JDBC connector 寫入到 LDSS 系統的 MySQL 資料庫中。能夠通過 SqlServer CDC、MySQL CDC、Oracle CDC 將異構資料來源轉化為統一的 Flink 內部型別，再往下游寫。

此架構相比於之前的架構，對業務系統沒有侵入性，而且實現較為簡單。

我們引入了 MySQL CDC 和 SqlServer CDC 分別連線 B2B 平臺的 MySQL 資料庫以及倉儲系統的 SqlServer 資料庫，然後將抽取到的資料通過 JDBC Connector 寫入到 LDSS 系統的 MySQL 資料庫。

通過以上改造，得益於 Flink CDC 賦予其實時的能力，不需要管理繁雜的定時任務。

基於 Flink CDC 同步程式碼的實現分為以下三步：

1. 第一步，定義源表 —— 需要同步的表；
2. 第二步，定義目標表 —— 需要寫入資料的目標表；
3. 第三步，通過 insert select 語句，即可完成 CDC 同步任務的開發。

上述開發模式非常簡單，邏輯清晰。此外，依託 Flink CDC 的同步任務和 Flink 架構，還獲得了失敗重試、分散式、高可用、全量增量一致性切換等特性。

三、未來內部推廣及平臺化建設

上圖為平臺架構圖。

左側 source 是由 Flink CDC + Flink 提供的源端，能夠通過豐富的源端抽取資料，通過資料平臺上的開發寫入到目標端。目標端又依託於 Flink 的強大生態，能夠很好地支撐資料湖、關係型資料庫、MQ 等。

Flink 目前有兩種執行方式，一種是國內比較流行的 Flink on Yarn，另一種是 Flink on Kubernets。中間部分的資料平臺向下管理 Flink 叢集，以向上支撐 SQL 線上開發、任務開發、血緣管理、任務提交、線上 Notebook 開發、許可權和配置以及對任務效能的監控和告警，同時也能夠對資料來源做到很好的管理。

資料同步的需求在公司內部特別旺盛，需要通過平臺來提高開發效率，加快交付速度。而且平臺化之後，可以統一公司內部的資料同步技術，收攏同步技術棧，減少維護成本。

平臺化的目標如下：

1. 能夠很好地管理資料來源、表等元資訊；
2. 任務的整個生命週期都可以在平臺上完成；
3. 實現任務的效能觀測以及告警；
4. 簡化開發，快速上手，業務開發人員經過簡單培訓即可上手開發同步任務。

平臺化能帶來以下三個方面的收益：

1. 收攏資料同步任務，統一來管理；
2. 平臺管理維護同步任務的全生命週期；
3. 專門的團隊負責，團隊能夠專注前沿的資料整合技術。

有了平臺之後，即可快速落地應用更多的業務場景。

• 實時數倉：希望通過 Flink CDC 以支援更多實時數倉的業務場景，藉助 Flink 強大的計算能力做一些資料庫的物化檢視。將計算從 DB 裡解脫出來，通過 Flink 的外部計算再重新寫回資料庫，以加速平臺應用的報表、統計、分析等實時應用場景。
• 實時應用：Flink CDC 能夠從 DB 層捕獲變更，因此可以通過 Flink CDC 實時更新搜尋引擎中的內容，實時向財務系統推送財務和核算資料。因為大部分財務系統的資料都需要業務系統通過跑定時任務以及經過大量關聯、聚合、分組等操作才能計算出來，再推送到財務系統中。而藉助 Flink CDC 強大的資料捕獲能力，再加上 Flink 的計算能力，將這些資料實時地推送到核算系統和財務系統，就能夠及時發現業務的問題，減少公司的損失。
• 快取：通過 Flink CDC，能夠構建一個脫離於傳統的應用之外的實時快取，對於線上應用的效能有極大的提升。

有了平臺的助力，相信 Flink CDC 能夠在公司內部更好地釋放它的能力。

四、社群合作

我們希望能與社群開展多元化的合作，以提升我們的程式碼質量以及公司的開源合作能力。社群合作主要將通過三個方面展開：

• 第一，開源共建。希望能夠有更多機會與同行交流分享 Flink CDC 在公司落地實踐的經驗以及接入的場景，也會在內部開展培訓 Flink CDC 技術，通過培訓讓大家瞭解 Flink CDC 技術，並在實際工作中能夠通過這項技術來解決更多的業務痛點。

目前公司和社群的合作共建已取得一些成果，公司向社群貢獻了 SqlServer CDC Connector 以及合作完成了 TiDB CDC Connector。

• 第二，服務社群。培養部門開發的開源合作能力，並將公司內部版本的特性貢獻給社群，只有經過社群廣大使用者的打磨，特性才能更加穩定合理。此外，也希望能夠在 schema evolution、turning performance、整庫同步的方向與社群開展緊密合作。

• 第三，探索方向。相信 Flink CDC 不會滿足於當下的成就，必定會繼續向更遠的目標前進。所以希望能夠與社群共同探索發掘 Flink CDC 更多可能的方向。

近期公司與社群的合作是：將 SqlServer CDC 基於併發無鎖框架實現的特性貢獻給社群。

上圖展示了 SqlServer CDC 的原理。

首先， SqlServer 會將資料變更記錄到 transaction log 中，通過捕獲的程式去匹配 log 中開啟 CDC table 的 log 日誌，將匹配到的日誌經過轉化後插入到 CDC 生成的 change tables 中，最終由 SqlServer CDC 呼叫 CDC query function 實時獲取 insert、update、delete 以及 DDL 語句，然後轉化成 Flink 內部的 OpType 和 RawData 做計算、入湖等操作。

社群同學使用了當前版本的 SqlServer CDC 後，主要反饋的問題有以下三個：

1. 快照過程中鎖表：鎖表操作對於 DBA 和線上應用都是不可忍受的， DBA 無法接受資料庫被夯住，同時也會影響線上應用。
2. 快照過程中不能 checkpoint：不能 checkpoint 就意味著快照過程中一旦失敗，只能重新開始跑快照過程，這對於大表非常不友好。
3. 快照過程只支援單併發：千萬級、上億級的大表，在單併發的情況下需要同步十幾甚至幾十個小時，極大束縛了 SqlServer CDC 的應用場景。

我們針對上述問題做了實踐和改進，參考社群 2.0 版本 MySQL CDC 併發無鎖演算法的思想，對 SqlServer CDC 進行了優化，最終實現了快照過程中無鎖，實現一致性快照；快照過程中支援 checkpoint ；快照過程中支援併發，加速快照過程。在大表同步的情況下，併發優勢尤為明顯。

但是由於 2.2 版本社群將 MySQL 的併發無鎖思想抽象成了統一公共的框架，SqlServer CDC 需要重新適配這套通用框架後才能貢獻給社群。

問答

Q：需要開啟 SqlServer 自己的 CDC 嗎？

A：是的，SqlServer CDC 的功能就是基於 SqlServer 資料庫自己的 CDC 特性實現的。

Q：物化檢視通過什麼方式去重新整理定時任務觸發器？

A：通過 Flink CDC 將需要生成物化檢視的 SQL 放在 Flink 裡執行，通過原表的變動觸發計算，然後同步到物化檢視表裡。

Q：平臺化是怎麼做的？

A：平臺化參考了社群眾多的開源專案以及優秀的開源平臺，比如 StreamX、DLink 等優秀的開源專案。

Q：SqlServer CDC 在消費 transaction log 時有瓶頸嗎？

A：SqlServer 並沒有直接消費 log，其原理是 SqlServer capture process 去匹配 log 內哪些表開啟了 CDC ，然後將這些表從日誌裡撈到開啟 CDC 表的變更資料，再轉插到 change table 裡，最後通過開啟 CDC 之後資料庫生成的 CDC query function 獲取到資料的變更。

Q：Flink CDC 高可用如何保障同步任務過多或密集處理方案？

A：Flink 的高可用依賴於 Flink 特性比如 checkpoint 等來保證。同步任務過多或處理方案密集的情況，建議使用多套 Flink 下游叢集，然後根據同步的實時性區分對待，將任務釋出到相應的叢集中。

Q：中間需要 Kafka 嗎？

A：取決於同步任務或數倉架構是否需要將中間資料做 Kafka 落地。

Q：一個資料庫中有多張表，可以放到一個任務裡執行嗎？

A：取決於開發方式。如果是 SQL 的開發方式，要實現一次性寫多表只能通過多個任務。但 Flink CDC 提供了另外一種比較高階的開發方式 DataStream ，可以將多表放到一個任務裡執行。

Q：Flink CDC 支援讀取 Oracle 從庫的日誌嗎？

A：目前還無法實現。

Q：通過 CDC 同步後兩個端的資料質量如何監控，如何比對？

A：目前只能通過定時抽樣來做資料質量的檢查，資料質量問題一直是業內比較棘手的問題。

Q：大健雲倉用的什麼排程系統？系統如何與 Flink CDC 集合？

A：使用 XXL Job 作為分散式的任務排程，CDC 沒有用到定時任務。

Q：如果採集增刪表，SqlServer CDC 需要重啟嗎？

A：SqlServer CDC 目前不支援動態加表的功能。

Q：同步任務會影響系統效能嗎？

A：基於 CDC 做同步任務肯定會影響系統效能，尤其是快照過程對資料庫會有影響，進而影響應用系統。社群將來會做限流、對所有 connector 做併發無鎖的實現，都是為了擴大 CDC 的應用場景以及易用性。

Q：全量和增量的 savepoint 怎麼處理？

A：（未通過併發無鎖框架實現的聯結器）全量過程中不可以觸發 savepoint，增量過程中如果需要停機發布，可通過 savepoint 恢復任務。

Q：CDC 同步資料到 Kafka ，而 Kafka 裡面存的是 Binlog ，如何儲存歷史資料和實時資料？

A：將 CDC 同步的資料全部 Sync 到 Kafka，保留的資料取決於 Kafka log 的清理策略，可以全部保留。

Q：CDC 會對 Binlog 的日誌操作型別進行過濾嗎？會影響效率嗎？

A：即使有過濾操作，對效能影響也不大。

Q：CDC 讀 MySQL 初始化快照階段，多個程式讀不同的表會有程式報錯無法獲取鎖表的許可權，這是什麼原因？

A：建議先檢視 MySQL CDC 是不是使用老的方式實現，可以嘗試新版本的併發無鎖實現。

Q：MySQL 上億大表全量和增量如何銜接？

A：建議閱讀雪盡老師在 2.0 的相關部落格，非常簡單清晰地介紹了併發無鎖如何實現一致性快照，完成全量和增量的切換。

點選檢視直播回放 & 演講PDF

更多 Flink 相關技術問題，可掃碼加入社群釘釘交流群
第一時間獲取最新技術文章和社群動態，請關注公眾號～

活動推薦

阿里雲基於 Apache Flink 構建的企業級產品-實時計算Flink版現開啟活動：
99 元試用 實時計算Flink版（包年包月、10CU）即有機會獲得 Flink 獨家定製衛衣；另包 3 個月及以上還有 85 折優惠！
瞭解活動詳情：https://www.aliyun.com/produc...