ChunJun（原 FlinkX）是一個基於 Flink 提供易用、穩定、高效的批流統一的資料整合工具。2018 年 4 月，秉承著開源共享的理念，數棧技術團隊在 github 上開源了 FlinkX，承蒙各位開發者的合作共建，FlinkX 得到了快速發展。

兩年後的 2022 年 4 月，技術團隊決定對 FlinkX 進行整體升級，並更名為 ChunJun，希望繼續和各位優秀開發者合作，進一步推動資料整合 / 同步的技術發展。

因該文創作于于 FlinkX 更名為 ChunJun 之前，因此文中仍用 FlinkX 來進行分享，重要的事情說三遍：

FlinkX 即是 ChunJun

FlinkX 即是 ChunJun

FlinkX 即是 ChunJun

進入正文分享⬇️⬇️⬇️

分享嘉賓：馮江濤 中國移動雲能力中心

編輯整理：陳凱翔 亞廈股份

出品平臺：DataFunTalk

導讀：

隨著本地資料遷移上雲、雲上資料交換等多源異構資料來源資料同步需求日益增多，傳統透過編寫指令碼進行資料同步的方式投入高、效率低、運維管理困難；在公司內部，多款移動雲資料庫和大資料類產品根據客戶需求迫切希望整合資料同步能力，但缺少易用的框架，從 0 開始研發投入研發成本高。

針對上述問題，基於 FlinkX 多源異構資料同步框架，實現了使用者自建和移動雲上訊息中介軟體、資料庫、物件儲存等多種異構資料來源雙向讀寫，基於社群版實現了 On k8s 改造，需簡單配置即可滿足使用者資料快速上雲及雲上資料高效交換需求，降低開發運維投入，該成果已在移動雲至少 3 款產品中應用。

本文的主要內容包括：

FlinkX 簡介

功能及原理

雲上入湖改造

展望

一、FlinkX 簡介

1. 背景介紹

現在市面上有很多種資料庫產品，包括傳統的 RDB 和大資料相關的 NoSQL，一般企業稍微大一點規模都會同時有各種各樣的資料庫。為什麼會有這麼多資料來源？是因為不同的資料來源適應不同的場景，但這麼多資料來源會給開發帶來困難。

傳統的企業業務庫多數還是 MySQL，Oracle 這種傳統 RDB，如果進行簡單的增刪改查是沒有問題的，但遇到大批次的資料計算這些 RDB 就無法支援了，所以就需要大資料的儲存。但是業務資料又在傳統資料庫中，所以傳統資料庫和大資料之間需要一個同步遷移的工具。

FlinkX 這個工具相對比較小眾，是袋鼠雲開源的專案。更熟悉的工具可能是 Sqoop 和阿里開源的 DataX，上圖是一個簡單的對比，我們開始選型的時候也做過調研，包括它的執行模式，外掛豐富度，是否支援斷點續傳等功能，特別是我們是做資料湖的，需要對資料湖外掛的支援，還有考慮新增外掛開發的難度。綜合調研下來，我們最終選擇了 FlinkX。多數傳統的企業使用 Sqoop 比較多，因為他們只會在 RDB 和大資料之間做遷移，但是 Sqoop 已經在今年 6 月份被移除了 Apache 頂級專案，上一次更新是在 2019 年 1 月份，已經 2 年多沒有任何的開發更新了，所以這個專案已經沒有新功能開發，這也不滿足我們的需求。之前我們也在移動雲上基於 Sqoop 做了一個外掛，但是發現 Sqoop 在開發、執行上不太符合我們的場景。最終我們選定了 FlinkX 這個工具。

2. Flink 簡介

什麼是 FlinkX 呢？FlinkX 是一個基於 Flink 流計算框架實現的資料同步外掛，它可以實現多種資料來源高效的資料同步，基本功能和 DataX 和 Sqoop 差不多。

批同步方面支援的資料來源跟 DataX 相當，但是在流式同步方面比較有優勢，因為它是基於 Flink 開發的，所以在流式資料方面支援的資料來源比較全，比如 Kafka，Pulsar 這種訊息佇列，還有資料庫的 Binlog 這種增量更新的資料同步，功能非常強大。基於開源社群 1.11 版本我們自己又開發了一些外掛：對 S3 的寫入、Hudi 資料湖的寫入、對 Pulsar 的寫入。Pulsar 部門已經開源提交到社群了，S3 和 Hudi 暫時還沒有提交。

二、功能及原理

接下來看一下 FlinkX 的功能和簡單的原理。

1. 斷點續傳

首先一個很棒的功能是斷點續傳，當然這個斷點續傳不是針對訊息佇列來說的，因為訊息佇列天然支援斷點續傳。FlinkX 依賴 Flink 的 checkpoint 機制，對 RDB 擴充套件了斷點續傳的功能。但是它有一個前提，首先是關係型資料庫需要包含升序的欄位，然後是需要支援資料的過濾，最後是需要支援事務。比如使用 MySQL 時如果需要斷點續傳，配置了這個功能後它會根據欄位做一個取模，然後在資料搬運的過程中當前節點的資料會在 checkpoint 裡面儲存，當需要重新執行任務的時候它會取上一次失敗的節點開始的那個點，因為它還需要根據儲存失敗的 id 的資料做一下過濾，最後再從那個節點重新開始執行任務，這樣資料量比較大的時候會稍微節約一點時間。

2. 指標監控

監控方面它會依賴 Flink 本身的監控功能，Flink 內部有一些 Accumulators 和 metric 統計指標，如果把它執行在 Flink 上的話就可以透過 Flink 的 DashBoard 來檢視 Job 的狀態。

或者是把一些指標資料收集到 Prometheus 裡面，例如基本的條數，統計的資料量和錯誤的資料量都可以透過 Prometheus 收集之後再透過 Grafana 這樣的一些工具做展示。目前線上的這個功能還在開發中。

3. 錯誤統計和資料限制

它還有一個比較好的功能是速率限制。當我們讀取資料寫入的時候，很多使用者首先擔心的問題是它會影響到生產庫，因為多數企業的庫可能沒有主從策略，生產庫是單例項執行的。如果這種搬運資料的任務影響到生產庫的話使用者基本上是不能接受的。所以做速率限制的功能對傳統使用者就非常友好。它的速率限制是基於 Guava 的 RateLimit，根據令牌工廠生產令牌的方式做的速率限制，跟另外的漏斗演算法稍微有一點差別。缺點是峰值還是會很高，因為它保證的是平均速率限制在某一個範圍之內。

4. 外掛式開發

FlinkX 的外掛式開發模式，與 Sqoop 和 DataX 類似，不同的資料來源都抽象成一個 Reader 外掛和一個 Writer 外掛，然後整個資料同步的任務和公有的邏輯就被抽象在一個統一的模組中。一個模組再根據同步任務的配置載入相應的 Reader，Writer 最後組裝成 Flink 任務，並提交到 Flink 叢集去執行。

我們可以簡單看一下任務配置，都是基於 JSON 的方式配置基礎的 Reader，Writer，然後是一些綜合的錯誤條數限制和速率限制，這邊的程式碼就會根據配置檔案透過 Reader 生成一個 Flink Source，再透過 Writer 生成 Sink，熟悉 Flink 程式碼的小夥伴對這塊應該比較熟悉，其實就是 Flink 從 Source 端讀資料然後往 Sink 端寫資料，相對來說比較簡單。

三、雲上入湖改造

雲上入湖這裡我們做了一些改造。

1. K8s

首先是 K8S 的改造，因為社群的 1.11 版本支援的是 Local，Standalone，YARN Session，YARN Perjob 的模式，對雲原生方式的開發不是太友好。並且 Flink 原生的 1.12 版本已經支援 K8S 排程執行了，所以我們把基於 FlinkX 的 1.11 版本 Flink 升級到了 1.12，讓它原生就可以支援 K8S 執行，這樣的話對我們任務的彈性擴縮容就更加友好，對入湖的任務資源隔離也比較友好，相互之間沒有影響。這裡也是基於 Flink 1.12 把裡面的 ApplicationClusterDeployer 這部分程式碼做了一些簡單的改造，來適配我們的一些系統。基本上是把 K8S 的一些配置組裝一下，然後把 FlinkX 的一些 Jar 包的路徑寫進去，最後提交任務到我們的 K8S 叢集。

我們的 JobManager 會透過 Quartz 來做 FlinkX 任務的排程，然後透過 Flink 的客戶端呼叫 K8S 的客戶端，最終把任務提交到 K8S 上去執行。

2. Hudi 寫入

我們擴充套件了一個 Hudi 的外掛，因為 FlinkX 裡面外掛非常多，我們這邊會考慮到寫 HBase 和寫 Hive 之類的情況，開發過程中遇到了很多 Jar 包衝突的問題，所以我們給 Hudi 社群版 0.09 版本打了非常多的 shade Jar，保證我們的線上執行沒有衝突，主要是 avro 的版本依賴問題。我們這邊 HBase 和 Hive 依賴的 avro 版本跟 Hudi 的版本會不一致，版本相容性之間有一些問題。

這裡看一下 Hudi 外掛預覽的樣子，參考了 Hudi 原始碼裡面加了 Client 的 Example，也就是先載入 Hudi 配置，初始化表和 Hive 的配置，最後透過 Kafka 做實時資料寫入。目前只提供 Upsert 的支援，後期考慮 MySQL Binlog 支援的話會增加 Delete 功能的支援。

3. 日誌

還有一個改造可能不屬於 FlinkX，就是我們的日誌功能，基於 K8S Fluentd 的一個小工具，EFK 這套系統去收集日誌。整個過程對我們的業務是沒有入侵，沒有感知的，最終我們的日誌解析收集到 ES 中。Fluentd 跟 K8S 結合的比較好的地方就是它可以採集到 NameSpace，PodName, NodeSelector 等資料，為後面查詢錯誤日誌提供了方便。

上圖就是使用 Fluentd 收集到的一些 Pod 的日誌，左側這邊看到有很多 K8S 的後設資料資訊，例如 ContainerName，映象，NodeSelector，PodId 等等這些資料。當然這個 Kibana 是我們留給後端開發用來排錯的，目前給前端使用者展示的還是把原始日誌資料做了彙總之後，透過頁面對應到任務上去檢視。

四、展望

最後一部分是我們對於 FlinkX 的一些展望，先來看一下 FlinkX V1.12 的一些新特性：

與 FlinkStreamSQL 融合；

增加了 transformer 運算元，支援 SQL 的轉換；

外掛向 Flink 社群看齊，不再區分 Reader、Writer，統一命名成 Connector，遵循 Flink 社群的規範，這樣統一以後 FlinkX 就可以和社群保持相容。理論上在使用 FlinkX 時可以使用 Flink 的原生 Connector。Flink 也可以呼叫 FlinkX 的 Connector，這樣的話 FlinkX 就可以做成外掛放到 Flink 的叢集裡面，後面對於做湖倉一體或者 Server 開發就會非常的方便。

資料結構最佳化

支援二階段提交、資料湖 Iceberg 和提交 kubernetes

對於資料入湖來說，目前的 FlinkX 有一個缺點，就是隻支援結構化資料的傳輸，還不能原生支援二進位制檔案的同步。如果資料要入湖，會有很多媒體檔案，Excel、Word、圖片、影片等等，這一塊後期可能會自己去開發一些外掛支援。

升級到 1.12 後對 FlinkSQL 的支援會更加友好，這樣傳統的 Lambda 升級到 Kappa 架構，對於習慣寫 SQL 做資料抽取轉換的使用者就非常友好，基本上可以靠一條 SQL 去實現流批一體化的任務，進一步降低開發維護的難度。我們可以從 Kafka 讀取一條資料，中間做一些簡單的轉換後寫到 MySQL。我們後面資料庫肯定要支援越來越多的實時資料寫入，所以後期用 SQL 的方式開發這些任務就會更加便捷。

五、問答環節

Q：一般情況下 FlinkX 作業分配多少 CPU 和記憶體資源？

A：我們這邊一般定義一個 Slot 是一核 2g，普通的一個 MySQL 到 MySQL 這樣的一個任務預設三個併發，使用者更多的是擔心我們的速度太快影響生產庫，目前自定義還沒有開放，後面具體的併發度會開放可以讓使用者自定義，目前 Slot 是固定的一核 2g。

Q：現在流批一體的應用範圍廣嗎？

A：我認為是挺廣的，對於移動集團的一些專案，其實我們在適配他們的一些場景，主要還是基於訊息佇列和 MySQL 的 Binlog。我們之前遇到的使用者他在阿里雲上訂購了結構化資料，現在他想上移動雲，但是他的生產庫又不能斷，他想做這樣的一個遷移，這就是需要流批一體的場景。他需要先做一個批的任務，把他歷史的資料搬運過來，再基於他的 Binlog 增量訂閱，實時同步更新他的增量資料，這就是一個很典型的傳統使用者的場景。再一個就是有一些大批次資料走 Kafka，原始資料還是需要落一份到 HDFS，但是需要實時的做一些彙總，這也算是一個比較典型的場景，會做流批一體的任務，我目前主要是針對這兩種場景做一些開發。

Q：FlinkX 相較於 FlinkCDC 優勢在哪裡？

A：單說 FlinkCDC 他只是支援結構化資料增量更新，FlinkX 如果是 1.12 版本它跟 FlinkCDC 之間的外掛一些是共用的，然後他相較於原生的 FlinkCDC 做了一些擴充套件，特別是它會支援很多國產的資料庫，比如達夢，FlinkCDC 目前還不支援。任務配置方式的話，FlinkX 是基於 JSON 的，對於寫 Flink 程式碼的的普通使用者更加友好。總結一句話就是擴充套件了更多外掛。

Q：流批一體真的會減少機器的預算嗎？計算資源減少了還是儲存資源減少了？

A：儲存會減少一點，計算可能不會減少，因為流批一體的話，是在用同一套程式碼維護批任務和流任務，中間的資料如果沒有必要的話是不用落地的，這塊肯定是節省儲存資源的。計算資源跟原來分開跑的話可能是相當的，不會有明顯的減少，主要是節省了儲存資源。

想了解更多有關袋鼠雲大資料產品、行業解決方案、客戶案例的朋友，瀏覽袋鼠雲官網：https://www.dtstack.com/?src=szitpub