伴鱼如何基于Flink构建数据集成平台的设计与实现？

目前伴鱼内部数据的集成需求主要体现在三块：Stat Log (业务标准化日志或称统计日志)、TiDB 及 MongoDB。

另外，由于实时数仓正处于建设过程中，目前数据集成平台只涵盖离线数仓 (Hive)。 • Stat Log：业务落盘的日志将由 FileBeat 组件收集至 Kafka。由于日志为 Append Only 类型， 因此 Stat Log 集成相对简单，只需将 Kafka 数据同步至 Hive 即可。

• DB (TiDB、MongoDB)：DB 数据相对麻烦，核心诉求是数仓中能够存在业务数据库的镜像，即存在业务数据库中某一时刻（天级 or 小时级）的数据快照，当然有时也有对数据变更过程的分析需求。因此DB 数据集成需要将这两个方面都考虑进去。 两种类型的数据集成方式差异较大，需要不同的解决方案。平台建设早期伴鱼的数据集成平台主要是借助一系列开源的工具实现。在State Log方面，日志的集成并未接入平台， 而是烟囱式的开发方式，Kafka 中的数据先经过 Flume 同步至 HDFS，再由 Spark 任务将数据从 HDFS 导入至 Hive 并创建分区。整体链路较长且引入了第三方组件（Flume）增加了运维的成本，另外 Kafka 的原始数据在 HDFS 冗余存储也增加 了存储的开销。

DB 数据的集成主要是基于查询的方式（批的方式，通过 Select 查询进行全表扫描得到快照数据）实现，用户通过平台提交集成任务，由 Airflow 定时任务扫描集成平台元数据库，生成对应的取数任务 (TiDB 的数据通过 Sqoop 工具，MongoDB 的数据则通过 Mongoexport 工具)。可以看到 V1 版本并没有获取数据库的变更的日志数据，不能满足对数据变更过程的分析诉求。

由于 Sqoop 任务最终要从 TiDB 生产环境的业务数据库获取数据，数据量大的情况下势必对业务数据库造成一定的影响。Mongoexport 任务直接作用在 MongoDB 的隐藏节点 (无业务数据请求)，对于线上业务的影响可以忽略不计。基于此，DBA 单独搭建了一套 TiDB 大数据集群，用于将体量较大的业务数据库同步至此 (基 于 TiDB Pump 和 Drainer 组件)，因此部分 Sqoop 任务可以从此集群拉群数据以消除对业务数据库的影响。 从数据流的角度，是否将生产环境 TiDB 业务数据库同步至 TiDB 大数据集群由数仓的需求以及 DBA 对于数据量评估决定。可以看出，这种形式也存在着大量数据的冗余，集群的资源随着同步任务的增加时长达到瓶颈。并且随着后续的演进，TiDB 大数据集群也涵盖一部分数据应用生产环境的业务数据库，集群作用域逐渐模糊。

随着时间推进，这个版本暴露的问题也逐渐增多，因此伴鱼开发了V2版本的数据集成平台，引入了 Flink，将同步的链路进行了简化。DB 数据集成从之前的基于查询的方式改成了基于日志的方式 (流的方式)，大大降低了冗余的存储。在State Log方面，借助 Flink 1.11 版本后对于 Hive Integration 的支持，可以轻松的将 Kafka 的数据写入Hive，从而大幅简化集成流程和组件依赖 (相比 V1 版本，去除了对 Flume 组件的依赖，数据冗余也消除了)。

同时 Flink Exactly-Once 的语义也确保了数据的准确性。基于日志的方式对 DB 数据进行集成，意味着需要采集 DB 的日志数据，在目前的实现中 TiDB 基于 Pump 和 Drainer 组件（目前生产环境数据库集群版本暂不支持开启 TICDC），MongoDB 基于 MongoShake 组件，采集的数据将输送至 Kafka。 采用这种方式，一方面降低了业务数据库的查询压力，另一方面可以捕捉数据的变更过程，同时冗余的数据存储也消除了。不过由于原始数据是日志数据，需要通过一定的手段还原出快照数据。

以上内容摘自《Apache Flink 案例集（2022版）》电子书，点击https://developer.aliyun.com/ebook/download/7718 可下载完整版