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%+ 即为有效。
