hudi使用过程中的问题总结

最新推荐文章于 2026-06-17 22:06:05 发布

原创最新推荐文章于 2026-06-17 22:06:05 发布 · 1k 阅读

本内容遵循CC 4.0 BY-SA版权协议

标签

#数据库

COMMIT 是全量写入的强一致性动作，适合 COW 表与 MOR 表的 Compaction 场景；DELTA_COMMIT 是 MOR 表的增量写入优化，通过日志追加实现快速入湖，两者结合让 Hudi 同时支持批量与实时数据处理，满足不同读写性能需求。

对比维度	COMMIT	DELTA_COMMIT
适用表类型	Copy-On-Write (COW) 表；MOR 表的 Compaction 完成阶段	Merge-On-Read (MOR) 表
数据写入目标	直接写入列式存储的 Base File（如 Parquet）	写入行存 Delta Log（如 Avro 日志），延迟合并到 Base File
写入特性	全量重写受影响的文件组，写入成本高、查询性能稳定	增量追加日志，写入成本低、查询需合并日志与 Base File
典型场景	批量全量写入、COW 表的 Upsert/Insert、MOR 表 Compaction 生成新 Base File	MOR 表的近实时增量写入、流式数据快速入湖

Hudi MOR 表的多版本存储遵循增量存储 + 文件粒度复用原则，而非简单的全量拷贝：

在 MOR 表中：

一个 FileGroup 包含多个 FileSlice（每个对应一个 commit/deltacommit）。
Compaction 会：
- 将某个 FileSlice 中的 Base File + Delta Log Files 合并成一个新的 Base File。
- 生成一个新的 FileSlice（带有新的 base file，无 log files）。
- 在 Hudi Timeline 上记录一个 .commit（注意：不是 .deltacommit）。

🔄 Compaction 不会立即删除旧的 base file 和 log files！

这些旧文件是否保留，取决于 Cleaner（清理）策略。

并且你假设：四个版本都保留（即 Cleaner 尚未删除任何文件）

时间点	操作类型	写入数据量（记录数）	生成文件	文件大小	文件用途说明	是否保留（Cleaner 未运行）	可用于哪些时间点查询
t0	Bulk Insert	1,000,000	`B0.parquet`	100 MB	初始 Base File	✅ 是	t1, t2
t1	Delta Commit	100,000	`L1.log`	10 MB	增量日志（更新/插入）	✅ 是	t1, t2
t2	Delta Commit	150,000	`L2.log`	15 MB	增量日志	✅ 是	t2
t3	Compaction	—（合并已有数据）	`B3.parquet`	125 MB	合并 B0+L1+L2 的新 Base File	✅ 是	t3, t4
t4	Delta Commit	80,000	`L4.log`	8 MB	Compaction 后的新增量日志	✅ 是	t4

表格

膨胀率 = (总存储 - 有效数据) / 有效数据 = (258 - 133) / 133 ≈ 0.94

表格

查询时刻	所需文件组合	是否可查	说明
`t1`	B0 + L1	✅ 是	日志 L1 存在
`t2`	B0 + L1 + L2	✅ 是	所有日志存在
`t3`	B3	✅ 是	Compaction 快照
`t4`	B3 + L4	✅ 是	当前最新状态

只要 Cleaner 未删除旧文件，所有历史时刻均可

表格