谈笑间学会数仓—维度层设计③

谈笑间学会数仓—维度层设计③

缓慢变化维

数据仓库的重要特点之一是反映历史变化,所以如何处理维度的变化是维度设计的重要工作之一。缓慢变化维的提出是因为在现实世界中,维度的属性并不是静态的,它会随着时间的流逝发生缓慢的变化。与数据增长较为快速的事实表相比,维度变化相对缓慢。

在一些情况下,保留历史数据没有什么分析价值;而在另外一些情况下,保留历史数据将会起到至关重要的作用。在Kimball的理论中,有三种处理缓慢变化维的方式,下面通过简单的实例进行说明。

第一种处理方式:重写维度值

采用此种方式,不保留历史数据,始终取最新数据。比如,商品所属的类目于2015年11月16日由类目1变成了类目2,采用第一种处理方式,变化前后的数据记录分别为下表所示:

在这里插入图片描述

在这里插入图片描述

第二种处理方式:插入新的维度行

采用此种方式,保留历史数据,维度值变化前的事实和过去的维度值关联,维度值变化后的事实和当前的维度值关联。同上面的例子,采用第二种处理方式,变化前的数据记录同表10.4,变化后的数据记录如表10.6所示。

在这里插入图片描述

第三种处理方式:添加维度列

采用第二种处理方式不能将前后记录的事实归一为变化前的维度或者归一为变化后的维度。比如根据业务需求,需要将11月份的交易金额全部统计到类目2上,采用第二种处理方式将无法实现。针对此问题,采用第三种处理方式,保留历史数据,可以使用任何一个属性列。同上面的例子,采用第三种处理方式,变化前后的数据积累了分别如表10.7和表10.8所示。通过变化后的商品表和订单表关联,可以根据不同的业务需求,将11月份的交易金额全部统计到类目2或者类目1上。

在这里插入图片描述

在这里插入图片描述

对于选择哪种方式处理缓慢变化维,并没有一个完全正确的答案,可以根据业务需求来进行选择。比如根据商品所属的类目统计淘宝2015年11月的成交额,商品所属的类目于2015年11月16日由类目1变成了类目2,假设业务需求方不关心历史数据,将所有的成交额都统计到最新的类目2上,则不需要保存历史数据;假设类目1属于某个业务部门,类目2属于另一个业务部门,不同业务部门需要统计各自的业绩,则需要保留历史数据。

快照维表

在“维度的基本概念”中,介绍了自然键和代理键的定义,在Kimball的维度建模中,必须使用代理键作为每个维表的主键,用于处理缓慢变化维。但,在阿里巴巴数据仓库建设的实践过程中,虽然使用的是Kimball的维度建模理论,但实际并未使用代理键。

那么为什么不使用代理键?原因如下:

1、阿里巴巴数据量庞大,使用的是阿里巴巴自助知识产权的分布式计算平台maxcomputer。对于分布式计算系统,不存在事务的概念,对于每个表的记录生成稳定的全局唯一的代理键难度很大,此处稳定指某条记录每次生产的代理键都相同。

2、使用代理键会大大增加ETL的复杂性,对ETL任务的开发和维护成本很高。

不使用代理键如何处理缓慢变化维的问题?

阿里巴巴数据仓库实践中,处理缓慢变化维的方法是采用快照方式。数据仓库的计算周期一般是每天一次,基于此周期,处理维度变化的方式就是每天保留一份全量快照数据。比如商品维度,每天保留一份全量商品快照数据。任意一天的事实均可以获取到当天的商品信息,也可以获取到最新的商品信息,通过限定日期,采用自然键进行关联即可。此方法既有优点,也有弊端。

优点主要有以下两点
  • 简单而有效,开发和维护成本低。

  • 使用方便,理解性好。数据使用方只需要限定日期,即可获取到当天的快照数据。任意一天的事实快照和维度快照通过维度的自然键进行关联即可。

弊端主要提现在存储极大浪费上。

比如某维度,每天的变化量占总体数据量的比例很低,在极端情况下,每天无变化,使得存储浪费很严重。此方法主要就是实现了牺牲存储获取ETL效率的优化和逻辑上的简化。但是一定要杜绝过度使用的这种方法,而且必须要有对应的数据生命周期制度,清除无用的历史数据。

综合来看,由于现在存储成本远低于CPU、内存等的成本,此方法弊大于利。那么是否有方法级可以实现上面的有点,又可以很好地降低存储呢?答案是肯定的。下篇继续探索 极限存储。

参考《大数据之路-阿里巴巴大数据实践》

©️2020 CSDN 皮肤主题: 技术黑板 设计师:CSDN官方博客 返回首页