缓慢变化维解决什么问题
维度属性会随时间变化：用户升了会员等级、组织调整了归属、商品换了类目。缓慢变化维（SCD）就是处理这类变化的策略集合。核心判断只有一个——业务是否需要「用当时的属性还原当时的指标」。需要，就用 Type 2 保留版本；不需要且允许直接覆盖，用 Type 1；只关心与上一版的对比，用 Type 3。
基本信息
| Type 1 | 原值覆盖，不保留历史 |
|---|---|
| Type 2 | 新增版本行，用生效区间区分，完整保留历史 |
| Type 3 | 增加前值列，只保留有限历史 |
| 选择依据 | 是否需要用历史属性回溯当时的指标口径 |
典型使用场景
- 会员等级变化：需要按当时等级回溯历史消费，用 Type 2
- 名称或拼写纠错：无分析价值，用 Type 1 直接覆盖
- 组织架构调整：关注归属变化前后对比，可用 Type 3
- 地址与联系方式：需要历史快照做地域分析，用 Type 2
- 维度表治理：给每个属性单独标注策略，而不是整表一刀切
选型提问
选型提问
业务是否需要用当时的等级或归属回溯历史指标？
→ 需要：Type 2（版本化，常见落地形态是拉链表）
→ 不需要且允许覆盖：Type 1
→ 只对比上一版本：Type 3三种策略对照
| 类型 | 做法 | 历史保留 | 典型场景 |
|---|---|---|---|
| Type 1 | 原值覆盖 | 不保留 | 纠错、无分析价值的属性 |
| Type 2 | 新增版本行（生效区间） | 完整保留 | 会员等级、组织归属、地址 |
| Type 3 | 增加前值列 | 保留有限历史 | 只关心上一版本的简单场景 |
同一张维度表可以对不同属性采用不同策略：等级用 Type 2，姓名拼写纠错用 Type 1，不必整表统一。
会员等级这类关键属性一旦用 Type 1 覆盖，历史报表的口径就永远无法复现，事后再想回补要从备份重算，代价极高。
变更判定的两个细节
实施 SCD 时有两个容易被忽略的判定细节：一是「哪些列算属性」——把同步时间、ETL 批次号这类技术字段纳入比对，会导致每次同步都判定为变更，维度版本无意义地膨胀；二是「空值的语义」——源端把删除的字段写成空串或 NULL，如果直接参与比对，会出现「属性从有值变为空」被判定为一次正常变更。处理方式是先明确空值口径，再在比对前统一规整。