马上注册,结交更多数据大咖,获取更多知识干货,轻松玩转大数据
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
一个困扰已久的问题 缓慢维度变化(Slowly Changing Dimension),是指维度建模得到的数据模型,因维度变化导致的数据分析异常。穆晨以为这是数仓理论最为重要的概念,故写下此文深入剖析之。
问题描述 —— 从数据库vs数据仓库开始
在前文中,穆晨提出了个有趣的观点:数据库是对客观世界的模拟,而数据仓库则是对人脑思考的模拟。客观世界时刻在变,数据库有范式建模足以应对,那数据仓库呢? 数据库是面向应用的,因此它的数据不会存太久,同时它基于范式建模,因此可直接修改数据不用顾虑更新异常;数据仓库则是面向分析的,如果要修改维度,即使可通过重写避免更新异常,但也避免不了历史信息的丢失。 现在问题来了:如果维度信息不能更改,那还能被称为“人类思考的模拟”吗?这样的数据仓库岂不是成了“老顽固”?
问题溯源 —— 五岳归来不看山?
讨论这类问题的过程的确挺枯燥的,所以穆晨引入古人徐霞客的例子,来类比研究数据分析异常出现的原因吧。 徐霞客曾言“五岳归来不看山,黄山归来不看岳”。显然他感受了五岳和黄山后,对“好山”的标准定义极为严格。但我们更关心的是他曾发现的所有“好山”,而不仅仅是他晚年认可的好山——那就只有一座黄山了。 另一方面,基于数据仓库的分析,也经常是要使用历史维度信息的。比如统计某国商圈的既往人流量,如果该商圈是动态生成的,那计算商圈既往人流时,就必须用既往的商圈维度。 所以,当“评价维度”发生变化后,我们不能直接修改维度,这样历史维度信息就丢失了。如何保留维度信息,从而灵活进行历史数据分析,正是“缓慢维度变化”需要考虑和解决的问题(不缓慢的情况也应考虑到)。
理论分析 —— 知其然,知其所以然?
在数据仓库理论中,解决缓慢维度变化的关键在于“三件套”:唯一性Key、有效时间戳、有效性标签。那为什么要设置这三项,在数据分析中又如何用它们进行历史数据分析呢? 显然当维度变化后,为了不丢失维度信息,只能往维度表里新增维度记录。但维度记录新增后,为了分析历史数据,自然要说明“旧维度”生效的时间段;同时为了方便查询当前业务,应当增加一个标签字段,表示该维度记录是否最新。
那为什么还要有唯一性Key?这其实是个有趣的问题。网上不少文章认为这是出于“主键”机制的考虑,因为新增维度信息后,原来的维度记录id就不唯一了。这里穆晨反驳一句,以维度记录id+时间戳为联合主键就可以了么? 结果是这会导致事实表也不得不冗余时间戳数据,是个很“恶心”的设计。最好还是新增维度的唯一性Key,同时将之设为交易表与维度表的关联键。
方案实践 —— just do it
实践得分两大部分说。一Part是数据仓库开发;另一Part是数据分析实现。这两部分都会产生一定开发与维护上的工作量,所以请事先确认好业务上是否需要考虑维度变化问题。 A 数据仓库开发 维度表开发:由于业务系统不会存放太多历史数据,更不会有专人维护维表。因此就需要DW人员定时更新历史维表,刷新其中的时间戳与有效性标签字段。 事实表开发:相对维表来说,事实表的开发简单很多,只需将维表的唯一性Key融合进来即可。 B 数据分析实现 构建好新的数据模型后,就能用它做历史数据分析了。由于维度表中包含了历史维度信息,因此分析逻辑会比不考虑维度变化的复杂一些。 在分析当前维度时,可用标志id去关联事实并加上可用性标签过滤;而分析历史维度时则可用唯一Key关联事实表并用时间戳字段截取统计值。
结 语 对于业务稳定的国有企业,维度变化问题其实并不严重;但在互联网公司中,由于业务变更迅速,产品迭代快,需要重点关注这个问题。 穆晨身边有些同事不甚了解维度变化,写了大量复杂的SQL,亦或折中各类业务方案。窃以为不论从数据资产积累还是个人技术沉淀角度来看,这都是不可取的。
作者:穆晨 来源:拾光斋 |