维度建模

1 维度建模关键概念

1.1 度量和环境

1.2 事实和维度

在维度建模中，度量称为事实，上下文和环境称为维度。

1.3 事实表

事实常以数值形式出现，而且一般都被大量文本形式的上下文包围着。这些文本形式的上下文描述了事实的“5个w”（when、where、what、who、why）信息
事实表的一行对应一个度量事件。
维度建模认为事实表应该包含最底层、最原子性的细节，因为这样会带来最大的灵活性。
事实表中最常用的度量一般是数值型和可加类型。但事实表的度量并非都是可加的，有些是半可加性质的，另一些则是非可加性质的。
除了存储的事实外，事实表都会包含多个相关的外键。
事实表根据粒度的角色划分不同，可分为事务事实表、周期快照事实表、累计快照事实表

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

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

1.4 维度表

维度表包含了事实表所记录的业务过程度量的上下文和环境，它们除了记录“5个w”等信息外，通常还包含了很多的描述字段和标签字段。
维度表通常有多列或者说多个属性。
维度表应该尽可能多地包括一些有意义的文字描述。
维度属性是查询约束条件（SQl where条件）、分组（SQL group语句）与报表标签生成的基本来源。
维度属性在数据仓库中承担着一个重要的角色。
维度表是事实表的入口。

如果不能确定从数据源取出的一个数字型数据字段到底应该作为事实还是维度属性看待。通常可以，看字段是一个含有许多取值并参与运算的度量值（当事实看待），还是一个变化不多并作为约束条件的离散值得描述（当维度属性看待）。

1.5 星型架构和雪花架构

组合维度表和事实表的基本架构

1.5.1 星型架构

所有维度表直接连接到事实表，整个组合的形状类似于星星。
星型架构是一种非规范化的架构，其数据存储存在冗余。
例如考虑商品的维度表，其品牌信息在商品的每一行中都存在，包括其品牌ID、名称、品牌拥有者等。通常很多商品的品牌都是一样的，所以在商品维度表中品牌的信息被重复存储了很多次，也就是存在冗余。

1.5.2 雪花架构

当有一个或者多个维度表没有直接连接到事实表，而通过其他维度表连接到事实表上。
雪花架构是对星型架构维度表的规范化。
比如上述的商品例子，在雪花架构中，其每行仅存储品牌ID，而品牌的所有其他信息（包括品牌名称、拥有者、注册地等所有描述信息）都存储在单独的品牌维度表内。通过品牌ID整个外键，商品表可以间接获取到所有品牌的描述信息。雪花架构去除了数据冗余，节省了部分存储，但是在使用过程中复杂度增加，给用户使用带来不方便。因此在维度建模的实际中，雪花架构很少使用到。

星型架构牺牲了部分存储的冗余，但是带来了使用上的极度便捷。现在存储成本极低，多出的存储开销相比后续每次的关联计算、用户使用和学习成本来说，是非常划算的。

2 维度建模一般过程

选择业务过程-》定义粒度-》确定维度-》确定事实

2.1 选取业务过程

业务过程即企业和组织的业务活动，它们一般都有相应的源头业务系统支持。
业务过程并不是指业务部门或者职能。如果建立的维度模型是同部门捆绑在一起的，就无法避免出现数据不一致的情况（如业务编码、含义等）。确保数据一致性的最佳办法是从企业和公司全局与整体角度，对于某一个业务过程建立单一的、一致的维度模型。

2.2 定义粒度

定义粒度意味着对事实表行实际代表的内容和含义给出明确的说明。其实质就是如何描述事实表的单个行。
如果没有明确的粒度定义，则不能进入后面的环节。如果在后面的环节中发现粒度的定义不够或者是错误，那么也必须返回这一环节重新定义粒度。
最大限度地选择业务过程中最为原子性的粒度，这样可以带来后续的最大灵活度

2.3 确定维度

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

2.4 确定事实

维度一般是名词，事实一般是动词。

3 维度表设计

3.1 维度变化

1、重写维度值

当一个维度值属性发送变化时，重写维度值，直接用新值覆盖旧值。该方法适用于维度建模中不需要保留此维度属性历史变化的情况，常用于订正或者维度属性改变无关紧要的场景。

2、插入新的维度行

插入新的维度行通过在维度表中插入新的行来保存和记录变化的情况。属性改变前的事实表行和旧的维度值关联，而新的事实表行和新的维度值关联。
这也给维度表用户带来了困惑，为什么查询一个会员会在维度表中发现多行记录？用户的使用和学习成本无疑增加了，而且数据开发人员对于维度变化的处理逻辑无疑变得复杂了。

3、插入新的维度列

这种方法通过新增一列

这三种方法，在大数据时代都不是完美的。

3.2 维度层次

维度层次指的是某个维度表中属性之间存在的从属关系问题。比如商品的类目可能是有层次的（一级类目、二级类目）

• 方法一：将所有维度层次结构全部扁平化、冗余存储到一个维度化表中
• 方法二：新建类目维度表，并在维度表中维护父子关系

我们常用第一种来处理维度的层级问题

3.3 维度一致性

可以采用共享同一个的维度表或者让其中一个维度表是另外一个维度表的子集等方式来保证一致性

3.4 维度整合和拆分

1、在实际整合中，同一个维度的整合需要考虑如下问题。

• 命名规范：要确保一致和统一
• 字段类型：统一整合为一个字段类型
• 字段编码和含义：编码及含义要整合为一致。实际中可能碰到商品状态A系统有3个，而B系统有四个的情况，此时需要和业务人员或者需求方共同讨论确定整合逻辑。

2、与整合相对的是拆分。
在维度建模理论中，处理拆分通常有两种处理办法。
1）建一个基础维度表，此基础维度表包含这些不同业务的共有属性，同时建立各自业务的单独维度表以包含其独特的业务属性。
2）拆分，即不合并，即各个业务差异独特性的业务各自建立完全独立的两个维度表，各自管理各自维度表和属性
实际操作中，通常倾向于拆分（即不合并）

3.5 维度其他

1、退化维度
退化维度在分析中通常用来对事实表行进行分组
2、行为维度
行为问题是基于过去维度成员的行为进行分组或者过滤事实的办法。行为维度即将事实转化为维度，以确保获得更多的分析能力。
3、角色维度
角色维度指的是一个事实表中多个外键指向同一个维度表。
当事实表和维度表存在上述多对一关系时，没有必要为维度表建立多个副本，只需要基于维度表建立多个视图即可。
4、杂项维度
一般由前台业务系统中的指示符或者标志字段组合而成。
通常的解决方案就是建立杂项维度，将这些字段建立到一个维度表中，在事实表中只需要保存一个外键。
5、微型维度
微型维度的提出主要是为了解决快变超大维度问题。
以客户维度为例，如果维度表中有数百万、千万甚至以亿计的记录，而且这些记录中的字段又经常变化，则将这样的维度表一般称为快变超大维度。
解决的方法是，将分析频率比较高或者变化频率比较大的字段提取出来，建立一个单独的维度表。这个单独的维度表就是微型维度表。
6、多值维度和属性
当事实表的一行涉及维度表的多行时，会产生多值维度。同样。维度表的一行需要获取单一属性的多个值时，也会产生多值维度。
通常有两种办法可以解决多值维度或者多值属性。
1）扁平化多值维度：在事实表中引入多列。此外考虑到业务的可变性，可同时添加预留字段
2）桥接表：在事实表和多值维度表之间新增一个表，这个表起到桥接作用

4 深入事实表

事实表的主要类型：事实事实表、快照事实表、累计快照事实表

4.1 事务事实表

事务事实表通常用于记录业务过程事件，而且是原子粒度的事件。事务事实表中的数据在事务事件发送后产生，数据的粒度通常是每个事务一条记录。一旦事务被提交，事实表数据被插入，数据就不再进行改变。通过事务事实表存储单次业务事件/行为的细节，以及存储与事件相关的维度细节，用户即可单独或者聚合分析业务事件和行为。

在事实表的设计中，一个常见的原则是只存放比例的分子和分母，一般不将比例的计算放入事实表中。

4.2 快照事实表

所谓周期快照事实表，是指间隔一定的周期对业务的状态进行一次拍照并记录下来的事实表。
周期快照事实表的周期通常需要和业务方共同确定，最常见的周期是天、周和月等。
周期快照事实表中的事实一般是半可加的，如某个商品的库存可以跨商品、仓库等相加，但是明显在时间上相加是没有意义的。

4.3 累计快照事实表

累计快照事实表非常适用于具有工作流或者流水线形式业务的分析，这些业务通常涉及多个时间节点或者有主要里程碑事件，而累计快照事实表正是从全流程角度对其业务状态拍照。

5 大数据维度建模实践改良

5.1 事实表

最初的维度建模设计主要是出于存储的成本以及处理的性能考虑。大数据时代下，各种分布式存储和计算技术的发展，存储、成本以及性能等不再是关键，所以在维度建模理论反规范化思想的基础上，可以更进一步地把常用的维度属性沉淀在事实表中。以存储的冗余为代价，换来下游的使用便捷以及多次关联计算开销。
当然，反规范化也不是把所有的维度属性都放在事实表中，应该将业务使用最为频繁和常用的维度属性沉淀在事实表中。

5.2 维度表

用维度表快照的方式来处理缓慢变化维，实际上也是用存储的冗余开销换来了缓慢变化维复杂逻辑的消除以及下游使用的便捷。例如，将维度表的快照每天存储一份。
维度层次的扁平化也就是在单一维度表中用冗余字段来存储所有层次，维度有5个层次就用5个层次的字段，有10个层次就用10个层次的字段，存储和成本不是问题。
当然，也可以通过大字段的方式来解决，比如把多值属性组装成键值对放在一个长字符串内。