Flink 數據同步先行者- FlinkX
最近在學習Flink,看到目前的Connector支持還較少，聯想到之前的DataX與FlinkX，由感而發。
從我個人的理解上，Connector是連接各個數據源的連接器，它屏蔽了一系列的組件兼容問題，實現統一的數據源連接與數據實體的抽象，就是爲了數據通道而生的基礎設施，而目前數據通道做的比較全的就是DataX。
DataX 是一個異構數據源離線同步工具，致力於實現包括關係型數據庫(MySQL、Oracle等)、HDFS、Hive、ODPS、HBase、FTP等各種異構數據源之間穩定高效的數據同步功能。
DataX本身作爲離線數據同步框架，將數據源讀取和寫入抽象成爲Reader/Writer插件，納入到整個同步框架中。
Reader：Reader爲數據採集模塊，負責採集數據源的數據，將數據發送給Framework。Writer： Writer爲數據寫入模塊，負責不斷向Framework取數據，並將數據寫入到目的端。Framework：Framework用於連接reader和writer，作爲兩者的數據傳輸通道，並處理緩衝，流控，併發，數據轉換等核心技術問題。
而在Flink的生態圈裏面與DataX對標的就是FlinkX，有可能就是同一批開發人員。
FlinkX現有功能
-
支持離線（
MySQL、Hbase、MongoDB、Redis、Hive等25種數據源）與**實時（kafka、mysql等）**數據同步 -
大部分插件支持併發讀寫數據，可以大幅度提高讀寫速度；
-
部分插件支持失敗恢復的功能，可以從失敗的位置恢復任務，節約運行時間；
-
關係數據庫的Reader插件支持間隔輪詢功能，可以持續不斷的採集變化的數據；
-
部分數據庫支持開啓Kerberos安全認證；
-
可以限制reader的讀取速度，降低對業務數據庫的影響；
-
可以記錄writer插件寫數據時產生的髒數據；
-
可以限制髒數據的最大數量；
-
支持多種運行模式；
所以對於Flink Connector的支持較好的應該就是非FlinkX莫屬了。
底層實現
在使用DataX的時候，DataX是一個單機同步工具，核心底層通道的分佈式支持不友好。
因爲作爲同步通道插件，意味着整個同步過程一定要高性能，高併發，高可靠性。並支持增量同步、斷點續傳和實時採集。
就同步的場景：
比如說同步一張表，如果我們的分片策略合理的話，是可以再Source和Target的理論性能下面，增加多個數據管道來增加同步性能的。每個管道同步不同的分片。
而Flink就剛好補齊了這個短板。
圖片來自於社區
下面從增量同步、斷點續傳和實時採集三個方面簡單解釋一下FlinkX的實現方式。
增量同步
增量同步指每次記錄最大值，下次從最大值的位置來同步。
累加器是具有添加操作和最終累積結果的簡單構造，可在作業結束後使用。
從Flink的實現上面講，可以使用Flink的累加器記錄作業的最大值，同步任務的每次運行使用上一個任務實例作爲起始位置同步。
斷點續傳
斷點續傳指的是當同步任務同步過程出現同步錯誤，不需要重新從頭開始同步，只需要從上次失敗的地方從新開始同步即可。降低了同步的成本。
從哪裏跌倒就從哪裏爬起來，不需要從起跑線重新開始。
從實現原理上就是要實時的記錄同步的位置，下次讀取上次同步的記錄。在Flink上面就是CheckPoint的機制，簡直就是很契合。
CheckPoint是FLink實現容錯機制最核心的功能，通過異步輕量級的分佈式快照實現。分佈式快照可以將同一時間點的Task/Operator的狀態數據全局統一快照處理。
如上圖，Flink會將數據集間隔性的生成checkpoint barrier，通過barrier分割數據，將兩個barrier之間的數據保存爲一個CheckPoint。當應用出現異常的時候，可以從上一次快照中，恢復所有的狀態。
實時採集
實時採集就是指的實時數據同步，當數據源李的數據發生增刪改查操作的時候，同步任務監聽到這些變化，將辯護的數據實時同步到目標數據源，並且因爲實時同步的特性，同步任務會一致駐留進程，不會停止。一般會採用kafka作爲實時採集工具。在這裏FlinkX支持了mysql-binlog和mongodb-oplog採集。
實時採集的難點在於：對於修正數據的更新策略，比如是更新舊數據，如果是大批量的數據，對目標數據源的壓力會特別大，怎麼做更新策略就是一個難點，據我所知的目前用的大多數都是不考慮修正數據。只是append，使用lambda架構的還比較多，採用離線跑批定時修正結果。Flink 後續Api規劃支持流批一體，對開發與運維是一個好消息。
總結
本文主要是針對於認識到了Flink與DataX結合之後，對數據同步的一些新想法和感知。現在很多開源工具的特點就是它僅僅是個工具，它是沒有一個技術生態與應用生態，從應用者的角度更關注與作業的開發與作業管控，從作業開發上來看，目前FlinkX和DataX的採用的都是Json配置的方式，沒有一個開發工具。看FlinkX的後續規劃是有元數據管理、作業歸檔的。而我們公司的數據管控、數據開發就是從某種程度上面補齊了一個這樣的短板。
參考資料
https://mp.weixin.qq.com/s/9DMRLI19i1g55X4YuK33HA
https://github.com/DTStack/flinkx
https://github.com/alibaba/DataX