缓慢变化维（SCD）三种类型：不是"选一个"，而是逐列定策略

站在指标体系与数据仓库落地视角，把 SCD Type 1 / Type 2 / Type 3 的适用边界、拉链闭合的边界坑、以及同一张维度表内混合 SCD 类型的做法一次讲清。

一、现象与背景

接手一个电商数仓（Hive 3.1 + Spark 3.3，维度表 dim_shop 约 45 万行，被 12 张事实表引用）后，第一个月就撞上一次财务审计事故：

业务方要求拉「2023 Q3 按大区汇总的 GMV 排名」。数据团队跑完报表，财务对不上。排查后发现：门店的"所属大区"在 2023 年 11 月做过一次组织调整（华东 128 家门店划入华南），而 dim_shop 用的是 SCD Type 1（直接 UPDATE 覆盖）。

结果：

• 2023 Q3 的 128 家门店被错误归入「华南」，该季度按大区汇总的 GMV 偏差约 14%（约 380 万元）；
• 更麻烦的是，历史已经丢了——覆盖式更新后，没有任何一行记录"这 128 家在 2023 Q3 属于华东"；
• 财务追问"能不能恢复"，答案是"不能，除非从 ODS 层重新回放 14 个月的 binlog"。

这件事的教训：维度表的更新策略，决定了指标体系能不能追溯。而"能不能追溯"不是 nice-to-have，是审计合规的硬要求。

二、原理与根因：三种 SCD 类型的本质区别

缓慢变化维（Slowly Changing Dimension）的核心问题只有一个：维度属性变了，事实表里引用的那个"值"还算不算数？

| 类型 | 策略 | 维度表行数 | JOIN 复杂度 | 历史追溯 | |---|---|---|---|---| | Type 1 | 直接覆盖 | 不变 | 最低 | 无 | | Type 2 | 新增一行（拉链表） | 随变更次数线性增长 | 中（需日期匹配） | 完整 | | Type 3 | 加一列 prev_xxx | +1 列 | 低 | 仅前一个值 |

为什么指标体系默认应该用 Type 2？

因为指标计算需要的是「事件发生时刻的维度值」，而不是「当前时刻的维度值」。

举例：一笔 2023 年 8 月的订单，门店当时属于「华东」。现在（2024 年）这家门店已经划到「华南」。如果你用 Type 1，2023 年 8 月的这笔订单在按大区汇总时会被算进「华南」——事件发生的时空上下文被篡改了。

Type 2 的本质：把「时间轴上的版本」压扁成行，每行是一个版本区间 [start_date, end_date)。JOIN 时用事实表的事件日期去匹配版本区间，就能拿到「事件发生时刻」的维度值。

Type 3 的本质：承认"我只需要知道前一个值"。它比 Type 2 省存储，但最多保留一个历史值，且那个值永远是"上一次"，不是"任意历史时刻"。

三、具体做法（可复现）

3.1 Type 1：覆盖（纠错 / 合规场景）

-- 最简单，但不可逆
UPDATE dim_shop SET region = '华南' WHERE shop_id = 10284;

适用：录入错误修正、隐私合规（旧手机号不留）。不适用于任何需要历史追溯的指标计算。

3.2 Type 2：拉链表（指标体系默认解）

表结构：

CREATE TABLE dim_shop_scd2 (
    shop_id      INT,
    shop_name    STRING,
    region       STRING,
    start_date   DATE,    -- 版本生效起始日（含）
    end_date     DATE,    -- 版本失效日（不含）
    is_current   TINYINT  -- 1 = 当前版本
) PARTITIONED BY (dt STRING);

每日增量闭合 + 新增（Spark SQL，幂等可重跑）：

INSERT OVERWRITE TABLE dim_shop_scd2 PARTITION(dt='${bizdate}')
-- ① 闭合旧版本：把「今天有变更」的当前版本 end_date 设为今天
SELECT
    a.shop_id, a.shop_name, a.region, a.start_date,
    '${bizdate}' AS end_date,          -- 闭合
    0            AS is_current
FROM dim_shop_scd2 a
WHERE a.dt = '${bizdate}' AND a.is_current = 1
  AND a.shop_id IN (
      SELECT DISTINCT shop_id FROM ods_shop_change WHERE dt = '${bizdate}'
  )
UNION ALL
-- ② 新增新版本
SELECT
    c.shop_id, c.shop_name, c.region,
    '${bizdate}' AS start_date,
    '9999-12-31' AS end_date,
    1            AS is_current
FROM (SELECT shop_id, shop_name, region FROM ods_shop_change WHERE dt = '${bizdate}') c
UNION ALL
-- ③ 未变更的行原样保留
SELECT shop_id, shop_name, region, start_date, end_date, is_current
FROM dim_shop_scd2
WHERE dt = '${bizdate}' AND is_current = 1
  AND shop_id NOT IN (
      SELECT DISTINCT shop_id FROM ods_shop_change WHERE dt = '${bizdate}'
  );

JOIN 时的日期匹配（最关键的一步）：

-- 正确写法：用事实表的事件日期匹配维度版本区间
SELECT f.dt, d.region, SUM(f.gmv) AS gmv
FROM fact_order f
JOIN dim_shop_scd2 d
  ON f.shop_id = d.shop_id
 AND f.dt >= d.start_date
 AND f.dt <  d.end_date          -- 左闭右开，含 start 不含 end
WHERE f.dt BETWEEN '2023-07-01' AND '2023-09-30'
GROUP BY f.dt, d.region;

3.3 Type 3：有限历史列（展示"前值"的报表）

CREATE TABLE dim_shop_scd3 (
    shop_id            INT,
    region             STRING,
    prev_region        STRING,   -- 只保留前一个值
    region_change_date DATE
);

-- 变更时：旧值挪到 prev，新值写入当前列
UPDATE dim_shop_scd3
SET prev_region        = region,
    region             = '华南',
    region_change_date = '2023-11-01'
WHERE shop_id = 10284;

适用：运营报表里需要展示"大区（前值：华东）→ 大区（当前：华南）"的场景。不适用于指标计算——它只能追溯"上一次"，不能追溯"任意历史时刻"。

四、踩过的坑与反直觉之处

坑 1：JOIN 漏了日期区间，GMV 被重复计算 3 倍

最初写 JOIN 时只写了 f.shop_id = d.shop_id，没写日期匹配。一个门店有 3 个版本（2021 华东 → 2022 华北 → 2023 华南），JOIN 后每笔订单被匹配了 3 行，GMV 直接膨胀 3 倍。排查了 4 小时（先怀疑分区裁剪，再怀疑数据重复），最后发现是 JOIN 条件缺了日期区间。

教训：Type 2 的 JOIN 必须同时带主键 + 日期区间，缺一不可。

坑 2：<= vs < 的边界

如果 start_date 和 end_date 都含当天（即 [start, end] 闭区间），那变更当天会有两个版本同时生效，JOIN 结果翻倍。

统一规则：左闭右开 [start_date, end_date)，end_date 是"失效日"（不含当天）。

坑 3：Type 2 行数膨胀不是线性的

45 万门店、3 年变更约 8 万次，dim_shop_scd2 从 45 万行涨到 53 万行——看起来不多。

但换成商品维度（SKU 级别，500 万行，每天约 12% 的 SKU 改价或改类目）：

500 万 × (1 + 0.12 × 365) ≈ 2.2 亿行

存储、JOIN 成本、拉链闭合的写入量全部指数级增长。高变更频率的维度，Type 2 不是免费午餐。

坑 4：Type 3 的"有限历史"陷阱

prev_region 只保留前一个值。如果门店在 2023 年 1 月从「华东」改到「华北」，11 月又从「华北」改到「华南」，那 prev_region = '华北'，但 2023 年 1 月之前的「华东」彻底丢了。

Type 3 的"历史"只有 1 步，不是"完整历史"。

坑 5：SCD 类型不是全局统一的，要逐列定

这是最反直觉的一点：同一张维度表里，不同列可以用不同的 SCD 类型。

以 dim_shop 为例：

| 列 | SCD 类型 | 理由 | |---|---|---| | shop_name | Type 1 | 名字改错了就是改错了，覆盖即可 | | region | Type 2 | 归属变更必须追溯（审计 / 指标计算） | | contact_phone | Type 1 | 隐私合规，旧号码不留 | | manager_name | Type 3 | 运营报表需要展示"前任经理" |

不要试图用一种 SCD 类型统一所有列。

坑 6：拉链闭合的幂等性

上面的闭合 + 新增 SQL 是 INSERT OVERWRITE，天然幂等——重跑同一天不会产生重复版本。但如果你用 INSERT INTO（追加），重跑就会多出两份"当前版本"，is_current = 1 的行数翻倍，JOIN 直接炸。

规则：拉链表的每日任务必须用 INSERT OVERWRITE（或等价的整分区重写），不能用 INSERT INTO。

五、结论与可复用清单

选型决策表

| 判断条件 | 推荐 SCD 类型 | 原因 | |---|---|---| | 录入错误 / 合规不留旧值 | Type 1 | 覆盖最简单，无历史需求 | | 指标计算需要事件时刻的维度值 | Type 2 | 唯一能完整追溯的方案 | | 报表只需展示"前一个值" | Type 3 | 省存储，JOIN 简单 | | 变更频率 > 5%/天（如 SKU） | Type 1 + 变更日志表 | Type 2 行数膨胀不可控 | | 同一张表内不同列需求不同 | 混合 | 逐列定策略，不要一刀切 |

可复用清单（6 条）

1. 指标体系默认 Type 2，除非有明确的"不留历史"理由（合规、纠错）；
2. 左闭右开 [start_date, end_date)，end_date 不含当天，全团队统一；
3. Type 2 的 JOIN 必须同时带主键 + 日期区间，只 JOIN 主键 = 行数膨胀 = 指标错误；
4. 同一张维度表内可以混合 SCD 类型，逐列定策略，不要全局统一；
5. 高变更频率维度（> 5%/天）慎用 Type 2，考虑 Type 1 + 独立变更日志表，控制存储成本；
6. 拉链闭合任务必须幂等（INSERT OVERWRITE 整分区重写），禁止 INSERT INTO 追加。

一句话总结

SCD 不是"选一个类型"的单选题，而是逐列定策略的填空题。指标体系要的是"事件发生时刻的维度值"，Type 2 拉链表是目前唯一能完整交付这个承诺的方案——代价是 JOIN 复杂度 +1 个日期条件、维度表行数随变更次数线性增长。这个代价，在审计合规和指标正确性面前，几乎总是值得付的。