[数据模型/大数据] 数据建模之缓慢变化维

1 概述： 数据建模之缓慢变化维场景(SCD)

• 缓慢变化维(Slowly Changing Dimension, SCD)，是大数据或数据仓库中，维度表（如用户、商品表）的属性随时间而【缓慢变更】（非实时高频），却需保留历史状态以支持多时间点数据分析的问题。

【问题核心】是平衡“数据时效性”与“历史可追溯性”。

关键：维度属性随时间变化时，如何保存历史、如何追溯。

比如，用户表中，用户“所在城市”从“北京”变更为“上海”，若直接覆盖旧数据，将无法统计该用户变更前在北京产生的订单数据；若不处理，当前数据又会失真，这就是典型的缓慢变化维问题。

• 这数据仓库中的一种常见概念，用于处理维度表中的数据发生变化的情况。

在实际应用中，业务数据会随着时间发生变化，如何捕捉并正确反映这些变化对于数据分析至关重要。

2 常见缓慢变化维（SCD）处理方案及适用场景

以下是4种核心处理方案，均以“用户ID=10001的用户，所在城市从北京变更为上海”为例说明：

方案1：覆盖式更新

• 处理逻辑：直接用新属性值【覆盖旧值】，不保留历史记录。（只存当前值）
• 示例：用户表中，将用户10001的“所在城市”字段直接从“北京”改为“上海”，原“北京”记录被删除。
• 适用场景：无需追溯历史、仅需保留最新状态的场景，如用户“昵称”“头像”等非核心属性的变更，或数据录入错误后的修正。

方案2：新增行式更新 => 拉链表 (最常见的方案)

• 处理逻辑：保留历史版本，通过新增行 + 生效区间实现。（即： 拉链表 or 流水表）

新增一行包含新属性值的记录，通过“生效时间”、“失效时间”、“是否当前记录”等字段区分状态。

• 示例：保留原“用户10001-北京”的记录，新增“用户10001-上海”的记录；原记录失效时间设为变更日期，新记录生效时间设为变更日期、“是否当前”设为“是”。

• 适用场景：需完整追溯历史状态的核心场景，如用户“所在城市”“会员等级”等影响业务统计（如区域订单量、会员消费分析）的属性变更。

• 流水表在 SCD 问题里的定位

流水表本身不直接等于任何一种 SCD 方案类型，但它是实现 SCD方案2（拉链表） 的重要输入：

流水表（ODS 层：逐笔变更，每一条变更记录都存储）
   ↓ 按月/天/小时 ETL，识别状态切换
拉链表（DW 层：SCD方案2 历史维）
   ↓ 按查询需求
当前维表（DM 层：SCD方案1 视角）

• 【纯流水表】：能回答"某天维度值是什么"（通过 change_time <= 目标时间 取最新），从能力上可以支撑 SCD 的历史追溯需求
• 但它没有【显式的生效区间】，查询时要靠【排序 + 取最新】，【性能】和【语义清晰度】都不如【拉链表】

所以，业界实践里，【流水表】通常被当作 SCD 的"原材料"，ETL 加工成【拉链表】后才作为正式的 SCD方案2 维度对外服务

• SCD 问题中，拉链表 vs. 流水表 vs 方案1 的选型？

• [数据仓库/数据建模] 浅谈历史拉链表 - 博客园/千千寰宇

场景	推荐方案	原因
维度属性变化慢、需频繁查历史状态	拉链表（SCD方案2）​	区间查询直接、语义清晰
变更频繁（如交易系统的账户余额）	流水表 + 定期快照​	拉链表会区间碎片化，失去优势
既要保留所有变更明细，又要高效查历史	流水表（ODS）+ 拉链表（DW）​	分层协作，各司其职
只关心当前值，历史无所谓	SCD方案1（覆盖更新）​	最简模型

方案3：新增列式更新 => 保留有限历史（如: 新增"上一版本的列值"字段)

• 处理逻辑：在原表中新增“旧属性列”（如“原所在城市”），保存旧值，原字段更新为新值，仅保留最近一次历史记录。
• 示例：用户表新增“原所在城市”列，将旧值“北京”存入该列，原“所在城市”列更新为“上海”，仅记录“上海→北京”这一次变更。
• 适用场景：仅需对比“当前值”与“最近一次旧值”，无需完整历史轨迹的场景，如商品“原价”与“现价”的对比展示，或用户“上次所在城市”与“当前城市”的简单分析。

方案4：组合式更新(方案 1+2+3)

• 处理逻辑：结合Type1（覆盖）、Type2（新增行）、Type3（新增列）的特点，既新增行保留完整历史，又在当前行新增列记录关键历史信息。
• 示例：新增“用户10001-上海”的行（Type2），同时在当前行新增“上次所在城市”列记录“北京”（Type3），原记录标记失效（Type2）。
• 适用场景：需兼顾完整历史追溯与便捷查询关键历史信息的场景，如金融领域客户“职业”“收入等级”变更，既需追溯每一次变更以满足合规审计（Type2），又需快速获取“当前职业”与“上一职业”进行对比分析（Type3）。

Y 推荐文献

X 参考文献