考察点
这道题考的是你对湖表格式的设计理解，不是罗列特性。面试官想听你说清三者元数据架构的本质差别（Iceberg 的快照树、Hudi 的 timeline、Delta 的事务日志），以及由此带来的读写路径、并发控制、生态绑定的不同。追问基本会落到「你们为什么选 X」「更新场景多为什么用 Hudi」这类实际选型。
参考答案
先讲它们共同解决什么问题
在表格式出现之前，湖上就是一堆裸 Parquet 文件加 Hive Metastore 的目录元数据，没有事务、没法删改、小文件失控。三大格式本质上都在做同一件事：在文件之上加一层元数据管理，让对象存储上的文件集合表现得像一张数据库表——支持 ACID、upsert、schema 演进、时间旅行。差别在于这层元数据怎么组织。
元数据架构是理解三者的钥匙
Iceberg 用一棵「快照树」：表状态是 snapshot 链表，每个 snapshot 指向一组 manifest list，再下钻到 manifest，最后才是数据文件。查询引擎做 planning 时可以逐层裁剪，不需要列目录（list 目录在对象存储上又慢又贵），所以 Iceberg 的查询规划和文件裁剪效率是三者里最好的，大表优势明显。
Hudi 用 timeline 记录每次 commit、compaction、cleaning 操作，表按 file group 组织，每个 file group 内有 base file 和 log file。这套设计是为 upsert 量身定做的，记录级更新是它的主场。
Delta Lake 最朴素：_delta_log 目录下一串 JSON 事务日志（000001.json、000002.json……）记录所有文件增删，定期 checkpoint 成 Parquet 加速读取。简单直接，但超大表时日志文件会膨胀。
更新模型：Hudi 的差异化主场
Hudi 的 COW（Copy on Write，写时复制，读快写慢）和 MOR（Merge on Read，读时合并，写快读慢）两种表类型是经典考点。CDC 入湖、订单状态频繁变更这类高更新场景，Hudi MOR 配合 compaction 是公认的好选择。Iceberg 早期更新偏弱，靠 equality/position delete 补齐，现在删除文件（delete file）机制成熟后更新能力已经不差，但设计基因还是分析优先。
生态绑定与中立性
- Iceberg：格式规范完全开放，Flink、Spark、Trino、StarRocks 都原生支持，社区中立性最好，国内大厂新上湖仓基本默认它。
- Hudi：更新能力最强，但引擎支持相对集中在 Spark/Flink。
- Delta Lake：和 Databricks 深度绑定，开源版和商业版能力有差距，不在 Databricks 生态里的话吸引力打折。
选型结论
高频更新/CDC 场景选 Hudi（MOR）；通用湖仓、多引擎共存选 Iceberg；已经在 Databricks 上的选 Delta。面试里如果能补一句「三者其实在互相借鉴，能力差距在缩小，选型更多是看团队现有栈和云厂商绑定」，说明你看的是趋势不是静态对比表。
可能的追问
- Iceberg 怎么做小文件合并？ 答 rewrite_data_files（bin-pack 或 sort 策略）离线合并，配合 Flink 写入端的 checkpoint 提交频率控制；也可以讲用 Spark 周期性跑 OPTIMIZE。
- Hudi MOR 的 compaction 什么时候触发？ 答默认按 delta commit 次数（ hoodie.compact.inline.max.delta.commits，默认 5 次）触发，生产上常关掉 inline 改异步调度，避免影响写入延迟。
- 三者的事务怎么保证？ 答都是乐观并发控制：写时基于某个快照，提交时校验冲突（Iceberg 用 catalog 的 atomic swap，Hudi 用锁服务，Delta 用日志原子 rename），冲突则重试。