数据仓库系列之维度建模
学习数据仓库,你一定会了解到两个人:数据仓库之父比尔·恩门(Bill Inmon)和数据仓库权威专家Ralph Kimball。Inmon和Kimball两种DW架构支撑了数据仓库以及商业智能近二十年的发展,其中Inmon主张自上而下的架构,不同的OLTP数据集中到面向主题、集成的、不易失的和时间变化的结构中,用于以后的分析;且数据可以通过下钻到最细层,或者上卷到汇总层;数据集市应该是数据仓库的子集;每个数据集市是针对独立部门特殊设计的。而Kimball正好与Inmon相反,Kimball架构是一种自下而上的架构,它认为数据仓库是一系列数据集市的集合。企业可以通过一系列维数相同的数据集市递增地构建数据仓库,通过使用一致的维度,能够共同看到不同数据集市中的信息,这表示它们拥有公共定义的元素。
这里我主要介绍维度建模方法。这一方法是Kimball最先提出的,其最简单的描述就是按照事实表、维度表来构建数据仓库、数据集市。在维度建模方法体系中,维度是描述事实的角度,如日期、客户、供应商等,事实是要度量的指标,如客户数、销售额等。按照一般书籍的介绍,维度建模还会分为星型模型、雪花模型等,各有优缺点,但很少直接回答一个问题,也就是数据仓库为什么要采用维度建模?
星型模型
雪花模型
数据仓库包含的内容很多,它可以包括架构、建模和方法论。对应到具体工作中的话,它可以包含下面的这些内容:
1、数据架构体系:以Hadoop、Spark等组建为中心的数据架构体系。
2、各种数据建模方法:如维度建模、范式建模法、实体建模法。
3、辅助系统:调度系统、元数据系统、ETL系统、可视化系统这类辅助系统。
我们暂且不管数据仓库的范围到底有多大,在数据仓库体系中,数据模型的核心地位是不可替代的。因此,下面的将详细地阐述数据建模中的典型代表:维度建模,对它的的相关理论以及实际使用做深入的分析。
为了能更真切地理解什么是维度建模,我将在后续的文章中模拟一个大家都十分熟悉的电商场景,运用讲到的理论进行建模。理论和现实的工作场景毕竟会有所差距,这一块,我会分享一下企业在实际的应用中所做出的取舍。接下来具体来了解维度建模
一、什么是维度建模
维度模型是数据仓库领域大师Ralph Kimball 所倡导,他的《数据仓库工具箱》,是数据仓库工程领域最流行的数仓建模经典。维度建模以分析决策的需求出发构建模型,构建的数据模型为分析需求服务,因此它重点解决用户如何更快速完成分析需求,同时还有较好的大规模复杂查询的响应性能。
我们换一种方式来解释什么是维度建模。学过数据库的童鞋应该都知道星型模型,星型模型就是我们一种典型的维度模型。我们在进行维度建模的时候会建一张事实表,这个事实表就是星型模型的中心,然后会有一堆维度表,这些维度表就是向外发散的星星。那么什么是事实表、什么又是维度表,下面会专门来解释。
星型模型
二、维度建模的基本要素
维度建模中有一些比较重要的概念,理解了这些概念,基本也就理解了什么是维度建模。
1. 事实表
发生在现实世界中的操作型事件,其所产生的可度量数值,存储在事实表中。从最低的粒度级别来看,事实表行对应一个度量事件,反之亦然。不太理解举个例子。比如一次购买行为我们就可以理解为是一个事实,大家看一下星星模型示例。
图中的订单表(ICstockbill)就是一个事实表,你可以理解他就是在现实中发生的一次操作型事件,我们每完成一个订单,就会在订单中增加一条记录。我们可以回过头再看一下事实表的特征,在事实表里没有存放实际的内容,他是一堆主键的集合,这些ID分别能对应到维度表中的一条记录。
2. 维度表
每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键,当然,维度表行的描述环境应与事实表行完全对应。 维度表通常比较宽,是扁平型非规范表,包含大量的低粒度的文本属性。图中的customer(客户表)、goods(商品表)、d_time(时间表)这些都属于维度表,这些表都有一个唯一的主键,然后在表中存放了详细的数据信息。
最后说一下维度模型的优缺点:
1、数据冗余小(因为很多具体的信息都存在相应的维度表中了,比如客户信息就只有一份)
2、结构清晰(表结构一目了然)
3、便于做OLAP分析(数据分析用起来会很方便)
4、增加使用成本,比如查询时要关联多张表
5、数据不一致,比如用户发起购买行为的时候的数据,和我们维度表里面存放的数据不一致
再说没有数据仓库的宽事实表的优缺点:
1、业务直观,在做业务的时候,这种表特别方便,直接能对到业务中。
2、使用方便,写sql的时候很方便。
3、数据冗余巨大,真的很大,在几亿的用户规模下,他的订单行为会很恐怖、粒度僵硬,什么都写死了,这张表的可复用性太低。