系列文章目录

2.2 维度建模
2.2.1 维度表
2.2.2 事实表
2.2.3 维度建模的三种模型
3. 建模设计
3.1 ODS层
3.2 DWD层
3.3 DWS层
3.4 ADS层

---

前言

本文主要详解了维度建模和flink车联网项目的建模设计。由于篇幅过长，后续章节：数据开发

---

2.2 维度建模

数据仓库领域的另一位大师——Ralph Kimball 倡导的建模方法为维度建模。维度模型将复杂的业务通过事实和维度两个概念进行呈现。事实通常对应业务过程，而维度通常对应业务过程发生时所处的环境。

2.2.1 维度表

维度表：一般是对事实的描述信息。每一张维表对应现实世界中的一个对象或者概念。如商品信息表，每一行表示一种商品的具体特征和概念（小米手机，128G，白色，4999元）。

 维表的特征：

1. 维表的范围很宽（具有多个属性、列比较多）
2. 跟事实表相比，行数相对较小：通常< 10万条
3. 内容相对固定：编码表

2.2.2 事实表

事实表中的每行数据代表一个业务事件（下单、支付、退款、评价等）。“事实”这个术语表示的是业务事件的度量值（可统计次数、个数、金额等）。
每一个事实表的行包括：具有可加性的数值型的度量值、与维表相连接的外键，通常具有两个和两个以上的外键。
如订单表（小明，小米手机，4999元，优惠券200元，下单时间2020-05-21 09：00）。

 事实表的特征：

1. 非常的大
2. 内容相对的窄：列数较少（主要是外键id和度量值）
3. 经常发生变化，每天会新增加很多

 事实表分类：

1. 事务型事实表
   事务事实表是维度建模事实表中最为常见、使用最为广泛的事实表。
   事务事实表通常用于记录业务过程的事件，而且是原子粒度的事件。事务事实表中的数据在事务事件发生之后，数据的粒度通常是每个事务一条记录。一旦事务被提交，事实表数据被插入，数据就不再进行更改。比如用户注册，用户访问记录，用户评论等。
   通过事务事实表存储单次业务事件/行为的细节，以及存储与事件相关的维度细节，用户即可以单独或者聚合分析业务事件和行为。
2. 周期型快照事实表
   所谓周期快照事实表，是指间隔一定的周期对业务的状态进行一次拍照并记录下来的事实表。最常见的例子是银行账户余额、销售库存等。
   与事务事实表的稀疏性不同（这里的稀疏性是相对的），周期快照事实表通常被认为是稠密的。因此事务事实表只有事务发生才会记录，但是周期快照则必须捕获当前每个实体的状态。
   比如，某个商品如果某天没有销售，那么这个商品不会存在于当天的事务事实表中的，但是为了记录其库存情况，即使没有销售行为，也必须再周期快照事实表中对其进行拍照。
   周期快照事实表的周期通常需要和业务方共同确定，最常见的周期是天、周和月等。
   周期快照事实表中的事实一般是半可加的，如商品的库存可以跨仓库、跨品类累加的，但是明显在时间上相加是没有意义的。
3. 累计型快照事实表
   累计快照事实表非常适用于具有工作流或者流水线形式业务的分析，这些业务通常涉及多个时间节点或者有主要的里程碑事件，而累计快照事实表正是从全流程角度对其业务状态的拍照。例如，数据仓库中可能需要存储订单从下订单开始，然后接单，然后到达出发点，然后订单完成，然后支付等各个业务阶段的时间点数据来跟踪订单声明周期的进展情况。当这个业务过程进行时，事实表的记录也要不断更新。
   

2.2.3 维度建模的三种模型

星型模型：事实表周围只有一层维度表。星型模型是非规范化的设计，在设计与建设过程中不受关系数据库范式规则的约束，简单的关联逻辑便可以支持高度复杂的维度组合需求，在查询性能方面具有明显的优势。

雪花模型：维度表有多个层级。雪花模型是将一个维度规范化成多个关联的表，规范化的过程就是将维表中冗余的数据进行解耦从而分离出一些新表，以减少数据冗余。

雪花模型和星型模型的区别：雪花模型会对维度表进一步细分和规范化。

星座模型：也被称作星系模型，有多张事实表。星座模型是由星型模型延伸而来，星型模型是基于一张事实表而星座模型是基于多张事实表，并且共享维度表信息，这种模型往往应用于数据关系比星型模型和雪花模型更复杂的场合。

星型模型和星座模型区别：星座模型有多个事实表，而星型模型只有一个事实表。

如何选择建模类型：
星型还是雪花取决于性能优先还是灵活优先，实际企业开发中不会绝对选一种，根据实际情况灵活组合，甚至并存。但整体而言，倾向于维度更少的星型，尤其是Hadopp生态，减少Join即可减少MR的shuffle，性能差距大。关系型数据库则依靠强大的主键索引。
如果业务比较复杂，则都会发展成星座模型。
2.2.4 小结
维度建模从需求出发，重点关注快速完成需求分析，围绕性能和易理解性构建模型，以事实表与维度表的形式重新组织数据。

 在OLAP应用中主要有两大优势：

1. 前期建模成本较低，从业务需求出发，快速迭代；
2. 查询性能高，通过数据冗余降低查询的复杂度。

 主要的劣势表现在：

1. 通过降低规范化、尽可能多的冗余维度信息在一张“大宽表”之中，使整个模型臃肿，当遇到不断变化的业务时，数据的维护成本大；
2. 由于数据的大量冗余，如何保证数据一致性也是一个问题，无疑增加了模型的管理成本。

因此，从整体来说维度建模的开发和使用成本较低，但是维护成本较高，比较适合在接近业务分析的数据集市层、分析层来使用。

维度建模源于Kimball提出的总线式的自下而上（DM-DW）的数据仓库架构，范式建模源于Inmon提出的集线器的自上而下（EDW-DM）的数据仓库架构。两种建模方法对比如下：

3. 建模设计

本项目ODS层使用关系建模开发，DW层和ADS层采用维度建模开发。

3.1 ODS层

 数据类型：用户行为数据、业务数据
 规划处理：

1. 保持数据源不做修改，起到备份数据的作用
2. 数据采用压缩，减少磁盘存储空间
3. 创建分区表，防止后续的全表扫描

3.2 DWD层

DWD层需构建维度模型，采用星型模型，呈现的状态为星座模型。

维度建模一般按照以下四个步骤：选择业务过程→声明粒度→确认维度→确认事实

1. 选择业务过程
   在业务系统中，挑选业务方感兴趣的业务线，比如下单业务，支付业务，退款业务，物流业务，一条业务线对应一张事实表。
2. 声明粒度
   数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别。
   声明粒度意味着精确定义事实表中的一行数据表示什么，应该尽可能选择最小粒度，以此来应各种各样的需求。
   典型的粒度声明如下：
   订单事实表中一行数据表示的是一个订单中的一个商品项。
   支付事实表中一行数据表示的是一个支付记录。
3. 确定维度
   维度的主要作用是：描述业务的事实情况。主要表示的是“谁，何处，何时”等信息。
   确定维度的原则是：后续需求中是否要分析相关维度的指标。例如，需要统计什么时间下的订单多，哪个地区下的订单多，哪个用户下的订单多。需要确定的维度就包括：时间维度、地区维度、用户维度。
4. 确定事实
   此处的“事实”一词，指的是业务中的度量值（次数、个数、件数、金额，可以进行累加），例如订单金额、下单次数等。
   在DWD层，以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的明细层事实表。事实表可做适当的宽表化处理。
   事实表和维度表的关联比较灵活，但是为了应对更复杂的业务需求，可以将能关联上的表尽量关联上。

3.3 DWS层

DWD层是以业务过程为驱动，DWS层以及ADS都是以需求为驱动。
通过以下案例进行阐述。
 问题引出：如果想统计一个司机一天的跑了多少单，挣了多少钱怎么算
 处理办法：
如果只是单单计算这一次，就可以直接将订单表进行处理后聚合，然后计算单量和金额。但是在企业中，很多指标都是要重复计算的。比如计算了天维度的单量和金额，还有计算周和月维度的单量和金额。如果每次都从明细去算，显然不现实，即浪费计算资源又容易造成数据不一致。针对上述场景，可以设计一张订单宽表(DWS)，从DWD表进行轻度聚合得到，主要包含订单相关的指标，比如金额、数量、时间等，以后如果再有类似的指标计算都可以直接从这张表拿，从而减少重复计算，提高计算速度。

 总结：

1. 需要建哪些宽表：以需求为主，需要分析哪些业务，需要分析哪些实体。
2. 宽表里面的字段：一方面站在不同维度的角度去看事实表，另一方面关注事实表聚合后的度量值。

3.4 ADS层

这一层是最贴近需求的，基本的开发思路就是使用DWS和DWD的中间表，进行计算，得到需求需要的数据。其实也是基于星型模型来做的。