Apache Hudi：数据湖的实时革命

喂完待续2025-08-17 21:44

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 适用场景
存储类型 支持COW和MOR 仅支持COW Hudi适合实时更新和低延迟查询；Delta Lake适合Spark生态内的流批一体
增量消费 时间轴机制，支持事件时间与提交时间分离 事务日志，按提交时间戳消费 Hudi支持延迟数据归入正确事件时间分区；Delta Lake需重新处理全量数据
索引机制 支持多种索引（BloomFilter、HBase等） 仅支持简单的分区索引 Hudi提供高效的记录定位能力；Delta Lake依赖分区优化查询
并发控制 COW表使用OCC，MOR表使用NBCC 仅支持OCC Hudi的MOR表支持更高的写入吞吐量；Delta Lake在冲突时需重试
生态集成 原生支持Flink，与Spark、Hive等兼容 深度集成Spark，对其他引擎支持较弱 Hudi适合多引擎环境；Delta Lake适合Spark主导的生态系统

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

5.2 Hudi vs Iceberg
特性 Hudi Iceberg 适用场景
存储类型 支持COW和MOR 仅支持COW Hudi适合实时更新；Iceberg适合大规模元数据管理
文件管理 LSM树时间线，动态压缩日志文件 清单文件（Manifest）管理，无内置压缩机制 Hudi优化存储效率；Iceberg提供文件级元数据统计
版本控制 时间轴记录所有操作，支持按时间戳回滚 快照（Snapshot）基于清单文件生成，支持时间旅行 Hudi提供更细粒度的版本控制；Iceberg适合EB级数据的元数据管理
并发控制 COW表使用OCC，MOR表使用NBCC 基于OCC，依赖外部工具实现冲突检测 Hudi的MOR表支持更高的写入吞吐量；Iceberg在元数据管理上更高效
生态集成 原生支持Flink，与Spark、Hive等兼容 兼容多引擎（Spark、Flink、Trino），但需额外适配 Hudi适合实时流处理；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的依赖和参数：

Scala 复制代码 
// 添加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表类似，但需要指定存储类型和主键：

Scala 复制代码 
// 创建COW表
spark.sql(
  """
  CREATE TABLE cow_table (id INT, name STRING, price DOUBLE)
  USINGHUDI
  TBLPROPERTIES (
   hoodie table type='cow',
   hoodiehoodie key='id',
   hoodiehoodie index type='bloom'
  )
  """
)

// 创建MOR表
spark.sql(
  """
  CREATE TABLE mor_table (id INT, name STRING, price DOUBLE)
  USINGHUDI
  TBLPROPERTIES (
   hoodie table type='mor',
   hoodiehoodie key='id',
   hoodiehoodie index type='bloom',
   hoodiehoodie compaction strategy='inplace'
  )
  """
)
6.3 写入数据

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

Scala 复制代码 
// 插入数据
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支持三种视图，根据查询需求选择合适的视图：

Scala 复制代码 
// 查询快照视图（最新状态）
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提供了多种表服务操作，用于优化表性能：

Scala 复制代码 
// 压缩操作（合并日志文件到基线文件）
spark.sql("CALLHUDI.执行压缩('basepath/mor_table')")

// 清理操作（删除旧版本文件）
spark.sql("CALLHUDI.执行清理('basepath/cow_table')")

// 保存点操作（标记某些文件组为已保存，防止被清理）
spark.sql("CALLHUDI.创建保存点('basepath/cow_table', '20250815000000')")
6.6 实时流处理集成

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

Scala 复制代码 
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 表

Scala 复制代码 
// 读优化查询
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 数据删除
Scala 复制代码 
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，意味着你能够在云原生时代构建真正弹性的数据基础设施"

相关推荐
青云交2 小时前
Java 大视界 -- 基于 Java 的大数据可视化在城市交通拥堵治理与出行效率提升中的应用（398）
java·大数据·flink·大数据可视化·拥堵预测·城市交通治理·实时热力图
高阳言编程7 小时前
4. 存储体系
架构
Galaxy在掘金7 小时前
从业8年，谈谈我认知的后端架构之路-1
java·架构
还是大剑师兰特8 小时前
Flink面试题及详细答案100道（1-20）- 基础概念与架构
大数据·flink·大剑师·flink面试题
天波信息技术分享9 小时前
AI 云电竞游戏盒子：从“盒子”到“云-端-芯”一体化竞技平台的架构实践
人工智能·游戏·架构
yh云想10 小时前
《从入门到精通：Kafka核心原理全解析》
分布式·kafka
k↑11 小时前
微服务之注册中心与ShardingSphere关于分库分表的那些事
数据库·微服务·架构·shardingsphere
1892280486111 小时前
NY243NY253美光固态闪存NY257NY260
大数据·网络·人工智能·缓存
武子康12 小时前
大数据-70 Kafka 日志清理：删除、压缩及混合模式最佳实践
大数据·后端·kafka
热门推荐
01UV安装并设置国内源02KGG转MP3工具|非KGM文件|解密音频03Qwen3-Coder 快速上手教程 | Qwen Code + Claude Code04【2025.08.06最新版】Android Studio下载、安装及配置记录（自动下载sdk）052025最新国内服务器可用docker源仓库地址大全（2025年8月更新）06蜘蛛磁力 搜索引擎大全，如何使用蜘蛛磁力查找磁力链接07TRAE 规则（Rules）配置指南：个人习惯、团队规范与最佳实践08TRAE Rules 实践：为项目配置 6A 工作流09全球最强模型Grok4，国内已可免费使用！（附教程）10NVIDIA显卡驱动、CUDA、cuDNN 和 TensorRT 版本匹配指南