《Apache Flink 案例集（2022版）》——1.数据集成——伴鱼-伴鱼基于 Flink 构建数据集成平台的设计与实现（1） https://developer.aliyun.com/article/1228434

用户提交集成任务后将同步创建三个任务：  

增量任务 (流)：增量任务将 DB 日志数据由 Kafka 同步至 Hive。由于采集组件都是按照集群粒度进行采集，且集群数量有限，目前都是手动的方式将同步的任务在「实时计算平台」创建，集成任务创建时默认假定同步任务已经 ready，待「数据同步平台」落地后可以同步做更多的自动化操作和校验。

存量任务 (批)：要想还原出快照数据则至少需要一份初始的快照数据，因此存量任务的目的是从业务数据库拉取集成时数据的初始快照数据。 Merge 任务 (批)：Merge 任务将存量数据和增量数据进行聚合以还原快照数据。还原后的快照数据可作为下一日的存量，因此「存量任务」只需调度执行一次，获取初始快照数据即可。  

存量任务和Merge任务由离线调度平台 Dolphinscheduler (简称 DS) 调度执行，任务执行过程中将从集成任务的元数据库中获取所需的信息。目前Merge 任务按小时粒度调度，即每小时还原快照数据。  

从数据流的角度，整个过程如下图所示：

生产实践

1. 存量任务  

存量任务虽然有且仅执行一次，但为了完全消除数据集成对业务数据库的影响，伴鱼选择数据库的备份-恢复机制来实现。公司内部数据库的备份和恢复操作已经平台化，集群将定期进行备份 (天粒度)，通过平台可以查询到集群的最新备份，并且可由接口触发备份恢复操作，故存量的获取可直接作用于恢复的数据库。  

由于数据库备份的时间点与集成任务提交的时间点并不一定是同一天，这之间存在着一定的时间差将导致存量快照数据不符合我们的预期，各时间点的关系如下图所示：

按照设定，存量快照数据应当是包含 T4 之前的全部数据，而实际备份的快照数据仅包含 T1 之前的全部数据，这之间存在这 N 天的数据差。  

注：这里之所以不说数据差集为 T1 至 T4 区间的数据，是因为增量的 Binlog 数据是以整点为分区的，在 Merge 的时候也是将整点的分区数据与存量数据进行聚合，并支持了数据去重。因此 T1 时刻的存量数据与 T0-T3 之间的增量数据的 Merge 结果等效于 T0 时刻的存量数据与 T0-T3 之间的增量数据的 Merge 结果。所以 T1 至 T4 的数据差集等效 T0 至 T3 的数据差集，即图示中的 N 天数据。  

对于缺失的这部分数据可以在存量任务中进行补全，通过执行 Merge 任务的补数操作实现。  

整个存量任务的工作流如下图所示：

同步触发数据库平台进行备份恢复，产生回执 ID；

通过回执 ID 轮训备份恢复状态，恢复失败需要 DBA 定位异常，故将下线整个工作流，待恢复成功可在平台重新恢复执行「存量任务」。恢复进行中，工作流直接退出，借助 DS 定时调度等待下次唤醒。恢复成功，进入后续逻辑；

从恢复库中拉取存量，判定存量是否存在数据差，若存在则执行 Merge 任务的补数操作，整个操作可幂等执行，如若失败退出此次工作流，等待下次调度； 成功，下线整个工作流，任务完成。  

《Apache Flink 案例集（2022版）》——1.数据集成——伴鱼-伴鱼基于 Flink 构建数据集成平台的设计与实现（3） https://developer.aliyun.com/article/1228430