Laurence的技术博客

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

本方案的技术链路为：使用 Flink CDC 将 MySQL 的 CDC 数据 （Avro 格式）接入到 Kafka ，然后通过 Flink Hudi Connector 将摄取的 CDC 数据写入到 Hudi 表中。整个链路由 Confluent Schema Registry 控制 Schema 的变更。本文是《CDC 实时入湖方案：MySQL > Flink CDC > Kafka > Hudi》的增强版，在打通从源端数据库到 Hudi 表的完整链路的前提下，还额外做了如下两项工作：

本方案的技术链路为：使用 Kafka Connect 的 Debezium MySQL Source Connector 将 MySQL 的 CDC 数据 （Avro 格式）接入到 Kafka 之后，通过 Flink 读取并解析这些 CDC 数据，其中，数据是以 Confluent 的 Avro 格式存储的，也就是说，Avro 格式的数据在写入到 Kafka 以及从 Kafka 读取时，都需要和 Confluent Schema Registry 进行交互，从而获取 Schema 信息，消息经 Fli

本文首发于Apache Hudi公众号。Apache Hudi的DeltaStreamer是一种以近实时方式摄取数据并写入Hudi表的工具类，它简化了流式数据入湖并存储为Hudi表的操作，自 0.10.0 版开始，Hudi又在DeltaStreamer的基础上增加了基于Debezium的CDC数据处理能力，这使得其可以直接将Debezium采集的CDC数据落地成Hudi表，这一功能极大地简化了从源头业务数据库到Hudi数据湖的数据集成工作。

本文再次去动态表和表流二象性做一些梳理。1.将流转换为动态表。2.在动态表上计算一个连续查询，生成一个新的动态表。3.生成的动态表被转换回流。我们会从实际代码层面把动态表的概念打通，核心问题就是：动态表的 DDL 定义了什么？持续查询又做了什么？动态表的 DDL 定义了三项核心要素：数据结构，数据源（connector），传输格式（format）；从 ETL 的角度看，持续查询完成了最核心的 ETL 逻辑，从整个流式处理管道的角度看，是持续查询驱动了整个 Pipeline 运转，只有动态表的DDL，不会有任

本方案的技术链路为：使用 Kafka Connect 配合 Debezium MySQL Source Connector 将 MySQL 的 CDC 数据 （Avro 格式）接入到 Kafka ，然后通过 Hudi 的 HoodieMultiTableStreamer 将摄取的 CDC 数据写入到 Hudi 表中。整个链路由 Confluent Schema Registry 控制 Schema 的变更。本文和《CDC 实时入湖方案：MySQL > Kafka Connect > Kafka ＆ Sche

先介绍一下大的背景吧，我们已经能通过 Flink CDC 将整个数据库同步到 Kafka 中了，这一部分的实现方案已经汇总在了 《Flink CDC 整库 / 多表同步至 Kafka 方案（附源码）》一文中。接下来要完成的是后半程的工作：读取 Kafka 的 Debezium CDC 数据写入到数据湖的 Hudi 表中，这样就能完整地实现整个数据库同步入湖的设计目标，当然，要求还是：“源库整库 / 多表 => Kafka”是一个作业，“Kakfa => Hudi 整库 / 多表”也是一个作业，这样才有比较强

本方案的技术链路为：使用 Flink CDC 将 MySQL 的 CDC 数据 （Avro 格式）接入到 Kafka ，然后通过 Hudi 的 HoodieMultiTableStreamer 将摄取的 CDC 数据写入到 Hudi 表中。整个链路由 Confluent Schema Registry 控制 Schema 的变更。本文和《CDC 实时入湖方案：MySQL > Flink CDC > Kafka ＆ Schema Registry > Hudi ( Flink Connector ) 》介绍的

这几年，在流式链路上引入一个 Schema Registry 变得越来越流行，也越来越有必要， Schema Registry 能有效控制 Schema 的变更，合理推进 Schema Evolution，同时，引入它以后还能有效精简消息内容（特别是针对 Avro 格式），提升消息的传输效率，所以引入 Schema Registry 是有很多正向收益的。在 Flink 生态中，对 Confluent Schema Registry 的支持度如何呢？本文，我们来详细地梳理和总结一下。有关的组件主要是 Flin

在使用 HoodieStreamer / HoodieDeltaStreamer 从 Kafka 摄取 Debezium CDC 消息并自动解析写入到 Hudi 表时，我们可能会遇到这样一个问题：org.apache.hudi.utilities.sources.debezium.DebeziumSource only support org.apache.hudi.utilities.schema.SchemaRegistryProvider 这个问题本身的解决方法很简单，但是这个问题对整个 CDC 数据

在使用 Flink CDC 的 API 摄取 CDC 数据到 Kafka 的时候，如果使用的是 JsonDebeziumDeserializationSchema，那么会有很大概率遇到中文乱码问题，下面就是一个示例

不管是用 Flink CDC 还是 Kafka Connect (Debezium Connector)，在实时获取数据库的 CDC 数据并以 Json 格式写入 Kafak 中时，都会遇到 DataTime / Timpstamp 类型的转换问题，即：原始数据库中的 DataTime / Timpstamp 的字面量是 2021-12-14 00:00:00 这种形式，但是，转换为 Json 后就变成了 1639411200000 (带毫秒位的 epoch 时间)，这带来的问题是：下游表基于 Json 数

本测试要验证两个问题：Flink CDC 能否将多张表的 CDC 数据 （debezium-json 格式）写入到同一个 Kafka Topic 中？验证使用 Flink SQL 方式将多表同时写入 Kafka 时，Flink 的作业数量,首先，准备好用 Flink SQL 实现的将两张表同步到一个 Kafka Topic 中的代码

在使用 Flink CDC 的 API 编写整库、多表接入 Kafka 的程序时，遇到题目所述的报错。如果是自己编写的程序，可在 IDE 中直接查找该类是否在项目的依赖声明中；如果是部署的第三方应用，可以使用如下命令确认报错的类是否在所有依赖包中都不存在

这是一个很容易混淆和误解的问题，值得拿出来讨论对比一下。我们知道 Debezium 是专门用于捕获 CDC 数据的开源框架，它对接了多种数据库，同时也定义了自己的 CDC 数据交换格式，也就是常说的 `debezium` 格式。而Flink CDC 复用了 Debezium 的部分功能，也就是说：Debezium 是 Flink CDC 的底层采集工具，Flink CDC 的工程依赖会用使用到 Debezium 的 Jar 包，然后 Flink CDC 在 Debezium 基础之上，封装了额外的功能，

debezium-json 格式有一种非常典型的应用场景，就是：上游（Source）是一张使用 Flink CDC 接入的关系数据库中的表，下游（Sink）是一张创建在 Kafka 上的表，这张表的 format 往往会定义为 debezium-json，以便 Flink 能获得全面的 CDC 信息用于流上的实时处理，这种场景我们在 《Flink CDC 与 Kafka 集成：Snapshot 还是 Changelog？Upsert Kafka 还是 Kafka？》 一文的 ”测试组合(1)：connect

数据库压测最主要的工作是：如何能简单地生成压测数据（Dummy Data），还要能控制好数据的取值范围，写脚本太麻烦，图形化工具收费还不通用，所以，我们选择使用老牌的压力测试工具：Apache JMeter，除了它内置了丰富的随机值生成方法外，还因为它是一个统一的压测平台，操作和配置都和其他类型的压测一致。本文以 Debezium 官方提供的 MySQL Docker镜像 中的 Inventory 数据库为示例介绍和演示压测步骤。

Debezium 官方提供的 MySQL Example 数据库是一个很好的工具，它内置了一个名为 inventory 的数据库，且已经配置好了 binlog，在测试 CDC 方案时非常有用，同时，它又可以基于 Docker 快速部署，所以使用起来就更方便了。本文专门介绍一下这个数据库的使用的方法。本文操作预设本地已安装并配置好了 docker，如需先行安装 docker，请参考 《Apache Kafka 基于 S3 的数据导出、导入、备份、还原、迁移方案》一文第4节提供的 Shell 脚本。

本方案的技术链路为：使用 Flink CDC 将 MySQL 的 CDC 数据 （Json 格式）接入到 Kafka ，然后通过 Flink Hudi Connector 将摄取的 CDC 数据写入到 Hudi 表中。文本是本博客的 CDC 数据入湖系列方案中最为基础的一套堆栈，架构上也比较简单，适合作为 POC 快速搭建 CDC 实时处理链路。如果寻求更加适用于生产环境的解决方案，请参考

我们知道，尽管 Flink CDC 可以越过 Kafka，将关系型数据库中的数据表直接“映射”成数据湖上的一张表（例如 Hudi 等）， 但从整体架构上考虑，维护一个 Kafka 集群作为数据接入的统一管道是非常必要的，这会带来很多收益。在 Flink CDC 之前，以 Debezium + Kafka Connect 为代表的技术组合都是将数据库的CDC数据先接入到 Kafka 中，然后再由后续的组件解析和处理。

问题场景是：使用 Kafka Connect 的 Debezium MySQL Source Connector 将 MySQL 的 CDC 数据 （Avro 格式）接入到 Kafka 之后，通过 Flink 读取并解析这些 CDC 数据，然后以流式方式写入到 Hudi 表中，测试中发现，INSERT 和 UPDATE 消息都能很好的处理，但是，-D 类型的 Delete 消息被忽略了，即使已经开启了 ‘changelog.enabled’ = ‘true’ ，既然无效。

本问题发生的场景是：使用 Kafka Connect 的 Debezium MySQL Source Connector 将 MySQL 的 CDC 数据 （Confluent Avro 格式）接入到 Kafka 之后，通过 Flink 读取并解析这些 CDC 数据，然后写入到 Hudi 表中。在测试过程中发现：启动写入作业后，Hudi 表中迟迟没有数据写入，而 Flink 作业也没有报错。实际上，这应该是一比较常见的问题，我们的测试环境并没有特别的配置，大多数初次进行集成的开发者，大概率都会遇到这一问题，

在使用 Flink 读取 Debezium Confluent Avro 格式的 CDC 数据时，遇到了上述错误。背景介绍和具体操作请参考 《Flink 集成 Debezium Confluent Avro ( format=debezium-avro-confluent )》 一文，该错误是在查询 Kafka Sink Table 时（也就是真正读取并解析 Avro CDC 数据时）发生的，错误信息 AvroTypeException: Found .Value, expecting union

本文介绍的场景是：使用 Kafka Connect 的 Debezium MySQL Source Connector 将 MySQL 的 CDC 数据 （Avro 格式）接入到 Kafka 之后，通过 Flink 读取并解析这些 CDC 数据，其中，数据是以 Confluent 的 Avro 格式存储的，也就是说，Avro 格式的数据在写入到 Kafka 以及从 Kafka 读取时，都需要和 Confluent Schema Registry 进行交互，从而获取 Schema 信息，本文讨论的就是在这一场

MSK Connect 的插件包需要将各种插件的 Jar 包及其依赖包放到一起，打成 Zip 包，上传到 S3，然后在MSK Console 上创建插件时指定好 Zip 位置即可。为了便于维护，我们不建议将各种插件的 Jar 包混在一起放入同一个文件内，最好还是按插件原来的名称单独创建文件夹，单独放置各自的 Jar 包。我们以 Debezium MySQL Connector 和 Confluent Avro Converter 这两个插件为例

使用 Avro 格式传递 Kafka 消息要比 Json 更加高效，因为它是二进制格式，在启用了 Confluent Schema Registry 的情况下，会进一步地提升传输效率，因为 Avro 中的 Schema 信息将不再出现在消息中，消息体积会进一步压缩，同时，还可以利用到 Schema Registry 的其他好处，例如 Schema Evolution 管理。

在系统升级或迁移时，用户常常需要将一个 Kafka 集群中的数据导出（备份），然后在新集群或另一个集群中再将数据导入（还原）。通常，Kafka集群间的数据复制和同步多采用 Kafka MirrorMaker，但是，在某些场景中，受环境限制，两个于 Kafka 集群之间的网络可能无法连通，亦或是需要将 Kafka 的数据沉淀为文件存储以备他用。此时，基于 Kafka Connect S3 Source / Sink Connector 的方案会是一种较为合适的选择，本文就将介绍一下这一方案的具体实现。

本文记录HBase CDC ( WAL日志写入Kafka ) 方案的实操步骤，测试使用的方案和环境如下：创建HBase集群在MER 空置台上创建一个EMR集群，选择HBase一个App即可，S3路径使用上一步创建的桶。我们需要一个MSK集群，本文不赘述MSK集群的创建步骤，这个集群须无身份认证，使用PLAINTEXT传输，同时和EMR需能连通。将如下两个包上传至集群所有节点的/usr/lib/hbase/lib/文件下

首先，强调一下测试环境：本次测试是在AWS EMR Serverless EMR 6.10 和 6.11 两个版本上进行的，对应的Hudi版本是0.12.2和0.13.0，该测试的结论在同版本的开源Spark和Hudi上不一定成立，请知悉。其次，在同一测试环境下，单表的 CDC 数据接入已经测试完毕并发表在：《…》，多表接入的细节汇总在此文中。先说重要结论

题目有些拗口，简短截说，我们对于Apache Hudi DeltaStreamer在接入CDC数据时，对于其如何通过 Kafka 的身份认证，做了一系列测试和研究，有如下明确结论：

问题描述：AWS MSK Connector 使用了Confluent Schema Registry, 消息格式为Avro, 在启动Connector 时日志中报错：[Worker-0cb4b7ad6e5f2ce25] Caused by: org.apache.kafka.connect.errors.DataException: Failed to serialize Avro data from topic osci.mysql-server-3