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.

我们此前介绍的一些 CDC 开箱即用方案往往都是一张表对应一条独立的链路（作业），需要一个独立的数据库连接，在表数量很大的情况下，会对数据库造成很大压力，同时过多的 Flink 作业会不易于管理和维护，为众多小表创建独立的采集作业也浪费了资源。此外，使用 Flink SQL 针对每张表定义 CDC 作业也是一项繁重的工作，如果能简化或省略编写大量 SQL 的工作也是一项重要的改进。所以，一种更为实用的解决方案是：使用一个 Flink 作业完成整库 / 多表的 CDC 数据接入工作。本文我们会详细介绍一下这一

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

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

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

本方案的技术链路为：使用 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 管理。

当我们使用命令行批量从 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 的作用机理。

此前，我们单独介绍过 PIP 和 Conda，在后续的实际应用中，还是遇到了不少 Python 环境构建的问题，特别是在 Windows 系统上，最突出的表现是：虽然PIP的包依赖解析和下载都很快，但在 Windows 上经常会因为缺失底层依赖的程序库（例如某些dll文件）而导致 Python 程序启动时报错，此时，改用 Conda 通常可以解决此类问题，但是，Conda 的问题在于：它的包依赖解析问题很大，耗时很长，解决 Conda 这一问题的方法是引入 Mamba，Mamba 可以视作是 Conda 的

简单讲：Conda 的 Channel 就是 Repo，与 Yum 和 Maven 中的 Repository 是一样的，用于存放各种 Python 包的公共库。以下几个 Channel 是 Conda 中最为常见的，简单介绍一下. Default Channel：顾名思义，默认的 Channel，它由 Anaconda 公司维护Anaconda Channel：是由社区维护的，通常比默认 Channel 包含更多的包，更新也更快

配置 AWS 的 AD Connector 通常遇到的都是些网络问题，且 AD Connector 本身屏蔽了一些网络细节，使得查找root cause往往有点困难，本文就把 AD Connector 网络问题梳理一下。首先，需要搞清楚的是：AD Connector 是 Microsoft Active Directory 的一种代理，IAM可以通过它联通到一个现有的 AD 服务器，从而可以值得用户可以使用AD上的域账号登录AWS的某些服务。要特别注意的是：AD Connector 本身是需要服务器承载

HBase 的 Compaction 有两个线程池，一个是为 Minor Compaction 准备的， 一个是为 Major Compaction 准备的，hbase.regionserver.thread.compaction.throttle 是决定 Compaction 请求放入哪个线程池的阈值，当待合并文件的总大小小于这个阈值时，就是一个 Minor Compaction，当待合并文件的总大小大于这个阈值时，就是一个 Major Compaction。这个阈值的默认值是：2.5 GB （26843