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

博主历时三年经心创作的《大数据平台架构与原型实现：数据中台建立实战》一书现已由着名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 ) 》

• 优势
  
  
  
  • 前半程有 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 => 数据湖 } 两端都是一张表一个作业/数据库连接
    
  
  
• 评价
  
  
  
  • 团体链路完全打通，但只能应用于表数量不多的中小型场景
    
  
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。