代理键为什么不是普通的 id 字段
很多数据仓库团队都会遇到这样的问题：维度表一开始建得挺顺利，字段少，逻辑清晰。等业务跑了两年，突然发现主键开始变得尴尬——业务系统里订单号被回收重用，用户 ID 跨系统合并，几个源头系统的编码规则还不一样。这时候才意识到，当初图省事直接用业务键当维度主键，欠下的账迟早要还。
代理键的价值，往往不是在一开始显现的，而是在数据链路越来越长、数据源越来越杂的时候才变得扎眼。这篇文章想聊聊代理键设计里那些容易被低估的地方，以及真实工程中怎么选、怎么用、怎么避坑。
代理键和自然键的核心区别
所谓代理键，简单说就是维度表中与业务含义无关、由数仓自己生成的主键。它不来自上游系统，不代表现实世界里的任何代码，只是一个纯技术标识。自然键则不同，它是业务系统里本来就有、且有业务含义的字段，比如订单号、用户编号、产品编码。
需要先厘清一个常见误区：并不是说自然键不能用，而是它不适合直接作为维度表主键。原因不在于业务键本身，而在于业务键的稳定性无法由数仓团队控制。上游系统的编码规则一变，数仓的历史数据就面临跟随变还是保持原样的两难抉择。
还有一个偏工程的原因：查询性能。代理键通常使用整数类型，索引紧凑，join 速度快。自然键通常是字符串，长度更长，还可能包含空格、大小写不一致等脏数据问题。在千万级维表、亿级事实表的环境里，这种差异会被明显放大。
自然键没那么可靠：三种常见变化场景
真实业务场景里，自然键会变，而且变化方式比想象中多。这里列举三种常见情况，任何一种都能让原有设计失效。
- 业务键重用：系统迁库或者业务规则调整后，旧订单号被回收，新的记录又用同一个编号。对业务系统来说这没什么，但数仓里主键就冲突了。
- 业务键含义漂移：同一个编码字段，早期代表一类对象，后续扩展成另一类。比如线下门店编号和线上虚拟门店混在同一个维度里，单靠编码无法稳定区分。
- 多源合并：集团下面几个子公司，各自建系统，用户 ID 都是从 1 开始的。要合并到统一数仓，直接拿自然键做主键，唯一性立刻崩溃。
这三种情况有个共同点：外部系统的自然键遵循的是业务逻辑，不是数仓逻辑。数仓需要稳定的身份锚点，就必须自己造一个。
代理键的生成方式：不同选择区别很大
既然要引入代理键，最实际的问题就是它怎么生成。不同生成方式之间的差异，比想象中要大。在单一来源、集中式管理的前提下，自增整数仍然是大多数数仓维度的首选。这里先做一个直观对比。
| 生成方式 | 主要优点 | 主要缺点 | 适用场景 |
|---|---|---|---|
| 自增整数 | 实现简单，索引紧凑，查询性能好 | 多源合并时容易撞号，需要统一规划 | 单一来源、集中式数仓 |
| 哈希值（MD5/SHA-256） | 可确定性生成，适合多源合并 | 存在碰撞概率，需要唯一约束，列宽较大 | 需要同一业务键映射到同一代理键 |
| UUID/GUID | 全局唯一，无需协调，分布式友好 | 索引随机，存储较大，查询性能略低 | 分布式采集、分库分表环境 |
真正需要避免的，是不加区分地在所有场景里硬套同一套生成逻辑。比如在很多团队里，一张维度表在 MySQL 里跑得好好的，换到分布式数据库后仍然沿用自增主键，结果导入多分片时频繁撞号，最后只能回炉重造。
ETL 中如何查找和填充代理键
代理键的生成通常发生在维度建模和 ETL 加载阶段。以 PostgreSQL 为例，可以在建表时用 IDENTITY 列生成代理键，自然键用唯一约束保存下来，这样就同时保留了业务识别和主键稳定性。
CREATE TABLE dim_customer (
customer_sk BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
customer_nk VARCHAR(64) NOT NULL,
customer_name VARCHAR(128),
valid_from DATE NOT NULL,
valid_to DATE,
UNIQUE (customer_nk, valid_from)
);ETL 写入时，关键一步是通过自然键查找已有代理键，而不是每次重新生成。比如增量加载客户数据时，需要先确认这条客户是否已经存在：
SELECT customer_sk
FROM dim_customer
WHERE customer_nk = 'C10001'
AND valid_to IS NULL;如果查到结果，说明这是一个已有客户，需要走更新逻辑；查不到，才考虑插入新版本。这段逻辑看起来简单，却是代理键应用里最容易被忽略的部分。很多团队建表时给维度表加了代理键，但 ETL 里仍然每次重新生成，最后维度表里出现大量重复记录，原因基本都出在这里。
代理键与缓慢变化维（SCD2）结合
代理键真正发挥威力的场景是缓慢变化维（SCD）处理，尤其是 SCD2。当一条记录的属性发生变化时，我们需要为新版本生成一条新记录，同时保留历史版本。如果维度表里直接用自然键做主键，新版本一插入，主键就撞了；用代理键的话，每个版本都能拥有独立标识，既不影响历史，又能向前追踪。
举个例子，某个客户从北京搬到上海，地址属性变化了。在 SCD2 处理下，原记录的 valid_to 会更新为变动当天，新记录则生成新的代理键。事实表里的旧订单继续指向旧版本，新订单指向新版本。这样统计历史业绩时，能看到那段时间客户所在城市的影响，而不是像 SCD1 那样直接把历史覆盖掉。
这个场景里，如果没有代理键，只靠自然键是绝对做不到的。这也是为什么很多数仓建模规范会明确规定：维度表必须使用代理键作为主键，自然键作为业务唯一键保留。
再往深一层说，事实表里保存的关联键应当是不可变的。事实一旦发生，它关联的维度状态就是固定的。自然键会随着业务变化而调整，如果事实表直接引用自然键，历史事实的归集口径就会跟着变。代理键的作用，就是为每个维度状态提供一个永久不变的标识，让事实永远稳定地指向它应该指向的版本。
关于代理键的三个常见误区
说了这么多，再看几个实际项目里频繁出现的误区。
误区一：把代理键回传给业务系统。代理键是数仓内部的标识，不代表业务含义。一旦下游应用或数据服务依赖这个字段，它就会变成变相的自然键，失去设计意义。正确做法是代理键只存在于数仓内部，对外仍然提供自然键。
误区二：认为哈希代理键绝对可靠。哈希函数都存在碰撞概率，虽然很低，但无法从数学上排除。尤其在千万级以上的维度表里，不能只依赖哈希，必须加唯一约束，并对 ETL 的冲突情况进行监控。这种问题一旦发生，数据库会直接报 duplicate key，事务回滚，排查成本极高。
误区三：有代理键就可以不保留自然键。自然键是连接上游和数仓的锚点。没有自然键，增量更新时无法判断记录是否已存在，数据血缘也没法追溯。代理键替代的是主键职能，不是业务识别职能。两者应该共存。
落地建议：现在就开始用代理键
如果你正在设计一个新的数仓，最直接的建议是：从第一版就引入代理键。哪怕当前只有单一数据源、业务键也足够稳定，这一步也不要省。因为后续每次引入新数据源、新系统，都会面对无法改变历史表结构的痛苦。
存量系统迁移也不用太慌。可以参考这样的思路：先对维度表做去重分析，把自然键作为唯一约束确认不会冲突，然后添加代理键列，再迁移历史数据。注意迁移时不能对外键关系制造断裂，要保证事实表关联使用的是同一套代理键，而不是混用自然键和代理键。
还有一个容易被忽略的点：代理键的命名和类型要保持一致。团队里要约定好统一的格式，例如以 _sk 结尾，统一使用 BIGINT，避免一半维度表用 INT，一半用 VARCHAR，后续 join 全是隐式转换，排查问题非常痛苦。
代理键不是银弹，但它解决的是数仓建模中最基础的一层稳定性问题。理解它为什么重要，不是为了多一个 id 字段，而是为了理解维度建模的意图：数据仓库的可信度，往往就藏在这些不太显眼的表结构设计里。
原创文章，作者：fudengji，如若转载，请注明出处：https://fudengji.cn/article/724/