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

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

CDC 数据实时同步入湖的技术、架构和方案汇总_第1张图片

近期,对 “实时摄取 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 => 数据湖 } 两端都是一张表一个作业/数据库连接
  • 评价
    • 整体链路完全打通,但只能应用于表数量不多的中小型场景

你可能感兴趣的:(CDC数据入湖方案,•,合集,大数据专题,CDC,实时,同步,数据湖,方案,架构,技术)