Apache Hudi 通过哪些机制分别支撑近实时查询与批量查询场景？

回答思路

1. 【回答框架 1】Hudi 提供 Copy-on-Write（COW）与 Merge-on-Read（MOR）两种表类型。COW 在写入时合并数据文件与增量日志，生成新版本列文件，查询直接读取最新快照，适合批量查询；MOR 将更新写入增量日志文件，查询时需合并基础文件与日志，牺牲部分查询性能换取更低写入延迟。
2. 【回答框架 2】实时查询依赖 Hudi 的增量视图与读取优化视图。增量视图可消费指定 commit 或 instant 时间之后的变更记录，适合流式处理；读取优化视图直接扫描基础文件，速度快但可能读到稍旧数据。通过配置合理的清理（cleaner）与压缩（compaction）策略，可控制文件版本数量，平衡存储与查询效率。
3. 【回答框架 3】批量查询通常使用快照查询，读取最新一致快照。Hudi 维护表的时间线（timeline），记录每次提交的 instant，查询引擎（如 Spark、Flink、Presto）通过时间线定位文件切片，实现 ACID 语义。COW 表天然适合批量场景，因无日志文件需合并。
4. 【回答框架 4】实际方案中，常将 MOR 表用于高频更新且查询延迟要求不严的场景，配合异步 compaction 将小文件合并为列文件；对延迟敏感的分析查询则选用 COW。查询类型与表类型需共同考虑，通过 metadata table 加速文件列表获取，避免大规模 listing。
5. 【关键点 1】COW 适合批量查询，MOR 适合写入频繁且可容忍查询合并开销的场景
6. 【关键点 2】快照查询、增量查询、读取优化视图对应不同实时性需求
7. 【关键点 3】compaction 与 clean 策略直接影响查询性能与存储占用
8. 【易错点 1】误以为 Hudi 天然实时，实际实时性依赖查询方式与压缩频率
9. 【易错点 2】忽略 MOR 查询合并日志带来的性能下降，未做针对性优化