大数据技术之Hudi

最新推荐文章于 2025-06-15 17:51:19 发布

原创

最新推荐文章于 2025-06-15 17:51:19 发布 · 2.5k 阅读

3 ·

CC 4.0 BY-SA版权

文章标签：

#大数据 #hive #spark

ApacheHudi是一个流数据湖平台，提供表、事务、高效更新和删除功能，支持多种引擎如Spark、Presto等。其特色包括可插拔索引、增量拉取、事务控制和性能优化。Hudi适用于近实时写入、分析和增量数据管道，通过时间轴管理操作，优化文件布局和索引机制，支持CopyOnWrite和MergeOnRead两种表类型，适应不同场景需求。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Hudi概述

1.1 Hudi简介

Apache Hudi（Hadoop Upserts Delete and Incremental）是下一代流数据湖平台。Apache Hudi将核心仓库和数据库功能直接引入数据湖。Hudi提供了表、事务、高效的upserts/delete、高级索引、流摄取服务、数据集群/压缩优化和并发，同时保持数据的开源文件格式。
Apache Hudi不仅非常适合于流工作负载，而且还允许创建高效的增量批处理管道。
Apache Hudi可以轻松地在任何云存储平台上使用。Hudi的高级性能优化，使分析工作负载更快的任何流行的查询引擎，包括Apache Spark、Flink、Presto、Trino、Hive等。
在这里插入图片描述

1.2 Hudi特性

 可插拔索引机制支持快速Upsert/Delete。
 支持增量拉取表变更以进行处理。
 支持事务提交及回滚，并发控制。
 支持Spark、Presto、Trino、Hive、Flink等引擎的SQL读写。
 自动管理小文件，数据聚簇，压缩，清理。
 流式摄入，内置CDC源和工具。
 内置可扩展存储访问的元数据跟踪。
 向后兼容的方式实现表结构变更的支持。

1.3 使用场景

1）近实时写入

减少碎片化工具的使用。
CDC 增量导入 RDBMS 数据。
限制小文件的大小和数量。
2）近实时分析
相对于秒级存储（Druid, OpenTSDB），节省资源。
提供分钟级别时效性，支撑更高效的查询。
Hudi作为lib，非常轻量。
3）增量 pipeline
区分arrivetime和event time处理延迟数据。
更短的调度interval减少端到端延迟（小时 ->分钟） => Incremental Processing。
4）增量导出
替代部分Kafka的场景，数据导出到在线服务存储 e.g. ES。

3核心概念

3.1 基本概念

3.1.1 时间轴（TimeLine）

在这里插入图片描述
Hudi的核心是维护表上在不同的即时时间（instants）执行的所有操作的时间轴（timeline），这有助于提供表的即时视图，同时还有效地支持按到达顺序检索数据。一个instant由以下三个部分组成：

1）Instant action：在表上执行的操作类型

COMMITS：一次commit表示将一批数据原子性地写入一个表。
CLEANS：清除表中不再需要的旧版本文件的后台活动。
DELTA_COMMIT：增量提交指的是将一批数据原子性地写入一个MergeOnRead类型的表，其中部分或所有数据可以写入增量日志。
COMPACTION：合并Hudi内部差异数据结构的后台活动，例如:将更新操作从基于行的log日志文件合并到列式存储的数据文件。在内部，COMPACTION体现为timeline上的特殊提交。
ROLLBACK：表示当commit/delta_commit不成功时进行回滚，其会删除在写入过程中产生的部分文件。
SAVEPOINT：将某些文件组标记为已保存，以便其不会被删除。在发生灾难需要恢复数据的情况下，它有助于将数据集还原到时间轴上的某个点。

2）Instant time

通常是一个时间戳（例如：20190117010349），它按照动作开始时间的顺序单调增加。

3）State

REQUESTED：表示某个action已经调度，但尚未执行。
INFLIGHT：表示action当前正在执行。
COMPLETED：表示timeline上的action已经完成。

4）两个时间概念

区分两个重要的时间概念：

Arrival time: 数据到达 Hudi 的时间，commit time。
Event time: record 中记录的时间。

在这里插入图片描述
上图中采用时间（小时）作为分区字段，从 10:00 开始陆续产生各种 commits，10:20 来了一条 9:00 的数据，根据eventtime该数据仍然可以落到 9:00 对应的分区，通过timeline 直接消费 10:00 （commit time）之后的增量更新（只消费有新 commits 的 group），那么这条延迟的数据仍然可以被消费到。

3.1.2 文件布局（File Layout）

Hudi将一个表映射为如下文件结构:
在这里插入图片描述
Hudi存储分为两个部分：
（1）元数据：.hoodie目录对应着表的元数据信息，包括表的版本管理（Timeline）、归档目录（存放过时的instant也就是版本），一个instant记录了一次提交（commit）的行为、时间戳和状态，Hudi以时间轴的形式维护了在数据集上执行的所有操作的元数据；
（2）数据：和hive一样，以分区方式存放数据；分区里面存放着Base File（.parquet）和Log File（.log.*）；
在这里插入图片描述
（1）Hudi将数据表组织成分布式文件系统基本路径（basepath）下的目录结构
（2）表被划分为多个分区，这些分区是包含该分区的数据文件的文件夹，