题干与适用场景
一张 Iceberg 表按日期和租户组织，查询经常按低基数状态列过滤，但每次规划仍需检查大量数据文件。团队希望把不能直接放进 manifest 的索引或统计放入 Puffin 文件，再由规划器选择性使用。请说明如何绑定快照、避免陈旧统计误导裁剪、处理统计缺失和并发提交，并证明收益不牺牲结果正确性。
容量、过滤选择性和文件数量是面试设定，不是通用基准。题目适合数据工程、湖仓存储、查询引擎和数据平台岗位。核心能力是表格式元数据与查询规划，因此归为 data。
面试官考察点
第一，能否理解 Puffin 的边界。Puffin 是存放 Iceberg 表索引和统计的文件格式，blob 元数据描述内容；它不能替代表快照或 manifest。
第二，能否区分“可选优化”和“正确性元数据”。统计信息可以被 reader 忽略，忽略时仍必须正确读取；裁剪逻辑只能安全减少确定不匹配的候选。
第三，能否绑定快照与分区。统计必须标识适用的 snapshot、分区或数据文件范围；表更新后不能盲用旧 blob。
第四，能否处理成本和维护。额外文件需要对象存储 I/O、缓存、生成作业和过期策略；低选择性查询可能只增加规划成本。
第五，能否设计灰度和回退。读取失败、blob 缺失、版本不兼容或校验失败时，规划器应退回 manifest 和数据文件扫描，而不是返回空结果。
回答前需要澄清的问题
- 使用的 Iceberg 版本和查询引擎是否支持目标 Puffin blob 类型？
- 统计按分区、数据文件、列还是值域生成？
- 表是否有频繁快照提交、回写和时间旅行需求？
- 统计生成延迟允许多久，能否接受最终一致的优化收益？
- blob 的压缩、校验、加密和对象存储权限如何管理？
- 查询规划器如何证明候选被安全排除？
30 秒回答框架
“我先确认 reader 支持的 Puffin blob 类型和 Iceberg snapshot 关联方式。统计文件只提供可选优化，不能成为正确性前提；每个 blob 要记录适用快照、分区或数据文件范围，规划器遇到缺失、陈旧或解析失败就回退 manifest。生成作业以快照为输入并原子提交引用，避免在新快照上复用旧统计。灰度比较候选文件数、规划时间、额外 Puffin I/O、端到端延迟和结果校验，只有收益稳定且失效时不影响正确性才扩大范围。”
分步骤深入解答
第一步：确认 Puffin 与表快照的关系
Puffin 设计用于保存不能直接放进 Iceberg manifest 的索引和统计。StatisticsFile API 提供路径、文件大小、footer 大小、blob 元数据和关联 snapshot ID。先把这些字段纳入元数据契约，不能只把对象路径写入外部配置。
第二步：定义 blob 内容和范围
每个 blob 应说明类型、版本、编码、覆盖的分区或数据文件、生成 snapshot，以及统计的列和比较规则。低基数状态列可以用分区级计数或值域摘要；高基数列若无法安全判断，宁可只用于观测，不参与排除。
statistics = build_from_snapshot(snapshot_id, data_files)
blob = {
type, version, snapshot_id, partition_scope,
covered_files, column_rules, checksum, payload
}
commit_statistics_file(blob)第三步：设计安全裁剪
规划器只有在统计明确证明文件不可能匹配时才排除候选。统计缺失、列值域重叠、null 语义不确定、blob 版本未知或校验失败，都回退到 manifest 与数据文件级过滤。优化路径不能把“没有统计”解释为“没有数据”。
第四步：处理快照并发与陈旧性
生成作业从固定 snapshot 读取输入，提交时检查表仍允许引用该 snapshot 或其兼容后代。新写入、删除和分区演进可能改变文件集合；旧 blob 只能用于它声明覆盖的范围。不能在对象存储中原地改写 Puffin 文件来“更新”统计。
第五步：规划读取与缓存
Puffin 文件本身也有 footer 和 blob I/O。规划器应先用轻量目录信息判断是否值得读取，再按查询列和分区选择 blob。缓存键包含表标识、snapshot、blob 类型和版本；读取异常时让缓存失效并回退，不把异常结果缓存为“空统计”。
第六步：成本、过期与权限
记录 blob 字节、footer 比例、生成 CPU、对象存储请求和规划命中率。快照过期或文件重写后，统计文件要按引用关系清理；不能只按文件修改时间删除。生成和读取身份分别授予最小对象存储权限，校验 checksum，必要时加密敏感统计。
第七步：灰度验收
对同一 snapshot 使用统计开启和关闭两条规划路径，比较候选文件集合、扫描字节、规划 p50/p95、额外 Puffin I/O、端到端延迟和结果哈希。故意删除 blob、制造版本不匹配和并发提交，验证回退仍返回完整结果。保留低选择性查询作为负对照。
高质量示范回答
“我会把 Puffin 当作可选的规划加速层。生成作业从固定 snapshot 读取数据文件，blob 元数据记录 snapshot、分区或文件范围、列规则、版本和校验值；新快照提交不能复用超出声明范围的旧 blob。
规划器先判断 blob 是否适用，只有统计能安全证明不匹配时才排除文件。缺失、陈旧、解析失败、null 语义不清或版本未知都回退 manifest 和数据文件过滤，不能把缺统计当成空结果。缓存键包含表、snapshot、类型和版本。
灰度时比较候选文件数、规划时间、Puffin I/O、端到端 p95 和结果哈希，并故意注入缺失 blob 与并发提交。只有收益稳定、回退正确且维护成本可接受，才扩大统计生成范围。”
常见错误
- 把 Puffin 当快照真源 → 统计失效会改变结果 → 只做可选优化并保留 manifest 回退。
- 只记录对象路径 → 无法判断适用 snapshot 与范围 → 写入完整 blob 元数据。
- 陈旧 blob 继续裁剪 → 新写入或删除可能被漏掉 → 绑定 snapshot 和覆盖文件。
- 缺失统计返回空结果 → 把未知误判为无匹配 → 回退正常过滤。
- 原地覆盖 Puffin 文件 → 并发 reader 看到混合版本 → 生成新文件并原子引用。
- 缓存不带 snapshot → 不同快照复用错误统计 → 缓存键纳入版本与快照。
- 只测规划时间 → 扫描结果可能改变 → 比较候选集合与结果哈希。
- 按修改时间直接删文件 → 仍被快照或分支引用 → 按引用关系过期清理。
追问及应对
追问一：为什么统计信息可以被 reader 忽略？
Puffin 统计是 informational。表仍可依赖 manifest 和数据文件完成正确读取，因此 reader 不支持或暂时无法读取时应透明回退。
追问二：如何处理快照过期？
先确认没有保留快照、分支或标签需要 blob 覆盖的数据范围，再按表格式引用关系清理。不能只依据对象最后修改时间。
追问三：统计值域不完整怎么办？
把未知部分视为可能匹配，扩大候选集合或完全回退。优化必须容忍假阳性，不能产生假阴性。
追问四：并发写入时何时生成统计？
以已提交 snapshot 为输入，在元数据提交成功后生成或绑定；写入期间的临时文件不应被规划器使用。提交时重新检查 snapshot 兼容性。
追问五：什么时候不值得使用 Puffin？
查询选择性低、blob 大于节省的 manifest I/O、生成延迟过高或维护成本超过收益时，应关闭或缩小范围，并保留按表配置开关。
追问六：如何证明优化没有改变结果？
在同一 snapshot 上运行开启和关闭统计的等价查询，比较完整结果、聚合、候选文件集合和边界样本；再注入缺失、损坏与版本不兼容 blob 验证回退。