Laurence的技术博客

本文首发于Apache Hudi公众号。Clustering是Hudi在0.7.0版本引入的一项特性，用于优化文件布局，提升读写性能，现在它已经成为Hudi的一项重要性能优化手段。本文我们会通过Notebook介绍并演示Clustering的运行机制，帮助您理解其工作原理和相关配置。

本文首发于Apache Hudi公众号。Compaction是MOR表的一项核心机制，Hudi利用Compaction将MOR表产生的Log File合并到新的Base File中。本文我们会通过Notebook介绍并演示Compaction的运行机制，帮助您理解其工作原理和相关配置。

本文首发于Apache Hudi公众号。在本系列的上一篇文章中，我们通过Notebook探索了COW表和MOR表的文件布局，在数据的持续写入与更新过程中，Hudi严格控制着文件的大小，以确保它们始终处于合理的区间范围内，从而避免大量小文件的出现，Hudi的这部分机制就称作“File Sizing”。本文，我们就针对COW表和MOR表的File Sizing进行一次深度探索。

本文首发于Apache Hudi公众号。以往介绍Apcache Hudi的文章对核心概念的解读大多引用官方文档中的概念图，但是，抽象概念与实际运行状况还是有不少差异的，很多学习和使用Hudi的开发者都曾尝试过：将文档中的概念和Hudi的实际运行状况结合起来推导每个动作背后的逻辑是什么。本文利用Notebook良好的交互能力，设计一系列有针对性的操作，让这些操作去触发Hudi的某些机制，然后观察Hudi数据集的状态（包括元数据和存储文件），再结合对Hudi相关概念的介绍，解读这些行为。

本文发表于Apache Hudi公众号，文章对Glue与Hudi的集成做了可行性分析和理论探索，并通过一个完整的示例演示了如何在Glue作业中使用Hudi，同时将将Hudi元数据同步到Glue Catalog。

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

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

本文由本人撰写并首发于Apache Hudi公众号，共计四篇文章。本系列文章使用 Notebook 对 Apache Hudi 核心概念展开深入的探索和介绍，利用 Notebook 提供的统一环境和上下文，我们可以非常生动地观察到 Hudi 的运行机制，并深刻体会到其背后的控制原理，这也正是本系列文章的写作灵感：我们希望借助 Notebook“探索，发现，思考，领悟”的思维模式，带领大家开启一段 Hudi 核心概念的探索之旅。

最近一次使用Hudi SQL向一个Hudi数据表插入数据时，遇到如下错误：HoodieException: Expected table’s schema: … query’s output (including static partition values): … 经过仔细核查发现插入的目标表中少了一个刚刚修改过的列product_category，但让人费解的是，这个列明明在建表语句中有，但是执行建表语句后查询表结构，确实没有该列

该问题一般发生在EMR6+版本上，也就是Hive3/Spark3上，诱因之一是在Hudi中设置了：DataSourceWriteOptions.HIVE_USE_JDBC_OPT_KEY -> "false"，具体错误为：java.lang.ClassNotFoundException: org.apache.calcite.rel.type.RelDataTypeSystem这是由于Hiv3/Spark3移除了对于calcite包的依赖引起的，所以不建议在EMR上配置DataSourceWri

继我们上篇文章《在AWS Glue中使用Apache Hudi》介绍了如何在Glue中同步Hudi元数据之后，本文我们再简短截说一下Hudi在EMR上的元数据同步。首先，EMR对于元数据的存储提供两种方案：一是标准的Hive Metastore ，即使用一个关系型数据库村存储元数据；二是使用是Glue Catalog。显然，在使用标准Hive Metastore时，我们不必担心Hudi有同步元数据上有任何问题，需要我们确认的是在EMR使用Glue Catalog时，应该如何配置元数据同步。先说结论：当E

1 问题描述闯过第二关之后，普通的元数据同步基本就没什么问题了。但是当遇到下面这种场景时，同步再次“翻了车”：如果在一个SparkSession下，先读取一个Hudi数据集，得到DataFrame，在进行一些数据转换之后将变换后DataFrame再次以Hudi的形式写入另一张表，此时，Hudi会在同步这张新表的元数据时离奇失败。而这类操作其实是最典型不过的ETL操作流程，所以你大概率会遇上这个问题。这一问题并不在配置上，所有配置与前面完全一样，起初在遇到这一问题时，我试过修改各种操作与配置进行验证，可

让Hudi自动同步元数据到Hive Metastore，我们需要对Hudi进行一些必要的配置，根据官方文档( https://hudi.apache.org/docs/configurations.html#hive-sync-options )给出的说明，标准的Hudi Hive Sync配置应该是这样的：首先是最基本的三项：DataSourceWriteOptions.HIVE_SYNC_ENABLED_OPT_KEY -> "true"DataSourceWriteOptions.HIVE

Glue集成Hudi有几个很“深”的坑，一不小心掉进去就会耽误大量时间，像Got runtime exception when hive syncing / Failed to check if database exists / Cannot create hive connection jdbc:hive2://localhost:10000/ 这些错误怎么解决？ 本文会一一解决！1. 第一关：标配无效，使用替代方案2. 第二关：找到关键配置，开启同步3. 第三关：同Session先读再写，再次失败

答案：不是!默认情况下，Record Key只保证在同一分区内是唯一的。如果我们需要让Record Key变成全局唯一主键，按官方文档的说法：Record keys uniquely identify a record/row within each partition. If one wants to have a global uniqueness, there are two options. You could either make the dataset non-partitioned, o

本文要讨论的是这样一个问题：使用Hudi的COW表时，有一个很明显的现象：当表中有大量的更新数据写入时，落地的parquet文件往往总大小往往要double，每写入一次就会double一次，对于数据体量非常大，且每次都有大量更新的数据来说，不禁会让人担心：这种数据膨胀是否会快速耗尽存储资源？有没有可以克制的方法？其实，这并不是一个问题，而是Hudi表的正常表现，我们先从原理上来看一下产生这个问题背后的原因。对于Huidi COW表的工作方式，下图有非常清晰的演示：我们要注意到：Copy-On-Writ