考察点
这题考快照机制的两个应用面：往前看（时间旅行）和往后追（增量读取）。面试官想确认你理解「快照=不可变的文件清单」这个根基，然后能讲出实际用途——数据回滚、审计、复现、增量同步。追问会往快照过期策略和增量拉取的边界条件上走。
参考答案
时间旅行的根基：快照不可变
湖表格式的每次提交产生一个新 snapshot，snapshot 本质是「此刻这张表由哪些数据文件组成」的清单。文件本身不可变，新写入只是追加文件加一个新清单，旧清单指向的文件原封不动。所以查历史数据不需要备份恢复，只要让查询基于旧快照做 planning 就行。
怎么用
Iceberg 支持两种定位方式：
-- 按时间戳
SELECT * FROM db.table FOR SYSTEM_TIME AS OF '2026-07-01 10:00:00';
-- 按快照 ID（先从 metadata_log 或 snapshots 表查出来）
SELECT * FROM db.table FOR SYSTEM_VERSION AS OF 8745392012345678;
Spark 里还可以 spark.read.option("as-of-timestamp", ...)。Hudi 对应的是 Time Travel 查询，Delta Lake 是 TIMESTAMP AS OF / VERSION AS OF，语法不同原理一致。
真实用途，不止于炫技
- 数据回滚：ETL 写错了一批数据，不用停表重跑，
rollback（Iceberg 有 rollback_to_snapshot，Delta 有 RESTORE）直接把元数据指针拨回好快照，秒级完成。这是比「恢复备份」高一个量级的运维体验。 - 问题排查与审计：昨天的报表数字不对，直接查昨天的快照和今天对比，定位是哪批写入引入的。
- 实验复现：算法团队要复现某个模型训练时的数据分布，锁定当时的快照读，保证数据可复现。
快照不是免费的：保留策略
快照和旧文件会一直占存储，必须定期过期。Iceberg 用 expire_snapshots 保留最近 N 天或 N 个快照；Delta 的 VACUUM 默认保留 7 天，低于这个值要显式确认（防止有长查询还在读旧文件）。工程上有个关键约束：快照保留时长必须大于集群里最长查询的执行时间，否则查询读到一半文件被清了，直接报错。流式写入频繁的表（比如 Flink 分钟级提交）一天能攒上千个快照，过期任务要跟上。
增量读取：快照机制的另一半
既然每个快照记录了「相对上个快照新增/删除了哪些文件」，那「给我上次同步之后的变化」就是顺手可得的能力。Iceberg 的 incremental read（Spark 里 streaming 或指定 from/to snapshot）、Hudi 的增量查询（begin instant time 之后的 commit）都是这个思路。典型场景：
- 下游增量同步：数仓 ODS→DWD 不用全量比对了，按快照区间拉增量，省掉昂贵的 diff 计算。
- 替代 Kafka 做近实时管道：对秒级延迟不敏感的场景，直接让下游轮询湖表的增量，架构上省掉一套消息队列的维护。Hudi 社区甚至把这个当主打场景。
要注意增量读取拿到的是「文件级变化」，想要行级的 before/after（真正的 CDC），得看引擎和格式的具体支持，比如 Hudi 的 CDC 模式或配合 Debezium 入湖，不要混为一谈。
可能的追问
- 时间旅行查询性能会不会差？ 答 planning 成本差不多（快照清单就在那里），但如果旧快照引用的文件已按旧布局组织（比如后来做过 compaction/Z-Order），读旧快照享受不到新优化，可能慢一些。
- rollback 之后写错的数据文件怎么办？ 答变成孤儿文件，由 expire_snapshots + delete_orphan_files 清理；rollback 本身只动元数据指针，不删文件。
- 增量读取漏数/重复怎么处理？ 答消费端记录上次消费到的 snapshot ID 或 commit time 做 checkpoint，失败从 checkpoint 重拉，幂等消费（按主键 merge）兜底。