【Hudi】 Hudi 是什么,解决什么问题

Parquet、HDFS / 对象存储上的文件,写完就不能改。但业务总是要改 — 用户改了收货地址、订单从"待支付"变成"已发货"、某笔交易被风控标黑。

这些"改一行"的事情落到 Parquet 层,就变成了"重写整个文件"。

传统做法:Hive/Spark OVERWRITE

最直接的思路是 INSERT OVERWRITE 或 df.write.mode("overwrite"):

1. 读出全表数据
2. 应用更新
3. 把改完的全量写到新路径
4. 原子替换旧文件

简单清晰,但代价不小:

• 写放大:改一行也要扫全表、读全表、写全表。一张 10GB 的订单表重写一遍要几分钟,一天改几万行根本顶不住。
• 并发不安全:两个作业同时跑,后写的覆盖先写的,中间状态对外不可见。
• 历史快照难留:想看"昨天 12 点的数据"基本要从要从外部备份系统捞。

Hudi 的解法

Hudi 没去"改"文件,而是在不可变文件之上做了一层版本管理。可以拆成三块:

• 存储主要用 Parquet 和 Avro。Parquet 列式、读快;Avro 行式、适合追加。
• 数据按 recordKey 分桶到文件组。改一行只动它所在的桶,不会扫全表。
• 每次写入是 Timeline 上的一个 commit。查最新就看最后一个 commit 的结果;查历史就往 Timeline 前面翻 — 这就是 time travel。

一句话:Hudi = 在不可变的 Parquet/Avro 文件之上,做了一套文件版本管理。

它不是什么

为了避免误解,顺带讲一下边界:

• 它不是数据库。没有事务、没有二级索引、做不到毫秒级随机写。
• 它不是查询引擎。读还是要靠 Spark / Flink / Hive / Trino。
• 它不是新的存储格式。它站在 Parquet / Avro 之上,做的是"如何组织这些文件"这件事。