3. 写入性能对比
写入性能，说白了就是数据进湖的速度。很多人在选型时只看读得快不快，忽略了写入这个关键环节。我见过不少项目，上线后发现数据延迟越来越高，最后排查下来，是写入引擎扛不住流量了。
这一章，咱们就聚焦三个典型场景：批量写入、微批写入、实时写入。看看 Hudi 和 Delta Lake 在这三种模式下，到底谁更扛造。
核心结论先放这儿：Hudi 在实时写入和增量处理上更激进，Delta Lake 在批量写入和事务一致性上更稳健。选谁，取决于你的写入模式。
3.1 批量写入：谁更“大力出奇迹”？
批量写入，通常是 T+1 的离线任务，一次写几百万甚至上亿条数据。这时候，吞吐量是第一指标。
Delta Lake 的表现：
- 基于 Spark 的批量写入非常成熟。我习惯用
OPTIMIZE和ZORDER来优化布局。 - 写入时，Delta Lake 会先写 Parquet 文件，再提交事务日志。这个过程是原子性的。
- 在纯批量场景下，Delta Lake 的吞吐量很稳定，几乎不会出现抖动。
Hudi 的表现：
- Hudi 的批量写入支持
COPY_ON_WRITE和MERGE_ON_READ两种表类型。 - 在
COPY_ON_WRITE模式下，每次写入都会重写整个文件。数据量越大，写放大越明显。 - 我建议：如果每天批量写入超过 500GB，优先考虑
MERGE_ON_READ，否则小文件问题会让你头疼。
| 对比维度 | Delta Lake | Hudi (COPY_ON_WRITE) | Hudi (MERGE_ON_READ) |
|---|---|---|---|
| 写入吞吐量 | 高，稳定 | 中，有写放大 | 高，但读时合并有开销 |
| 小文件控制 | 需手动 OPTIMIZE |
自动 Clustering | 自动 Clustering |
| 事务开销 | 低 | 中 | 中 |
| 适用场景 | 离线数仓，T+1 | 中等规模批量 | 大吞吐批量 + 近实时 |
我的经验：曾经有一个客户，每天批量写入 2TB 的点击流数据。一开始用 Hudi COPY_ON_WRITE，结果每天跑 6 小时。后来换成 Delta Lake + ZORDER 优化，压缩到 2.5 小时。批量场景下，Delta Lake 的稳定性确实更胜一筹。
3.2 微批写入：谁更“丝滑”？
微批写入，通常是 5-15 分钟一个批次。这种场景下，既要保证吞吐，又要控制延迟。
Delta Lake 的微批写入：
- 配合 Structured Streaming，Delta Lake 的微批写入非常自然。
- 每个批次是一个独立事务，失败后自动重试。
- 但要注意：频繁的小批次会导致大量小文件。我曾经遇到一个场景，每 5 分钟一个批次，一天产生 288 个小文件，查询性能急剧下降。
Hudi 的微批写入：
- Hudi 的
MERGE_ON_READ模式天生适合微批。 - 写入先进入 Avro 格式的 log 文件，后台异步合并成 Parquet。
- 这样，写入延迟很低，读时合并也能接受。
避坑指南：我曾经在微批场景下踩过 Delta Lake 的坑——没有及时做 OPTIMIZE，导致小文件数量超过 10 万，Spark 的 listing 操作直接 OOM。后来我养成了一个习惯：微批写入后，每 10 个批次做一次 OPTIMIZE。
为什么会这样？因为 Delta Lake 的事务日志是 append-only 的，每个批次都会生成新的文件。而 Hudi 的 log 文件可以合并，天然减少了文件数量。
3.3 实时写入：谁更“低延迟”？
实时写入，延迟要求通常在秒级。这时候，写入路径的每一个环节都不能有阻塞。
Hudi 的实时写入：
- Hudi 支持
UPSERT操作，可以做到秒级延迟。 - 它的索引机制（如 Bloom Filter、HBase 索引）能快速定位记录位置。
- 我建议：在实时场景下，使用
MERGE_ON_READ+ 异步 Compaction。写入延迟可以控制在 1-3 秒。
Delta Lake 的实时写入：
- Delta Lake 的
MERGE操作在实时场景下性能一般。 - 因为每次
MERGE都需要读取整个文件，然后重写。 - 如果每秒有上千条
UPSERT，Delta Lake 的延迟会明显上升。
| 场景 | Delta Lake 延迟 | Hudi 延迟 | 推荐方案 |
|---|---|---|---|
| 每秒 100 条 UPSERT | 2-5 秒 | 1-2 秒 | 两者均可 |
| 每秒 1000 条 UPSERT | 5-15 秒 | 2-5 秒 | Hudi |
| 每秒 10000 条 UPSERT | 不可用 | 5-10 秒 | Hudi + 异步 Compaction |
关键点：实时写入的核心瓶颈在于“更新”操作。Hudi 通过索引 + log 文件，把更新变成了 append；而 Delta Lake 的更新是 read-modify-write，天然慢一拍。
3.4 三种写入模式的综合对比
我把三种模式放在一起，画了一张对比图。你一看就明白了。
3.5 我的选型建议
说了这么多，到底怎么选？我总结几条实战经验：
- 纯离线批量（T+1）：无脑选 Delta Lake。稳定、成熟、社区支持好。
- 近实时微批（5-15分钟）：如果团队熟悉 Spark，Delta Lake 也能用；如果追求极致延迟，Hudi 更合适。
- 实时写入（秒级）：Hudi 是唯一选择。Delta Lake 的 MERGE 性能在实时场景下扛不住。
- 混合场景：我建议用 Hudi。因为它支持三种模式共存，一张表可以同时做批量、微批和实时写入。
一个小技巧：如果你决定用 Hudi 做实时写入，记得把 hoodie.compact.inline 设为 false，用异步 Compaction。这样写入延迟不会因为合并操作而抖动。
嗯，写入性能这块，核心就是理解每种引擎的写入路径。Hudi 用 log + 索引换延迟，Delta Lake 用事务 + 文件重写换稳定。没有的好坏，只有适不适合你的场景。