CDC 数据实时同步入湖的技术、架构和方案汇总

原创已于 2024-08-26 11:48:01 修改 · 置顶 · 5k 阅读

23 ·

CC 4.0 BY-SA版权

本文为博主原创文章，未经博主允许不得转载。

文章标签：

#CDC #实时 #同步 #数据湖 #方案 #架构 #技术

于 2024-05-27 09:20:18 首次发布

大数据专题同时被 2 个专栏收录

184 篇文章

订阅专栏

CDC数据入湖方案 • 合集

32 篇文章

订阅专栏

博主历时三年精心创作的《大数据平台架构与原型实现：数据中台建设实战》一书现已由知名IT图书品牌电子工业出版社博文视点出版发行，点击《重磅推荐：建大数据平台太难了！给我发个工程原型吧！》了解图书详情，京东购书链接：https://item.jd.com/12677623.html，扫描左侧二维码进入京东手机购书页面。

在这里插入图片描述

近期，对 “实时摄取 CDC 数据同步到数据湖” 这一技术主题作了一系列深入的研究和验证，目前这部分工作已经告一段落，本文把截止目前（2024年5月）的研究结果和重要结论做一下梳理和汇总。为了能给出针对性的技术方案，我们收敛了一下话题，对一些技术选型做了限制，在数据库这一侧，主要以 MySQL 作为示例进行介绍和演示（理论上，PG 等其他主流数据库均可行），在数据湖这一侧，我们重点关注的是 Apache Hudi。

1. 方案架构

首先，我们认为在链路上引入 Kafka 是很有必要的，这在架构上会有很大的弹性和灵活性，所以我们讨论的所有方案都是先将 CDC 数据接入到 Kafka，然后再从 Kafka 读取 CDC 数据并写入到 Hudi 表中，没有调研从数据库直接落地到数据湖的方案。因此，这一主题的技术架构基本上可以分为两个相对独立的部分：

前半程：{ 数据库 => Kafka } 的 CDC 数据采集
后半程：{ Kafka => 数据湖 } 的 CDC 数据写入

在这套方案的架构上，有一个显著的差异，或者说挑战：不管是前半程还是后半程，都有两种可能的模式：

单表单作业：使用一个作业将一张表同步到 Kafka ，再使用一个作业读取 Kafka 数据并写入一张 Hudi 表
多表单作业：使用一个作业将整库 / 多表同步到 Kafka ，再使用一个作业读取 Kafka 数据并同时写入多张 Hudi 表

如果是单表单作业模式，方案已经已经非常成熟了，但是这种模式不适合大中型场景，应用范围有限，应该说，最好的实现方式是：多表单作业，但目前来看，这一方式实现起来还有一定的挑战，我们后文会详细介绍。

2. 技术堆栈

从技术选型上看，整个链路可能会包含这样几类组件：

CDC 数据采集组件：Flink CDC、Kafka Connect
Schema Registry组件：Confluent Schema Registry 或不设置
Hudi 表数据写入组件：Flink Hudi Connector、HoodieMultiTableStreamer

除了搭配使用多个开源组件形成一套完整的解决方案外，还有一些一站式的解决方案，例如：阿里云实时计算Flink版的 MySQL整库同步Kafka 功能，开源工具 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 ) 》