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个层次的字段，存储和成本不是问题。
当然，也可以通过大字段的方式来解决，比如把多值属性组装成键值对放在一个长字符串内。

维度建模方法

一、前言

本人学习《数仓工具箱》的学习总结，纯学习分享，供大家参考。

二、经典数仓架构理论

围绕着维度建模，那就不得不了解，早期的数据仓库构架方法。这里介绍一下两个经典的数仓架构理论。

2.1、Kimball模式

2.2、Inmon模式

参考：深入对比数据仓库模式：Kimball vs Inmon

三、维度建模步骤

3.1、设计企业服务总线

需要调查业务过程以及业务过程所涉及的公共维度。比如零售商从订单到库存到零售这些业务过程中所涉及到的公共维度用一个矩阵进行统计，梳理这些的过程中，也对总体业务流程有概要的了解。

3.2、选择业务过程

业务过程通常用行为动词表示，如：获取订单、开具发票、接收付款，注册账号、处理索赔等。维度建模是紧贴业务的，所以必须以业务为根基进行建模，那么选择业务过程，顾名思义就是在整个业务流程中选取我们需要建模的业务，根据运营提供的需求及日后的易扩展性等进行选择业务。比如商城，整个商城流程分为商家端，用户端，平台端，运营需求是总订单量，订单人数，及用户的购买情况等，我们选择业务过程就选择用户端的数据，商家及平台端暂不考虑。业务选择非常重要，因为后面所有的步骤都是基于此业务数据展开的。

3.3、声明粒度

先举个例子：对于用户来说，一个用户有一个身份证号，一个户籍地址，多个手机号，多张银行卡，那么与用户粒度相同的粒度属性有身份证粒度，户籍地址粒度，比用户粒度更细的粒度有手机号粒度，银行卡粒度，存在一对一的关系就是相同粒度。为什么要提相同粒度呢，因为维度建模中要求我们，在同一事实表中，必须具有相同的粒度，同一事实表中不要混用多种不同的粒度，不同的粒度数据建立不同的事实表。并且从给定的业务过程获取数据时，强烈建议从关注原子粒度开始设计，也就是从最细粒度开始，因为原子粒度能够承受无法预期的用户查询。但是上卷汇总粒度对查询性能的提升很重要的，所以对于有明确需求的数据，我们建立针对需求的上卷汇总粒度，对需求不明朗的数据我们建立原子粒度。

3.4、确认维度

维度表是作为业务分析的入口和描述性标识，所以也被称为数据仓库的“灵魂”。在一堆的数据中怎么确认哪些是维度属性呢，如果该列是对具体值的描述，是一个文本或常量，某一约束和行标识的参与者，此时该属性往往是维度属性，牢牢掌握事实表的粒度，就能将所有可能存在的维度区分开，并且要确保维度表中不能出现重复数据，应使维度主键唯一

3.5、确认事实

可以通过回答“业务过程的度量是什么？”这一问题来确定事实。事实表是用来度量的，基本上都以数量值表示，事实表每行的数据是一个特定级别的细节数据，称为粒度。维度建模的核心原则之一是同一事实表中的所有度量必须具有相同的粒度。这样能确保不会出现重复计算度量的问题。有时候往往不能确定该列数据是事实属性还是维度属性。记住最实用的事实就是数值类型和可加类事实。所以可以通过分析该列是否是一种包含多个值并作为计算的参与者的度量，这种情况下该列往往是事实。

四、维度建模设计技巧

4.1、使用代理键代替自然键作为维度表主键

自然键：就是充当主键的字段本身具有一定的含义，是构成记录的组成部分，比如学生的学号，除了充当主键之外，同时也是学生记录的重要组成部分。

代理键：就是充当主键的字段本身不具有业务意义，只具有主键作用，比如自动增长的ID。

使用代理键的优点：

• 为数据仓库缓冲源系统的变化。例如：账号闲置一年就会重新分配给新用户，如果用账号作为数据主键，则原账号数据就会被覆盖丢失；如果用代理键作为维度主键，那么可以对账号的变化赋予新的代理键以作区分。
• 集成多个源系统。可以通过引用映射表将多个自然键连接成一个公共的代理键。

4.2、缓慢变化维度处理方法

参考：建模之旅：你以为的SCD

4.3、树状结构数据处理

有些涉及多层级数据处理，比如对财务各级组织的相关指标计算。这就需对多层级数据处理。如下图，模拟的是集团中的组织架构，举例：怎么计算7和7所有的下属机构对应的月营收收入？

这里可以建立多层级组织关系桥接表，如下图。通过这个桥接表来筛选出7的所有下属机构。

维度模型是数据仓库领域大师Ralph Kimball 所倡导，以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，所以它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。性能

维度建模是 数据仓库/商业智能 项目成功的关键，为何这么说，由于无论咱们的数据量从GB到TG仍是到PB，虽然数据量愈来愈大，可是数据展示要得到成功，就必须创建在简单性的基础之上，而维度建模就是时刻考虑如何可以提供简单性，以业务为驱动，以用户理解性和查询性能为目标。学习

维度建模：维度建模是专门应用于分析型数据库、数据仓库、数据市集建模的方法。数据市集能够理解为一种“小型的数据仓库”
维度建模指导咱们在数据仓库中如何建表大数据

维度建模分为两种表：事实表和维度表设计

1. 事实表：必然存在的一些数据，像采集的日志文件，订单表，均可以做为事实表
   特征：是一堆主键的集合，每一个主键对应维度表中的一条记录，客观存在的，根据主题肯定出须要使用的数据
2. 维度表：维度就是所分析的数据的一个量，维度表就是以合适的角度来建立的表，分析问题的一个角度：时间、地域、终端、用户等角度

维度建模的三种模式

1. 星形模式：以事实表为中心，全部的维度表直接连在事实表上，最简单最经常使用的一种

2. 雪花模式：雪花模式的维度表能够拥有其余的维度表，这种表不易维护，通常不推荐使用

3.星座模型：基于多张事实表，并且共享维度信息，即事实表之间能够共享某些维度表

维度建模怎么建

咱们知道事实表，维度表，星形模型，星座模型这些概念了，可是实际业务中，给了咱们一堆数据，咱们怎么拿这些数据进行数仓建设呢，数仓工具箱做者根据自身60多年的实际业务经验，给咱们总结了以下四步，请务必记住！

数仓工具箱中的维度建模四步走：

请牢记以上四步，无论什么业务，就按照这个步骤来，顺序不要搞乱，由于这四步是环环相扣，步步相连。下面详细拆解下每一个步骤怎么作

一、选择业务过程
维度建模是紧贴业务的，因此必须以业务为根基进行建模，那么选择业务过程，顾名思义就是在整个业务流程中选取咱们须要建模的业务，根据运营提供的需求及往后的易扩展性等进行选择业务。好比商城，整个商城流程分为商家端，用户端，平台端，运营需求是总订单量，订单人数，及用户的购买状况等，咱们选择业务过程就选择用户端的数据，商家及平台端暂不考虑。业务选择很是重要，由于后面全部的步骤都是基于此业务数据展开的。

二、声明粒度
先举个例子：对于用户来讲，一个用户有一个身份证号，一个户籍地址，多个手机号，多张银行卡，那么与用户粒度相同的粒度属性有身份证粒度，户籍地址粒度，比用户粒度更细的粒度有手机号粒度，银行卡粒度，存在一对一的关系就是相同粒度。为何要提相同粒度呢，由于维度建模中要求咱们，在同一事实表中，必须具备相同的粒度，同一事实表中不要混用多种不一样的粒度，不一样的粒度数据创建不一样的事实表。而且从给定的业务过程获取数据时，强烈建议从关注原子粒度开始设计，也就是从最细粒度开始，由于原子粒度可以承受没法预期的用户查询。可是上卷汇总粒度对查询性能的提高很重要的，因此对于有明确需求的数据，咱们创建针对需求的上卷汇总粒度，对需求不明朗的数据咱们创建原子粒度。

三、确认维度
维度表是做为业务分析的入口和描述性标识，因此也被称为数据仓库的“灵魂”。在一堆的数据中怎么确认哪些是维度属性呢，若是该列是对具体值的描述，是一个文本或常量，某一约束和行标识的参与者，此时该属性每每是维度属性，数仓工具箱中告诉咱们紧紧掌握事实表的粒度，就能将全部可能存在的维度区分开，而且要确保维度表中不能出现重复数据，应使维度主键惟一

四、确认事实
事实表是用来度量的，基本上都以数量值表示，事实表中的每行对应一个度量，每行中的数据是一个特定级别的细节数据，称为粒度。维度建模的核心原则之一是同一事实表中的全部度量必须具备相同的粒度。这样能确保不会出现重复计算度量的问题。有时候每每不能肯定该列数据是事实属性仍是维度属性。记住最实用的事实就是数值类型和可加类事实。因此能够经过分析该列是不是一种包含多个值并做为计算的参与者的度量，这种状况下该列每每是事实。

事实表种类

事实表分为如下6类：

1. 事务事实表
2. 周期快照事实表
3. 累积快照事实表
4. 无事实的事实表
5. 汇集事实表
6. 合并事实表

简单解释下每种表的概念：

• 事务事实表

表中的一行对应空间或时间上某点的度量事件。就是一行数据中必须有度量字段，什么是度量，就是指标，好比说销售金额，销售数量等这些可加的或者半可加就是度量值。另外一点就是事务事实表都包含一个与维度表关联的外键。而且度量值必须和事务粒度保持一致。

• 周期快照事实表

顾名思义，周期事实表就是每行都带有时间值字段，表明周期，一般时间值都是标准周期，如某一天，某周，某月等。粒度是周期，而不是个体的事务，也就是说一个周期快照事实表中数据能够是多个事实，可是它们都属于某个周期内。

• 累计快照事实表

周期快照事实表是单个周期内数据，而累计快照事实表是由多个周期数据组成，每行汇总了过程开始到结束之间的度量。每行数据至关于管道或工做流，有事件的起点，过程，终点，而且每一个关键步骤都包含日期字段。如订单数据，累计快照事实表的一行就是一个订单，当订单产生时插入一行，当订单发生变化时，这行就被修改。

• 无事实的事实表

咱们以上讨论的事实表度量都是数字化的，固然实际应用中绝大多数都是数字化的度量，可是也可能会有少许的没有数字化的值可是还颇有价值的字段，无事实的事实表就是为这种数据准备的，利用这种事实表能够分析发生了什么。

• 汇集事实表

汇集，就是对原子粒度的数据进行简单的聚合操做，目的就是为了提升查询性能。如咱们需求是查询全国全部门店的总销售额，咱们原子粒度的事实表中每行是每一个分店每一个商品的销售额，汇集事实表就能够先聚合每一个分店的总销售额，这样汇总全部门店的销售额时计算的数据量就会小不少。

• 合并事实表

这种事实表遵循一个原则，就是相同粒度，数据能够来自多个过程，可是只要它们属于相同粒度，就能够合并为一个事实表，这类事实表特别适合常常须要共同分析的多过程度量。

维度表技术

1. 维度表结构

维度表谨记一条原则，包含单一主键列，但有时因业务复杂，也可能出现联合主键，请尽可能避免，若是没法避免，也要确保必须是单一的，这很重要，若是维表主键不是单一，和事实表关联时会出现数据发散，致使最后结果可能出现错误。

维度表一般比较宽，包含大量的低粒度的文本属性。

1. 跨表钻取

跨表钻取意思是当每一个查询的行头都包含相同的一致性属性时，使不一样的查询可以针对两个或更多的事实表进行查询

钻取能够改变维的层次，变换分析的粒度。它包括上钻/下钻：

上钻（roll-up）：上卷是沿着维的层次向上汇集汇总数据。例如，对产品销售数据，沿着时间维上卷，能够求出全部产品在全部地区每个月（或季度或年或所有）的销售额。

下钻（drill-down）：下钻是上钻的逆操做，它是沿着维的层次向下，查看更详细的数据。

1. 退化维度

退化维度就是将维度退回到事实表中。由于有时维度除了主键没有其余内容，虽然也是合法维度键，可是通常都会退回到事实表中，减小关联次数，提升查询性能

1. 多层次维度

多数维度包含不止一个天然层次，如日期维度能够从天的层次到周到月到年的层次。因此在有些状况下，在同一维度中存在不一样的层次。

1. 维度表空值属性

当给定维度行没有被所有填充时，或者当存在属性没有被应用到全部维度行时，将产生空值维度属性。上述两种状况，推荐采用描述性字符串代替空值，如使用 unknown 或 not applicable 替换空值。

1. 日历日期维度

在日期维度表中，主键的设置不要使用顺序生成的id来表示，可使用更有意义的数据表示，好比将年月日合并起来表示，即YYYYMMDD，或者更加详细的精度。