深入解析数据仓库中的缓慢变化维

作者 | 李谦恒

数据工程师。逻辑重于代码，高效胜过勤奋。崇尚 life work balance。

前言

最近公司在招聘数仓开发，笔者负责技术方面的一些问题，缓慢变化维自然是不可缺少的环节。

但出乎笔者预料的是，所有的面试者都没有完整了解 缓慢变化维 的前因后果及处理方式，大都是通过“野路子”碰运气实现几种简单通用的变化方式，甚至有人声称缓慢变化维就是拉链表。

因此，笔者将基于 kimball 的数仓理论和自身对其的理解，对缓慢变化维进行全面且深入的介绍。

什么是缓慢变化维？

要解释缓慢变化维，必须先解释什么是维度。

什么是维度？

在数据仓库的 DW 层中，表根据用途往往会分为 2 个类型：FACT（事实表）和 DIM（维度表）。

举个例子，如果我们要描述一个餐饮过程：

 小明 2020年4月19日下午3点20分 在 海底捞(万达广场) 吃了5道菜，每道菜的单价是4元，总价是20元。

那么这个过程在数仓中，会如此划分：

• fact：餐饮过程，单价、数量、总价

• dim：小明，餐饮时间，餐饮门店，菜名。

也就是说：吃了多少东西，多少钱——这些属于 fact；在哪里吃、什么时候吃？这些属于 dim。

下面是简单的 ER 图，方便大家更好的理解。

黄色为事实表，蓝色的就是维度表。

什么是缓慢变化维？

正如上述所言，我们会将分析的各种角度，存放在维度表中。但正如每个人所见，维度里的数据是可能发生变化的——尽管可能跨越极久。

举2个例子：

• 客户的性别变更

  可能在第一次登陆中，我们得到的信息是 该客户性别为男。

  但在几年的客户再一次使用中，我们又得到该客户的性别为女。

  这就是维度值的一种变化可能

  性别一般并不会改变，所以大概率是其中的一次数据有误。但也有可能是客户做了变性手术。

• 雇员的部门更替

  假定有一个雇员叫小杨，他最早是负责运营的——此时他的 title 是"商品运营助理"；但因为某些原因，他转组成为数据组的一员，这时 title 就变成了"数据分析专员"。

  这是缓慢变化维的一种常见可能

上面提到的这些数据变化，业务系统(CRM、OA等)往往并不会保留历史数据。但在分析角度，我们是一定要保留这些改变的痕迹。这种随着时间可能会缓慢变化的维度，就是 缓慢变化维、也就是 SCD（Slowly Changing Dimensions）

常见的处理方法

kimball 整理的处理方法一共有 8 种，但往往只有 3 种被详细使用。

类型1 重写

与业务数据保持一致，直接 update 为最新的数据。

这种方法主要应用于以下两种情况：

1. 数据必须正确——例如用户的身份证号，如需要更新则说明之前录入错误。

2. 无需考虑历史变化的维度——例如用户的头像 url，这种数据往往并没有分析的价值。因此不做保留。

这种处理方式的优缺点：

• 优点：

• • 简化 ETL ——直接 update 即可。

  • 节省存储空间——其他存储方法都占用更多空间。

• 缺点：

  </