一、SCD 概念与业务场景：什么是缓慢变化维，为什么需要它

大家好，我是老周。做数据仓库这行十几年了，今天咱们聊聊一个绕不开的话题——缓慢变化维，简称 SCD。

说实话，我刚开始做数仓那会儿，觉得维度设计嘛，不就是建几张表、拉几个字段？直到第一次被业务方追着问：“为什么上个月客户地址改了，你们报表里还是老地址？” 嗯，从那以后我才真正意识到，维度数据是会变的，而且怎么处理这些变化，直接决定了数据仓库的靠谱程度。

1.1 什么是缓慢变化维

先看个最简单的例子。你有一张客户表，里面存了客户的地址。今天客户搬家了，地址变了。那问题来了：

• 如果直接更新，那历史数据就丢了——上个月的销售分析，地址全变成新的了。
• 如果不更新，那当前业务又没法用——发货都发到老地址去了。

这就是典型的“缓慢变化维”场景。维度表中的数据，不是完全不变的，也不是高频变动的，而是以一种“缓慢但确实在变”的方式在演进。

说白了，就是回答一个问题：当维度数据变了，我们怎么记录这个变化？

1.2 为什么需要 SCD

你可能要问：直接覆盖不就完了？我举个例子你就明白了。

假设你是做零售分析的。去年客户张三住在北京，今年搬到了上海。如果你直接覆盖地址：

• 去年北京门店的销售业绩，全算到上海门店头上了。
• 区域经理一看报表：北京业绩怎么突然少了？上海业绩怎么多了？
• 实际上，张三在北京的消费记录，应该归属北京区域才对。

你看，一个地址的变更，直接影响了区域维度的分析准确性。这就是为什么我们需要 SCD——不是为了技术炫技，而是为了业务分析的准确性。

1.3 常见业务场景

SCD 不是理论空谈，它每天都在真实业务中发生。我挑三个最常见的场景说说。

场景一：客户地址变更

这是最经典的 SCD 场景。客户搬家、换公司、改联系方式，这些信息变了，但历史交易记录需要保留原来的地址信息。

时间点	客户 ID	地址	业务影响
2024-01-01	C001	北京市朝阳区	1月订单归属北京区域
2024-06-01	C001	上海市浦东新区	6月订单归属上海区域

如果不做 SCD，要么所有订单都变成上海，要么所有订单都还是北京——都不对。

场景二：产品分类调整

公司业务调整，产品线重新划分。比如原来“手机”属于“消费电子”，现在划到“智能终端”下面了。

• 去年的销售数据，分类是“消费电子”
• 今年的销售数据，分类是“智能终端”
• 如果直接改分类，去年“消费电子”的业绩就没了

我遇到过一家电商公司，就因为产品分类调整没处理好，导致年度同比分析完全对不上。后来花了整整两周重新梳理数据，教训深刻。

场景三：员工部门调动

员工从 A 部门调到 B 部门。这时候：

• 他之前在 A 部门的业绩，应该算 A 部门的
• 他之后在 B 部门的业绩，应该算 B 部门的
• 如果直接更新部门字段，A 部门的业绩就少了

1.4 SCD 的核心逻辑框架

为了让你更直观地理解 SCD 在整个数据仓库中的位置，我画了一张图：

从这张图你能看到，SCD 不是孤立存在的。它连接了业务系统、变化检测、维度表存储和下游应用。每个环节都有讲究，后面几章我会逐一展开。

1.5 什么时候该用 SCD

不是所有维度变化都需要 SCD。我总结了一个判断标准：

• 需要历史分析：比如要看去年各区域的销售对比 → 必须用 SCD
• 变化频率低：地址、分类、部门这些，一年变一两次 → 适合 SCD
• 变化影响范围大：一个维度变化影响多条事实记录 → 必须用 SCD
• 业务审计要求：需要追溯历史状态 → 必须用 SCD

1.6 本章小结

这一章我们聊了：

• 什么是缓慢变化维——维度数据随时间缓慢变化的现象
• 为什么需要它——保证历史分析准确、业务决策靠谱
• 三个常见场景——客户地址、产品分类、员工部门
• SCD 的核心逻辑框架——从业务系统到下游应用的完整链路