漫谈“缓慢维度变化”

一个困扰已久的问题

缓慢维度变化(Slowly Changing Dimension)，是指维度建模得到的数据模型，因维度变化导致的数据分析异常。穆晨以为这是数仓理论最为重要的概念，故写下此文深入剖析之。

问题描述

—— 从数据库vs数据仓库开始

在前文中，穆晨提出了个有趣的观点：数据库是对客观世界的模拟，而数据仓库则是对人脑思考的模拟。客观世界时刻在变，数据库有范式建模足以应对，那数据仓库呢？

数据库是面向应用的，因此它的数据不会存太久，同时它基于范式建模，因此可直接修改数据不用顾虑更新异常；数据仓库则是面向分析的，如果要修改维度，即使可通过重写避免更新异常，但也避免不了历史信息的丢失。

现在问题来了：如果维度信息不能更改，那还能被称为“人类思考的模拟”吗？这样的数据仓库岂不是成了“老顽固”？

问题溯源

—— 五岳归来不看山？

讨论这类问题的过程的确挺枯燥的，所以穆晨引入古人徐霞客的例子，来类比研究数据分析异常出现的原因吧。

徐霞客曾言“五岳归来不看山，黄山归来不看岳”。显然他感受了五岳和黄山后，对“好山”的标准定义极为严格。但我们更关心的是他曾发现的所有“好山”，而不仅仅是他晚年认可的好山——那就只有一座黄山了。

另一方面，基于数据仓库的分析，也经常是要使用历史维度信息的。比如统计某国商圈的既往人流量，如果该商圈是动态生成的，那计算商圈既往人流时，就必须用既往的商圈维度。

所以，当“评价维度”发生变化后，我们不能直接修改维度，这样历史维度信息就丢失了。如何保留维度信息，从而灵活进行历史数据分析，正是“缓慢维度变化”需要考虑和解决的问题(不缓慢的情况也应考虑到)。

理论分析

—— 知其然，知其所以然？

在数据仓库理论中，解决缓慢维度变化的关键在于“三件套”：唯一性Key、有效时间戳、有效性标签。那为什么要设置这三项，在数据分析中又如何用它们进行历史数据分析呢？

显然当维度变化后，为了不丢失维度信息，只能往维度表里新增维度记录。但维度记录新增后，为了分析历史数据，自然要说明“旧维度”生效的时间段；同时为了方便查询当前业务，应当增加一个标签字段，表示该维度记录是否最新。

那为什么还要有唯一性Key？这其实是个有趣的问题。网上不少文章认为这是出于“主键”机制的考虑，因为新增维度信息后，原来的维度记录id就不唯一了。这里穆晨反驳一句，以维度记录id+时间戳为联合主键就可以了么？

结果是这会导致事实表也不得不冗余时间戳数据，是个很“恶心”的设计。最好还是新增维度的唯一性Key，同时将之设为交易表与维度表的关联键。

方案实践

—— just do it

实践得分两大部分说。一Part是数据仓库开发；另一Part是数据分析实现。这两部分都会产生一定开发与维护上的工作量，所以请事先确认好业务上是否需要考虑维度变化问题。

A

数据仓库开发

维度表开发：由于业务系统不会存放太多历史数据，更不会有专人维护维表。因此就需要DW人员定时更新历史维表，刷新其中的时间戳与有效性标签字段。

事实表开发：相对维表来说，事实表的开发简单很多，只需将维表的唯一性Key融合进来即可。

B

数据分析实现

构建好新的数据模型后，就能用它做历史数据分析了。由于维度表中包含了历史维度信息，因此分析逻辑会比不考虑维度变化的复杂一些。

在分析当前维度时，可用标志id去关联事实并加上可用性标签过滤；而分析历史维度时则可用唯一Key关联事实表并用时间戳字段截取统计值。

结 语

对于业务稳定的国有企业，维度变化问题其实并不严重；但在互联网公司中，由于业务变更迅速，产品迭代快，需要重点关注这个问题。

穆晨身边有些同事不甚了解维度变化，写了大量复杂的SQL，亦或折中各类业务方案。窃以为不论从数据资产积累还是个人技术沉淀角度来看，这都是不可取的。

作者：穆晨  来源：拾光斋