Hudi组件概述
更新时间 2026-10-12 11:42:27
最近更新时间: 2026-10-12 11:42:27
本章节介绍Hudi服务基础概述。
Hudi（Hadoop Upserts Deletes and Incrementals）是构建于分布式存储之上的数据湖框架，为数据湖提供记录级 upsert、delete 与增量查询能力，并通过时间线（Timeline）机制保证快照隔离与原子性。Hudi 管理的数据以列式格式（Parquet）存储，配合基础文件与日志文件的组合，在近实时写入与高性能查询之间取得平衡。
本集群中Hudi 1.2.0 与 Spark 3.4.1 集成部署：用户通过 spark-submit 提交 Spark on YARN 作业，在作业内以 DataSource API（format("hudi")）或 Spark SQL（USING hudi）方式读写 Hudi 表，表数据与元数据存储于 HDFS。Hudi 通过写入时维护时间线元数据（.hoodie 目录），保证并发读写之间的一致性视图。
Hudi 的核心概念说明如下表所示：
| 概念 | 说明 |
|---|---|
| Timeline（时间线） | Hudi 表所有操作的时间序列，由若干 Instant（时刻）组成，是提供快照隔离与原子性的基础 |
| Instant（时刻） | 一次操作的唯一标识，由时间戳、操作类型与状态组成，例如20260917093000123.commit |
| File Group（文件组） | 数据组织的基本单元，由File ID 唯一标识，记录的 upsert 始终落在所属文件组内 |
| File Slice（文件切片） | 文件组在某个时刻的数据形态，由一个基础文件（Base File）与若干日志文件（Log File）组成 |
| Base File（基础文件） | 列式存储文件，Parquet 格式，文件名为 <fileId>_<writeToken>_<instantTime>.parquet |
| Log File（日志文件） | MOR 表追加更新的载体，文件名以 . 开头，格式为 .<fileId>_<instantTime>log.<version> |
| Record Key（记录键） | 唯一标识分区内一条记录的字段，upsert/delete 按其定位 |
| Precombine Field（预合并字段） | 同一批次内Record Key 相同时，保留该字段值最大的一条记录 |
| Index（索引） | Record Key 到 File Group 的映射，决定 upsert 时记录的定位方式，支持 Bloom、Simple、Bucket、HBase 等类型 |
| Compaction（压缩） | MOR 表将日志文件与基础文件合并生成新基础文件的机制 |
| Clustering（聚簇） | 在不改变数据内容的前提下重组文件布局，优化文件大小与查询性能 |
时间线上记录的主要操作类型如下表所示：
| 操作类型 | 说明 |
|---|---|
| commit | COW 表的写入提交（原子性重写基础文件） |
| deltacommit | MOR 表的写入提交（追加日志文件） |
| replacecommit | 涉及文件替换的提交，如insert_overwrite、clustering |
| compaction | MOR 表日志与基础文件的合并计划（deltacommit 执行） |
| clustering | 数据重布局计划（replacecommit 执行） |
| clean | 清理过期文件版本 |
| rollback | 失败写入的回滚 |
| savepoint/restore | 保存点与恢复到历史保存点 |
Hudi 支持两种表类型，写入延迟、更新代价与查询性能的权衡不同，建表时通过 type 指定且建表后不可更改：
| 表类型 | 写入方式 | 查询方式 | 适用场景 |
|---|---|---|---|
| COW（Copy On Write） | 更新时重写生成新的基础文件，写放大较高 | 直接读Parquet，查询性能最优 | 读多写少、批量ETL 场景 |
| MOR（Merge On Read） | 更新追加写入日志文件，写入快 | 快照查询需合并基础文件与日志文件，读放大较高 | 写多读少、频繁更新场景 |
