数据仓库系列缓慢渐变维度SCD(SlowlyChangingDimension)常见的三种类型及原型设计

开篇介绍

在从 OLTP 业务数据库向 DW 数据仓库抽取数据的过程中，特别是在第一次导入之后的每一次增量抽取往往会遇到这样的问题：业务数据库中的一些数据发生了更改，到底要不要将这些变化也反映到数据仓库中？在数据仓库中，哪些数据应该随之变化，哪些可以不用变化？考虑到这些变化，在数据仓库中的维度表又应该如何设计以满足这些需要。

很显然在业务数据库中数据的变化是非常自然和正常的，比如顾客的联系方式，手机号码，住址等信息可能随着顾客的所在地的更改发生变化，比如商品的价格在不同时期有上涨和下降的变化。那么在业务数据库中，很自然的就会修改并马上反映到实际业务当中去。但是在数据仓库中，其数据主要的特征一是静态历史数据，二是少改变不删除，三是定期增长，其作用主要用来数据分析。因此分析的过程中对历史数据就提出了要求，有一些数据是需要能够反映出在周期内的变化历史，有一些数据却不需要，那么这些数据应该如何来控制。

假设在第一次从业务数据库中加载了一批数据到数据仓库中，当时业务数据库有这样的一条顾客的信息。

顾客 BIWORK ，居住在北京，目前是一名 BI 的开发工程师。假设 BIWORK 因为北京空气质量 PM2.5 等原因从北京搬到了三亚。那么这条信息在业务数据库中应该被更新了

那么当下次从业务数据库中抽取这类信息的时候，数据仓库又应该如何处理呢？

我们假设在数据仓库中实现了与业务数据库之间的同步，数据仓库中也直接将词条数据修改更新。后来我们创建报表做一些简单的数据统计分析，这时在数据仓库中所有对顾客 BIWORK 的销售都指向了 BIWORK 新的所在地 - 城市三亚，但是实际上 BIWORK 在之前所有的购买都发生在 BIWORK 居住在北京的时候。这是一个非常简单的例子，它描述了因一些基本信息的更改可能会引起数据归纳和分析出现的问题。但是有时，这种场景的的确确可能是存在的。

为了解决类似于这样的问题需要了解数据仓库中的一个非常重要的概念 - 缓慢渐变维度。

缓慢渐变类型一 (Type 1 SCD)

在数据仓库中，我们可以保持业务数据库和数据仓库中的数据始终处于一致。可以在 Customer 维度中使用来自业务数据库中的 Business Key - CustomerID 来追踪业务数据的变化，一旦发生变化那么就将旧的业务数据覆盖重写。

DW 中的记录根据业务数据库中的 CustomerID 获取了最新的 City 信息，直接更新到 DW 中。

缓慢渐变类型二 (Type 2 SCD)

当然在数据仓库中更多是对相对静态的历史数据进行数据的汇总和分析，因此会尽可能的维护来自业务系统中的历史数据，能够真正捕获到这种历史数据的变化。以上面的例子来说，可能需要分析的结果是 BIWORK 在 2012年的时候购买额度整体平稳，但是从2013年开始购买额度减少了，出现的原因可能与所在的城市有关系，比如在北京的门店可能比在三亚的门店相对要多一些。像这种情况，就不能很简单在数据仓库中将 BIWORK 当前所在城市直接更新，而应该新增加一条数据来说明现在 BIWORK 所在地是在 Sanya。

但是如果仅仅在 DW 中新增一条新的数据仍然会出现新的问题，因为在 DW 中标识这个顾客是通过 CustomerID 来实现的，这条 CustomerID 来源于业务数据库，它是唯一的。然而在 DW 中新增一条数据来保存业务数据库中历史信息，就无法保证这条数据在 DW 中的唯一性了，其它的 DW 数据表关联到这张表就无法知道应该如何引用这个 Customer 的信息。实际上，如果 CustomerID 在 DW 中也作为主键来唯一标识 Customer 的话，在插入新数据的时候就会发生失败 - 主键冲突。

因此我们需要继续保持 Business Key 业务键，因为它是关联到业务数据库的唯一纽带。做出改变的部分就是新增加一个 Key，一个数据仓库的键。在数据仓库的术语里面，这个唯一标识数据仓库表记录的键我们称之为 Surrogate Key 代理键，通常设置为DW表的主键。

在上面这张表中，其中 -

CustomerID 是 Business Key 业务键，用来连接业务数据库和数据仓库的键，注意无论在业务数据库还是数据仓库，无论任何时候都不应该发生改变。DW ID 是 Surrogate Key 代理键，一般设置为 DW 维度表的主键，用来在数据仓库内部中的维度表和事实表建立关联。

为什么使用代理键，有什么好处？

• 假设我们的业务数据库来自于不同的系统，对这些数据进行整合的时候有可能出现相同的 Business Key，这时通过 Surrogate Key 就可以解决这个问题。
• 一般来自业务数据库中的 Business Key 可能字段较长，比如 GUID，长字符串标识等，使用Surrogate Key 可以直接设置成整形的。事实表本身体积就很大，关联 Surrogate Key 与关联 Business Key 相比，Surrogate Key 效率更高，并且节省事实表体积。
• 最重要的一点就是上面举到的这个例子，使用 Surrogate Key 可以更好的解决这种缓慢渐变维度，维护历史信息记录。

什么时候可以不用代理键？我觉得可以结合我们的实际业务，比如像有些业务表本身的 Business Key 就已经是整形的了，并且表中的属性基本上不随着时间或地理发生改变。比如像某些国家名称，地区编号编码等等基本上不会怎么发生改变，即使改变了也不需要维护历史记录这样的情况下可以直接使用业务数据库中的 Business Key 而不需要设置新的 Surrogate Key。

接着上面的表结构讲，光这样设置了新的 Surrogate Key - DWID 是不够的，因为还需要告诉数据仓库哪一条信息是现在正在使用的。当然可以根据 DW ID 的顺序来查出最新的记录，但是每次都要比较 CustomerID 然后找出最大的 DW ID 这样的查询比较麻烦。

因此可以额外一个标志表示这条数据是最新更改的。

另外的一种方式就是通过起始时间来标识，Valid To 为 NULL 的标识当前数据。

当然，也有将两者都综合的。

还有一种情况就是混合使用 Type 1 和 Type 2 的，比如说 Occupation 这个字段在业务数据库中发生了变化，但是可以不用维护这个历史信息，因此可能的做法是直接将最新的 Occupation 在数据仓库中覆盖掉。

根据实际情况，还有一种做法就是全部覆盖掉。

缓慢渐变类型三 (Type 3 SCD)

实际上 Type 1 and 2 可以满足大多数需求了，但是仍然有其它的解决方案，比如说 Type 3 SCD。 Type 3 SCD 希望只维护更少的历史记录，

比如说把要维护的历史字段新增一列，然后每次只更新 Current Column 和 Previous Column。这样，只保存了最近两次的历史记录。但是如果要维护的字段比较多，就比较麻烦，因为要更多的 Current 和 Previous 字段。所以 Type 3 SCD 用的还是没有 Type 1 和 Type 2 那么普遍。

总结

• Type 1 SCD - 不记录历史数据。一切不需要维护的历史数据都可以选择 Type 1 ，假设地理信息中的国家名称发生更改，像这种数据基本上不需要维护的话，那么就直接使用 Type 1 SCD 覆盖旧的国家名称。
• Type 2 SCD - 添加新的数据。使用的比较常见，基本上除了 Type 1 SCD 之外的情形都会优先考虑 Type 2 SCD。
• Type 3 SCD - 添加历史列。不会追踪所有的历史记录，只会追踪上一次的历史信息。这种情况往往介于 Type 1 和 Type 2 的时候会考虑，需要记录历史数据，但是又不需要记录那么多。

PS

在不同的工具中对 SCD 的实现是不一样的，比如在微软 SSIS SCD 控件的设计当中对 SCD 的实现:

• Type 0 - Fixed Attribute 不变化的属性。
• Type 1 - Changing Attribute 可变化的属性，会重写数据。
• Type 2 - Historical Attribute 历史属性。

所以和我这里介绍到的三种 Type SCD 基本类型在原型和概念实现上有一些区别，这一点希望大家不要混淆，关注的重点应该是具体的实现方式和解决思路的原型。

结束

^  - ^ ......