数据工程面试：如何用 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 阈值？

用删除比例、向量大小、随机读取放大、扫描延迟和存储成本建立阈值，在代表性查询与写入负载上压测；不应只按文件数量拍脑袋。