数仓(六)：维度建模、步骤： 事实表&维度表设计
一、维度建模 基本方法、设计步骤：
1、4步骤维度设计过程
1、选择业务过程
业务过程是组织完成的操作型活动。例如注册用户、下订单，开具发票，付款、处理索赔等。
- 业务过程通常用行为动词表示。因为他们通常表示业务执行的活动。与之相关的维度描述与某个业务过程时间关联的描述环境。
- 业务过程通常由某个操作系统支撑，例如账单或购买系统。
- 业务过程建立或获取关键性能度量。有时这些度量事业务过程的直接结果，度量从其他时间获得。分析人员总是想通过过滤器和约束不同组合，来审查和评估这些度量。
- 业务过程通常由输入激活，产生输出度量。在许多组织中，包含一系列过程，他们即是某些过程的输出，也是某些过程的输入。即一系列过程产生一些列的事实表。
业务过程事件建立或获取性能度量，并转换为事实表中的事实。多数事实表关注某一业务过程的结果。过程的选择是非常重要的，因为过程定义了特定的设计目标以及对粒度，维度，事实的定义。每个业务过程对应企业数据仓库总线矩阵的一行。
2、声明粒度
先举个例子：对于用户来说，一个用户有一个身份证号，一个户籍地址，多个手机号，多张银行卡，那么与用户粒度相同的粒度属性有身份证粒度，户籍地址粒度，比用户粒度更细的粒度有手机号粒度，银行卡粒度，存在一对一的关系就是相同粒度。为什么要提相同粒度呢，因为维度建模中要求我们，在同一事实表中，必须具有相同的粒度，同一事实表中不要混用多种不同的粒度，不同的粒度数据建立不同的事实表。并且从给定的业务过程获取数据时，强烈建议从关注原子粒度开始设计，也就是从最细粒度开始，因为原子粒度能够承受无法预期的用户查询。但是上卷汇总粒度对查询性能的提升很重要的，所以对于有明确需求的数据，我们建立针对需求的上卷汇总粒度，对需求不明朗的数据我们建立原子粒度。
3、确认维度
维度围绕某一业务过程事件所涉及的谁、什么、何处、何时、为什么、如何等背景。维度表包含BI应用所需要的用于过滤及分类事实的描述性属性。牢牢掌握事实表的粒度，就能够将所有可能存在的维度区分开。当与给定的事实表关联时，任何情况都能保证维度表唯一值。
常见的维度实例包括日期、产品、客户、雇员、地区、机构等。在选择每个维度时，应该列出所有具体的、文本类型的属性以充实每个维度表。
数仓工具箱中告诉我们牢牢掌握事实表的粒度，就能将所有可能存在的维度区分开，并且要确保维度表中不能出现重复数据，应使维度主键唯一
4、确认用于度量的事实
事实表是用来度量的，基本上都以数量值表示，事实表中的每行对应一个度量，每行中的数据是一个特定级别的细节数据，称为粒度。维度建模的核心原则之一是同一事实表中的所有度量必须具有相同的粒度。这样能确保不会出现重复计算度量的问题。有时候往往不能确定该列数据是事实属性还是维度属性。记住最实用的事实就是数值类型和可加类事实。所以可以通过分析该列是否是一种包含多个值并作为计算的参与者的度量，这种情况下该列往往是事实。
明显属于不同粒度的事实必须放在不同的事实表中。典型事实是可加性数值，例如订货数量是以美元计的成本总额等。
5.确定命名规范
在详细设计之前，为DW/BI系统制定规范，主要包含源系统、主题、业务术语、报表，物理设计命名、调度任务、文档方面的规范。
6.编写详细设计映射文档
详细设计文档包括从源系统到维度模型的每个数据层的物理映射文档。
7.审查和验证模型
详细设计文档出来后，要和业务用户和团队成员进行评审，记录下来评审过程中的问题，形成问题清单。
8.完成设计文档
最后确定设计文档，进行下一步的ETL开发。
维度建模优点：
- 结构清晰
- 便于理解
- 便于应用，应用开发
- 提高查询性能，一个表聚合出结果，少join
- 便于扩展
维度模型设计流程图
数据建模 ：概念建模+逻辑建模+物理建模 概念模型->逻辑模型->物理模型
概念建模：概念模型
主要内容：客户交流，了解需求，形成实体，如销售业务中的“客户”和“定单”，还有就是“商品”，“业务员” 等实体。在概念建模阶段，只需要关注实体即可，不需要关注任何实现细节。（此时可以不包含属性，只有实体集，联系集的分析结构）
逻辑建模：逻辑模型
主要内容：将概念模型具体化，即要实现概念模型所描述的东西，需要哪些具体的功能和具体的信息，这就到了需求分析的细化阶段。还以销售业务为例：
- “客户” 信息基本上要包括：单位名称，联系人，联系电话，地址等属性；
- “商品”信息基本上要包括：名称，类型，规格，单价等属性；
- “定单”信息基本上要包括：日期 和时间属性。
- 并且“定单”要与“客户”，“业务员”和“商品”明细关联。
这个阶段的产物是可以在数据库中生成具体的表及其他的数据库对象（如主键、外键、索引、约束、视图、存储过程等）。
物理建模：物理模型
主要内容：针对逻辑模型的结果，在具体的物理介质上实现，如采用何种数据库，然后在数据库上以SQL的形式将数据库建立起来。不仅如此，针对业务需求，我们也可能做如数据拆分，读写分离等设计。
二、事实表
事实表存储了从业务活动或事件提炼出来的性能度量，它主要包含维度表的外键和连续变化的可加性数值或半可加事实。事实表产生于业务过程中而不是业务过程的描述性信息。它一般是行多列少，占了数据仓库的90%的空间。在维度模型中也有表示多对多关系的事实，其他都是维度表。
事实表粒度
事实表的粒度是产生事实行的度量事件的业务定义。粒度确定了事实表的业务主键， 事实表的所有度量值必须具有相同的粒度。
1、事实表类型——事务事实表、周期快照事实表、累计快照事实表
贴源数据层ODS、统一数仓层DW(细分为明细数据层DWD和汇总数据层DWS)、标签数据层TDM、应用数据层ADS。
其中，DW层采用维度建模的思想，包含维度表与事实表。涉及到常用的事实表如下：
| 特点 | 事务事实 | 周期快照 | 累计快照 |
| 时间/周期 | 离散的事务发生时间点 | 以有规律的间隔产生快照，每天 | 时间跨度不确定的变化的流程节点 |
| 粒度 | 每行代表一个交易事件 | 每个快照周期加其他维度一行 每行代表一个时间周期 |
每次管道事件一行(事件整个流程) 每行代表一个业务周期 |
| 日期维度 | 事务日期、业务日期 | 快照日期、时期末 | 管道事件中每个里程碑节点涉及多日期， 多个业务过程的完成日期 |
| 事实 | 交易活动、事务度量 | 时间间隔内累积度量、状态度量、 时间周期内的绩效 |
管道事件度量 限定多个业务阶段内的绩效 |
| 事实表稀疏性 | 与事务活动有关 | 稠密 | 与管道事件有关 |
| 事实表更新 | 不更新 |
不更新 |
新事件产生时更新 |
| 事实表加载 |
新增 |
新增 |
新增和修改 |
1.事务事实表
个人理解：类似于mysql binlog日志，每一次相关的 change 都记录下来，生成一行新的数据
记录的是事务层面的事实，保存的是最原子的数据，也叫做“原子事实表”。事务事实表中的数据在事务事件发生后产生，数据的粒度通常是每个事务一条记录。
一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。
1.1 明细事实表（单事件事实表，流程事实表）： 一般位于DWD层，该层事实表设计不进行聚合、汇总等动作，仅做数据规范化，数据降维动作，同时数据保持业务事务粒度，确保数据信息无丢失。
-
单事件事实表：
1.更方便跟踪业务流程细节数据，针对特殊的业务分析场景比较方便和灵活，数据处
理上也更加灵活；
2.不方便的地方就是数仓中需要管理太多的事实表，同时跟踪业务流转不够直观； -
流程事实表
能够更直观的跟踪业务流转和当前状态，流程事实集中，方便大部分的通用分析应
用场景，由于和业务侧的数据模型设计思路一致，也是目前最常用的事实表设计；但是细节
数据跟踪不到位，特殊场景的分析不够灵活；
1.2 聚合事实表：相对于明细事实表，聚合事实表通常是在明细事实表的基础上，按照一定的粒度粗细进行的汇总、聚合操作，它的粒度较明细数据粒度粗，同时伴随着细节信息的丢失。聚合事实表一般位于DWS层，聚合事实表的数据来源可以是两种明细事实表中的任一种。
- 通用汇总层：封装底层计算逻辑，做通用汇总，避免上层直接访问下层明细数据，应用广泛
- 日粒度：数据范围一般为T-1天的数据
- 周期性积累：用于周期性分析，数据来源于通用汇总层，或者日粒度
- 历史积累：历史数据积累的大表，用于用户画像，特征提取，经营分析等场景，计算比较耗时。
2.周期快照事实表
周期事实表就是每行都带有时间值字段，代表周期，通常时间值都是标准周期，如某一天，某周，某月等。粒度是周期，而不是个体的事务，也就是说一个周期快照事实表中数据可以是多个事实，但是它们都属于某个周期内。
周期快照事实表以具有规律性的、可预见的时间间隔来记录事实，时间间隔如每天、每月、每年等等。以一定的周期间隔来记录事实，它是在事务事实表之上建立的聚集表，记录的事实是这一段时间的聚集事实值。 典型的例子如销售日快照表、库存日快照表等。
例如购物车，有加减商品，随时都有可能变化，但是我们更关心每天结束时这里面有多少商品，例如每天或者每月的销售额，或每月的账户余额等。方便我们后期统计分析。
周期快照事实表的日期维度通常是记录时间段的终止日，记录的事实是这个时间段内一些聚集事实值。事实表的数据一旦插入即不能更改，其更新方式为增量更新。
它是按照良好的时间周期间隔(每天，每月)来捕捉业务活动的执行情况，一旦装入事实表就不会再去更新，它是事务事实表的补充，而非替代品。
3.累积快照事实表
个人理解：累计快照事实表用于跟踪业务事实的变化。要看整个生命周期的多个业务过程，比如：创建订单 → 买家付款 → 卖家发货 → 买家确认收货。粒度是一个订单一行数据，创建订单时间，付款时间，发货时间，收货时间，分别作为一个字段，便于计算不同业务过程的时间间隔。
它用于描述业务过程中某个不确定时间跨度里的活动，它随着业务活动的发生会不断的更新。
举例来说，订货日期、预定交货日期、实际发货日期、实际交货日期、数量、金额、运费 
3、事实表设计 8 大原则
原则 1：尽可能包含所有与业务过程相关的事实
- 分析哪些事实与业务过程相关，是设计过程中非常重要的关注点；
- 在事实表中，尽量包含所有与业务过程相关的事实，即使存在冗余，由于事实通常是数字型，存储开销不会太大；
原则 2：只选择与业务过程相关的事实
- 如，订单的下单这个业务过程，事实表中不应该存在支付金额这个表示支付业务过程的事实；
原则 3：分解不可加性事实为可加的组件
- 如，订单的优惠率，应分解为订单原价金额与订单优惠金额两个事实存储在事实表中；
原则 4：在选择维度和事实之前必须先声明粒度
- 粒度用于确定事实表中一行所表示业务的细节层次，决定了维度模型的扩展性；
- 每个维度和事实必须与所定义的粒度保持一致；
- 设计事实表时，粒度定义越细越好，一般从最低级别的原子粒度开始；
- 因为原子粒度提供了最大限度的灵活性，可以支持无法预期的各种细节层次的用户需求；
原则 5：在同一个事实表中不能有多种不同粒度的事实
- 疑问：怎么判断不同事实的粒度是否相同？
- 粒度为票一级；（实际业务中，一个订单可以同时支付多张票）
- 票支付金额和票折扣金额，两个事实的粒度为 “票级”，与定义的粒度一致；
- 订单支付金额和订单票数，两个事实的粒度为 “订单级”，属于上一层订单级数据，与 “票级” 事实表的粒度不一致，且不能进行汇总；
- 如果，以订单金额和订单票数这两个维度汇总总金额和总票数，会造成大量的重复计算；
原则 6：事实的单位要保持一致
- 如，订单金额、订单优惠金额、订单运费这 3 个事实，应该采用统一的计量单位，统一为元或者分，以方便使用；
原则 7：对事实的 null 值要处理
- 原因：在数据库中，null 值对常用数字型字段的 SQL 过滤条件都不生效；如，大于、小于、等于、大于或等于、小于或等于；处理：用 0 代替 null ；
原则 8：使用退化维度提高事实表的易用性
- 事实表中存储各种类型的常用维度信息，较少下游用户使用时关联多个表的操作；
- 通过退化维度，可以实现对事实表的过滤查询、控制聚合层次、排序数据、定义主从关系等；
- 易用性：对事实表，更较少关联操作、过滤查询、控制聚合层次、排序数据、定义主从关系等；
- 在 Kimball 的维度建模中，通常按照星形模型的方式设计，通过事实表的外键关联专门的维表，这种方式来获取维度，谨慎使用退化维表；这与大数据领域的事实表设计不一样；
- 思路：通过增加冗余存储，减少计算开销，提高使用效率；
三、维度表
维度表是对业务过程的上下文描述，主要包含代理键、文本信息和离散的数字。它是进入事实表的入口，丰富的维度属性给出了对事实表的分析切割能力，它一般是行少列多。如果属性值是离散的，用于过滤和标记的，就放到维度表里，如果是属性值是连续取值，用于计算的，就放到事实表中。
1、维度表类型
1.0稳定维度表
部分维度表的维度是在维度表产生以后，属性是稳定的，无变化的。eg：时间维度，区域维度，
2.0缓慢变化维度表（拉链表）
维度数据会随着时间发生变化，变化速度非常缓慢。eg：电商平台的用户维度表，用户的收货地址是缓慢变化的。
1.类型1
字段值发生变化时覆盖原来的值。
2.类型2
字段值发生变化时会新增一行，重新分配代理键，每一行添加开始日期，结束日期，版本号，是否当前值。
3.类型3
每条记录会新增一列来标识变化前的值，发生变化时，把旧值放到新增的列中，把新值覆盖旧值。
4.混合类型
把上面的三种类型混合来使用。
日期维
它是数据仓库必须有的维度，包含日期，日期所属的周，月，季度，年等信息。
角色维
相同的维度表在维度模型中扮演不中的逻辑角色，一般通过创建视图来表示。
杂项维
如果每个属性值都很少，可以把这些维度的组合起来生成一个维度表。
支架维
如果维度之间是一对多的关系或区别于原维度的多个描述性维度属性，可以建雪花型支架维度。
多值维度桥接维
如果二个维度表是多对多的关系，可以使用多值维度设计。
微型维
一个大型维有些属性变化比较频繁，把这些属性单独生成一个微型维度表。
缩小维
它是维度表的一个子集或部分属性。
查找维
系统里代码表里维度信息。
层次维
有些维度表是有层次结构的，可以通过视图生成树形结构的维度表。
手工维护的维表
有些数据不在业务系统里，需要业务用户手工维护的维度表。
2、维度整合
1）垂直整合：
不同的来源表包含相同的数据集，只是存储的信息不同时，进行垂直整合。" “比如淘宝会员在源系统中有多个表，如会员基础信息表、会员扩展信息表、淘宝会员等级信息表、天猫会员等级信息表，这些表都属于会员相关信息表，依据维度设计方法，尽量整合至会员维度模型中，丰富其维度属性。”
2.水平整合：
不同的来源表包含不同的数据集，不同子集之间无交叉，也可以存在部分交叉。此时才用水平整合。” “比如针对蚂蚁金服的数据仓库，其采集的会员数据有淘宝会员、 1688 会员、国际站会员、支付宝会员等，是否需要将所有的会员整合到一个会员表中呢？如果进行整合，首先需要考虑各个会员体系是否有交叉，如果存在交叉，则需要去重；如果不存在交叉，则需要考虑不同子集的自然键是否存在冲突，如果不冲突，则可以考虑将各子集的自然键作为整合后的表的自然键；另一种方式是设置超自然键，将来源表各子集的自然键加工成一个字段作为超自然键。在阿里巴巴，通常采用将来源表各子集的自然键作为联合主键的方式，并且在物理实现时将来源字段作为分区字段。”
3、维度拆分
3.1水平拆分
3.1.1何时需要拆分？
由于维度分类的不同而存在的特殊的维度属性，可以通过水平拆分的方式来解决此问题。
3.1.2两种方案
方案一：将维度的分类实例化成不同的维度，同时在主维度表中保存公共属性；
方案二：维护单一维度，包含所有可能的属性。
3.2.3两个拆分依据
“依据一：是维度的不同分类的属性差异情况。
当维度属性随类型变化较大时，将所有可能的属性建立在一个表中是不切合实际的，也没有必要这样做，此时建议采用方案一” “比如在阿里巴巴数据仓库维度体系中，依据此方法，构建了商品维度、航旅商品维度等。公共属性一般比较稳定，通过核心的商品维度，保证了核心维度的稳定性；通过扩展子维度的方式，保证了模型的扩展性。”
“依据二：是业务的关联程度。
两个相关性较低的业务，耦合在一起弊大于利，对模型的稳定性和易用性影响较大。也要进行拆分，直接拆分成两个维度。” “比如在阿里巴巴数据仓库维度体系中，对淘系商品和 1688 商品构建两个维度。虽然淘系和1688 在底层技术实现上是统一的，但属于不同的BU，业务各自发展；在数据仓库层面，淘系和1688属于不同的数据集市，一般不会相互调用，业务分析人员一般只针对本数据集市进行统计分析。”
3.2 垂直拆分
为何做垂直拆分 “某些维度属性的来源表产出时间较早，而某些维度属性的来源表产出时间较晚；或者某些维度属性的热度高、使用频繁，而某些维度属性的热度低、较少使用；
或者某些维度属性经常变化，而某些维度属性比较稳定。在“水平拆分”中提到的模型设计的三个原则同样适合解决此问题。”
出于扩展性、产出时间、易用性等方面的考虑，设计主从维度。主维表存放稳定、产出时间早、热度高的属；从维表存放变化较快、产出时间晚、热度低的属性。 “比如在阿里巴巴数据仓库中，设计了商品主维度和商品扩展维度。其中商品主维度在每日的1 :30 左右产出，而商品扩展维度由于有冗余的产出时间较晚的商品品牌和标签信息，在每日的 3:00 左右产出。”
————————————————
4、退化维度、维度退化，
退化维度就是将维度退回到事实表中，宽表。因为有时维度除了主键没有其他内容，虽然也是合法维度键，但是一般都会退回到事实表中，减少关联次数，提高查询性能
DWD有简单的维度信息冗余到事实表，
DWS汇总数据，指标的维度退化，采取更多的宽表化手段构建公共指标数据层，提升公共指标的复用性，减少重复加工
ADS应用层宽表，维度冗余的
四、大宽表的优点与缺点？维度退化
优点：
- 提高查询性能
- 快速响应
- 方便使用，降低使用成本：单表查询即可，不用复杂join
- 构建公共指标数据层，提升公共指标的复用性，减少重复加工。
- 提高用户满意度
缺点：
- 数据冗余
- 另外就是灵活性差，就比如说线上业务表结构变更，宽表模式改造量也比较大
- 开发宽表为了避免宽表重复迭代，我们应该去了解业务全流程，得需要知道需扩展哪些维度，沉淀哪些指标，这样就流程会比较长，特别是有些业务快速迭代的话，就有点捉襟见肘
企业数据仓库总线架构
企业价值链
每家机构都有一个关键业务过程组成的潜在价值链，这个价值链确定机构主体活动的自然逻辑流程。数据仓库建设就是围绕着价值链建立一致化的维度和事实。
数据总线
这些业务过程都会共用一些维度，形成了企业数据仓库的总线，一致化维度和事实看作一组标准的应用程序连接口，可以看作一个数据仓库的总线架构。它可以将新的业务过程引入数据仓库中，该业务过程从总线获得动力，并且和其他已经存在的业务过程和谐共存。
数据总线矩阵
矩阵的每一行对应都对应机构中的一个业务过程，每一列都和一个业务维度相对应，用叉号填充显示的是和每一行相关的列。业务过程应该先从单个数据源系统开始，然后再进行多数据源的合并。
企业数据仓库总线矩阵是DW/BI系统的一个总体数据架构，提供了一种可用于分解企业数据仓库规划任务的合理方法，开发团队可以独立的，异步的完成矩阵的各个业务过程，迭代地去建立一个集成的企业数据仓库。
一致性维度和事实
企业数据仓库应该建立一个一致性维度和事实，而不是为每个部门建立维度和事实。
一致性维度
具有一致的维度关键字，一致的属性列名称，一致的属性定义和一致的属性值。一致性维度要么是统一的，要么是维度表的一个子集。
一致性事实
指每个度量在整个数据仓库中都是唯一的统计口径，为了避免歧义，一个度量只有唯一的业务术语。
八、问题：事实表指标（如金额、数量等）出现变化时
处理方式一般有：
1、直接更新事实表原记录以及相应的聚集表（如月度、年度聚集表）。
这种处理方式，
- A.把事实表的变化蔓延到相关的聚集表上，极端情况下，可能会改变所有的聚集表。
- B.客户会发现先前打印的报表，现在再浏览的时候数据出现不一致。
2、直接更新事务表原记录，重新执行后面表的脚本，保持数据一致；
3、不更新事实表原记录，在事实表中插入一条新数据，统计期别维度，新增一条冲销记录用于冲销原记录和一条新记录。如在2012年12月，需把2011年10月的金额从1000变为2000，则在统计期别为201212的事实表中产生一笔-1000的记录和一笔2000的记录。这种方式处理稍显复杂，但可以保持数据一致。
4、对于不是频繁修改的事实表，采用缓慢变化维的思想。
如果事务型，频繁变化。则采用：新建另外一张修改事实表，下单，退单，修改 等
数仓模型优化-如何判断一个数据模型的好坏
