题干与适用场景
一个事件湖接收多个供应商的 webhook。核心字段稳定，但扩展字段变化频繁，且部分事件包含日期、时间戳、二进制和小数。请设计 Iceberg v3 的存储模型，比较 Variant、JSON 字符串和 struct 的边界，并给出迁移和验收计划。
题目考察半结构化数据建模，而不是把所有数据都塞进 Variant。Iceberg 规范把 Variant 定义为跨行结构和类型都可能变化的值，支持比 JSON 更丰富的 primitive；它是 v3 能力，必须纳入 format-version 和读者兼容矩阵。
面试官考察点
强回答会把稳定、高频过滤字段提升为顶层列，把低频或变化快的扩展保留为 Variant，并说明 Variant 数组和对象不等同于固定类型 list、struct。它会讨论统计信息、谓词下推、投影成本和跨引擎支持，而不是只说“灵活”。
面试官还看重数据契约、字段命名、类型冲突、隐私治理、回填和降级路径。优秀回答会给出从原始 payload 到规范化列的双写或视图策略，并明确旧引擎不能读取 v3 特性时的处理方式。
回答前需要澄清的问题
哪些字段是业务主键和过滤键
确认租户、事件类型、发生时间和幂等键是否稳定且高频查询。它们应成为类型明确的列，不能依赖每次从 Variant 解析。
扩展字段需要怎样的查询保证
若只是审计回放，Variant 可保留原貌；若要低延迟聚合或分区裁剪，应把经过验证的路径提升为列或物化视图。
读取引擎是否全部支持 v3
确认 Spark、Flink、Trino、服务端 SDK 和导出任务的版本。若有 v2 读者，必须定义降级为 JSON、隔离 v3 表或延迟升级的策略。
30 秒回答框架
“我先把稳定且高频过滤的字段做成顶层列，变化快的低频扩展才放 Variant。Variant 比 JSON 字符串保留更多类型，但不自动带来列式统计和谓词下推；我会通过路径白名单、数据质量规则和物化列控制查询成本。表升级到 v3 前先盘点所有读者，旧引擎走兼容视图或延迟读取，最后用查询延迟、扫描字节、类型冲突和回填成功率验收。”
分步骤深入解答
第一步：划分规范列和扩展域
将租户 ID、事件名、事件时间、来源和幂等键放在顶层 struct 字段，统一类型、可选性和字段 ID。供应商特有的低频对象放入 Variant，并保留来源版本和原始事件 ID，便于重放和追责。
第二步：比较三种表示
固定 struct 适合稳定 schema、强类型计算和列级统计；JSON 字符串兼容性高但需要重复解析，日期、小数和二进制语义容易丢失；Variant 允许跨行变化的对象、数组和更丰富 primitive，但引擎支持、统计和治理成本更高。
第三步：定义 Variant 契约
为允许的路径建立 registry：路径、期望类型、敏感级别、拥有团队、首次出现版本和是否可提升为列。写入时拒绝未知高风险类型，或将其隔离到 quarantine，而不是静默转字符串。
event_id: string
event_time: timestamptz
payload: variant
payload_registry:
vendor.order.total: decimal(18,2)
vendor.order.shipped_at: timestamptz注册表是治理依据，不是把所有 Variant 路径硬编码进表 schema；一旦某路径成为核心查询，才通过 schema evolution 或物化列正式提升。
第四步：控制查询成本
避免在大扫描中对 Variant 做无界通配符遍历。为稳定路径建立投影视图或物化列，按事件类型和时间分区，记录扫描字节、解析 CPU 和命中率。对未知路径采用采样和离线 profiling，确认收益后再提升。
第五步：处理版本与跨引擎读取
Iceberg v3 才允许 Variant。发布前检查每个 reader 的 format-version、Parquet/Avro 映射和 SDK 支持；不支持 v3 的任务可读兼容视图，其中 Variant 被序列化为 JSON，但必须标明类型精度损失和不可查询字段。
第六步：设计回填、冲突和隐私策略
新增规范列时从 Variant 回填，保留原始 payload 和转换版本。遇到同一路径出现 string 与 decimal 冲突，不要静默覆盖：按版本拆路径、记录冲突指标，必要时把坏记录隔离。Variant 也要执行字段级脱敏、删除请求和访问审计。
第七步：建立验收矩阵
测试空值、混合类型、深层数组、时区、精度、未知字段、旧 reader、并发写入和重试。指标包括查询扫描字节、解析 CPU、p95 延迟、类型冲突率、回填重放一致性和 v2/v3 reader 成功率。
高质量示范回答
我不会把 webhook 全部存成 JSON 字符串。租户、事件类型、时间和幂等键进入顶层强类型列；变化快的供应商扩展放进 Variant，并以 registry 管理路径、类型和敏感级别。Variant 保留日期、时间戳、小数等类型，比字符串少一次解析，但不能假设所有引擎都能做高效下推。
表升级到 Iceberg v3 前，我盘点所有 reader，给 v2 任务提供 JSON 兼容视图并记录精度损失。查询侧将高频路径物化，未知路径采样 profiling；类型冲突进入隔离流，回填保留版本和原始事件。最终用扫描字节、p95、冲突率、回填一致性和跨引擎成功率验收。
常见错误
- 错误表现 → 所有字段都放 Variant → 失败原因 → 核心过滤失去类型和统计，查询成本不可控 → 修正方法 → 稳定字段顶层化，Variant 只承载变化扩展。
- 错误表现 → 把 Variant 当成 JSON 字符串 → 失败原因 → 丢失日期、小数、二进制等类型语义 → 修正方法 → 依据 registry 保留真实 primitive 类型。
- 错误表现 → 未验证 reader 就升级 v3 → 失败原因 → 旧引擎可能无法读取表或静默降级 → 修正方法 → 建立版本矩阵和兼容视图。
- 错误表现 → 类型冲突时强制转 string → 失败原因 → 下游聚合和约束被破坏 → 修正方法 → 按版本拆路径或隔离坏记录并计量。
- 错误表现 → 回填直接覆盖原始 payload → 失败原因 → 无法重放和审计转换差异 → 修正方法 → 保留原始事件、转换版本和幂等回填作业。
追问及应对
追问一：为什么不直接使用 JSON 字符串，等查询时再解析？
字符串最兼容，但每次查询都要解析，类型和精度也依赖解析器。若字段只审计不查询可以接受；一旦需要聚合、过滤或跨引擎一致性，Variant 或规范列能把类型契约前移。
追问二：同一路径今天是数字，明天变成字符串，怎么办？
先按 registry 拒绝或隔离不符合类型的写入，记录供应商版本。若业务确实允许两种类型，拆成带版本的路径或显式 union 约定，不能让查询引擎自行猜测。
追问三：旧引擎只能读取 Iceberg v2，如何渐进迁移？
保留 v2 兼容表或视图，将 Variant 序列化为 JSON 并标注精度损失；新 reader 先影子读取 v3，再按作业灰度切换。所有任务在升级门禁中声明最小 format-version。
追问四：什么时候把 Variant 路径提升为顶层列？
当路径稳定、访问频率高、类型冲突率低且 profiling 证明能减少扫描或解析成本时提升。迁移后仍保留一段时间的原始 Variant，以便核对和回放，确认稳定后再评估清理。