代理键与自然键

操作数据库中的主要标识符通常与其所代表的业务实体紧密关联。客户可能通过电子邮件地址标识，产品可能通过制造商分配的SKU标识，订单可能通过顺序发票号标识。这些被称为自然键。虽然它们在特定事务应用中提供唯一性，但在分析环境中将它们作为主要连接列会给数据完整性和运行效率带来较大风险。

本节说明了自然键和代理键之间的技术差异，并解释了为何现代分析模型几乎完全使用后者。

自然键的局限性

自然键是源自数据本身或源业务过程的标识符。常见例子有：

• 国家身份证件号： SSN，护照号。
• 特定业务代码： 图书的ISBN，金融证券的ISIN。
• 源系统ID： PostgreSQL操作数据库中的 id 列。

在标准关系数据库设计（3NF）中，这些键充当表之间的连接。然而，在数据仓库中，这些键不可变、唯一且一致的假设通常不成立。

业务规则会发生变化。一家公司可能收购一家竞争对手，其为不同产品使用了相同的SKU格式，这会导致冲突。使用整数ID的旧系统可能被使用UUID（通用唯一标识符）的新系统取代。如果您的事实表是使用旧系统的自然键构建的，迁移到新系统将需要对模式进行全面重构。

此外，自然键经常带来隐私风险。如果您使用电子邮件地址或国家ID作为连接事实表和维度表的主要方式，您将在可能数十亿行的事实表中复制敏感个人身份信息（SPII）。这使得遵守GDPR或CCPA等法规变得复杂，因为被遗忘权将要求从庞大的历史表中清除数据，而不仅仅是维度表中的单行数据。

代理键策略

代理键是一个由系统生成的标识符，不具有业务含义。它通常是一个整数，在数据加载到维度表时按顺序（1、2、3...）分配。在维度建模中，代理键成为维度表的主键，并且正是这个整数，而非自然键，作为外键存储在相关事实表中。

使用代理键在原始数据源和您的分析模型之间提供了一个抽象层。这个缓冲使得数据仓库能够处理多种复杂情况，而不会破坏下游报告。

处理历史和SCD

对代理键最直接的技术要求源于追踪历史的需要。正如引言中所述，属性会随时间变化。如果客户从“纽约”搬到“伦敦”，操作系统通常会覆盖地址。在分析中，我们通常希望保留两种状态，以便正确分析历史表现。

如果依赖于自然键 customer_id = 'A100'，我们将无法在该维度表中为该客户存储两行，因为主键约束将被违反。通过使用代理键，我们可以存储同一业务实体的多个版本。

考虑以下关系：

$$\text{代理键} \neq \text{自然键}$$

相反，关系是一对多的：

$$\text{自然键} \to \{ \text{代理键}_1, \text{代理键}_2, \dots, \text{代理键}_n \}$$

客户记录的每个变体都会获得一个唯一的整数标识符。

该图说明了当属性随时间变化时，单个自然键（A100）如何生成不同的代理键（101、102），使得维度表能够为记录的每个版本保持唯一的主键。

整合多个源系统

企业数据仓库经常从不同来源接收数据。设想一个您正在分析来自电商平台和实体零售店的销售数据的情况。

1. 电商系统： 对产品使用整数ID（例如，5001）。
2. 零售销售点（POS）： 也使用整数ID，但独立生成。

电商系统中的产品5001可能是“笔记本电脑”，而POS系统中的产品5001则是“咖啡杯”。如果依赖自然键，这两个不同的产品将发生冲突。

通过应用代理键，数据管道会为每个传入记录分配一个新的唯一整数。维度表可能如下所示：

产品代理键	源系统	源ID	产品名称
1	电商	5001	笔记本电脑
2	零售POS	5001	咖啡杯

这使得分析模型能够统一数据，而无需上游操作系统之间的同步。

对运行效率的影响

除了结构灵活性，代理键在查询执行方面也提供了实际的运行效率优势。分析查询经常需要将庞大的事实表（包含数十亿行）与维度表连接起来。

JOIN 操作的效率受连接键的大小和数据类型影响。操作键通常是字符字符串（例如，UUID或字母数字代码）。比较两个UUID字符串比比较两个整数需要更多的CPU周期。

存储效率也是一个考虑因素。一个标准整数占用4字节。一个作为字符串存储的标准UUID占用36字节。在一个包含1亿行的事实表中，存储UUID外键而不是整数代理键会导致大量的I/O带宽浪费。

$$\text{空间节省} = N \times (\text{自然键大小} - \text{代理键大小})$$

如果 $N = 100,000,000$ 行：

• UUID (36 字节): ~3.6 GB
• 整数 (4 字节): ~0.4 GB

现代数据仓库（如Redshift、Snowflake或BigQuery）使用的列式压缩算法也能比随机字母数字字符串更有效地压缩整数序列，从而提升扫描速度。

处理空值和未知情况

在操作数据库中，缺失的关系通常通过外键列中的 NULL 值表示。然而，在分析环境中，NULL 值会使报告逻辑复杂化。如果用户筛选报告为“不属于（类别 A）”，SQL逻辑规定 NULL 值将完全排除在结果之外，这通常不是业务意图。

代理键使得可以应用“默认”维度行来优雅地处理这些边缘情况。标准做法是为未知状态预留特定的低数值键：

• -1 或 0： 未知 / 不适用
• -2： 待提取
• -3： 错误 / 无效

当事实记录到达时没有有效的维度链接（也许客户记录尚未到达），ETL过程会分配代理键 -1，而不是保留 NULL。这会将事实关联到维度表中标记 (token)为“未知”的特定行，从而保证连接保持为内连接，并且在聚合期间不会无意中丢失数据。

实现方法

生成代理键需要一种维护序列的机制。

在PostgreSQL或SQL Server等传统数据库中，这通过 IDENTITY 列或 SEQUENCES 来处理。当迁移到分布式分析仓库时，生成严格顺序的整数（1、2、3...）可能会成为瓶颈，因为它需要计算节点之间的协调。

现代仓库通常提供替代方案：

1. 哈希键： 对自然键和其他业务逻辑生成哈希值（例如MD5）。这种方法可并行化，但会产生更大的键（字符串或字节），而非紧凑的整数。
2. 行号函数： 在ETL批量加载期间使用 ROW_NUMBER() OVER() 为新行分配ID。

虽然哈希在“数据保管库”建模中很常见，但维度建模（星型模式）更倾向于紧凑的整数方法。在分布式加载中生成这些键的标准模式是计算目标维度中已存在的最大ID，并加上新传入记录的行号：

SELECT 
    ROW_NUMBER() OVER (ORDER BY source_date) + (SELECT COALESCE(MAX(customer_sk), 0) FROM dim_customer) as customer_sk,
    source_id,
    ...
FROM staging_table

这保证了唯一性，并维持了整数的运行效率优势，即使序列是分批处理的。