考察点
这道题分两问，考的是湖表格式的核心机制。ACID 部分面试官想听快照隔离、原子提交、乐观并发控制这套链路，而不是背教科书定义；schema 演进部分想看你是否真的在生产里加过列、改过类型，知不知道哪些变更安全、哪些要重写数据。追问常落在「并发写冲突怎么办」「改列类型为什么会失败」。
参考答案
湖上为什么需要重新发明 ACID
传统 Hive 表没有事务：一个任务写一半失败，目录里就留下半批脏文件；两个任务同时写一张表，结果不可预知。湖表格式要解决的第一个问题就是让「文件集合的变更」变成一个原子操作。
ACID 的实现机制
原子性（A）：写入分两步。先写数据文件（这些文件此刻对读者不可见），然后做一次原子提交——Iceberg 是向 catalog 做一次 atomic swap 更新当前元数据指针，Delta Lake 是往 _delta_log 追加一个原子可见的新日志文件，Hudi 是在 timeline 上把 inflight 请求标成 committed。提交成功才算写入生效，失败的任务留下的孤儿文件由后台清理（clean）回收。
隔离性（I）：快照隔离。读者总是基于某个确定的 snapshot 读，写入产生的新快照不影响正在进行的读。这天然解决了读写互斥问题，也是时间旅行的基础。
一致性/持久性（C/D）：schema 校验和约束在提交时检查；提交后的元数据和数据都落在持久存储上。
并发控制：乐观锁。两个写任务都基于 snapshot N 起笔，提交时只有先到的成功，后到的检测到 snapshot 已经变成 N+1，校验冲突类型（比如 Iceberg 会检查是否动了同一批文件），能重试就重放重试，不行就失败。这比悲观锁吞吐高，代价是冲突多的时候重试开销大——所以湖格式不适合行级高并发 OLTP，定位就是分析场景的批量写。
Schema 演进：哪些能改，哪些不能
以 Iceberg 为例，规则很清晰：
- 加列：安全，元数据变更，老数据新列读出来是 null。
- 删列：安全，但注意 Iceberg 里列是靠 column ID 而不是列名标识的，删了再加同名列会拿到新 ID，不会串数据——这一点比 Hive 表按位置/名字匹配要安全得多，是个很好的加分点。
- 改列名：安全，同样是 ID 机制的红利，rename 是纯元数据操作。
- 宽化类型：int→long、float→double、decimal 提精度，安全，读时自动升级。
- 窄化或换类型：long→int、string→int，不允许，要改就得重写整表数据。
- 改分区：Iceberg 的隐藏分区支持分区演进（比如按天分区改成按小时），新数据用新分区方案，老数据不动，查询时两套方案都参与裁剪。这是 Iceberg 相对 Hive 分区的杀手锏。
工程实践里的坑
一是嵌套列。Struct 里加字段通常没问题，但改嵌套类型很容易踩引擎兼容性的坑，不同引擎对 complex type 演进的支持参差不齐。二是下游联动。加列之前先想清楚下游的 Spark/Flink 任务、BI 报表是不是 select *，自动感知新列未必是你想要的行为。三是元数据膨胀。频繁的 schema 变更叠加高频提交会让元数据文件越积越多，要配 expire_snapshots 定期清理。面试时把这些坑讲出来，比背规则更能证明你干过。
可能的追问
- 乐观并发冲突多了怎么办？ 答降低写入并发度、把多流合并成单流写同一张表、增大提交间隔（Flink checkpoint 拉长），或者按写入方拆表再视图合并。
- Iceberg 的 column ID 机制具体怎么工作？ 答每个字段在 schema 里有唯一递增 ID，读写路径都按 ID 映射到数据文件的列，列名只是显示层，所以 rename、删了重加都不会串数据。
- 快照一直不清理会怎样？ 答元数据文件和孤儿数据文件膨胀，planning 变慢、存储成本上涨；要用 expire_snapshots 和 delete_orphan_files 定期治理，注意保留时长要大于最长查询耗时。