请解释 Hudi 中 Merge on Read 模式处理增量更新的具体流程是怎样的？

回答思路

1. 【回答框架 1】Merge on Read 是 Hudi 为平衡写入延迟与查询效率设计的表服务，核心思想是将更新先写入基于列存的 Parquet 基础文件，再将增量记录追加到基于行存的 Avro 日志文件中，查询时需合并基础文件与日志文件。
2. 【回答框架 2】处理增量更新时，写入端会对每条记录计算记录键，根据索引定位其所属文件组；若记录已存在，则将该变更追加到对应文件组的日志文件，而非重写整个基础文件，从而降低单次写入的 I/O 开销。
3. 【回答框架 3】读取时，Merge on Read 支持两种查询模式：读优化查询仅扫描基础文件，返回未合并的近似结果，适合对实时性要求不高的场景；快照查询则需合并基础文件与日志文件，通过记录键进行去重与覆盖，以返回最新状态，但查询延迟会因日志合并而增加。
4. 【回答框架 4】为控制日志文件无限增长，Hudi 提供压缩机制，异步或同步地将日志文件与基础文件合并，生成新的基础文件并清理旧日志，从而在写入性能与查询性能之间取得动态平衡。压缩的触发频率和策略可根据表负载配置。
5. 【回答框架 5】Hudi 的索引机制（如布隆过滤或 HBase 索引）用于快速定位记录所属文件组，减少写入时全表扫描的开销；若索引未能命中，则可能走全表扫描或写入新文件组，因此索引选择直接影响更新性能。
6. 【关键点 1】更新先写行存日志文件，不直接重写列存基础文件
7. 【关键点 2】查询时需合并基础文件与日志文件，快照查询返回最新数据
8. 【关键点 3】压缩机制定期合并日志与基础文件，平衡读写性能
9. 【易错点 1】不能认为 Merge on Read 写入总是比 Copy on Write 快，因日志文件膨胀和压缩开销可能抵消写入优势
10. 【易错点 2】快照查询在日志文件多时延迟明显，必须合理配置压缩策略
11. 【易错点 3】索引未命中时更新会退化为全表扫描或写入新文件组，应评估索引选择与维护成本