数仓代理键和自然键怎么选？
面试怎么回答
我会把自然键和代理键分工使用。自然键来自业务系统，用于识别、幂等和回溯；代理键由数仓生成，用于跨系统统一和标识维度历史版本。SCD2 场景下，同一自然键会有多个代理键，事实表按业务时间关联当时版本。没有历史变化、自然键稳定的场景不必机械加代理键，关键看跨源冲突和版本管理需求。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
订单号、用户 ID 本来就能唯一标识记录，为什么维度表还要再造一个代理键？
自然键解决业务识别，代理键解决数仓版本、跨系统整合和历史关联，两者不是替代关系。
自然键负责找到业务实体，代理键负责标识数仓中的某个维度版本。
自然键的优势和边界
自然键来自业务系统，可读、可追溯，适合源端对账。但它可能变更、复用、不同系统冲突，甚至由多个字段组成，不能默认永久稳定。
代理键解决历史版本
代理键通常由数仓生成，与业务含义解耦。在 SCD2 维度中，同一个自然键可以对应多个版本，每个版本拥有不同代理键，事实表才能关联事件发生时的维度状态。
事实表如何关联
采集事实时先保留自然键用于追溯，再根据业务时间和有效区间查找维度代理键。查不到时使用明确的 Unknown 成员，而不是写 NULL 或随意补 0。
不是所有表都要强制代理键
稳定的事务事实主键仍可使用业务键或组合键做幂等。是否引入代理键，应看跨源整合、历史版本、Join 宽度和生命周期，而不是套建模模板。
为什么不能只回答概念？
“误区：有唯一业务 ID 就不需要代理键”之所以常见，是因为它在理想数据和单次执行里往往说得通。但生产环境会加入数据规模、异常值、并发、版本、失败重试和下游口径，这些条件一变化，只记住术语就很容易给出错误结论。
所以我会把 自然键的优势和边界、代理键解决历史版本、事实表如何关联、不是所有表都要强制代理键 串成一条完整链路。最终判断标准不是某个函数或配置是否出现，而是能否稳定得到可解释、可验证、可恢复的业务结果。
落地时我会检查什么？
- 输入边界：确认数据范围、时间口径、主键和异常值是否符合假设。
- 执行过程：观察分区、并行度、状态、Shuffle 或资源变化，验证方案是否真正生效。
- 输出结果：用行数、唯一性、关键指标和样本明细证明结果正确，而不是只看任务成功。
- 失败恢复：说明重跑、回滚、版本兼容和责任人，避免一次成功后无人维护。
这些检查不一定全部写进一条 SQL 或一个任务，但面试时能主动补充，说明你回答的不是背诵题，而是在描述一套可上线的工程方案。
一个典型场景
一个典型场景是 CRM 和交易系统都使用从 1 开始的用户 ID。合并到企业级用户维度后，自然键发生冲突；若只保留 user_id，事实会串到错误用户。正确做法是把来源系统纳入自然键，并由数仓分配统一代理键，同时保留源键方便回查。
自然键回答“业务里是谁”，代理键回答“数仓里哪个版本”。