题干与适用场景
一张 Apache Iceberg 表承载用户资料，既要支持 GDPR 删除，也要接收高频更正。团队准备从 v2 升级到 v3，并考虑使用 deletion vector。请说明三种行级删除格式的差异、何时选择它们，以及如何保证旧读者、并发写入、回滚和 compaction 都安全。
这道题考察数据湖表格式的读写协议，而不是记忆一个开关。Iceberg 规范把 deletion vector（DV）定义为针对单个数据文件、按行位置编码的位图；它与 equality delete 和 position delete 的作用范围、元数据及维护责任不同。
面试官考察点
- 能否区分按列值删除、按文件位置删除和位图删除。
- 是否知道 DV 是 Iceberg v3 能力，v2 不支持新增 DV。
- 是否能解释快照读取时的文件路径、分区和 sequence number 条件。
- 是否考虑一个数据文件最多一个 DV，以及与旧 position delete 的合并规则。
- 是否能把格式选择连接到读放大、写放大、删除比例、兼容性和维护窗口。
- 是否会设计可观测性、回滚演练和旧读者降级方案。
回答前需要澄清的问题
先确认：
- 当前表是 Iceberg v2 还是 v3，读写引擎和版本分别是什么？
- 删除请求按主键值到达，还是已经知道数据文件与行位置？
- 删除比例、更新频率、查询延迟和 compaction 预算是多少？
- 是否仍有只读 v2 引擎，是否要求时间旅行和快照回滚？
- 是否需要把删除事件下游化为 CDC，还是只保证当前查询不可见？
如果条件不明，可假设主要读者支持 v3、仍有少量 v2 读者，并且删除必须在提交成功的快照中可见。
30 秒回答框架
我会先按语义选择：按列值匹配用 equality delete，已知文件和行位置且需要兼容 v2 时用 position delete；v3 场景下，对单个数据文件的高频位置删除可合并为一个 deletion vector。读取时必须同时检查引用数据文件、分区和 sequence number，不能只看位图。
写入端要保证一个数据文件在一个快照中最多一个 DV，并把既有 position delete 合并进去；提交使用 Iceberg 的快照并发校验。v2 读者不能理解 DV，因此升级前要完成能力矩阵、双读验证和回滚方案。最后用删除可见性、旧快照、并发冲突、compaction 和性能指标验收。
分步骤深入解答
1. 先定义三种格式的语义
equality delete 用一个或多个列值匹配任意数据文件中的行，例如 id = 5。position delete 用数据文件路径与从零开始的行位置标记删除。deletion vector 则为一个被引用的数据文件保存位置位图，置位表示对应行已删除。
三者不是简单的压缩等级。equality delete 适合主键事件但扫描时匹配成本更高；position delete 精确且可兼容 v2，但文件数量容易增长；DV 把同一数据文件的许多位置删除合并成一个可定位的二进制对象。
2. 处理版本与读者能力
Iceberg 规范把行级删除放在 v2 之后，deletion vector 是 v3 新增能力。v3 表不能新增 position delete，但从 v2 升级而来的旧 position delete 仍然有效，并应在创建 DV 时被合并。
因此不能只升级 catalog。要盘点每个读引擎是否能读取 v3 元数据、Puffin 中的 deletion-vector-v1 blob 和删除 manifest。未支持的读者应继续消费兼容快照，或在切换前完成迁移；不能把 DV 写入后再期待旧引擎静默忽略。
3. 遵守快照读取范围
读取器把 DV 应用于数据文件，需要同时满足：数据文件路径等于 referenceddatafile、数据文件 sequence number 不大于 DV 的 sequence number、分区规范和值相等。只按路径匹配会把删除错误应用到重写后的文件，忽略 sequence number 会破坏时间顺序。
删除 manifest 还要记录 DV 所在文件、blob 的 offset 和 length。读取器必须从正确的快照元数据定位 blob，而不能把对象存储目录中的同名文件当作事实来源。
4. 设计写入合并与并发提交
同一快照中一个数据文件最多允许一个 DV。写入者在追加删除时要读取当前删除状态，把新位置与旧 DV、旧 position delete 合并，再写出新的 DV。若移除数据文件，也要从 delete manifest 移除适用的 DV。
提交仍然通过 Iceberg 快照和 optimistic concurrency 完成。冲突重试时必须重新读取最新 metadata 和 delete manifests，不能复用第一次尝试生成的位图。重试次数、冲突原因和最终提交 snapshot id 都应记录。
5. 选择写放大与读放大的平衡
删除很少且分散时，equality delete 能避免定位原始文件，但扫描器需要应用谓词。删除集中在少量文件且频繁发生时，DV 通常能减少 position delete 文件管理与读取合并成本。大面积删除或文件已经需要重写时，直接重写数据文件并清理删除文件可能更划算。
不要用“DV 一定更快”作为结论。需要用查询扫描字节、删除文件数量、位图大小、manifest 读取时间、compaction CPU 和端到端延迟比较不同删除密度。
6. 规划维护、回滚和合规证明
维护任务应在安全窗口合并旧 delete files、重写高删除比例的数据文件并清理无引用 blob。清理必须尊重时间旅行保留策略，否则历史快照会失去可读性。GDPR 场景还要证明当前有效快照和下游副本都不再返回目标行。
回滚演练要覆盖：写入提交后回滚、DV 所在 Puffin 文件仍在、旧 position delete 是否仍能应用、以及新快照是否继续满足删除要求。删除审计应保存请求 id、匹配范围、提交 snapshot id 和验证结果，但不能把个人数据写入日志。
7. 建立兼容性与可观测性门禁
发布前建立读写引擎矩阵：v2 读者、v3 读者、批处理、流式读取和维护工具分别验证 equality、position、DV。指标至少包括 DV 应用失败、未匹配数据文件、delete manifest 膨胀、冲突重试、旧快照读取失败和 compaction 积压。
在灰度期间让同一快照由新旧读引擎做结果对比，检查行数、主键集合和抽样内容。发现旧读者无法解释 v3 删除时，应停止 DV 写入或切换到兼容格式，而不是继续扩大影响面。
高质量示范回答
我会先看删除事件的语义和引擎矩阵。按主键值删除用 equality delete；已经知道数据文件和行位置、且仍需 v2 兼容时可用 position delete；如果表已升级到 v3，并且删除集中在单个数据文件，我会把位置集合合并为 deletion vector。DV 是单文件位图，一个快照中同一数据文件最多一个，创建新 DV 时要合并已有 position delete。
读取时不能只依据文件路径。必须校验 referenceddatafile、分区规范和值，以及数据文件 sequence number 不大于 DV 的 sequence number；DV 的 blob offset 和 length 也必须来自 delete manifest。写入采用快照乐观并发，冲突重试要重新读取最新 metadata，不能复用旧位图。
迁移前我会验证所有读者是否支持 v3、Puffin 和 DV，并保留停止写 DV 的开关。验收包括当前快照删除可见、旧快照时间旅行、并发删除、回滚、compaction、旧引擎结果对比和合规证明。性能上比较扫描字节、manifest 时间、DV 大小、compaction CPU 与端到端延迟；当删除比例很高时，重写数据文件可能比继续累积 DV 更合适。
常见错误
- 把 DV 当成 equality delete 的压缩版，忽略匹配语义。
- 误称 Iceberg v2 可以写入 deletion vector。
- 只按文件路径应用 DV，不校验分区与 sequence number。
- 为同一数据文件保留多个 DV，或没有合并旧 position delete。
- 升级 catalog 后没有验证所有读引擎和维护工具。
- 用一次 compaction 解决所有删除密度，没有比较读放大与写放大。
- 清理 delete manifest 时破坏时间旅行保留的历史快照。
- 把日志中的个人资料当作删除审计证据。
追问及应对
追问一：为什么不能让 v2 读者直接忽略 DV？
因为忽略删除元数据会把已删除行重新返回，形成静默的数据正确性事故。应先完成引擎能力矩阵和结果对比，再决定迁移、兼容写入或停止 DV。
追问二：如果同一数据文件的删除持续增加，何时重写文件？
按删除密度、位图大小、扫描 CPU、查询延迟和 compaction 预算设门槛。超过门槛后重写数据文件并在新快照中移除适用 DV，随后验证旧快照保留策略。
追问三：并发提交冲突重试时最容易漏什么？
漏读最新 delete manifests 和 data sequence number。每次重试都要基于最新表 metadata 重新合并删除集合，并记录冲突与最终 snapshot id。
追问四：如何证明删除满足合规要求？
保存请求范围、提交 snapshot id、当前快照查询结果、下游副本核验和清理任务状态；同时明确时间旅行保留期限，避免把含个人数据的日志作为证明。
追问五：什么时候 equality delete 反而更合适？
当事件只携带业务键、数据文件不断重写、或需要跨多个文件表达同一删除谓词时，equality delete 更直接。仍应测量读取匹配成本并设置后续重写策略。