Laurence的技术博客

本文是《CDC 数据入湖方案：MySQL ＞ Flink CDC ＞ Kafka ＞ Hudi》的增强版，借助 Flink CDC 从源头数据库接入数据并写入到 Kafka 后再使用 Flink 将数据写入到 Hudi 表中，在此过程中，使用了 Avro 格式传输数据，提升了效率，同时全程由 Confluent Schema Registry 参与，对 Schema Evolution 进行管控，该方案是一个完整的端到端的解决方案，也是最接近实际应用的选型方案之一。

我们用 Flink CDC 完成 CDC 数据入湖任务：借助 Flink CDC 从源头数据库接入数据并写入到 Kafka 中，然后再使用 Flink 将数据写入到 Hudi 表中，所以这是一个完整的端到端的解决方案。上一篇文章我们省略了搭建 Kafka Connect + Debezium MySQL Connector 采集 CDC 数据的环节，因为这部分操作很复杂，Flink CDC 在应用和架构上确实比 Kafka Connect + Debezium MySQL Connector 的组合简单得多

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

需要提醒的是：Kafka Connect上必须安装Debezium MySQL Connector和Confluent Avro Converter两个插件，因此需要在官方镜像的基础上手动添加这两个插件；在上面的 SQL 中，开头部分的几个 SET 语句非常重要，它们用于设置 Checkpoint，如果没有这些设置，写入操作都不会提交，看到的状况就是：作业流一直运行，没有报错，但是 Hudi 表不会有任何数据，关于这一问题以及这些 SET 语句的解释，已在。

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

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

以往介绍的开箱即用方案往往都是一张表对应一个 Kafka Topic，在数据库和数据表数量很大的情况下，这种模式是不实用的，主要问题在于：每张表都对应一个单独的 Flink 作业，占用一个单独的数据库连接，表的数量一多，对数据库造成的压力是不可接受的。此外，针对每张表使用 Flink SQL 定义 CDC 作业也是一项繁重的重复性工作，如果能简化或省略也是很实用的一项改进。所以，实用的解决解决方案应该是：使用一个 Flink 作业完成整库 / 多表的 CDC 数据接入工作。

本测试要验证两个问题：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 脚本。

问题场景是：使用 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