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