Laurence的技术博客

由于 Hudi 的 HoodieMultiTableStreamer / HoodieMultiTableDeltaStreamer 是一次处理多张 Hudi 表的写入，这些表既会有如 hoodie.deltastreamer.source.kafka.value.deserializer.class 这样相同的公共配置，也会有如 hoodie.datasource.write.recordkey.field 这样每张表每张表都不同的个性化配置，为此，HoodieMultiTableStreamer / H

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

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

在使用 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，那么会有很大概率遇到中文乱码问题，下面就是一个示例

在使用 HoodieStreamer 启动一个 CDC 数据实时入湖的作业中，遇到了这样一个报错：org.apache.spark.sql.AnalysisException:[UNRESOLVED_COLUMN.WITH_SUGGESTION] A column or function parameter with name ts_ms cannot be resolved. Did you mean one of the following? [after, op, before].; line

在使用 Hudi 的 HoodieStreamer 或 HoodieMultiTableStreamer 接入 Debezium CDC 数据并写入 Hudi 表过程中，我们可能会遇到这样一个错误：NoSuchMethodException: org.apache.hudi.utilities.sources.debezium.MysqlDebeziumSource.(org.apache.hudi.common.config.TypedProperties, org.apache.spark.api.

作为开发者，在构建 Flink 应用程序时的体验真是一言难尽，想必大家都曾遇到过各种 ClassNotFoundException、NoSuchMethodError 以及 Could not find any factory for identifier kafka/jdbc/hive/hudi that implements org.apache.flink.table.factories.DynamicTableFactory in the classpath 这样的错误。坦率地说，Flink 的应用

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

运行 Flink 应用或执行 Flink SQL 时会经常遇到下面的错误：org.apache.flink.table.api.ValidationException: Could not find any factory for identifier kafka jdbc hive hudi mysql-cdc that implements ‘org.apache.flink.table.factories.DynamicTableFactory’ in the classpath.

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

MSK 集群通常都是建在私有子网中的，这给本地访问带来了很多麻烦，特别是需要在本地使用 Kafka GUI 客户端管理和读写 MSK 数据的时候。本文会给出一套解决方案。我们这里讨论的问题有一点特殊性，那就是：由于 MSK 是托管服务，它的 Broker 主机名虽然映射了一个私有的 IP 地址，但是不能通过 SSH 登录的，这是比较特殊的一个地方，另一个地方是：Kafka 集群基本都是三个以上的 Broker，它的连接地址往往是三台以上的主机+端口号，这是另一个比较特殊的地方

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

最近几年，整个 Java 生态圈正在经历并将长期出于从 JDK 8 到 JDK 17 或更高版本的升级换代中，较为典型是：以 Spring 为代表的 Web 应用开发框架大多已经升级到了 JDK 17，而在大数据生态圈，Flink、Spark 还在使用 JDK 8，对于那些多模块的 Maven 项目，会出现不同的 Module 使用不同版本的 JDK 问题，这给构建这类项目造成了一些困难，本文简单梳理一下这一问题的解决方法，给出最佳实践。

Flink的Temporal Join以及Temporal Table （时态表）关系密切，在知识结构上有点混乱，可能是历史原因造成的。本文希望把所有与 Temporal Join 相关的概念进行一次统一梳理，用更规范的知识结构把 Flink 的 Temporal Join 介绍清楚，包括：以 Temporal Table DDL 方式实现基于事件时间的 Temporal Join;以 Temporal Table DDL 方式实现基于处理时间的 Temporal Join;以 Temporal Table

本文要演示的是：使用 Temporal Table Function 定义被关联表（维表），然后基于主动关联表（事实表）的“处理时间”去进行 Temporal Join（关联时间维度上对应版本的维表数据）。由于 Flink 在新版本中已经禁止使用 Temporal Table DDL 实现基于处理时间的 Temporal Join，所以通过 Temporal Table Function 实现基于处理时间的 Temporal Join 已经是唯一的手段了。该演示同样涉及三个要点：被关联的表（维表）是用 Te

本文要演示的是：在流上关联一张外部表（例如 MySQL 数据库中的一张维表），用于丰富流上的数据，实际上，这正是最普遍的 ”维表 Join“ 的实现方式。通过这种方式和外部维表关联时，依然能关联到最新变化的维度数据，所以才说这是 ”维表 Join“。Lookup Join 与 《Flink Temporal Join 示例演示 (2)：Temporal Table DDL + 处理时间》一文演示情形是很相似的，但不同之处在于：这里的维表是通过 JDBC 方式连接的，而文章中的 Temporal Join 方

本文要演示的是：使用 Temporal Table Function 定义被关联表（维表），然后基于主动关联表（事实表）的“事件时间”去进行Temporal Join（关联时间维度上对应版本的维表数据）。该演示同样涉及三个要点：被关联的表（维表）是用 Temporal Table Function 形式定义的时态表;主动关联的表（事实表）需要定义：“事件时间”属性（但并不需要是一张版本表）;Temporal Join 是使用 Temporal Table Function + LATERAL TABLE 关

本文要演示的是：使用 Temporal Table DDL 定义被关联表（维表），然后基于主动关联表（事实表）的“处理时间”去进行Temporal Join（关联时间维度上对应版本的维表数据）。该演示涉及三个要点：被关联的表（维表）是用 Temporal Table DDL 形式定义，必须是一张时态表（版本表）;主动关联的表（事实表）需要定义“处理时间”属性，但并不需要是一张时态表（版本表）;Temporal Join 是使用 Temporal Table DDL + FOR SYSTEM_TIME AS

本文要演示的是：使用 Temporal Table DDL 定义被关联表（维表），然后基于主动关联表（事实表）的“事件时间”去进行Temporal Join（关联时间维度上对应版本的维表数据）。该演示涉及三个要点：被关联的表（维表）是用 Temporal Table DDL 形式定义，必须是一张时态表（版本表）;主动关联的表（事实表）需要定义”事件时间“属性，但并不需要是一张时态表（版本表）;Temporal Join 是使用 Temporal Table DDL + FOR SYSTEM_TIME AS

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

使用 Flink 向 Hudi 表中写入数据，使用 Spark SQL 的 Shell 查询 Hudi 表（使用的是 Hudi HMS Catalog 统一管理和同步 Hudi 表的元数据），结果在 Spark 中只能查询到打开 Shell 之前表中的数据，之后通过 Flink 写入的数据不可见，但重新打开一个新的 Spark SQL Shell，就可以看到了。

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

本方案的技术链路为：使用 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 中，然后再由后续的组件解析和处理。

一般来说，在 Flink SQL Client 中使用各种 Connector 只需要该 Connector 及其依赖 Jar 包部署到 ${FLINK_HOME}/lib 下即可。但是对于某些特定的平台，如果 AWS EMR、Cloudera CDP 等产品会有所不同，主要是它们中的某些 Jar 包可能被改写过，例如和 Hive Metastore 的交互，AWS EMR 就有另外一套 Metatstore：Glue Data Catalog，所以接口也做了相应的，所以，简单的复制开源的 Jar 包可能会

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

本问题发生的场景是：使用 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 管理。

有时候，使用 Maven 构建项目时，你可能会遇到上述错误。 导致产生这一错误的原因是：项目声明（POM文件）使用的 JDK 版本和本地安装的版本不一致导致的，例如：目前还有大量的项目在使用 JDK 8，而假如你本地安装的是 JDK 17，就会有很大概率遇到该问题。解决该问题的方法是：在本地安装与程序相匹配的 JDK 版本，然后在使用 Maven 命令构建项目前，显式地配置的 JAVA_HOME，就像下面这样：

当我们使用命令行批量从 S3 上拷贝文件或统计文件数量时，希望能排除掉 S3 上以 _$folder$ 结尾的占位文件，这个正则表达式应该怎么写呢？以下是统计 S3 某个位置下的除 _$folder$ 结尾的文件的文件数量

使用 aws emr modify-instance-groups 更新集群配置时可能会遇到如下错误信息：Unknown parameter in InstanceGroups[0]: “Configurations”, must be one of: InstanceGroupId, InstanceCount, EC2InstanceIdsToTerminate, ShrinkPolicy这一报错其实和提供的json配置信息并没有任何关系，是一个很糟糕的误导信息，如果你的配置确实是根据官方文档给

s3-dist-cp 是 AWS EMR 内置的用于 S3 和 HDFS 之间文件拷贝的专用工具，与 Hadoop 的 distcp 类似，也是通过 Map-Reduce 作业的方式实现分布式的文件复制（distcp 就是 distributed copy 分布式拷贝的意思）。s3-dist-cp 并不是一个简单的在 S3 和 HDFS 之间拷贝文件的工具，因为它并不是一个独立运行的命令行工具，而是要依靠 EMR 集群提交 MR 作业。实际上，它更多应用在超大数据集的迁移上，例如将原来 HDFS 上的构

DominantResourceCalculator 仅工作于 capacity-scheduler 模式下，需要启用 capacity-scheduler，然后在其下面配置 DominantResourceCalculator。以下是 启用 DominantResourceCalculator 的 EMR Configuration 的 Json 内容 （注意：spark-defaults 部分配置用于通过 Spark 测试时排除 DynamicAllocation 机制的影响，非必要配置，如不需要可移除

云上的计算实例挂载的存储盘通常可以在线实现磁盘扩容。本文以 AWS EMR 节点的磁盘扩容为例，记录一下具体的操作步骤。在详细介绍前，先将重要的总结发在前面，便于以后查阅：EMR 磁盘分配规则是：第一磁盘（/dev/nvme0n1），必备，大小由控制台的"EBS root volume"配置项指定，默认是 15GB，该盘是系统盘，挂载在根目录/下 第二磁盘（/dev/nvme1n1），必备，默认会大小根据所选EC2类型自动调整 第二磁盘的第一分区：5GB（固定值），挂载至 /emr 文件夹

IAM 和 Lake Formation 都是 AWS 上的权限管理服务，且默认都是自动开启并生效的，只是如果你没有特别配置过它们，可能感觉不到它们的存在，特别是Lake Formation（后文简写为 LF），通常情况下都是“透明”的，虽然但它确实在每次请求时进行了权限检查。本文会详细介绍一下两者之间的区别和联系，特别是 Lake Formation 的作用机理。