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

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

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

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

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

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

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

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

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

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

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

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

维度表

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

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

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

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

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

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

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

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

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

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

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

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

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

星形架构和雪花架构

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

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

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

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

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

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

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

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

有时候简单的方案是最美的、最有力的，也是最有效的

基于星形架构的维度建模就是这种情况 。星形架构牺牲了部分存储的冗余，但是带来了使用上的极度便捷，也使下游用户的使用和学习成本变得非常低。

即使是没有任何技术背景或者维度建模背景知识的业务人员，也很容易理解，更何况目前的存储成本极低，多出的这份存储开销相比后续每次的关联计算、用户使用和学习成本来说，是非常划算的。

星形架构中，每个维度都是均等的，所有维度表都是进入事实表的对等入口，用户可以从任一维度、任一维度属性或者任意多个维度组合、任意多个维度属性组合，方便地对数据进行过滤和聚合（汇总、均值、最大、最小等）操作，而且非常符合业务分析直觉。

业务是多变的，模型的设计必须能够经受住业务多变的需求。在实际设计中，可以通过添加新维度或者向维度表中加入维度属性来满足业务新视角的分析需求。

大多数情况下，数据仓库模型设计中都会采用星形架构，但是在某些特殊情况下 ，比如必须使用桥接表的情况下等，必须使用雪花架构。

维度建模一般过程

维度建模一般采用具有顺序的 个步骤来进行设计，即选择业务过程、定义粒度、确定维度和确定事实。

维度建模的这 个步骤贯穿了维度建模的整个过程和环节，下面逐一介绍。

1. 选取业务过程

业务过程即企业和组织的业务活动，它们一般都有相应的源头业务系统支持。

对于一个超市来说，其最基本的业务活动就是用户收银台付款；对于一个保险公司来说，最基本的业务活动是理赔和保单等 。当然在实际操作中，业务活动有可能并不是那么简单直接 ，此时昕取用户的意见通常是这一环节最为高效的方式。

但需要注意的是，这里谈到的业务过程并不是指业务部门或者职能。模型设计中，应将注意力集中放在业务过程而不是业务部门，如果建立的维度模型是同部门捆绑在一起的，就无法避免出现数据不一致的情况（如业务编码、含义等）。 因此，确保数据一致性的最佳办法是从企业和公司全局与整体角度，对于某一个业务过程建立单一的、一致的维度模型。

2. 定义粒度

定义粒度意味着对事实表行实际代表的内容和含义给出明确的说明，粒度传递了事实表度量值相联系的细节所达到的程度的信息。其实质就是如何描述事实表的单个行。

典型的粒度定义包括：

• 超市顾客小票的每一个子项；
• 医院收费单的明细子项；
• 个人银行账户的每一次存款或者取款行为；
• 个人银行账户每个月的余额快照；

对于维度设计来说，在事实表粒度上达成一致非常重要，如果没有明确的粒度定义，则不能进入后面的环节。

在定义粒度过程中，应该最大限度地选择业务过程中最为原子性的粒度，这样可以带来后续的最大灵活度，也可以满足业务用户的任何粒度的分析需求。

3. 确定维度

定义了粒度之后，相关业务过程的细节也就确定了，对应的维度就很容易确定。正如前文所述。

维度是对度量的上下文和环境的描述

通过维度，业务过程度量与事实就会变得丰富和丰满起来。对于订单来说，常见的维度会包含商品、日期、买家、卖家、门店等。

而每一个维度还可以包含大量的描述信息，比如商品维度表会包含商品名称、标签价、商品品牌、商品类目、商品上线时间等。

4. 确定事实

确定事实通过业务过程分析可能要分析什么来确定。定义粒度之后，事实和度量一般也很容易确定，比如超市的订单活动，相关的度量显然是销售数量和销售金额。

在实际维度事实设计中，可能还会碰到度量拆分的问题，比如超市开展单个小票满 100减 10 元的活动，如果小票金额超过 10 元，这 10 元的优惠额如何分配到每一个小票子项实际设计中，可以和业务方具体讨论并制订具体的拆分分配算法。

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

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

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

14523419787)]

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

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

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