Dinky 和 Flink CDC 在实时整库同步的探索之路

摘要：本文整理自 Dinky 社区负责人，Apache Flink CDC contributor 亓文凯老师在 Flink Forward Asia 2024 数据集成（二）专场中的分享。主要讲述 Dinky 的整库同步技术方案演变至 Flink CDC Yaml 作业的探索历程，并深入讲解Flink CDC Yaml的一些细节能力。其主要分为三个部分：

1、起源

2、探索

3、未来

01.起源

1.1 数据集成的背景

本次分享围绕数据集成，它也是 Flink CDC Yaml 作业的出现背景。在 Dinky 的众多用户中，我们总结出以下在传统的数据集成方案中普遍会遇到的问题：需要将业务库中的业务数据同步到分析库中，起到解耦分析的作用，一般有三点要求。要求数据必须一致、链路要求稳定、数据时效性尽可能要高。

 

1.2 传统数据集成方案

在传统的数据集成方案中可以通过离线和实时两条链路进行，离线通常会选择开源的方案 DataX 或 Sqoop 来做一些快照同步，实时方案会根据数据库类型进行选择，例如 Mysql 数据库采用 Debezium 或 Canal 实现增量同步，但是最终在分析库中是两种表的存在形式。需要在下一步数据加工治理过程中先将快照表和增量表合并为一张表，才能进行完整的一个统计分析。这样会造成一个影响：全量和增量割裂，并且使用到的技术组件和链路较长，导致整体的数据时效性偏低。

1.3 Flink CDC 数据集成方案

Flink CDC 自发布以来，其中 2.0 版本带来了重大更新，尤其是增量快照方法。可以将数据库中的全量数据和增量实时数据合并，保证数据的一致性。其次采用 Flink CDC 时可以不需要部署 Debezium 或 Kafka 等其他组件，只需要 Flink CDC 一个组件就可以完成从业务库到分析库的实时一致性快照的同步。数据链路缩短，数据时效性比传统的方案高。

1.4 数据集成面临的挑战——整库同步

在去年经常会遇到一个场景：Flink CDC 在大面积使用的情况下，业务比较多，分析需求会逐步增长，所以构建了一个整库同步的作业，将业务库中的全部表或部分表同步到分析库中。以往在技术瓶颈的限制下，开发方式是通过 Flink CDC 的 SQL 来完成对每一张表的处理。例如源库中有一千张表，可能就需要开发一千个 Flink SQL 的作业，每一个作业会建立一个单独的数据源连接，会消耗额外的连接数，Binlog 也会重复读取。整个过程中会产生大量的 Flink 流作业，导致 Flink 集群越来越难以运维。这是遇到的第一个挑战。

1.5 数据集成面临的挑战——模式演变

第二个挑战是模式演变的问题。业务库如果发生表结构变更，下游分析库无法感知到。如果下游库无法感知进行同步变更，此时数据链路仍然在进行同步，就会丢失一些新增的数据信息。例如增加了一个 age 列，如果下游库没有同步更新表结构就会丢失最新列的一些数据。

1.6 用户渴望——端到端数据集成

用户所渴望的是可以有全增量的自动切换、元数据可以自动发现、表结构可以自动同步、整库同步只需要一个链接一个作业、在开发过程中只需一个 SQL 完成。

02.探索

2.1整库同步的探索之路

先介绍一下 Dinky。Dinky 是一个以 Apache Flink 为内核构建的开源实时计算平台，具备实时应用的作业开发、数据调试及运行监控能力，助力实时计算高效应用。

2.2 Dinky的介绍

Dinky 可以连接众多的开源框架，例如 Paimon、Hudi、Iceberg 等其它数据库和数据湖。Dinky 主要有两个核心能力，第一是实时计算 IDE，可以对 Flink 作业、Flink SQL 和整库同步作业进行调试，在 IDE 界面上实时展现任务的流数据，便于排查数据问题。第二是提供实时运维的能力，将 Flink 集群进行统一管理，可以对任务进行实时监控，触发自定义的告警规则时，进行多渠道的告警通知。

2.3 Dinky基于Flink CDC的整库同步探索

对于整库同步，Dinky 还提供 CDC Source 的方案。此分享将对两个方案进行对比。

Dinky 在实现 Flink CDC 整库同步的探索上，通过实现一个 EXECUTE CDCSOURCE 的语法，让用户通过正则表达式等其他配置来完成整库同步任务的定义，来实现全增量自动切换、元数据自动发现、结构变更自动同步、只用一个库连接、一句 SQL 部署作业。此外，还支持写入各种数据源、支持各种部署模式，这些额外能力在一定程度上缓解了 Flink CDC 在各种连接器 Source 和 Sink 上的不足。

2.4 Dinky CDC Source 整库同步数据链路

Dinky CDC Source 整库同步数据链路分析如下。在分库分表的场景下，由 Source 节点将 Binlog 日志解析成 Debezium 格式的 Json，将 Json 数据按表名和主键进行分区，来支持下游多并行度的处理。下游按表名合并后进行分发，此处的表名合并主要用于分库分表的场景，可以通过一些正则表达式和条件来指定分库分表的规则。Route 可以将符合规则的表合并为一张表进行输出。按表名合并后，会为下游每一张表产生对应算子。示例中有两张表，就可以产生 Table1 和 Table2 两条路线进行输出。该 Pipeline 的实现主要基于 Process 和 Data Stream 来开发。为了适配更多的连接器，例如适配输出到 Hudi 或 MySQL 数据库，在最后一步 Data Sink 时也支持使用 Flink 的 SQL API 进行，这样就可以兼容所有的 Flink SQL API，最终实现将 Flink CDC 支持的数据源整库同步到任意一个 Flink SQL API 实现的数据库。

由于基于 Data Stream 开发，所以模式演变比较受限，会导致模式演变受下游数据库影响。例如 Doris Sink 支持下游演变，需要将数据流转换为字符串的格式。所以我们可以进行一个链路的复用，将前面的 Debezium json 进行相关处理，到最后环节序列化成字符串，将字符串传输给 Doris Sink，由 Doris Sink 进行模式演变的处理。此时可能存在问题：当有多并行度任务时，例如多并行度为 2 时有两个 Doris Sink 写入同一张表，会存在模式演变时数据的丢失，一个算子在进行模式演变，另一个算子在进行数据写入，这就是一个弊端。所以只能在并行度为 1 时正常使用。

2.5 Dinky CDC Source的局限性

Dinky CDC Source 存在一些局限性。

首先不支持自定义转换，Dinky CDC Source 只支持宽容数据类型的转换。

第二，由之前的算子拓扑图可以发现，面对一些表同步时会构建大量的算子节点，这样作业会非常庞大，从而会导致作业的恢复成本增加。

第三点是模式演变受限。本身框架不支持模式演变，需要由下游 Sink 连接器独立实现。

2.6 Dinky CDC Source整库同步的数据转换探索

在 Dinky CDC Source 整库同步的数据转换探索上，由于下游可以支持 Table API 的使用，所以下游可以直接使用 Flink CTAS 语法，通过 Select 语句定义转换，本质上使用 Flink SQL 的处理来进行。但是仍然会构建大量算子节点，且不支持模式演变。

2.7 Flink CDC YAML定义的Pipeline作业

去年 Flink CDC 3.0 发布，并贡献给 Apache 孵化器。由于 Dinky CDC Source 存在严重的架构瓶颈，只能满足一些特定情况下的整库同步场景。经过调研后发现 Flink CDC YAML（Flink CDC Pipeline）作业完全重构了整库同步的底层设计，支持模式演变和数据转换的能力。

2.8 Flink CDC YAML核心架构

Flink CDC YAML 作业的架构主要核心是基于Flink 的运行环境来完成自定义算子的编排。在设计数据流时摒弃了 Flink SQL  的数据流，自定义了一些高效的数据结构。通过 Data Source、Data Sink、Schema Registry、Router 和 Transformer 五个算子来完成整个作业的编排。上游通过 Flink CDC Cli 和 Yaml 脚本来指定作业细节，完成整库同步作业定义。

2.9 Flink CDC Pipeline 整库同步链路

这是一张 Flink CDC Pipeline 的数据链路图，模式演变、数据转换和分库分表三种场景结合使用。在经历每个算子节点计算后，流数据的结构会发生变化。首先通过 Data Source 节点读取到原始的 Schema 结构，使用数据转换时引入 PreTransform 和 PostTransform 两个算子。PreTransform 对无关的列进行删除，裁剪后 Schema 更加简洁。PostTransform 进行一些计算及投影等能力，包括两部分，第一部分添加计算列，第二部分添加过滤条件，实现整库同步链路中自定义数据转换的能力。数据在投影后字段会增加，通常投影 Schema 会比之前的结构更宽。其中链路图中的数据流长度可以反映出 Schema 大小的变化。下一步在 Schema operator 算子中对分库分表场景下的一些结构进行进一步合并。不同的库表可能会存在表结构不同、数据类型不同的问题。为了保证数据可以完整输出到下游目标库，通过对分库分表场景的一些数据进行宽容处理，最终合并后的 Schema 大于等于投影后的 Schema 结构。此处在触发模式演变时，通过对 DataChangeEvent 进行阻塞处理，保证下游数据库数据正确一致性。解决了 Dinky CDC Source 在多并行度下进行模式演变的丢失部分变更数据的问题。