SQL Hudi 的 MOR 表读放大与 compaction 频率调优

hudi mor 表读放大源于实时查询需合并 base file 与多个 log file，compaction 频率过低加剧延迟，过高则浪费资源；应调优 delta_commits、delta_seconds 等参数，并结合 snapshot 查询与分区过滤缓解。

SQL 查询 Hudi MOR 表时出现读放大，本质是查询需合并 base file（Parquet）和多个 log file（Avro），文件越多、版本越旧、log 文件越碎，延迟越高。Compaction 频率直接影响 log 文件数量和查询性能——太低导致读放大严重，太高则浪费计算资源并可能阻塞写入。

理解 MOR 表的读放大来源

MOR（Merge-On-Read）表采用“base + delta”存储结构：新数据先写入 log 文件，定期通过 compaction 合并进 base file。SQL 查询（如 Spark SQL 或 Trino 通过 Hudi Hive Sync 元数据访问）默认走 realtime reader，会动态读取最新 base file 并逐个加载所有未 compact 的 log 文件，执行运行时 merge（即 record-level merge）。这意味着：

• 每多一个 log file，就多一次文件 IO 和解码开销；
• log file 越小、碎片越多（如频繁小批量写入），元数据压力和并发 merge 开销越大；
• 若启用 hoodie.datasource.query.type=realtime 但未配置合理 compaction 策略，查询可能扫描数百个 log 文件，响应从秒级升至分钟级。

关键 compaction 参数与调优建议

compaction 触发逻辑由两个维度协同控制：** 触发时机（scheduling）** 和 ** 执行节奏（execution）**。重点调优以下参数：

• hoodie.compaction.trigger.strategy：推荐设为 num_or_time_based（默认），兼顾 log 文件数与 age；避免仅用 num_commits 导致低吞吐场景下 compaction 滞后。
• hoodie.compaction.delta_commits：每 N 次 commit 触发一次 compaction。写入稳定时可设为 5–10；若单次写入量大（如 >1GB），可适当提高到 15–20，避免 compaction 过载。
• hoodie.compaction.delta_seconds：强制兜底策略，例如设为 3600（1 小时），防止因写入间歇导致 log 积压。
• hoodie.compaction.small_file_limit：小于该值（如 104857600，即 100MB）的 base file 被视为 small file，在 compaction 中优先合并，减少碎片 base file 数量，间接降低后续读需加载的 log 文件范围。
• hoodie.compaction.max.num.delta.files：单次 compaction 最多合并多少个 log file（默认 10）。若观察到单次 compaction 合并不充分，可提升至 20–30，但需确保 executor 内存充足（每个 log file 解码需 ~50–100MB 堆内存）。

配合查询侧的轻量缓解手段

compaction 是治本之策，但在调优收敛前，可通过查询侧降低感知延迟：

• 对非实时性要求高的场景，改用 hoodie.datasource.query.type=snaphot，直接查最新 compact 完成的 base file，完全跳过 log merge —— 但数据有最多一次 compaction 周期的延迟（如 1 小时）；
• 在 Spark SQL 中显式设置 spark.sql.hudi.merge.enable=true（Hudi 0.13+），启用优化后的 merge 执行器，减少 shuffle 和重复解码；
• 限制查询时间范围（加 partition_path >= 'xxx' AND partition_path）或使用 <code>HoodieMetadataTable 加速元数据过滤，避免全表扫描所有分区下的 log 文件。

监控与验证是否生效

调优后必须验证效果，重点关注三个指标：

• 在 Hudi Timeline Server 或 `.hoodie` 目录中检查 commits 与 compactions 数量比，理想值应接近 delta_commits 设定值（如设为 10，则每约 10 个 commit 出现 1 个 compaction commit）；
• 用 hudi-cli 执行 commits show --limit 20 和 compactions show --limit 10，确认 compaction commit 时间点紧随写入高峰之后，无明显滞后；
• 对比调优前后相同 SQL 的 Spark UI 中 task metrics：Input Size / Records Read 应显著下降，Shuffle Read Size 和 GC 时间减少，Stage duration 缩短 30%+ 即为有效。