Apache Hudi是一个开源的数据湖存储格式和框架，它通过引入类似数据库的事务机制，解决了传统数据湖在实时更新、低延迟查询和增量消费方面的痛点。Hudi最初由Uber于2016年开发并应用于生产环境，2017年开源，2019年成为Apache孵化项目，2021年正式毕业为Apache顶级项目。作为数据湖领域的创新者，Hudi的核心价值在于实现了PB级数据湖上的低延迟ACID事务，使数据湖具备了接近数据库的实时性 ，同时保持了数据湖的灵活性和成本优势。

Figure: Apache Hudi Database Architecture

一、Apache Hudi的诞生背景

1.1 传统数据湖的局限性

在大数据领域，数据湖（Data Lake）作为一种存储原始数据的低成本解决方案，得到了广泛应用。然而，传统数据湖（如HDFS+Parquet）存在几个关键缺陷：

• 仅支持追加操作：传统数据湖无法高效支持记录级别的更新、删除操作，每次更新都需要全量覆盖，导致存储膨胀和性能下降 。
• 缺乏版本控制：数据更新后无法回滚，难以支持复杂的数据治理和合规要求 。
• 高延迟查询：数据更新后需要等待批处理作业完成，才能获得最新视图，无法满足近实时分析需求 。
• 增量消费困难：下游系统需要重新处理全量数据才能获取变更，导致资源浪费和处理延迟 。

这些问题在Uber等处理海量实时数据的企业中尤为突出。Uber每天处理数百TB的行程、乘客和司机数据，传统的批处理方式无法满足其对低延迟数据分析的需求。

1.2 Hudi的诞生历程

为解决上述问题，Uber于2016年8月开发了Hudi（Hadoop Updates and Incrementals的缩写），并在生产环境中部署 。Hudi最初被称为"Hoodie"，在2017年开源，并于2019年捐赠给Apache软件基金会，2021年4月左右毕业成为Apache顶级项目 。

Hudi的诞生背景与Uber的业务需求紧密相关。在当时，Uber面临的主要挑战包括：

• 实时数据更新：需要支持海量数据的实时更新，如行程状态变更、乘客信息更新等 。
• 低延迟查询：业务决策需要基于最新数据，无法接受小时级或天级的延迟 。
• 增量消费：下游系统需要高效获取数据变更，而不是重新处理全量数据 。
• 数据治理：需要支持数据版本控制、回滚和审计等功能 。

Hudi通过引入类似数据库的事务机制和文件组织方式，成功解决了这些问题，成为Uber数据湖的核心组件。

二、Hudi的核心架构设计

2.1 三层架构模型

Apache Hudi采用分层架构设计，分为事务数据库层、编程API层和用户接口层：

1. 事务数据库层：这是Hudi的核心，包含表格式（存储布局）、表服务（文件优化）、索引（加速读写）、并发控制（确保数据一致性）、湖缓存（提升读取效率）和元服务器（集中元数据访问）等组件 。
2. 编程API层：提供标准化的写入器和读取器接口，使Hudi能够与各种计算引擎（如Spark、Flink）集成，同时支持高效的更新插入和增量处理 。
3. 用户接口层：提供高级别工具，包括摄取实用程序（如DeltaStreamer）、目录同步工具和管理CLI等平台服务，以及与Spark、Hive、Presto等查询引擎的集成 。

这种分层设计使Hudi既具备了数据库的事务能力和实时性，又保持了数据湖的灵活性和可扩展性。

2.2 存储类型与文件组织

Hudi支持两种主要的存储类型，针对不同的使用场景优化：

1. 写时复制（Copy On Write, COW）：所有数据都存储在列式文件（如Parquet）中，每次更新都会生成新版本的文件。COW表的写入成本较高（需要重写整个文件），但读取性能最佳，适合读取密集型分析工作。

2. 读时合并（Merge On Read, MOR）：数据分为基线文件（列式Parquet）和增量日志（行式Avro）两部分存储。MOR表的写入成本较低（只需追加日志），但读取性能略差（需要合并基线和日志），适合写入密集型场景和需要低延迟查询的应用。

Hudi的数据组织遵循以下层级结构：

• 基本路径（Base Path）：数据集的根目录，所有数据和元数据都存储在此路径下 。
• 分区（Partition）：数据按分区键（如时间戳）组织到不同的子目录中，类似于Hive表的分区机制 。
• 文件组（File Group）：由文件ID唯一标识的逻辑单元，包含一组记录的所有版本。
• 文件切片（File Slice）：每个文件组包含多个文件切片，每个切片包含一个基线文件（.parquet）和一组增量日志（.log.*）。

这种组织方式使Hudi能够高效管理海量数据，并支持记录级别的更新操作。

2.3 时间轴与版本控制

Hudi的核心创新之一是引入了时间轴（Timeline）机制，用于跟踪表的历史变化：

• 时间轴结构：Hudi 1.0版本引入了LSM（Log-Structured Merge）树时间线，采用分层结构（L0活动层、L1-Ln优化层）管理历史操作，支持百万级历史记录管理 。
• 操作类型：包括COMMITS（提交）、CLEANS（清理）、DELTA_COMMIT（增量提交）、COMPACTION（压缩）、ROLLBACK（回滚）和SAVEPOINT（保存点）等 。
• 时间戳管理：Hudi采用TrueTime语义确保所有操作的时间戳单调递增和全局有序，解决时钟偏斜问题 。

时间轴机制使Hudi能够提供三种视图：

1. 快照视图（Snapshot View）：提供表的最新状态，所有已完成操作的数据 。
2. 读优化视图（Read Optimized View）：仅包含基线文件，优化查询性能 。
3. 增量视图（Incremental View）：提供指定时间点后的增量数据，支持高效消费变更 。

这种设计使Hudi能够同时满足实时更新和高效查询的需求。

三、Hudi解决的关键问题

3.1 数据更新问题

传统数据湖仅支持追加操作，无法高效支持记录级别的更新、删除操作。Hudi通过COW/MOR表结构实现了记录级的IUD（插入、更新、删除）操作：

• COW表：通过重写文件保证更新一致性，适合读取密集型场景。
• MOR表：通过日志追加降低写入开销，适合写入密集型场景 。

Hudi的索引机制（如BloomFilter、HBase索引）将hoodie键（记录键+分区路径）映射到文件组，确保更新操作能够快速定位到目标文件。这种设计使Hudi能够处理PB级数据湖的实时更新，而无需全量覆盖。

3.2 延迟处理问题

在流处理场景中，数据通常存在延迟到达的情况。Hudi通过事件时间（Event Time）与提交时间（Arrival Time）分离的机制，支持乱序数据处理：

• 事件时间：数据中记录的时间，表示事件实际发生的时间。
• 提交时间：数据到达Hudi的时间，表示数据被写入的时间。

这种分离使Hudi能够将延迟数据归入正确的事件时间分区，而不是提交时间分区。例如，一个9:00事件的数据在10:20到达，Hudi仍会将其写入9:00的分区，而不是10:20的分区。这使得下游系统能够基于事件时间进行一致的分析，而无需担心数据延迟。

3.3 增量消费问题

传统数据湖的增量消费通常依赖文件夹/分区的创建时间，这在处理延迟数据时效率低下。Hudi通过时间轴机制提供了高效的增量消费能力：

• 增量视图：下游系统可以基于提交时间戳获取增量数据，无需扫描全量数据。
• 增量查询：通过时间轴的元数据，Hudi能够快速定位哪些文件切片包含新数据，只消费这些文件。
• 增量管道：Hudi支持构建高效的增量ETL管道，每小时处理TB级数据，端到端延迟仅30分钟。

这种能力在构建实时数据管道、机器学习特征工程和数据分发等场景中尤为重要，能够显著降低计算资源消耗和处理延迟。

四、Hudi的核心特性

4.1 ACID事务支持

Hudi提供了类似数据库的ACID事务能力，确保数据更新的原子性、一致性、隔离性和持久性 ：

• 原子性（Atomicity）：通过时间轴的atomic commit机制实现，提交前生成临时文件，成功后原子替换 。
• 一致性（Consistency）：保证数据更新符合业务规则，如主键唯一性等 。
• 隔离性（Isolation）：通过快照隔离（Snapshot Isolation）确保并发事务互不干扰，读取器始终基于提交时间戳访问已完成的文件版本 。
• 持久性（Durability）：确保已提交的数据即使在系统故障后也能恢复 。

Hudi的ACID事务支持使其能够处理关键业务场景，如GDPR数据删除、金融交易记录更新等，确保数据的准确性和可靠性。

4.2 MVCC与并发控制

Hudi采用多版本并发控制（MVCC）和非阻塞并发控制（NBCC）机制，实现高并发写入和低延迟查询：

• MVCC机制：基于时间轴的瞬时（Instant）生成Read View，事务开始时创建快照，后续查询仅访问该快照时间点前的已完成版本 。
• NBCC机制：允许多个写入器并行追加日志文件（MOR表），冲突在压缩阶段解决，通过记录提交开始和完成时间戳实现日志排序 。
• OCC机制：用于COW表，写入前检查版本，冲突时重试 。

这些机制使Hudi能够在处理大量并发写入的同时，保持低延迟的查询性能，满足实时分析的需求。

4.3 文件组织与LSM树时间线

Hudi 1.0版本引入了LSM树时间线，优化了元数据管理和历史版本控制：

• 分层结构：元数据文件按对数结构合并（LSM）树布局组织成层（L0、L1、L2等），每层文件按时间戳排序，命名遵循{min_instant}_{max_instant}_${level}.parquet格式 。
• 压缩策略：活动层（L0）的事务日志（Avro格式）在达到阈值后被合并到优化层（L1），进一步减少存储开销和查询延迟  。
• 清单文件：跟踪同一层中可能重叠时间范围的文件，提高元数据查询效率  。

LSM树时间线使Hudi能够有效管理海量历史版本，支持长时间窗口的增量查询，而不会因文件列表膨胀导致性能下降。

4.4 索引机制

Hudi支持多种索引机制，加速记录的定位和查找：

• BloomFilter索引：为每个文件切片生成布隆过滤器，快速判断记录是否存在，减少文件扫描范围 。
• HBase索引：利用HBase的O(1)查询能力，实现高效记录定位。
• Elasticsearch索引：支持全文搜索和复杂查询，适合非结构化数据场景。

这些索引机制使Hudi能够处理PB级数据的高效查询，而无需依赖外部数据库或搜索引擎。

4.5 增量查询与消费

Hudi的时间轴机制使其能够提供高效的增量查询和消费能力：

• 增量视图：下游系统可以基于提交时间戳获取增量数据，无需扫描全量数据 。
• 增量拉取：通过时间轴的元数据，Hudi能够快速定位哪些文件切片包含新数据，只消费这些文件 。
• 增量处理：支持构建增量ETL管道，每小时处理TB级数据，端到端延迟仅30分钟 。

这种能力在构建实时数据管道、机器学习特征工程和数据分发等场景中尤为重要，能够显著降低计算资源消耗和处理延迟。

五、Hudi与同类产品的技术对比

5.1 Hudi vs Delta Lake

Hudi在实时更新和低延迟查询方面具有优势，而Delta Lake在批处理性能和Spark生态集成方面表现更好。例如，在处理每小时TB级数据的增量管道时，Hudi可以提供端到端30分钟的延迟，而Delta Lake可能需要更长时间。

5.2 Hudi vs Iceberg

Hudi在实时更新和增量消费方面表现更佳，而Iceberg在元数据管理和大规模数据集查询方面更具优势。例如，在处理高吞吐量的实时数据流时，Hudi的MOR表能够提供更好的性能，而Iceberg更适合需要复杂查询优化的场景。

​​选型建议​​：

• 需要最强UPSERT性能 → ​​Hudi​​

• 已深度使用Spark且需求简单 → ​​Delta Lake​​

• 追求最大兼容性和标准性 → ​​Iceberg​

六、Hudi的使用方法与最佳实践

6.1 环境准备

要使用Hudi，需要确保以下环境已就绪：

• 存储系统：HDFS、S3或其他Hadoop兼容文件系统。
• 计算引擎：Spark 2.4.4+版本（Hudi主要依赖Spark的计算能力）。
• 查询引擎：Hive、Presto、Hudi Native等。

在Spark中配置Hudi的依赖和参数：

// 添加Hudi依赖
val hudiSpark = spark.config("spark.sql.catalog.spark_catalog","org.apache.spark.sql.hudi catalog.HoodieCatalog"
).config("spark.serializer","org.apache.spark.serializer.KryoSerializer"
).config("spark.sql extensions","org.apache.spark.sql.hudi.HoodieSparkSessionExtension"
)

6.2 创建Hudi表

Hudi表的创建与普通Spark表类似，但需要指定存储类型和主键：

// 创建COW表
spark.sql("""CREATE TABLE cow_table (id INT, name STRING, price DOUBLE)USINGHUDITBLPROPERTIES (hoodie table type='cow',hoodiehoodie key='id',hoodiehoodie index type='bloom')"""
)// 创建MOR表
spark.sql("""CREATE TABLE mor_table (id INT, name STRING, price DOUBLE)USINGHUDITBLPROPERTIES (hoodie table type='mor',hoodiehoodie key='id',hoodiehoodie index type='bloom',hoodiehoodie compaction strategy='inplace')"""
)

6.3 写入数据

Hudi支持多种写入方式，包括插入、更新、删除和合并：

// 插入数据
val df = spark.createDataFrame(data, schema)
df.write.format("HUDI").option("hoodie.insert.update.key", "id").save("basepath/cow_table")// 更新数据
df.write.format("HUDI").option("hoodie.insert.update.key", "id").option("hoodie操作类型", "upsert").save("basepath/mor_table")// 删除数据
df.write.format("HUDI").option("hoodie.insert.update.key", "id").option("hoodie操作类型", "delete").save("basepath/cow_table")

6.4 查询数据

Hudi支持三种视图，根据查询需求选择合适的视图：

// 查询快照视图（最新状态）
val snapDF = spark.read.format("HUDI").load("basepath/cow_table")// 查询读优化视图（优化查询性能）
val roDF = spark.read.format("HUDI").option("hoodie.read.optimize", "true").load("basepath/mor_table")// 查询增量视图（获取指定时间点后的增量数据）
val incDF = spark.read.format("HUDI").option("hoodie.read增量", "true").option("hoodie开始时间", "20250815000000").load("basepath/cow_table")

6.5 表服务与优化

Hudi提供了多种表服务操作，用于优化表性能：

// 压缩操作（合并日志文件到基线文件）
spark.sql("CALLHUDI.执行压缩('basepath/mor_table')")// 清理操作（删除旧版本文件）
spark.sql("CALLHUDI.执行清理('basepath/cow_table')")// 保存点操作（标记某些文件组为已保存，防止被清理）
spark.sql("CALLHUDI.创建保存点('basepath/cow_table', '20250815000000')")

6.6 实时流处理集成

Hudi与Flink集成，支持实时流处理：

Map<String, String> options = new HashMap<>();
options.put("connector", "hudi");
options.put("path", "hdfs://path/to/table");
options.put("table.type", "MERGE_ON_READ");DataStream<RowData> source = HoodiePipeline.builder("my_table").column("id STRING").column("name STRING").pk("id").options(options).source(env);HoodiePipeline.builder("my_table").options(options).sink(source, false);

6.7 读取优化查询

仅适用于 Merge-On-Read 表

// 读优化查询
val readOptimizedDF = spark.read.format("org.apache.hudi").option(DataSourceReadOptions.QUERY_TYPE_OPT_KEY, DataSourceReadOptions.QUERY_TYPE_READ_OPTIMIZED_OPT_VAL).load("/user/hudi/" + tableName + "/*")readOptimizedDF.show()

6.8 数据删除

import org.apache.hudi.QuickstartUtils._
import scala.collection.JavaConverters._// 定义要删除的记录主键
val deleteIds = Seq(3).toList.asJava// 执行删除操作
spark.write.format("org.apache.hudi").option(DataSourceWriteOptions.TABLE_TYPE_OPT_KEY, DataSourceWriteOptions.COW_TABLE_TYPE_OPT_VAL).option(HoodieWriteConfig.TABLE_NAME, tableName).option(DataSourceWriteOptions.RECORDKEY_FIELD_OPT_KEY, primaryKey).option(DataSourceWriteOptions.PARTITIONPATH_FIELD_OPT_KEY, partitionColumn).option(DataSourceWriteOptions.OPERATION_OPT_KEY, DataSourceWriteOptions.DELETE_OPERATION_OPT_VAL).mode(SaveMode.Append).save("/user/hudi/" + tableName)

七、未来展望：Hudi的发展路线

1. ​​Z-Order优化​​：更高效的多维数据布局

2. ​​更强大的流式能力​​：降低端到端延迟

3. ​​跨云统一​​：优化不同存储后端的性能

4. ​​AI集成​​：直接支持机器学习工作流

结语：为什么开发者应该选择Hudi？

在数据架构从传统数据仓库向Lakehouse演进的今天，Apache Hudi提供了​​唯一兼具数据库灵活性和数据湖扩展性​​的解决方案。其​​增量处理能力​​特别适合现代实时分析需求，而​​ACID保证​​则解决了数据一致性的老大难问题。

"掌握Hudi，意味着你能够在云原生时代构建真正弹性的数据基础设施"