企业官网建设流程全解析

1. 先从“看不了历史”的业务需求说起

做数据仓库的朋友，早晚都会撞上“缓慢变化维”这面墙。我第一次认真研究它，不是因为看了哪本书，而是被业务方一个很朴素的问题问住了：“这个客户上个月还是‘普通会员’，这个月变成了‘VIP会员’，我想统计他作为‘普通会员’期间贡献了多少销售额，能不能查？”

乍一听这问题好像不难，查订单表带上会员等级字段不就行了？结果一查发现，订单表里根本没有会员等级，等级存在客户维表里，而且已经被更新成“VIP会员”了。也就是说，历史订单如果关联当前维表，全都算成“VIP会员”贡献的，上个月的经营分析直接失真。这个问题不大，但影响很实际——会员等级变了，历史订单归属全错。

这就是缓慢变化维（Slowly Changing Dimensions，简称SCD）要解决的核心问题：维表的属性会随着时间变化，而数据仓库里的历史事实，需要按照“当时”的维度属性去归因，不能跟着现在的属性跑。

那“缓慢”是什么意思？它相对的是“快速变化”。比如订单状态，从待付款变成已付款，几分钟就变一次，那是快变化。但像客户等级、商品分类、员工所属部门、区域归属这类属性，可能几天、几周甚至几个月才变一次，节奏慢、频率低，但它确实会变。这种“慢，但会变”的维度属性，就是SCD的研究对象。

这话题看着理论，实际全是实操。建表怎么写、ETL怎么改、拉链路怎么做、查询怎么写才能拿到历史版本，每一步都有讲究，而且选择不同策略，后续的存储成本、查询复杂度、数据修正方式全都不一样。我从策略分类到建表细节，把这块掰开揉碎讲讲。

2. 三类基本策略：覆盖、新行、新列

SCD的核心解法，业界归纳下来主要是三种基本策略，加上若干组合变体。先记住这三类，剩下都是它们的组合或延伸。

2.1 类型1：直接覆写，适合“错了就要改”的属性

类型1（SCD Type 1）的做法最简单：维度属性发生变化时，直接在原记录上更新，旧值被覆盖，不保留任何历史。比如客户等级变了，就把客户表里的等级字段改成新值，完事。

这种策略适合什么场景？属性本身只有“现状”有意义，历史值没有分析价值，或者这个属性根本就是录入错了，需要修正。比如客户的联系方式、默认收货地址这类信息，你分析历史销售的时候，其实不太关心客户当时的电话是多少，只管当前的就行。还有纯纠正错误的情况，比如性别因为录入笔误写错了，改过来就好，没必要留一条“错误历史”。

实现也简单，UPDATE一条SQL搞定。但它有个硬伤——历史事实的归因会跟着变。还是开头那个例子，上个月的订单关联现在的客户表，看到的就是“VIP会员”。如果业务方需要分析“当时还是普通会员的时候表现如何”，类型1完全没法满足。

所以类型1的定位是：能用，但只适合“历史值不值得留”这个问题答案是“不值得”的属性。凡是业务方可能会问“当时是什么”的属性，尽量别用类型1去处理。

2.2 类型2：新增一行，保留完整历史版本

类型2（SCD Type 2）是三种策略里最常用、也最能扛事的一种。核心思路是：属性一变化，不修改原记录，而是插一条新记录，用版本号或者生效时间区分新旧版本。

还是客户等级的例子，客户A本来是普通会员，2月1日升级为VIP。类型2的做法是：

客户表里原来有一条记录，客户ID是A，等级是“普通会员”，生效日期是2024-01-01，失效日期是2024-01-31，当前版本标记为“否”。升级当天，再插一条新记录，客户ID还是A，等级是“VIP会员”，生效日期是2024-02-01，失效日期是2099-12-31，当前版本标记为“是”。

这样，两张表一关联，上个月的订单用“普通会员”那条版本去关联，这个月的订单用“VIP会员”关联，历史归因就完全对了。

类型2的代价是存储膨胀。维度属性每变一次，表里就多一行。而且查“当前是什么”的时候，必须加过滤条件（比如失效日期是9999-12-31或者当前版本标记为是），不然一关联就出多行，把事实数据翻倍。这两种代价，一个是存储在明处，一个是查询的复杂度在暗处，都容易踩坑。

2.3 类型3：新增一列，保留“上一次的值”

类型3（SCD Type 3）的思路是：不新增行，而是加列。一个字段存当前值，另一个字段存变化前的值（或者初始值），这样能同时看到“现在是什么”和“之前是什么”。

比如客户表加一列“原始会员等级”，当等级从普通会员变成VIP时，当前等级字段更新为VIP，“原始会员等级”保留为普通会员。这样你分析的时候，既能按当前等级统计，也能按初始等级统计，覆盖了两种视角。

但类型3只能追溯“上一次”或者“初始值”，没法完整地保留每一次变化的历史。客户变了三次等级，类型3只能看到当前值和某一个参考值，中间那次就丢了。所以类型3在实操里用得不多，更像是一种“妥协方案”——业务方只关心“最早是什么”和“现在是什么”，不愿接受类型2的行膨胀，才考虑它。

我个人的观点是：类型3适合特定场景，别当主力方案用。因为一旦业务后面说“我还想看中间那次变化”，类型3就得推倒重来，改成类型2，数据加工逻辑、下游报表全部受影响。

3. 除了这三种，还有两个常见变种

除了上面三个基本类型，实际项目中还会碰到两类变体，一个是“什么都不做”，一个是组合多种策略。

3.1 类型0：不变化，原样保留

类型0（SCD Type 0）严格来说不算一种“处理变化”的策略，而是规定某些属性“不允许变化”，或者说“变了也不准改”。

哪些属性会用类型0？通常是维表的自然主键、业务主键、创建时间这类“一次写入、终身不变”的字段。比如客户ID、订单编号、商品编码，这些如果变了，等于这个维度实体就不是原来的实体了，数据关系会全面崩盘。

另外有些属性和业务规则强绑定，比如身份证号、税号，法律上要求唯一且不可变，如果你发现它变了，那大概率是录入错了，而不是业务变了，应该走修正流程，而不是版本管理。

实操上，类型0更多是一种“约束意识”，在ETL的时候对这类字段做校验（是不是和原来一致），不一致就告警，而不是覆盖。它的价值不在于“处理变化”，而在于防止不该变的东西被误改。

3.2 类型6：类型1、类型2、类型3的组合玩法

类型6（SCD Type 6）其实是“类型1+类型2+类型3”的混合体：既有类型2的行版本，也有类型1的当前值覆写字段，还保留了类型3式的“当前值”单独列。

它的好处是，一张表里既能查历史版本（类型2的行），又能直接拿到当前值（类型1的覆写列），不查历史的时候不用额外过滤。比如客户表里，既有“客户历史版本ID”区分每一行版本，又有“客户当前等级”字段，不管关联哪一行，都能直接知道这个客户现在的等级。

代价是字段更多、ETL更复杂。因为同一张表里有两种字段的更新逻辑——类型2的字段要检查变化后决定是否插入新行，类型1的字段则每次都要更新成最新值，两套逻辑必须同时写对。我在一个项目里见过类型6的表，开发和维护的复杂度明显比纯类型2高，如果不是业务确实同时需要“历史归因”和“当前属性”，不建议轻易上类型6。

4. 建表和ETL：从零实现一套SCD2

讲完策略，说点能落地的。拿最常用的类型2举例，从建表到ETL给你一套可以直接抄的模板。

4.1 一张典型SCD2维表的表结构

先看建表语句，以最常见的数据库语法为例（我用的是PostgreSQL风格，换成其他关系型数据库也差不多）：

CREATE TABLE dim_customer ( customer_sk BIGSERIAL PRIMARY KEY, -- 代理键，每条版本记录独立 customer_id VARCHAR(32) NOT NULL, -- 业务主键，客户ID customer_name VARCHAR(64), -- 客户姓名（属性，可变） member_level VARCHAR(16), -- 会员等级（需要追踪历史的属性） register_date DATE, -- 注册日期（属性，理论上不变） effective_date DATE NOT NULL, -- 版本生效日期 expiry_date DATE NOT NULL DEFAULT '9999-12-31', -- 版本失效日期 is_current BOOLEAN DEFAULT TRUE, -- 当前版本标记 created_at TIMESTAMP DEFAULT NOW(), -- 记录创建时间 updated_at TIMESTAMP DEFAULT NOW() -- 记录更新时间 ); CREATE INDEX idx_dim_customer_biz ON dim_customer(customer_id); CREATE INDEX idx_dim_customer_cur ON dim_customer(is_current);

这里有几个关键设计点：

第一，一定要有代理键（customer_sk）。代理键是数据仓库内部自增的、与业务无关的键，它唯一标识“一条版本记录”。业务主键（customer_id）是客户在新系统中的唯一标识，但同一客户有多条版本记录，业务主键会有重复，不能用它做事实表的外键。事实表关联的必须是代理键，这样同一个客户的不同版本记录，才能被历史订单正确匹配到对应版本。

第二，用effective_date和expiry_date来表示版本有效期，这是拉链表的经典做法。查询当前版本用“expiry_date = 9999-12-31”或者“is_current = TRUE”，取某个时间点的版本用“effective_date <= 时间点 AND expiry_date > 时间点”。这样既能按当前关联，也能按历史时点关联。

第三，is_current字段是个“冗余”，目的是加速“查当前”的操作。因为大多数查询都是看当前，如果每次都要比较日期范围，性能不好，加个布尔标记直接过滤就行。代价是要额外维护，ETL里每次开链、闭链都要把对应行的is_current置对。

4.2 拉链ETL的核心逻辑：闭链+开链

类型2的维度更新，业内叫“拉链”，核心步骤只有两步：把旧版本的链拉上（闭链），再挂上新版本（开链）。

用SQL描述增量更新的处理流程，大致是这个样子（假设每天跑一次，源表是customer_src，当天有变化的数据已经在里面了）：

-- 第一步：找到所有“属性发生变化”的客户，把当前版本闭链 UPDATE dim_customer dc SET expiry_date = DATE '2024-02-01' - 1, -- 前一天作为旧版本的失效日期 is_current = FALSE, updated_at = NOW() FROM customer_src cs WHERE dc.customer_id = cs.customer_id AND dc.is_current = TRUE AND ( dc.member_level IS DISTINCT FROM cs.member_level OR dc.customer_name IS DISTINCT FROM cs.customer_name ); -- 第二步：为变化的客户插入新版本 INSERT INTO dim_customer ( customer_id, customer_name, member_level, register_date, effective_date, expiry_date, is_current, created_at, updated_at ) SELECT cs.customer_id, cs.customer_name, cs.member_level, cs.register_date, DATE '2024-02-01', -- 当天作为新版本生效日期 DATE '9999-12-31', TRUE, NOW(), NOW() FROM customer_src cs WHERE NOT EXISTS ( -- 排除完全没变化的客户 SELECT 1 FROM dim_customer dc WHERE dc.customer_id = cs.customer_id AND dc.is_current = TRUE AND dc.member_level = cs.member_level AND dc.customer_name = cs.customer_name );

这段逻辑的关键在哪？在于“比较变化”的判断条件。我见过很多初版ETL漏掉了一个细节：如果源表本身是全量快照，你直接拿全量数据比对，没问题。但如果源表只给增量（比如只有发生变更的数据），你得小心，因为“没变化”的增量（比如只是更新了更新时间字段）也会进入SRC表，如果不对“业务属性是否真的变化”做判断，就会产生重复开链，导致同一客户出现多条“当前版本”，查询直接多行。

那怎么判断“真的变化”？就是把所有需要追踪的属性全部列出，逐一比较，任何一个不一致才算变化。这个比较逻辑必须和业务方确认清楚——哪些属性需要保留历史，哪些不需要。不需要保留历史的属性，变化时直接UPDATE当前版本就好，但没必要开新版本。这个“哪些属性进版本比较，哪些属性直接覆盖”的决策，直接影响表膨胀速度和查询结果，一定要在开发前就和业务对齐。

4.3 查询写法：三个你一定会遇到的SQL模式

SCD2的表建成之后，查询时最常遇到三种模式：

模式一：查当前数据，直接过滤is_current。

SELECT * FROM dim_customer WHERE is_current = TRUE;

模式二：查某个历史时点的数据，比如6月1日的订单关联客户资料，用日期范围：

SELECT f.order_id, f.order_amount, dc.member_level, dc.customer_name FROM fact_order f LEFT JOIN dim_customer dc ON f.customer_sk = dc.customer_sk WHERE DATE '2024-06-01' BETWEEN dc.effective_date AND dc.expiry_date;

模式三：查一个客户的历史变更轨迹，按版本时间排序：

SELECT customer_id, member_level, effective_date, expiry_date, is_current FROM dim_customer WHERE customer_id = 'C10001' ORDER BY effective_date;

这三种模式覆盖了日常分析百分之八十的需求。重点提醒一下模式二的写法：如果事实表里的订单日期是TIMESTAMP，直接用DATE去BETWEEN会有边界问题，最好统一转成DATE类型再比较，避免边界差一天导致关联错版本。

5. 选型对照：什么时候用哪一种策略

看得多了你会发现，SCD策略的选择并不是“哪个好”的问题，而是“哪种代价你更愿意接受”的问题。我整理了一张对照表，方便你快速决策。

这张表不是说类型2永远最优。如果一个维度表有20个属性，其中12个都需要保留历史，那类型2的表会快速膨胀，存储和刷新成本都上来了。这时候可以考虑只对真正需要历史归因的属性做类型2，其余属性做类型1混合处理——这就是上面说的类型6思路，但在具体实施时，我建议把它拆成两张表来维护：一张“当前最新维度表”（类型1），一张“历史版本维度表”（类型2），两张表用同一个业务主键和代理键机制关联。这比把全部字段塞进一张混合类型6的表要好维护得多。

6. 实操中那些没人明说但一定会踩的坑

SCD这块，教科书上讲得都很干净，一到实际项目里全是细节坑。我把这几年见过、踩过的几个典型问题列出来。

6.1 代理键分配时机：别在源系统里生成

有些初学朋友问，能不能直接用源系统的客户ID加生效日期当联合主键，省得建代理键？理论上可以，但实操很别扭：事实表关联的时候，联合主键写起来麻烦；如果哪天源系统把主键类型从整型改成字符串，或者补录数据时生效日期变了，联合主键就兜不住了。

所以代理键一定要在数仓这边自己生成，用自增序列或者雪花ID都行，和源系统完全解耦。这个键的唯一目的就是给事实表当外键，保证关联稳定。源系统的主键可以当业务键存下来，用于排查数据和更新版本，但不该参与版本唯一性约束。

6.2 多属性更新不一定是“开新版本”

这是最容易被过度设计的地方。一个客户改了手机号，要不要也开一条新版本？我的建议是，先把这个属性的历史归因需求问清楚，如果业务方只关心等级变化的归因，手机号改了直接覆盖就行。每个属性都开版本，表膨胀速度是灾难级的，维护成本直线上升。

6.3 增量源没有变化判断标识

很多源系统的增量数据，只是“这个表今天有行变动”的意思，不能区分是UPDATE还是INSERT，更不能告诉你具体哪个属性变了。这时候，ETL里一定要做“变化比对”，否则就会出现：源表里有一条客户数据，每天因为更新时间变化都会进入增量，如果直接往SCD表插新版本，这个客户每天多一行，一年下来几百行——还没到分析的时候，查询性能已经崩了。

正确做法是：比较“需要追踪历史”的属性集合，没变化就跳过开链步骤，最多只更新updated_at时间戳（那也只是日志用途，不影响业务关联）。

6.4 闭链的时间边界要统一

闭链日期怎么取？我见过有人把旧版本的失效日期填成新版本生效日期的前一天，有人填成生效日期当天，还有人填成跑批日期。这会导致同一个客户的版本之间有缝隙或者重叠。我的习惯是：统一用“生效日期减1天”作为旧版本失效日期，这样每天都有且仅有一个版本覆盖，不会有空窗也不会有重叠。

6.5 事实表已经关联了旧代理键，别做物理更新

这是类型2最容易“手滑”的地方。客户等级变了，开了一条新版本，结果发现事实表里已经存了客户代理键，那要不要把老订单的代理键也更新成新版本？千万别。历史订单的事实已经发生，它关联的就是当时那个版本，这是类型2的立足之本。你要是把已关联事实的代理键改掉，历史归因又把“普通会员”的贡献算到“VIP会员”头上了——等于把SCD解决的问题又绕回来了。

7. 一个真实项目的SCD落地复盘

前面讲了很多原理和片段，这里用一个实际模拟项目的完整过程把整个流程串起来。省去具体机构名和真实数据，用“某零售电商平台”为例，业务场景是会员等级分析。

项目背景是这样的：平台的客户等级由系统按月自动升降级，业务方需要分析“不同等级客户分别贡献了多少订单额”，同时还要看“从普通会员升级到VIP会员后，消费行为有没有变化”。这就两头都涉及SCD2——既要历史归因，又要对比变化前后。

我们当时的设计方案是：

第一步，盘点维表属性，确认哪些需要保留历史。和业务方逐字段过了一遍，最终确认会员等级、客户分组这两个属性需要类型2处理；客户姓名、手机号、地址用类型1直接覆盖；客户ID、注册日期用类型0不可变。

第二步，建表。主体结构就是前面给的dim_customer，追踪属性按类型2走，直接覆盖字段单独一列，建好索引。

第三步，写ETL。每天凌晨跑批，从源系统拉取客户全量快照，和数仓当前版本做比对。发现会员等级和客户分组有变化的，执行闭链+开链；只有手机号或地址变化的，直接UPDATE当前版本；完全没变化的，跳过。

第四步，验证数据。跑批完成后，用几条典型的测试数据核对：虚拟客户F从普通会员升级为VIP，分别查询当前版本、升级前后的历史版本，确认版本时间准确、事实表关联正确。另外写了一个校验脚本，统计“每个客户当前版本数量”，有超过1个的告警——这是拉链表最容易出的问题。

第五步，数据应用。报表里，收入归因类指标直接关联当前版本（对大多数场景足够），留存分析类指标关联历史版本，对比分析师直接跑版本轨迹查询。

这个项目上线之后，解决了一个最直接的问题：每个月做会员价值分析的时候，不用再跟业务方解释“为什么上个月的订单算到了VIP头上”，因为口径对了。这次的落地让我确认了一件事：SCD不是数据仓库的“附加题”，而是一开始就该设计好的基础模型，前期多花一周做设计，后期能少改十次报表。

8. 回到经验本身：SCD设计要问的三个问题

如果你正准备做一个带历史属性的维表，开工前先问自己三个问题：

第一个问题：业务方对“这个属性的历史”到底有没有需求？如果没有，别做类型2，别给自己加戏。第二个问题：属性变的频率到底多高？一个月变一次和一天变十次，采用的方案和存储策略完全不同。第三个问题：事实表关联的时候，分析口径是“当时的情况”还是“现在的情况”？只要涉及前者，SCD就躲不掉。

这三个问题想清楚，再去选策略、建表、写ETL，基本不会跑偏。我在实际中发现，大多数SCD设计失败的项目，不是技术不会写，而是业务口径没对齐就动工了。代码好改，口径难调，先跟业务聊明白，再动手写代码，永远不亏。

最后分享一个小经验：如果团队刚开始接触SCD，不要一上来就设计特别复杂的混合策略，先把类型2拉链表跑顺，把闭链、开链、代理键、版本过滤这些都掌握了，再去碰类型6那些组合玩法。基础打牢之后，你会发现在这个领域再复杂一点的需求，本质上还是在回答“某个历史时点，这个维度实体长什么样”这一个问题。把这个问题刻在脑子里，SCD就没什么神秘的了。