浅谈大数据建模的主要技术：维度建模_大数据平台数据 建模 设计(2)

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

实际上，我们通过和业务方、需求方交谈，或者阅读报表、图表等，可以很容易地识别度量。

考虑如下业务需求：

• 店铺上个月的销售额如何？
• 店铺库存趋势如何？
• 店铺的访问情况如何（ pv，uv) ?
• 店铺访问的熟客占比多少？

这里的销售额、库存、访问量、熟客量就是度量。

但是，单单谈论度量，是没有意义的。

度量和环境这两个概念构成了维度建模的基础。而所有维度建模也正是通过对度量和
及其上下文和环境的详细设计来实现的。

事实和维度

在 Kimball 的维度建模理论中，度量称为事实，上下文和环境则称为维度。

通常来说，事实常以数值形式出现，而且一般都被大量文本形式的上下文包围着。

这些文本形式的上下文描述了事实的“ 5个W ”（ When 、 Where 、 What 、 Who 、 Why ）信息，通常可被直观地分割为独立的逻辑块，每一个独立的逻辑块即为一个维度，比如一个订单可以非常直观地分为商品 、买家、卖家等多个维度。

在维度建模和设计过程中，可以根据需求描述或者基于现有报表，很容易地将信息和分析需求分类到事实和度量中。

比如业务人员需求为“按照一级类目，统计本店铺上月的销售额情况”，“按照一级类自”这个描述，很清楚地说明需求方希望对一级类目的销售额进行统计分析，这里的一级类目即为一个维度 。类似的是，“上月”为另一个维度，而销售额明显是事实。

事实表

事实表是维度模型中的基本表，或者说核心表

事实上，业务过程的所有度量在维度建模中都是存储在事实表中的，除此之外，事实表还存储了引用的维度。

事实表通常和一个 企业的业务过程 紧密相关，由于一个企业的业务过程数据构成了其所有数据的绝大部分，因此事实表也通常占用了数据仓库存储的绝大部分。

比如对于某个超市来说，其 销售的明细数据 通常占其拥有数据的绝大部分且每天还在不断地累计和增长，而商品、门店、员工、设备等其他数据相对来说固定且变化不大。

事实表的一行对应一个度量事件

事实上，每行对应的度量事件可粗可细，比如对某个超市来说，在设计其维度模型时，表示顾客购买事件的事实表的一行即可以记录一张顾客的小票，也可以记录顾客小票的一个子项。

那么我们究竟应该到何种级别呢？

维度建模认为事实表应该包含最底层的、最原子性的细节，因为这样会带来最大的灵活性 维度建模中，细节的级别称为事实表的粒度，比如上文顾客购买行为事实表的粒度就应该是小票子项，而非小票。

事实表中最常用的度量一般是数值型和可加类型的

比如小票子项的销售数量、销售金额等，可加性对于数据分析来说至关重要，因为数据应用一般不仅检索事实表的单行数据，而往往一次性检索数百、数千乃至百万行的事实，并且处理这么多行的最有用的和最常见的事就是将它们加起来，而且是从各个角度和维度加起来。

但事实表中的度量并不都是可加的，有些是半可加性质的，另一些则是非可加性质的

半加性事实是指仅仅某些维度可加，例如库存，可以把各个地方仓库的库存加起来，或者把一个仓库不同的商品加起来，但是很明显不能把一个仓库同一商品在不同时期的库存加起来。

银行的账户余额也是半可加事实的例子，可以把不同分行的账户余额加起来或者不同账户人的账户余额加起来，但是不能把不同月份的账户余额加起来。

非可加性事实则根本就不能相加的事实，比如商品的价格以及订单的状态等。

除了存储的事实外，事实表都会包含多个相关的外键

用于关联和连接相应的维度表。

例如，订单事实表会包含连接到商品表的商品外键、连接到会员表的买家外键、或者连接到门店表的门店外键等。

正是通过这些外键，才能进行各个角度的、各个维度的分析。

事实表根据粒度的角色划分不同，可分为事务事实表、周期快照事实表和累积快照事实表。

• 事务事实表用于承载事务数据，通常粒度比较低，例如产品交易事务事实、 ATM交易事务事实。
• 周期快照事实表用于记录有规律的、固定时间间隔的业务累计数据，通常粒度比较大，例如账户月平均余额事实表。
• 累积快照事实表用于记录具有时间跨度的业务处理过程的整个信息，通常这类事实表相对比较少见。

这里需要值得注意的是，在进行事实表的设计时，一定要注意 一个事实表只能有一个粒度，不能将不同粒度的事实建立在同一张事实表中。

维度表

维度表是维度建模的灵魂，通常来说，维度表设计得好坏直接决定了维度建模的好坏

维度表包含了 实表所记录的业务过程度量的上下文和环境，它们除了记录“5 个 W”等信息外，通常还包含了很多的描述字段和标签字段等。

维度表通常有多列或者说多个属性

实际应用中，包含几十甚至上百属性的维度表并不少见。维度表应该尽可能多地包括 些有意义的文字性描述，以方便下游用户使用。

维度属性是查询约柬条件（ SQL where 条件）、分组（ SQL group 语句）与报表标签生成的基本来源在查询与报表需求中， 属性用 by （按）这个单词进行标识。

维度属性在数据仓库中承担着一个重要的角色

由于它们实际上是所有令人感兴趣的约束条件与报表标签的来源，因此是数据仓库易学易用的关键。在许多方面，数据仓库不过是维度属性的体现而已。

数据仓库的能力直接与维度属性的质量和深度成正比 。

• 在提供详细的业务用语属性方面所花的时间越多，数据仓库就越好；
• 在属性列值的给定方面所花的时间越多，数据仓库就越好；
• 在保证属性列值的质量方面所花的时间越多，数据仓库就越好。

维度表是进入事实表的入口

丰富的维度属性给出了丰富的分析切割能力。维度给用户提供了使用数据仓库的接口， 最好的属性是文本的和离散的， 属性应该是真正的文字而不应是一些编码简写符号。

我们应该通过更详细的文本属性取代编码，力求最大限度地减少编码在维度表中的使用。

有时候在设计数据库时，并不能很确定从数据源析取出的一个数字型数据字段到底应该作为事实还是维度属性看待 ，通常可以这样来做出决定，即看字段是一个含有许多取值并参与运算的度量值（当事实看待），还是一个变化不多并作为约束条件的离散取值的描述（当维度属性看待）。

星形架构和雪花架构

在理解了事实表和维度表之后，接下来的问题就是如何组合它 在维度建模中，存在两种组合维度表和事实表的基本架构：星形架构和雪花架构。

当所有维度表直接连接到事实表时，整个组合的形状类似于星星，所以被称为星形架构。

星形架构是一种非规范化的结构，其数据存储存在冗余，比如考虑商品的维度表，其品牌信息在商品的每一行中都存在，包括其品牌 ID 、名称、品牌拥有者等。

通常很多商品的品牌都是一样的，所以在商品维度表中品牌的信息被重复存储了很多次，也就是存在冗余。

当有一个或者多个维度表没有直接连接到事实表，而是通过其他维度表连接到事实表上时，整个组合的形状就像雪花一样，这种架构被称为雪花架构。

雪花架构是对星形架构维度表的规范化，比如上述的商品表例子，在雪花架构中，其每一行仅存储品牌 ID ，而品牌的所有其他信息（包括品牌名称、拥有者、注册地等所有描述信息）都存储在单独的品牌维度表内。通过品牌 ID 这个外键，商品表可以间接获取到所有品牌描述信息。

雪花架构去除了数据冗余，节省了部分存储，但是也给下游用户的使用带来了不便

如下游用户需要分析品牌的销售额，必须自己先用订单表关联商品表，然后用商品表再关联品牌表。正是由于这一点，在维度建模的实际中， 雪花架构很少得到使用。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

)]

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！