数据工程面试：Iceberg v3 的 row lineage 如何保证稳定行标识？
题干与适用场景
一张 Iceberg v3 事件表需要支持 CDC、重算和跨快照审计。团队希望每行有可追踪的稳定标识，并能知道最后一次更新属于哪个提交。请解释 row lineage 的字段、继承时机、快照提交重试、equality delete 的限制和验证方案。
面试官考察点
- 是否理解
rowid与lastupdatedsequencenumber的继承，而非写入时臆造。 - 是否知道
first-row-id、next-row-id和 manifest 之间的关系。 - 是否能处理 optimistic commit 重试、并发写入和旧读者兼容。
- 是否区分 row lineage、业务主键、equality delete 与物理文件清理。
回答前需要澄清的问题
- 需要追踪的是物理行身份、业务实体身份，还是两者都要？
- 读取器是否全部支持 Iceberg v3，旧引擎如何降级？
- 更新采用 copy-on-write、merge-on-read 还是 equality delete？
- 审计要求跨快照重放，还是只需当前表的最新版本？
30 秒回答框架
Iceberg v3 的 row lineage 用 rowid 标识表内行，用 lastupdatedsequencenumber 表示最后更新提交；值在读取时通过 data file 的 first-row-id、行位置和 manifest sequence number 继承。写入阶段先生成带 null 的文件，提交成功后由元数据确定继承值，因此提交重试必须重新分配 first-row-id。它不等于业务主键，也不能让 equality delete 保留原行 ID。先建立 v2/v3 读取能力矩阵，再用快照、并发冲突和重试测试验证。
分步骤深入解答
1. 区分两种身份
业务主键回答“这是什么实体”；rowid 回答“这张表中的哪一行”。同一实体被删除后重新写入，业务键可以相同，但 row lineage 不应被误当成永恒实体 ID。审计系统应同时保留业务键、快照 ID 和 row ID。
2. 理解字段继承
新行的 rowid 和 lastupdatedsequencenumber 可以在 data file 中先写成 null。读取时，row ID 由文件的 first-row-id 加上行位置推导，更新时间由 manifest entry 的 sequence number 推导。这样写入器无需在提交成功前重写数据文件。
row_id = data_file.first_row_id + row_position
last_updated = manifest_entry.data_sequence_number3. 处理提交重试
乐观并发提交失败后，表的 next-row-id 可能已经变化。重试必须重新读取当前 metadata，重新分配 first-row-id，并重新生成 manifest list；不能复用第一次尝试的行号范围。提交日志应记录 attempt、冲突原因和最终 snapshot ID。
4. equality delete 的边界
使用 equality delete 的引擎通常不读取旧数据行就写入变更，因此无法提供被替换旧行的原始 row ID。规范把这类更新视作旧行被移除、再新增唯一行。需要稳定业务身份时，额外维护业务键和变更事件，不能假设 equality delete 自动延续 row lineage。
5. 兼容与读取
v3 引入 row lineage，但旧读取器可能不了解保留字段。升级前建立引擎能力矩阵，确认旧读者看到 null、忽略字段或直接失败的行为。对外导出不要依赖读者自动推导的 row ID，必要时由支持 v3 的服务先物化审计字段。
6. 验证、回滚与清理
测试单写入、并发提交、冲突重试、快照回读、删除后重写和 compaction。验证同一 snapshot 内 row ID 唯一、重试不会复用旧范围、sequence number 与最终 snapshot 对齐。回滚只切换快照引用，不重写历史 row ID；物理文件清理仍由快照过期和 orphan cleanup 负责。
高质量示范回答
我会把业务主键和 Iceberg row lineage 分开。v3 用 rowid 和 lastupdatedsequencenumber 提供表内行身份和提交顺序，它们可由 data file 的 first-row-id、行位置和 manifest sequence number 在读取时继承。写入先保留 null，提交冲突重试时重新读取 metadata 并重新分配 ID，不能复用旧 manifest。equality delete 不保证延续旧 row ID，所以审计要保存业务键、snapshot ID 和事件。上线前验证 v2/v3 读取、并发冲突、快照回读、compaction 与清理，并把回滚限定为快照引用切换。
常见错误
- 把 row ID 当业务主键 → 删除重建后语义错误 → 同时保存业务键和 snapshot。
- 在写文件时永久分配 row ID → 重试可能重复或浪费范围 → 依赖提交阶段的继承。
- 复用冲突提交的 manifest → 使用了过期 next-row-id → 每次重试重新读取 metadata。
- 认为 equality delete 会保留原 row ID → 规范不保证旧行可读 → 用业务事件追踪实体。
- 只验证当前查询 → 快照和旧读者仍可能不兼容 → 覆盖跨快照和能力矩阵。
追问及应对
为什么不用业务主键代替 rowid？
业务键可能重复、变更或跨表不唯一；row lineage 是表内物理行身份。两者服务不同审计问题，应同时记录。
提交冲突重试会不会让 row ID 出现空洞？
可能出现未被最终快照使用的范围，具体回收策略由实现决定。关键是不能复用已暴露给成功快照的 ID，且最终快照中的 ID 保持唯一。
compaction 会改变 row ID 吗？
正确实现应通过 lineage 继承保留行身份；验证 compaction 前后同一快照语义和审计映射，不能只比较文件路径。