hudi mor表读优化视图（ro view）依赖compaction生成的新base file，需显式设置query.type为read_optimized且compaction成功后才生效；其查询快而稳定，但会滞后于最新写入。
Hudi 的 MOR（Merge-On-Read）表在读取时默认走实时视图（Real-time View），即对 base file（Parquet）和增量日志（log files）做即时合并，性能受 log 文件数量、大小及合并开销影响较大。要获得稳定低延迟的查询体验，需合理配置读优化（Read Optimized View）并控制 compaction 触发时机。
读优化视图（RO View）如何生效
RO View 本质是只读 Parquet 快照，不包含未 compaction 的 log 数据，因此查询快且稳定。它依赖 compaction 成功生成的新 base file。
- 查询时显式指定 hoodie.datasource.query.type=snaphot（默认）或 read_optimized，才能访问 RO View；实时查询用 realtime
- RO View 并非自动更新：只有 compaction 完成后，新的 base file 才会被后续 RO 查询识别
- 若 compaction 滞后，RO View 会“落后”于最新写入——它反映的是最近一次成功 compaction 后的状态
Compaction 的核心触发条件
Compaction 是将 log 文件合并进 base file 的过程，其触发由以下参数协同控制，而非单一阈值：
- hoodie.compact.inline=true：启用内联 compaction（同步写入时触发），否则需手动或异步调度
- hoodie.compact.inline.max.delta.commits：自上次 compaction 后，累积的 delta commits 达到该值即触发（最常用判断依据）
- hoodie.compact.inline.max.delta.seconds：自上次 compaction 起，超过该秒数且有新 delta commit 也会触发（防长时间无写入导致 stale）
- hoodie.logfile.to.parquet.compression.ratio：log 文件压缩比低于阈值时，可能提前触发（影响存储效率判断）
影响读性能的关键实操建议
单纯调小 max.delta.commits 并不一定提升 RO 查询体验，需结合 workload 权衡：
- 高频小写入（如每分钟多次 commit）：建议设为 5~10，避免 log 文件堆积过多导致 realtime 查询变慢
- 低频大写入（如每小时一批）：可设为 1 或配合 max.delta.seconds=3600，确保每批写完立即 compaction
- 禁止关闭 compaction：若长期不 compaction，log 文件持续增长，realtime 查询延迟飙升，RO View 始终陈旧
- 异步 compaction 更可控：用 Spark/Flink 作业定期调度，避开业务高峰，同时监控 compaction.totalCompleted 和 logFiles.totalSize 指标
验证是否真正受益于 RO View
不能只看 query type 设置，要确认底层读取路径是否真的跳过了 log 文件：
- 查 Spark UI 的 Input Size：RO 查询应只读 Parquet，realtime 查询则含大量 log 文件扫描
- 看 Hudi 表目录：compaction 成功后，对应文件组下 log 文件被归档（.archive）或删除，新增 .parquet 文件
- 执行 DESCRIBE FORMATTED
，检查 hoodie.table.version 和 last_compaction_time 是否更新
