導讀：Flink CDC如何解決海量數據集成的痛點？如何加速海量數據處理？Flink CDC社區如何運營？如何參與社區貢獻？
今天的介紹會圍繞下面四點展開：
- Flink CDC 技術
- 海量數據集成的痛點
- Flink CDC 如何加速海量數據集成
- 開源社區發展
分享嘉賓｜徐榜江 阿里巴巴 技術專家
編輯整理｜張德通 DataFun志願者
出品平台｜DataFunSummit
01
Flink CDC 技術
廣義的概念上, 能夠捕獲數據變更的技術, 我們都可以稱為 CDC(Change Data Capture)。通常我們說的 CDC 技術主要面向資料庫的變更, 是一種用於捕獲資料庫中數據變更的技術。
CDC 技術主要有三類應用場景:
①數據同步: 用於數據備份、系統容災
②數據分發: 一個數據源分發給多個下游
③數據採集: 面向數據倉庫/數據湖的 ETL 數據集成
業界 CDC 的技術方案非常多，從原理上可以分為兩大類：一類是基於查詢的 CDC，一類是基於日誌的 CDC。
基於查詢的 CDC 優點是實現簡單，是通過批處理實現的，需要依賴離線調度，不能保證數據強一致性和實時性。基於日誌的 CDC 實現比較複雜，但是可以實時消費日誌，流式處理，可保證數據一致性和實時性。
與開源 CDC 方案 Debezium、DataX、Canal、Sqoop、Kettle 和閉源 OGG 等方案對比，Flink CDC 在功能和架構方面優勢明顯。Flink CDC 支持全量和增量一體化同步、斷點續傳，支持分布式架構、支持事務，生態友好。
Flink CDC 支持全量和增量數據一體化同步，首先讀取資料庫中表的歷史全量數據，再無縫銜接到讀取表的增量數據，為用戶提供實時的、一致性的快照。
整個過程中，全量同步與增量讀取無縫銜接，不需要用戶進行手動干預或切換。
比如一張表中有全量的歷史數據，同時增量數據也在不斷寫入。增量的 update 數據會在實時一致性快照內進行更新，insert 的數據則會追加到實時一致性快照中。
Flink CDC 核心技術就是提供實時的的全增量一體化同步。
--
02
海量數據集成的痛點
傳統數據入倉架構1.0仍然有不少公司在使用，該方案通過 DataX、Sqoop 將數據以全量同步的方式寫入到 HDFS 再導入到 Hive 構建離線數倉。
這種方式需要按批從 MySQL 等業務資料庫拉取數據，通常一天做一次數據同步。拉取數據時會拖慢業務資料庫，同時由於其按批同步、影響業務資料庫性能的特點，導致數據延遲高，且該架構擴展性差，當大表越來越多、業務擴展越來越快時，拉取全表的性能會成為數據同步的瓶頸，導致數據延遲增加。
傳統數據入倉架構2.0則是典型的 Lamdba 架構，把全量數據和增量數據分為兩條鏈路。依然使用 DataX 和 Sqoop 做全量數據同步，增量同步則使用 Canal 或 Debezium 將數據寫入 Kafka，再定時回流將數據寫入 HDFS，通過全量表和增量表定時合併數據，得到最終表。
傳統數據入倉架構2.0的鏈路長、組件多，可維護性差，且實時和增量同步之間互相割裂，依然存在數據產出延遲高、無法保證實時性的問題。
在 ETL 分析的場景下，傳統 CDC ETL 分析的數據處理鏈路如圖所示：用戶會將資料庫內的 CDC 數據通過 Debezium、Canal 等工具進行採集，傳入 Kakfa 後經過 Spark 或Flink等計算引擎的加工、處理，寫入下游存儲。
Debezium 是單並發模型，且存在鎖的問題，可能影響吞吐量；Canal 只支持讀取增量數據，全量數據導入需要額外引入 DataX 或 Sqoop 組件，全量和增量銜接還需要用戶手動合併數據。
傳統ETL的整個鏈路依賴組件多，維護成本高，單並發性能差，全量增量割裂。
作為新一代數據集成框架，Flink CDC是如何處理、加速海量數據集成過程的？
--
03
Flink CDC 如何加速海量數據集成
1. 全、增量一體的分布式數據集成框架
Flink CDC 的核心是增量快照讀取算法。熟悉 Flink CDC 社區的同學應該了解，Flink CDC 早期使用 Debezium 做了一個單並發的版本。由於 Debezium 會使用鎖而且是單並發的，在海量數據的場景下吞吐量受限。在全量同步階段若發生失敗，Debezium 會重跑整個任務，如一張表有上億條記錄，全量同步耗時1天，在運行了23小時後任務失敗，此時 Debezium 只能重跑任務，這樣的重試在用戶的生產環境難以容忍、難以承載海量數據集成的需求。
針對這些缺點，Flink CDC 通過快照讀取算法進行了改進。Flink CDC 引入了無鎖算法，MySQL 生產庫不需要上鎖即可實現數據集成，降低了風險和資料庫壓力。Flink CDC 支持並發讀取，在全量數據同步階段可以更快地完成海量數據同步，可以通過水平擴展節點數來加快數據處理速度、加速海量數據的處理。Flink CDC 實現了斷點續傳，比如同步數據需要1天時間，但是同步任務運行23小時後失敗，不需要重跑整個數據同步任務，只需要從發生錯誤的位置重跑即可。
Flink CDC 增量快照框架處理流程如下圖所示：全量階段把表分為一個個切片（chunk），每個分片被分配到不同task，並行地讀取。全量讀取完成後，通過無鎖算法全自動地完成全量同步到增量同步的無鎖一致性切換。
增量階段，資料庫的寫入相對較少，如 MySQL 的 BInlog 只有一個文件在寫，Flink框架提供了縮容能力，可釋放多餘的 Task 減少資源消耗，圖上中的 Task1、Task2 被釋放，達到資源伸縮的效果。
Flink CDC 2.0 增量快照讀取算法實現後，我們進行了 TPC-DS 的讀取測試。1T標準數據集中的一張 customer 表，單表數據量 6500 萬。用 Debezium 單並發讀取需要 89 分鐘，使用 Flink CDC 時 8 個並發讀取，13 分鐘便可完成讀取，吞吐量提升了 6.8 倍，當然全量同步階段的並發性能提升和並發數是線性相關的。如果用戶需要更大吞吐量，可通過提高並發數達到提升數據同步速度的目的。
Flink CDC 可以很好地把數據導入到 Hudi、Iceberg 和 OLAP 系統，使用 Flink CDC 代替傳統的數據入倉、入湖架構，如下圖所示，大大簡化了入湖鏈路。
Flink CDC 的數據同步不影響業務穩定性，可以做到分鐘級別產出，適合當今海量數據場景和時效性要求高的業務。Flink CDC 的分鐘級別數據產出，配合 Hudi 可實現近實時的分析，可滿足絕大部分業務分析需求，全量+增量一體化數據同步，並發讀取等特性對業務更加友好。
Flink CDC 可以替代傳統 ETL 架構，只需通過 Flink CDC 即可完成採集、計算、傳輸，並且全增量一體化無需人工介入切換模式。Flink CDC 實時地加工數據，在 Flink CDC 內完成 ETL 過程後可將數據導入到下游的 Kafka、消息隊列、數據湖、OLAP等，對數據進行進一步分析處理。Flink CDC 可並發讀取，數據採集和處理速度快，整個 ETL 鏈路短、組件少，方便維護。
Flink SQL 具有強大的 transformation 能力，通過 Flink SQL 即可完成ETL 中的數據轉換，Flink CDC 也把 Flink SQL 這部分能力對外暴露給用戶。
接入Flink CDC後，用戶 ETL 可以通過 Flink SQL 實現 select、where、not in 等過濾處理，使用 group by、Top-N 等更複雜的聚合操作，還可以對數據做 Join 打寬。這些是傳統的 ETL 工具不具備的能力。
2. 多樣的業務場景支持
Flink可以支持多種業務場景下的各種需求：
①異構數據源集成。
②由於業務發展等各種緣故，有的業務資料庫是基於 MySQL 的、有的業務基於 PostgreSQL，需要連接兩張表做打寬分析。此時引入 Flink CDC 可以做 Streaming Join 的流式加工，將打寬後的表寫入到其他存儲中。Flink CDC 支持多種數據源的 connector，使用 Flink CDC 可以很方便地完成異構數據源的融合。整個過程中，只需要寫5行 Flink SQL 即可實現異構數據源集成。
以上圖左側的 SQL 為例，首先聲明一張 MySQL CDC 訂單表，再聲明一張 MySQL CDC 的產品表，再聲明一張 PostgreSQL CDC 的物流表，最後聲明一張 Hudi 結果表。只需要通過 Flink SQL 即可以完成 Streaming Join 獲得大寬表，用戶不需要了解底層技術、BI或數據分析人員也可以完成複雜的實時數據處理。
（1）支持分庫分表的集成
當業務規模大到一定程度時，基本都會使用 MySQL 的分庫分表方案。但傳統的數據集成方案中，要把分庫分表後的數據同步到下游數倉非常麻煩，需要一張一張表地同步。而使用 Flink CDC 可以很簡單地完成分庫分表後的數據同步。下圖中左側的 SQL 是把分庫分表的 MySQL 數據同步到 Hudi，以此為例，只需3行 Flink SQL 即可實現。
第一行 Flink SQL 是聲明 Flink CDC 的用戶表。資料庫、表參數支持正則表達式，用於匹配多個庫和多張表，user_source 表即代表分庫分表內的數據。第二行 SQL 聲明了 Hudi 結果表，其中 database_name、table_name 是表的元數據信息，通過 Flink SQL 的 Metadata Column 語法支持用戶獲取表的元數據信息。分庫分表數據同步到下游存儲中後可以帶著這些信息，比如 Hudi 表中的記錄可以帶上這些信息，只需要三行 SQL 便實現了分庫分表的數據集成。Flink CDC 社區用戶群中，有些中大型公司使用分庫分表的數據同步能達到上萬個表，這一功能很好地滿足了海量數據集成場景下的剛需。
（2）支持豐富的 Flink 生態
Flink CDC 擁有豐富的生態，支持多種數據源。如下圖中展示了一部分數據源，Flink CDC 支持關係型、非關係型資料庫，支持雲上資料庫和傳統的資料庫。Flink CDC 在數據源方面的支持已經非常完備，Flink CDC 社區也將不斷豐富更多數據源。
依託於Flink，用戶還可以根據場景，選擇 SQL API 或 DataStream API實現自己的需求。SQL API 可以讓 BI 和分析師輕鬆完成數據處理需求。DataStream API 被很多用戶用來做整庫同步、分發數據到不同下游，具備一定開發能力的用戶可以選擇 DataStream API 方案。Flink CDC 藉助了 Flink 豐富的生態，在數據集成時對下游的選擇有很大的靈活性和擴展空間。
--
04
Flink CDC 如何加速海量數據集成
Flink CDC 是一個完全開源的項目，遵循的 Apache Licence 2.0 也是對用戶最友好的開源協議。過去一年中，Flink CDC 發布了1.X、2.0、2.1、2.2版本，每個版本的 Commit 數和 contributor 數越來越多，我們最新版本的 commit 數已經達到近 120 個；貢獻者達到了 35 人，來自國內外、各中大型公司。
Flink CDC 2.0 是一個里程碑版本，支持了增量快照讀取算法、支持了水平擴展、斷點續傳等功能。
在2.1版本中，我們對 MySQL 這種百億級超大表達到了生產環境的支持，完成了 MySQL 的全類型，新增了 Oracle 和 MongoDB 數據源。Flink CDC 2.2 版本增加了 OceanBase、PolarDB-X、SQLServe、TiDB 四種數據源，同時提供了兼容 Flink 1.13 和 Flink 1.14 的功能，同一個 CDC connector 既可以在 Flink 1.13 的集群上運行，也可以在 Flink 1.14 集群運行，用戶不需要去做定製化適配，非常友好。
2.2版本還提供了增量快照讀取框架。此前只有 MySQL CDC 可以實現增量快照讀取算法，這一框架可以讓其他數據源也可以更方便地擴展、實現增量快照讀取。目前 OceanBase 社區的增量快照讀取已經有開發者完成了， SqlServer 等資料庫的增量快照讀取的 PR、Issue 都已經陸續開放。2.2版本支持了動態加表，Flink CDC 的數據同步作業可以動態地添加表，讓數據同步任務不停止可增加，方便維護，減少新建數據同步任務的工作。
作為一個開源社區，社區的文檔是非常重要的，Flink CDC 提供了獨立的社區文檔網站，前端頁面由貢獻者開發。我們提供了完善的入門文檔和FAQ手冊，FAQ手冊提供中文英文版本，幫助用戶降低上手門檻。
上手文檔中的 demo 都是通過 docker 容器運行的，不需要任何依賴，只需要在電腦上裝好 docker 即可體驗 Flink CDC。
在 GitHub 上，Flink CDC 項目放在 Flink 商業公司 ververica 的 Flink CDC connector 項目下，目前有2.3k star、700多Fork，活躍Issue 300+，已經解決掉400多Issue。
GitHub star 數量在 2021 年達到了 300% 增長。
為了方便大家交流討論，我們為國內用戶建立了釘釘群，這個群從2021年7月 Flink Meet UP 上倍創建以來，人數從4個人增長到4700，可見 Flink CDC 社區發展潛力，同時我們也歡迎更多感興趣的同學加入社區做更多貢獻。
--
05
Q&A環節
Q1：全量數據同步階段對資料庫是否有壓力？
A1：全量階段壓力主要是查詢壓力，Flink CDC 的查詢基本都是有索引的，其實對資料庫壓力還好，也可以通過並發控制，目前社區也在調研限流方案。
Q2：是否只支持全量同步？
A2：目前 Flink CDC 禁用了單獨的全量同步。目前社區也在調研，如果單獨的全量同步需求很大，社區會考慮以合適的方式支持單獨增量同步。
Q3：能捕獲動態 DDL 嗎？
A3：Flink CDC 支持同步 DDL，有一定開發能力的用戶會希望捕獲 DDL，DataStream API 可以拉到 DDL 信息進行處理，Flink CDC 可以保證順序輸出 DDL。
Q4：License 會變嗎？
A4：不會，可能會被放到 Flink Extended 項目下，具體時間要和 Flink 社區討論。
Q5：全量同步階段，數據漏斗進入內存合併增量 Binlog，是否存在 OOM風險？
A5：我們對數據進行了切片，切片大小用戶可配置，默認是 8000 多條記錄一個切片，占用內存不大。該過程短暫，source 中數據合併完成後數據馬上就會發送。
Q6：Flink CDC 可以保證數據質量嗎？
A6：用 Flink CDC 即可不需要手動做去重，sink 端和 source 端都可以保證 exactly once，即不會多發也不會少發。
Q7：Flink CDC 開箱即用有計劃嗎？
A7：Flink CDC 暫時不考慮生產化地開箱即用，Flink CDC 更偏向平台，因此目前只考慮為用戶上手提供開箱即用方案。
Q8：如果有物理刪除 Binlog 行為，Flink CDC 怎麼處理？
A8：需要用戶把物理刪除 Binlog 控制在 CDC 同步的點位之前，如果用戶刪除了還沒有消費到的 Binlog，Flink CDC 或其他同步工具都是無法處理的。
今天的分享就到這裡，謝謝大家。
｜分享嘉賓｜
徐榜江｜阿里巴巴 技術專家
阿里巴巴技術專家，Apache Flink Committer & Flink CDC Maintainer。
｜DataFun新媒體矩陣｜
｜關於DataFun｜
專注於大數據、人工智慧技術應用的分享與交流。發起於2017年，在北京、上海、深圳、杭州等城市舉辦超過100+線下和100+線上沙龍、論壇及峰會，已邀請超過2000位專家和學者參與分享。其公眾號 DataFunTalk 累計生產原創文章800+，百萬+閱讀，15萬+精準粉絲。