Flink 数据同步先行者- FlinkX

Myth丶恋晨 2023-03-14 10:38 21阅读 0赞

## `Flink` 数据同步先行者- `FlinkX` ##

最近在学习`Flink`,看到目前的Connector支持还较少，联想到之前的`DataX`与`FlinkX`，由感而发。

从我个人的理解上，`Connector`是连接各个数据源的连接器，它屏蔽了一系列的组件兼容问题，实现统一的数据源连接与数据实体的抽象，就是为了数据通道而生的基础设施，而目前数据通道做的比较全的就是`DataX`。

**DataX** 是一个异构数据源离线同步工具，致力于实现包括关系型数据库(MySQL、Oracle等)、HDFS、Hive、ODPS、HBase、FTP等各种异构数据源之间稳定高效的数据同步功能。

![image-20200517125230928][]

`DataX`本身作为离线数据同步框架，将数据源读取和写入抽象成为`Reader/Writer`插件，纳入到整个同步框架中。

![image-20200517125221332][]

*  `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`莫属了。

![image-20200517114749041][]

## 底层实现 ##

在使用`DataX`的时候，`DataX`是一个单机同步工具，核心底层通道的分布式支持不友好。

因为作为同步通道插件，意味着整个同步过程一定要**高性能，高并发，高可靠性**。并支持**增量同步、断点续传和实时采集**。

**就同步的场景：**

比如说同步一张表，如果我们的分片策略合理的话，是可以再Source和Target的理论性能下面，增加多个数据管道来增加同步性能的。每个管道同步不同的分片。

而`Flink`就刚好补齐了这个短板。

![image-20200517115711641][]

图片来自于社区

下面从**增量同步、断点续传和实时采集**三个方面简单解释一下`FlinkX`的实现方式。

### 增量同步 ###

**增量同步**指每次记录最大值，下次从最大值的位置来同步。

> 累加器是具有添加操作和最终累积结果的简单构造，可在作业结束后使用。

从Flink的实现上面讲，可以使用Flink的累加器记录作业的最大值，同步任务的每次运行使用上一个任务实例作为起始位置同步。

### 断点续传 ###

**断点续传**指的是当同步任务同步过程出现同步错误，不需要重新从头开始同步，只需要从上次失败的地方从新开始同步即可。降低了同步的成本。

> 从哪里跌倒就从哪里爬起来，不需要从起跑线重新开始。

从实现原理上就是要实时的记录同步的位置，下次读取上次同步的记录。在`Flink`上面就是`CheckPoint`的机制，简直就是很契合。

`CheckPoint`是`FLink`实现容错机制最核心的功能，通过异步轻量级的分布式快照实现。分布式快照可以将同一时间点的Task/Operator的状态数据全局统一快照处理。

![image-20200517123621842][]

如上图，`Flink`会将数据集间隔性的生成checkpoint barrier，通过barrier分割数据，将两个barrier之间的数据保存为一个`CheckPoint`。当应用出现异常的时候，可以从上一次快照中，恢复所有的状态。

### 实时采集 ###

**实时采集**就是指的实时数据同步，当数据源李的数据发生增删改查操作的时候，同步任务监听到这些变化，将辩护的数据实时同步到目标数据源，并且因为实时同步的特性，同步任务会一致驻留进程，不会停止。一般会采用kafka作为实时采集工具。在这里FlinkX支持了`mysql-binlog`和`mongodb-oplog`采集。

![image-20200517124153842][]

**实时采集的难点**在于：对于修正数据的更新策略，比如是更新旧数据，如果是大批量的数据，对目标数据源的压力会特别大，怎么做更新策略就是一个难点，据我所知的目前用的大多数都是不考虑修正数据。只是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

[image-20200517125230928]: /images/20230312/14c154d3dec94c0db38493f49f536132.png
[image-20200517125221332]: /images/20230312/096803282d614ea889bca58e547024e7.png
[image-20200517114749041]: /images/20230312/17b5d6d87caf4c7dbb037bf71459b41c.png
[image-20200517115711641]: /images/20230312/08e1bcc7b84246b6893342894ced428f.png
[image-20200517123621842]: /images/20230312/e088da8e539949b68e266eb34cd3bc4c.png
[image-20200517124153842]: /images/20230312/cecce113ce854a3f9b1e266cb74dd85b.png