数据工程面试：如何用 Iceberg Deletion Vector 处理行级删除？
题干与适用场景
事件湖每天追加数十亿行，用户删除请求会持续产生。团队希望采用 Iceberg v3 的 deletion vector，减少频繁重写数据文件。请解释它与 position delete、equality delete 的区别，如何保证快照一致性、跨引擎兼容和最终物理删除。
面试官考察点
- 是否理解删除向量是按数据文件记录行位置的逻辑删除标记，不是立即擦除底层字节。
- 能否区分三种删除表示及其写放大、读取成本和适用边界。
- 能否设计快照原子提交、并发合并、旧 reader 降级和 compaction。
- 能否把合规删除证明与查询正确性、备份保留联系起来。
回答前需要澄清的问题
- 所有 writer、catalog、查询引擎和 SDK 是否支持 Iceberg v3 与 deletion vector？
- 删除依据是稳定行位置、业务键，还是需要跨文件匹配？
- 允许逻辑删除保留多久，备份、对象版本和复制链路何时过期？
- 查询引擎如何加载删除文件，缓存键是否包含 snapshot ID？
- compaction 是否会与流式写入、快照过期和合规删除并发？
30 秒回答框架
我会把 deletion vector 作为快照内的逻辑删除层：每个数据文件最多关联一个向量，记录被删除的行位置；读取时按快照过滤，底层文件仍需在受控 compaction 后重写。position delete 也按位置记录但通常使用独立删除文件，equality delete 按列值匹配、灵活却可能扫描更多数据。先验证所有 reader 的 v3 支持，再用原子快照提交、旧引擎兼容视图和可审计的物理清理窗口完成迁移。
分步骤深入解答
第一步：定义删除语义
deletion vector 是与数据文件关联的位图或等价结构，用行位置标记已删除记录。它让查询在逻辑上看不到行，却不等于对象存储上的字节已经被擦除，因此隐私删除仍需要后续重写、过期和备份治理。
第二步：比较三种删除表示
position delete 以数据文件位置记录删除，适合写入时已知文件和行位置；equality delete 以字段值匹配，适合 CDC 或业务键删除，但读取侧可能需要更广的过滤；deletion vector 把位置标记集中到每个数据文件的向量中，减少大量小删除文件，却把读取过滤和向量维护成本前移。
第三步：建立快照提交边界
删除向量引用必须随 Iceberg 快照原子提交，记录数据文件路径、向量位置、大小、校验和与格式版本。生成任务固定输入快照，不应原地修改已有向量；并发写入失败时重新基于最新快照合并，而不是覆盖别人的删除。
第四步：设计读取路径
规划器先读取 manifest 与快照元数据，再加载适用的删除向量。向量缺失、损坏或 reader 不支持时，安全做法是拒绝该快照或回退到兼容的删除表示，不能把错误当成“没有删除”。缓存键至少包含表、数据文件、snapshot ID 和向量版本。
第五步：规划 compaction 与清理
当向量密度、随机读取开销或删除比例超过阈值时，将剩余行重写成新数据文件，并在新快照中移除旧文件和向量。对象存储生命周期、备份、跨区域复制和快照过期必须共同满足删除 SLA；只删除 catalog 引用不能证明物理清理完成。
第六步：迁移旧 reader
盘点每个引擎的 format-version、delete-file 支持和缓存行为。旧 reader 可暂时读取由 position/equality delete 表示的兼容快照，或通过物化视图隔离；发布前禁止让不理解向量的 reader 直接读取含有该特性的快照。
第七步：验证正确性与合规
构造并发删除、重复删除、删除后更新、快照回滚、向量损坏和 compaction 中断场景。对每个 snapshot 比较启用和禁用优化时的结果哈希，抽样检查删除请求对应的行不可见，并记录物理文件、备份和复制的最后保留时间。
高质量示范回答
我先确认所有 reader 能解析 Iceberg v3 与 deletion vector。删除事务固定一个基线 snapshot，生成每个数据文件的行位置向量，并把引用和新快照原子提交；并发冲突就重读最新快照后合并。查询按 snapshot ID 加载向量，缺失或不支持时停止发布或回退到兼容 delete 文件，绝不把错误当作空向量。向量密度达到阈值后 compaction 重写剩余行，旧文件、快照、备份和复制按同一删除 SLA 过期。验收覆盖并发删除、损坏向量、回滚和中断恢复，比较结果哈希并出具物理清理证据。
常见错误
- 把 deletion vector 当成对象存储上的立即擦除。
- 忽略一个数据文件只能安全关联受约束的向量版本，直接原地覆盖。
- 让不支持 v3 的 reader 读取含向量的快照并期待自动忽略。
- 删除 catalog 指针后就宣称合规删除完成。
- compaction 不检查并发快照，导致新写入或别人的删除丢失。
追问及应对
追问一：为什么不总是用 equality delete？
它适合按业务键表达删除，但读取时可能需要跨多个文件匹配。已知物理位置且删除频繁时，位置向量可减少删除文件数量；最终选择要以 reader 支持和查询代价实测为准。
追问二：向量损坏时能返回未过滤数据吗？
不能。返回未过滤数据会重新暴露已删除行。应校验校验和与版本，拒绝快照或回退到可信的删除表示，并告警修复。
追问三：删除向量如何与更新配合？
更新通常产生新数据文件并标记旧行删除。事务必须在同一快照中提交新文件和删除引用，读取器按快照只看新行，避免旧行和新行同时可见。
追问四：如何定义 compaction 阈值？
用删除比例、向量大小、随机读取放大、扫描延迟和存储成本建立阈值，在代表性查询与写入负载上压测；不应只按文件数量拍脑袋。
追问五：怎样证明隐私删除完成？
输出行级不可见证明、引用快照过期记录、重写后的文件清单、对象版本删除结果、备份与复制保留时间，以及抽样扫描无命中证据。