数仓建设 - 缓慢变化维的10种处理方式

顾名思义，缓慢变化维（Slowly Changing Dimension）就是变化相对缓慢（相对与快速变化的事实表来说）的维度。

在维度建模理论中，有8种处理方式，包括基础的5种以及混合的3种。 再加上大数据时代的2种极限型，共10种，具体如下：

1、基础型

1.1、方法0: 保留原始值

维度属性值不做更改，保留原始值。

此方式什么也不做，所以称之为方式0。

• 比如商品上架售卖时间：一个商品上架售卖后可能由于缺货下架，补充库存后又再次上架，此种情况产生了多个商品上架售卖时间。如果重点关注的是商品首次上架售卖时间，则采用方式0。

• 比如商品所属供应商：a商品的供应渠道是某供应商，随着时间推移可能转款到b供应商（由b供应商来供货），此种情况如果关注的是原始最初供应的供应商，则采用方式0。

1.2、方法1: 直接覆盖

修改维度属性为最新值，直接覆盖，不保留历史信息。

• 比如商品属于哪个品类：当商品品类发生变化时，直接重写为新品类，如果业务只关心最新的品类。

1.3、方法2: 增加新行

在维度表中增加新的一行，新行中采用新的属性值。此种方式需要借助代理键，需要为新行分配新的代理键，将其作为事实表的外键。

采用此方式，一般会在维度行中额外增加3列：行生效时间，行失效时间以及当前行标识（或者不使用当前行标识，由行失效时间来判断是否是当前行）

此方式及其变种是处理缓慢变化维的主要技术。

比如:

1.4、方法3: 增加新属性列

在维度表中增加新的一列，原先属性列存放上一版本的属性值，当前属性列存放当前版本的属性值。

比如:

1.5、方法4: 增加微型维度

当某维表是一个大型维度表，采用方式2时，如果某些维度属性变化相对较快，会导致该维表变得越来越大，导致存储压力和性能压力。

此时引入微型维度是一个不错的选择，将某些维度属性从该大型维表中抽离出来，单独构建微型维度。

比如将用户最近消费时间、消费频率、消费金额从用户维表中剥离出来，并结合业务以区间段形式表现，单独构建成RFM微型维度，并在相关事实表中增加RFM键作为外键

---

2、混合型

2.1、方式5: 微型维度与方式1支架表

该方式是方式1和方式4的结合，即建立微型维度后，微型维度的主键不仅作为事实表的外键，也作为主维度的外键。

在主维度中，此微型维度属性以方式1处理，即当该属性发生变化时，直接覆盖，不保留历史信息。

这种情况下的微型维度被称之为支架。

如方式4中的例子，我们再将RFM键添加至主维度（用户维度表）中作为外键，以方式1进行更新，即为方式5

2.2、方式6: 将方式1属性增加到方式2维度

该方式是方式1、2、3的结合，即同时增加维度行和维度列，并以方式1处理新加的维度列（当前属性）。

此种方式复杂，在少数特定迫切的场景下才会使用。

如商品的品类变化

2.3、方式7：双重外键并且方式1与方式2结合

在方式2的基础上，不仅是维度的代理键作为事实表外键，维度的自然键（如果自然键会被重新分配，发生变化，应该使用持续性超自然键）也同时作为事实表外键。

事实表通过代理键连接维表获取历史维度属性，通过自然键连接维表获取当前维度属性。

如以商品维度为例

---

3、极限型

3.1、方式8: 快照维度

此种方式比较暴力，每天保留全量维度属性的快照数据，自然键及日期键作为事实表的外键。

此方式依托的是当前存储成本远低于计算成本，以空间换时间的理念。

如商品快照维度表

3.2、方式9：历史拉链维度

此方式是方式2的阉割版，同样是增加维度行。

但舍弃了代理键，因为如MapReduce之类的分布式计算引擎，维护全局唯一的代理键难度大，成本高。

优点是此方式相比方式8，大大降低了存储（当然前提是不包含变化频率很高的维度属性，如果有，请考虑进行垂直拆分）。

缺点是和事实表连接时会有一些不足。如事实表只能以时间切片的方式和维度表进行连接，如果事实表要多个时间切片同时与维度表关联，需要一定的技术改造。

---

4、结语

以上就是针对缓慢变化维的10种处理方式了。

随着数据技术的发展，维度建模方法也不是一成不变的，需要结合当前技术的特点进行灵活转变。

总之，没有最牛x的建模方法论，只有最适合的。