flink数据存储在哪 flink 数据库

Flink 数据同步先行者- FlinkX

FlinkX是一款基于Flink的分布式离线/实时数据同步插件，可实现多种异构数据源高效的数据同步，其由袋鼠云于2016年初步研发完成，目前有稳定的研发团队持续维护，已在Github上开源（开源地址详见文章末尾）。并于今年6年份，完成批流统一，离线计算与流计算的数据同步任务都可基于FlinkX实现。

FlinkX将不同的数据源库抽象成不同的Reader插件，目标库抽象成不同的Writer插件，具有以下特点：

1. 基于Flink开发，支持分布式运行；
2. 双向读写，某数据库既可以作为源库，也可以作为目标库；
3. 支持多种异构数据源，可实现MySQL、Oracle、SQLServer、Hive、Hbase等近20种数据源的双向采集。
4. 高扩展性，强灵活性，新扩展的数据源可与现有数据源可即时互通。

 

从我个人的理解上，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规划支持流批一体，对开发与运维是一个好消息。

 

FlinkX应用场景

FllikX数据同步插件主要应用于大数据开发平台的数据同步/数据集成模块，通常采用将底层高效的同步插件和界面化的配置方式相结合的方式，使大数据开发人员可简洁、快速的完成数据同步任务开发。实现将业务数据库的数据同步至大数据存储平台，从而进行数据建模开发，以及数据开发完成后，将大数据处理好的结果数据同步至业务的应用数据库，供企业数据业务使用。

 

FlinkX工作原理详解

FlinkX基于Flink实现，其选型及优势详见FlinkX数据同步任务的本质是一个Flink程序，读出写入的数据同步任务会被翻译成StreamGraph在Flink执行，FlinkX开发者只需要关注InputFormat和OutputFormat接口实现即可。工作原理如下：

 

 

Engine是袋鼠云封装的任务调度引擎，WEB端配置好的数据同步任务首先会提交至任务调度引擎，Template模块根据同步任务的配置信息加载源数据库和目标数据库对应的Reader和 Writer插件，Reader插件实现InputFormat接口，从数据库获取DataStream对象，Writer插件实现OutFormat接口，将目标数据库与DataStream对象相关联，从而通过DataStream对象将读出写入串接在一起，组装成一个Flink任务提交至Flink集群上进行运行。

之前基于Flink的分片、累加器特性，解决了数据同步过程中的增量同步、多通道控制、脏数据管理与错误管理等场景。最近半年基于Flink的checkpoint机制，实现了断点续传、流数据续跑等功能，来了解一下它的新特性吧。

（1）断点续传

数据同步过程中，假如一个任务要同步500G的数据到目标库，已经跑了15min，但到400G的时候由于集群资源不够、网络等因素数据同步失败了，若需要重头跑此任务，想必该同学要抓狂了。FlinkX基于checkpoin机制可支持断点续传，当同步任务由于上述原因失败时，不需要重跑任务，只需从断点继续同步，节省重跑时间和集群资源。

Flink的Checkpoint功能是其实现容错的核心功能，它能够根据配置周期性地对任务中的Operator/task的状态生成快照，将这些状态数据定期持久化存储下来，当Flink程序一旦意外崩溃时，重新运行程序时可以有选择地从这些快照进行恢复，从而修正因为故障带来的程序数据异常。

并且断点续传可和任务失败重试机制配合，即当任务执行失败，系统会自动进行重试，若重试成功则系统会接着断点位置继续同步，从而减少人为运维。

（2）实时采集与续跑

今年6月份，袋鼠云数栈研发团队基于FlinkX实现批流数据采集统一，可对MySQL Binlog、Filebeats、Kafka等数据源进行实时采集，并可写入Kafka、Hive、HDFS、Greenplum等数据源，采集任务也支持作业并发数与作业速率的限制，以及脏数据管理。并基于checkpint机制，可实现实时采集任务的续跑。当产生业务数据或Flink程序引起的采集进程中断时，可基于Flink定期存储的快照，对流数据的读取节点进行保存，从而在进行故障修复时，可选择历史保存的数据断点进行续跑操作，保证数据的完整性。此功能在袋鼠云的StreamWorks产品中实现，欢迎大家了解。

（3）流数据的脏数据管理

之前在BatchWorks离线计算产品中，已实现离线数据同步的脏数据管理，并基于Flink的累加器实现脏数据的错误管理，当错误量达到配置时，置任务失败。目前流数据实时采集也支持了此功能，即在将源库数据写入目标库的过程中，将错误记录进行存储，以便后续分析数据同步过程中的脏数据，并进行处理。但由于是流数据采集，任务具有不间断性，没有进行错误数记录达到阈值的触发任务停止操作，待后续用户自行对脏数据分析，进行处理。

（4）数据写入至Greenplum、Oceanbase数据源

Greenplum是基于PostgreSQL的MPP数据库，支持海量数据的存储与管理，目前在市场上也被很多企业采用。于最近，数栈基于FlinkX实现多类型数据源写入Greenplum，除全量同步外，也支持部分数据库增量同步写入。OceanBase是阿里研发的一款可扩展的金融领域关系型数据库，其用法与MySQL基本一致，实现OceanBase的数据读入写出也是基于jdbc的连接方式，进行数据表与字段的同步与写入，也支持对OceanBase进行增量写入，以及作业同步通道、并发的控制。

写入Greenplum等关系数据库时，默认是不使用事务的，因为数据量特别大的情况下，一旦任务失败，就会对业务数据库产生巨大的影响。但是在开启断点续传的时候必须开启事务，如果数据库不支持事务，则无法实现断点续传的功能。开启断点续传时，会在Flink生成快照的时候提交事务，把当前的数据写入数据库，如果两次快照期间任务失败了，则这次事务里的数据不会写入数据库，任务恢复时从上一次快照记录的位置继续同步数据，这样就可以做到任务多次失败续跑的情况下准确的同步数据。

 

 

FlinkX开源地址：https://github.com/DTStack/flinkx

若需了解具体技术实现，详见https://mp.weixin.qq.com/s/VknlH8L2kpnlcJ3990ZkUw

总结

本文主要是针对于认识到了Flink与DataX结合之后，对数据同步的一些新想法和感知。现在很多开源工具的特点就是它仅仅是个工具，它是没有一个技术生态与应用生态，从应用者的角度更关注与作业的开发与作业管控，从作业开发上来看，目前FlinkX和DataX的采用的都是Json配置的方式，没有一个开发工具。看FlinkX的后续规划是有元数据管理、作业归档的。而我们公司的数据管控、数据开发就是从某种程度上面补齐了一个这样的短板。