近期，对 “实时摄取 CDC 数据同步到数据湖” 这一技术主题作了一系列深入的研究和验证，目前这部分工作已经告一段落，本文把截止目前（2024年5月）的研究结果和重要结论做一下梳理和汇总。为了能给出针对性的技术方案，我们收敛了一下话题，对一些技术选型做了限制，在数据库这一侧，主要以 MySQL 作为示例进行介绍和演示（理论上，PG 等其他主流数据库均可行），在数据湖这一侧，我们重点关注的是 Apache Hudi。
1. 方案架构
这一主题的技术架构基本上可以分为两个相对独立的部分：
- 前半程：{ 数据库 => Kafka } 的 CDC 数据采集
- 后半程：{ Kafka => 数据湖 } 的 CDC 数据写入
我们认为在链路上引入 Kafka 是很有必要的，这在架构上会有很大的弹性和灵活性，所以我们没有调研从数据库直接落地到数据库的相关方案。在这套方案的架构上，有一个显著的差异，或者说挑战：不管是前半程还是后半程，都有两种可能的模式：
- 使用一个作业将整库 / 多表同步到 Kafka ，以及再使用一个作业读取 Kafka 数据并同时写入多张 Hudi 表
- 一张表对应一个作业
如果是单表单作业模式，方案已经已经非常成熟了，但是这种模式不适合大中型场景，应用范围有限，应该说，最好的实现方式是：多表单作业，但目前来看，这实现起来确实有挑战，我们后文再详细介绍。
2. 技术堆栈
从技术选型上看，整个链路可能会包含这样几类组件：
- CDC 数据采集组件：Flink CDC、Kafka Connect
- Schema Registry组件：Confluent Schema Registry 或 不设置
- Hudi 表数据写入组件：Flink Hudi Connector、HoodieMultiTableStreamer
除了搭配使用多个开源组件形成一套完整的解决方案外，还有一些一站式的解决方案，例如：阿里云实时计算Flink版的 CDAS 功能，开源工具 Dinky 的 MySQLCDC 整库到 Hudi 等
3. 关键差异
在整个链路中，我们需要考虑多个关键技术点的实现，评估它们的利弊，这些技术点包括：
- 在 { 数据库 => Kafka } 的 CDC 数据采集过程中，是一张表对应一个作业，占用一个数据库链接还是整库 / 多表对应一个作业，占用一个数据库链接？
- 在 { Kafka => 数据湖 } 的 CDC 数据写入过程中，是一个 Topic 对应一个作业还是多个 Topic 对应一个作业？
- 在整个链路中是通过集成一个 Schema Registry 来注册并获取每张表的 Schema 信息？还是靠建表语句（Flink SQL）？或是类型推断？（Spark）
这些关键技术点叠加不同的技术组件会形成复杂多样的技术组合，并各有各的优缺点。
4. 值得期待的方案
个人认为：在仅依赖主流开源产品原生机制和特性的前提下，最值得期待的方案应该是：
Flink CDC ( API 整库 / 多表同步，分流写入多个 Topic ，集成 Schema Registry) => Kafka => HoodieMultiTableStreamer => Hudi
前半程的功能除了还不能和 Schema Registry 对接外，其他都已经实现，即使不能自动向 Schema Registry 自动注册 Schema，还可以手动注册，这不是一个 Block Issue；后半程的功能其实应该已经支持了，但是，截止当前最新版本 ( Hudi 0.14.1 )，HoodieMultiTableStreamer 在处理 Debezium CDC 数据时依然有问题，需要再等待一段时间。
这套方案值得期待的原因在于：后半程 CDC 数据写入 Hudi 表的工作依赖的是 Hudi 的原生组件 HoodieMultiTableStreamer ，尽管目前它还不成熟，但未来是很值得期待的，这比自己编写和维护解析 CDC 数据并写入 Hudi 表要明智的多。至于前半程 Flink CDC 是否会集成 Schema Registry，目前没有查到确切信息，但如前所述，没有也不会是很大的问题，无非是手动注册一个 Schema。不过从长远来看，Schema Registry 会在实时链路中扮演越来越重要的角色。
5. 当前的务实方案
在 HoodieMultiTableStreamer 工具完善之前的这段时间里，个人认为：在不引入任何第三方依赖的前提下，目前最为可靠和实用的解决方案应该是：
Flink CDC ( API 整库 / 多表同步，分流写入多个 Topic ) => Kafka => Flink Hudi Connector => Hudi
这一方案的优势在于：前半程是整库 / 多表同步，对数据库影响较小，后半程使用 Flink Hudi Connector 读取 Kafka 数据写入 Hudi 表，其中，在创建 Hudi 表时，使用 Flink SQL 的 create table ... with ... like ... 子句可以极大简化建表语句（建表其实就是提供 Schema 的过程），总体上的代码量并不大。这个方案不太完美的地方在于：从 Kafka => Hudi 还是要一张表对应一个 Flink 作业，不过，对于一般用户来说，这未必会带来很多麻烦。 这一方案具体实现代码已经在《Flink CDC 整库 / 多表同步至 Kafka 方案（附源码）》一文中给出。
此外，关于后半程 { Kafka => Hudi } 的写入还有一种实现方案：使用 Spark 的 foreachBatch 自行编程实现 Hudi 的多表写入，各个表的 Hudi 配置也是需要配置文件提供，至于 Schema 信息可以利用 Spark 的 Schema 推断自动生成，不必显式配置，但是这种方式多少是有些类型不安全的，本系列文章没有展开讨论，网上有现成方案可供参考。长远来说，个人还是更看好 HoodieMultiTableStreamer + Confluent Schema Registry 的组合。
6. 具体方案汇总
以下是近期研究和检验过的六个主要的解决方案及其它们的优势、不足和评价：
- 《Flink CDC 整库 / 多表同步至 Kafka 方案（附源码）》
- 优势
- { 数据库 => Kafka } 只有一个作业，只占用一个连接
- 多表公用一个 Topic 还是 一张表对应一个 Topic 可选
- 使用 Flink SQL 的
create table ... with ... like ...子句一定程度上简化了 Hudi 的建表工作
- 不足
- Kafka => Hudi 还是必须要一张表一个 Flink 作业
- 评价
- 实用，但还有提升空间
- 优势
- 《CDC 实时入湖方案：MySQL > Kafka Connect > Kafka ＆ Schema Registry > Hudi ( Flink Connector ) 》
- 优势
- 前半程有 Schema Registry 参与，提供 Schema 的注册、获取和变更管理
- 不足
- { 数据库 => Kafka } 和 { Kafka => 数据湖 } 两端都是一张表一个作业/数据库连接
- 整体评价
- 整体链路完全打通，但只能应用于表数量不多的中小型场景
- 优势
- 《CDC 实时入湖方案：MySQL > Kafka Connect > Kafka ＆ Schema Registry > Hudi ( HoodieMultiTableStreamer ) 》
- 优势
- 全程有 Schema Registry 参与，提供 Schema 的注册、获取和变更管理
- 不足
- { 数据库 => Kafka } 是一张表一个作业/数据库连接
- 目前版本的 HoodieMultiTableStreamer 有缺陷
- 评价
- 整体链路尚未完全打通，需要等待 Hudi 的后续版本修复 Bug
- 优势
- 《CDC 实时入湖方案：MySQL > Flink CDC > Kafka ＆ Schema Registry > Hudi ( Flink Connector ) 》
- 优势
- 前半程有 Schema Registry 参与，提供 Schema 的注册、获取和变更管理
- 不足
- { 数据库 => Kafka } 和 { Kafka => 数据湖 } 两端都是一张表一个作业/数据库连接
- 评价
- 整体链路完全打通，但只能应用于表数量不多的中小型场景
- 优势
- 《CDC 实时入湖方案：MySQL > Flink CDC > Kafka ＆ Schema Registry > Hudi ( HoodieMultiTableStreamer ) 》
- 优势
- 全程有 Schema Registry 参与，提供 Schema 的注册、获取和变更管理
- 不足
- { 数据库 => Kafka } 是一张表一个作业/数据库连接
- 目前版本的 HoodieMultiTableStreamer 有缺陷
- 评价
- 整体链路尚未完全打通，需要等待 Hudi 的后续版本修复 Bug
- 优势
- 《CDC 实时入湖方案：MySQL > Flink CDC > Kafka > Hudi》
- 优势
- 链路最简单，实现起来最容易
- 不足
- { 数据库 => Kafka } 和 { Kafka => 数据湖 } 两端都是一张表一个作业/数据库连接
- 评价
- 整体链路完全打通，但只能应用于表数量不多的中小型场景
- 优势
