![e9d3643fd5ada3c83ee9d2b28624001b.png](https://i-blog.csdnimg.cn/blog_migrate/35a6fe4cffc7989e18a386e157b4158d.jpeg)
数据建设,解决的目标就是从数据源头到数据价值实现的全链路工作,我们把这个链路比作有机蔬菜的商业化实现。那么,数据仓库建设就好比是这个商业化餐厅的厨师了。企业需求千万万,厨师的技能却是有章可循的。
本篇文章是基于kimball的代表作《数据仓库工具箱》,如果你是分析师、架构师或者是业务,对维度建模感兴趣,那么不妨看上一看。对你来说,了解别人在干嘛,对沟通成功率也能多一分提升。如果想更深一步了解相关知识或者案例,建议您抽时间来看看这本书。
事实与维度
事实表
事实,表示某个业务度量。比如你制造、消费、存储等,与之对应的都有一个可度量的事实。造了多少,花了多少,多少存货等。事实表往往保留着维度表的键,以进行关联分析不同维度下的事务发展与变化。
事务事实表
对应一个细化的业务过程,对应的是时间或空间上某点的度量事件,比如购物时的下单过程。围绕着此过程,考虑的指标可能有:下单数,下单金额,下单商品数等。
周期快照事实表
汇总发生在某一个特定周期,如某一天、某周、某月的多个度量事件。一般包含多个事实,因为符合同一个粒度的事实都被汇总。
累积快照事实表
汇总发生在过程开始与结束之间可预测步骤内的度量事件(如入库、分拣、出库)。管道或工作流过程(下单、支付、退款等)具有定义的开始点、标准中间过程、定义的结束点,他们在此类事实表中都可以被建模。
合并事实表
将来自多个过程的、以相同粒度表示的事实合并为单一的合并事实表。为过程关联性强,探索不同业务过程的之间的关联,提供简单快捷的分析。
事实表处理
- 一致性:业务过程应该能够被清晰地定义,有着明确的业务边界;对于表的创建,应符合统一的规范,增加可读性;对于字段的使用,也应能够做到同词同义;
- 可加性:度量值中类似销量,是完全可加的;库存,半可加的,你不能跨时间维度;单价,不可加的。而对于事实表中,我们尽可能的存储完全可加的度量值,对于半可加、不可加度量值,通过拆分子、分母的形式达到我们的目的
维度表
维度,是包含于业务过程度量事件有关的文本环境。它们用于描述与“谁、什么、哪里、何时、如何、为什么”有关的事件。维度常为一个主体,事实是跟这个主体有关的事务。区别维度与事实,最重要的一点就是是否具有可计算性。
雪花维度
为了维度表中的层级更加规范,通过与基本维度关联,获取低粒度属性。这个过程包含如果包含多重维度表层次时,这样的模型即为雪花模型。这样的模型,对于理解、查询、性能都有很大影响。建立扁平化、非规范化的维度表完全能够替代雪花。
杂项维度
在业务发展中,有很多各种各样的小维度,重要而又庞杂。我们可以通过将这些小维度合并到统一的杂项维度表中进行管理。
支架维度
支架维度类似与雪花维度,区别在于它是基本维度中,包含了其他属性维度。比如,银行维度中,引用日期维度。这样的辅助维度成为支架维度。同样指出,这样的方式不利于星型模型的建设,应该尽量较少使用。所希望的情况,维度之间的关联应该由事实表来完成。
退化维度
常是功能被弱化的一些主键,比如订单号。在事实表中,存在的意义主要是统计一些订单数量等。或者上卷时,作为关联键,连接订单维度的数据。
建设过程的一些思想和方法
缓慢变化维
对于变化的数据,我们怎么才能够追溯其历史呢?比如说,同样的商品,我想了解今天与昨天的价格差,是相对赚了,还是亏了。这个时候,我们就涉及到缓慢变化维的概念。
简单来说,它就是用户解决历史数据变化的一种方法,让数据可追溯。而在处理缓慢变化维中,处理的方式有几种。
1:重写
只保留最新的数据,舍弃历史的数据。主要场景,业务不关心历史变化情况,或者不太会发生历史变化;
2:增加新行
增加的新行,采用修改的维度属性,同时增加额外三个列,标识行有效时间、截止时间、当前行标识(曾命名为:bistarttime/biendtime/bi_etltime)
3:增加新属性
又称替换现实。比如以前的部门叫BI,后来换了个洋气的名字,就数据科学。在存储时,原来记录部门的名称只有一个,考虑缓慢变化后,变成两个。另一个叫,前名称。有时候也会考虑多种属性,如:前前部门,这种不太用到。
4.微型维度
当遇到频繁+大量的数据修改时,那么记录这些变化的数据将带来大量的性能压力。这个时候,往往考虑对变化数据进行范围化设计。如消费金额,用户每个月的消费金额都不同,但是我们可以设置一个范围:比如0-1万元。这样,她的消费变化就稳定了。
5.组合设计
考虑特定的场景,将上述的这些处理方法进行组合。如:2+3
桥接表与多对多关系
场景一:作者与书是一种多对多的关系,每本书可能有多个作者,作者从卖书的利润中获取收入。这个时候,最优的模型设计应该是怎么样的,来解决:书利润有多少钱,每个作者多少钱,top10的书,top10的作者呢 ?
场景二:我们去体检,在某些项目上,我们有多条重复的记录。比如,测量身高、测量血液等。这个时候,我们应该怎么设计,能够将这些数据都记录下来呢?
从模型的角度来考虑,我们应该尽可能的扁平化,有时应采用行列转换的方式来达到这个目的。而有时候,我们也需要一个桥接表,来记录这样的关系。
建模过程
- 选择业务过程
在传统的行业中,是有比较成型的模型设计(如:FSLDM)的,从总体上设计,分成十大主题(人、产品、财务...),核心则是这些实体之间的关系。而在维度建模中,以业务过程中发生的事务作为一条中轴线(核心源),将实体(维度)关系联系在一起,来构建企业的数据仓库 - 声明粒度 粒度,即是一种统计角度。一般情况下,应该从最细的粒度出发,以便足够覆盖业多变的需求。
- 确定维度
尽可能的将与事务相关的实体,纳入到事实表中。这样对于数据探索也有着很大的帮助 - 确定事实
可以理解为,需要哪里度量值吧数据建设,解决的目标就是从数据源头到数据价值实现的全链路工作,我们把这个链路比作有机蔬菜的商业化实现。那么,数据仓库建设就好比是这个商业化餐厅的厨师了。企业需求千万万,厨师的技能却是有章可循的。
本篇文章是基于kimball的代表作《数据仓库工具箱》,如果你是分析师、架构师或者是业务,对维度建模感兴趣,那么不妨看上一看。对你来说,了解别人在干嘛,对沟通成功率也能多一分提升。如果想更深一步了解相关知识或者案例,建议您抽时间来看看这本书。
事实与维度
事实表
事实,表示某个业务度量。比如你制造、消费、存储等,与之对应的都有一个可度量的事实。造了多少,花了多少,多少存货等。事实表往往保留着维度表的键,以进行关联分析不同维度下的事务发展与变化。
事务事实表
对应一个细化的业务过程,对应的是时间或空间上某点的度量事件,比如购物时的下单过程。围绕着此过程,考虑的指标可能有:下单数,下单金额,下单商品数等。
周期快照事实表
汇总发生在某一个特定周期,如某一天、某周、某月的多个度量事件。一般包含多个事实,因为符合同一个粒度的事实都被汇总。
累积快照事实表
汇总发生在过程开始与结束之间可预测步骤内的度量事件(如入库、分拣、出库)。管道或工作流过程(下单、支付、退款等)具有定义的开始点、标准中间过程、定义的结束点,他们在此类事实表中都可以被建模。
合并事实表
将来自多个过程的、以相同粒度表示的事实合并为单一的合并事实表。为过程关联性强,探索不同业务过程的之间的关联,提供简单快捷的分析。
事实表处理
- 一致性:业务过程应该能够被清晰地定义,有着明确的业务边界;对于表的创建,应符合统一的规范,增加可读性;对于字段的使用,也应能够做到同词同义;
- 可加性:度量值中类似销量,是完全可加的;库存,半可加的,你不能跨时间维度;单价,不可加的。而对于事实表中,我们尽可能的存储完全可加的度量值,对于半可加、不可加度量值,通过拆分子、分母的形式达到我们的目的
维度表
维度,是包含于业务过程度量事件有关的文本环境。它们用于描述与“谁、什么、哪里、何时、如何、为什么”有关的事件。维度常为一个主体,事实是跟这个主体有关的事务。区别维度与事实,最重要的一点就是是否具有可计算性。
雪花维度
为了维度表中的层级更加规范,通过与基本维度关联,获取低粒度属性。这个过程包含如果包含多重维度表层次时,这样的模型即为雪花模型。这样的模型,对于理解、查询、性能都有很大影响。建立扁平化、非规范化的维度表完全能够替代雪花。
杂项维度
在业务发展中,有很多各种各样的小维度,重要而又庞杂。我们可以通过将这些小维度合并到统一的杂项维度表中进行管理。
支架维度
支架维度类似与雪花维度,区别在于它是基本维度中,包含了其他属性维度。比如,银行维度中,引用日期维度。这样的辅助维度成为支架维度。同样指出,这样的方式不利于星型模型的建设,应该尽量较少使用。所希望的情况,维度之间的关联应该由事实表来完成。
退化维度
常是功能被弱化的一些主键,比如订单号。在事实表中,存在的意义主要是统计一些订单数量等。或者上卷时,作为关联键,连接订单维度的数据。
建设过程的一些思想和方法
缓慢变化维
对于变化的数据,我们怎么才能够追溯其历史呢?比如说,同样的商品,我想了解今天与昨天的价格差,是相对赚了,还是亏了。这个时候,我们就涉及到缓慢变化维的概念。
简单来说,它就是用户解决历史数据变化的一种方法,让数据可追溯。而在处理缓慢变化维中,处理的方式有几种。
1:重写
只保留最新的数据,舍弃历史的数据。主要场景,业务不关心历史变化情况,或者不太会发生历史变化;
2:增加新行
增加的新行,采用修改的维度属性,同时增加额外三个列,标识行有效时间、截止时间、当前行标识(曾命名为:bistarttime/biendtime/bi_etltime)
3:增加新属性
又称替换现实。比如以前的部门叫BI,后来换了个洋气的名字,就数据科学。在存储时,原来记录部门的名称只有一个,考虑缓慢变化后,变成两个。另一个叫,前名称。有时候也会考虑多种属性,如:前前部门,这种不太用到。
4.微型维度
当遇到频繁+大量的数据修改时,那么记录这些变化的数据将带来大量的性能压力。这个时候,往往考虑对变化数据进行范围化设计。如消费金额,用户每个月的消费金额都不同,但是我们可以设置一个范围:比如0-1万元。这样,她的消费变化就稳定了。
5.组合设计
考虑特定的场景,将上述的这些处理方法进行组合。如:2+3
桥接表与多对多关系
场景一:作者与书是一种多对多的关系,每本书可能有多个作者,作者从卖书的利润中获取收入。这个时候,最优的模型设计应该是怎么样的,来解决:书利润有多少钱,每个作者多少钱,top10的书,top10的作者呢 ?
场景二:我们去体检,在某些项目上,我们有多条重复的记录。比如,测量身高、测量血液等。这个时候,我们应该怎么设计,能够将这些数据都记录下来呢?
从模型的角度来考虑,我们应该尽可能的扁平化,有时应采用行列转换的方式来达到这个目的。而有时候,我们也需要一个桥接表,来记录这样的关系。
建模流程
- 选择业务过程
在传统的行业中,是有比较成型的模型设计(如:FSLDM)的,从总体上设计,分成十大主题(人、产品、财务...),核心则是这些实体之间的关系。而在维度建模中,以业务过程中发生的事务作为一条中轴线(核心源),将实体(维度)关系联系在一起,来构建企业的数据仓库 - 声明粒度 粒度,即是一种统计角度。一般情况下,应该从最细的粒度出发,以便足够覆盖业多变的需求。
- 确定维度
尽可能的将与事务相关的实体,纳入到事实表中。这样对于数据探索也有着很大的帮助 - 确定事实
可以理解为,需要哪里度量值吧