题干与适用场景
生产 Iceberg 表每天接收增量数据。团队希望开发者先在隔离分支写入并跑质量检查，再原子发布到生产，同时保留审计点并自动清理旧快照。请设计 branch、tag、快照引用、并发提交、保留策略和回滚流程。核心考察表格式元数据与数据发布治理，归为 data。
面试官考察点
- 能否区分 mutable branch 与 immutable tag。
- 能否说明 snapshot reference、main 分支和当前快照的关系。
- 能否设计 WAP 校验、原子发布和并发冲突处理。
- 能否配置 branch/tag 独立保留和快照过期，避免误删可回滚数据。
- 能否证明读者看到的是一致快照，而非半成品文件。
回答前需要澄清的问题
- 使用的 catalog、引擎和版本是否支持 branch、tag 与 WAP？
- 生产读者是否固定读取
main，还是通过视图/引用读取？ - 数据质量检查需要哪些表级、分区级和跨表约束？
- 多个写入分支是否会并行合并，冲突如何解决？
- 审计点要保留多久，旧快照和孤儿文件由谁清理？
30 秒回答框架
“我会让写入任务提交到独立 branch，使用同一表 schema 执行质量检查；通过原子引用更新把经过审核的 snapshot 发布到 main，并创建不可变 tag 作为审计点。branch 和 tag 设置独立保留期限，snapshot expiration 只能删除未被引用且满足保留条件的快照。发布前后比较 snapshot ID、行数、关键指标和读取结果，冲突则重试或人工裁决。”
分步骤深入解答
第一步：建立引用模型
Iceberg 用 snapshot references 记录 branch 和 tag。branch 是可继续提交的可变引用，tag 指向固定快照，适合发布、月结或审计标记。生产 main 应有明确 owner，禁止绕过 catalog 直接改 metadata。
main -> snapshot 120
audit-2026-08-01 (tag) -> snapshot 118
daily-load (branch) -> snapshot 121示意强调引用关系；实际提交由 catalog 的并发检查保护。
第二步：设计 Write-Audit-Publish
写入阶段把新文件和删除文件提交到工作分支，不改变 main。审计阶段在该分支快照上执行 schema、唯一性、范围、行数和跨表检查。发布阶段只有在检查通过后把生产引用推进到目标快照，并记录提交者、版本和检查报告。
第三步：处理并发提交
若两个任务基于同一祖先提交，catalog 的 optimistic concurrency check 应拒绝过期更新。系统不能直接覆盖引用；应重新读取最新 snapshot，重跑冲突检测和必要的数据质量检查。对不同分区的并发写入也要明确是否允许自动合并。
第四步：保证读一致性
查询开始时固定 snapshot ID 或固定引用版本，避免长查询过程中看到不同快照。发布只改变 metadata 引用，数据文件先完成写入并可读。失败任务留下的未引用文件进入 orphan cleanup，但清理不能早于提交和保留窗口。
第五步：设置保留和审计策略
tag 可保留关键发布快照，branch 可设置最大快照数和最大年龄。过期任务应先计算被 main、branch、tag 引用的快照集合，再删除符合策略的历史；不能只按时间删除。审计 tag 的生命周期必须覆盖合规和回滚窗口。
第六步：设计回滚
回滚将 main 指向经过验证的旧 snapshot 或 tag，并记录新的回滚提交。不要删除当前坏快照后再恢复，因为审计和并发冲突会丢失证据。回滚后重新运行下游刷新，确认缓存和物化视图没有继续使用坏版本。
第七步：定义验收指标
记录分支提交延迟、质量检查通过率、发布成功率、冲突重试次数、引用快照数、过期删除量、孤儿文件量和回滚耗时。发布前后比较 snapshot ID、行数、关键聚合和下游读取结果，保证没有半成品可见。
高质量示范回答
“我会让每日任务写入独立 branch，所有质量检查针对该分支的固定 snapshot。通过后原子推进 main，并创建不可变 tag 作为审计点。branch 和 tag 分别设置保留策略，过期任务先排除所有仍被引用的快照，再清理历史和孤儿文件。
并发更新使用 catalog 的乐观并发检查；检测到祖先过期就重新读取最新快照并重跑校验，不能覆盖引用。查询固定 snapshot ID，回滚通过指向旧 tag 产生新的元数据提交。验收比较 snapshot、行数、关键指标、发布成功率、冲突和回滚耗时。”
常见错误
- 把 branch 当不可变发布点 → 后续提交会改变它 → 用 tag 固定审计快照。
- 直接覆盖 main metadata → 绕过并发保护 → 通过 catalog 原子提交。
- 先删旧快照再回滚 → 丢失审计证据 → 保留 tag 并产生新的回滚提交。
- 只按时间过期快照 → 误删仍被引用数据 → 先计算引用集合。
- 查询不固定 snapshot → 长查询看到混合版本 → 固定引用或快照 ID。
- 把孤儿文件立即清理 → 可能删除尚未提交文件 → 等待提交和安全窗口。
追问及应对
追问一：为什么发布要用 tag？
branch 会继续前进，tag 指向固定 snapshot，适合审计、月结和回滚。两者可以同时保留，各自设置生命周期。
追问二：两个分支都写同一分区怎么办？
让 catalog 的冲突检查拒绝过期提交，重新基于最新祖先合并或人工裁决；不能按文件名覆盖。
追问三：snapshot expiration 会不会删掉回滚点？
只要回滚点仍被 tag 或 branch 引用并满足保留策略，就不应删除。过期任务必须把引用纳入保留集合。
追问四：如何防止半成品被读取？
数据文件先写完，生产读者固定读取 main 的原子 snapshot 引用；未发布分支不暴露给生产查询。