大数据之路—— 事实表设计

11.1 事实表基础

11.1.1 事实表特性

事实表作为数据仓库维度建模的核心，紧紧围绕着业务过程来设计。
<>
事实表中一条记录所表达的业务细节程度被称为粒度。两种方式表达：
一、维度属性组合所表示的细节程度。
二、所表示的具体业务含义。

作为度量业务过程的事实，一般为整形或者浮点型，有三种类型

• 可加性。按照与事实表关联的任意维度进行汇总
• 半可加性。按照特定维度
• 不可加性。比如汇率型事实

事实表三种类型: 事务事实表、周期快照事实表、累积快照表

• 事务事实表：类似于mysql binlog日志，每一次相关的 change 都记录下来，生成一行新的数据
• 周期快照事实表：只看某个业务过程，比如订单收货，数据按订单收货时间来切分，周期可以为每天、每月等。
• 累积快照事实表：要看整个生命周期的多个业务过程，描述过程开始和结束之间的关键性步骤事件，覆盖整个生命周期，比如：创建订单 → 买家付款 → 卖家发货 → 买家确认收货。粒度是一个订单一行数据，创建订单时间，付款时间，发货时间，收货时间，分别作为一个字段，便于计算不同业务过程的时间间隔

11.1.2 事实表设计原则

1. 尽可能包含所有与业务过程相关的事实，可有部分冗余
2. 只选择与业务过程相关的事实，订单的下单这个业务过程，事实表中不应该存在支付金额这个表示支付业务过程的事实；
3. 分解不可加性事实为可加的组件，订单的优惠率，应分解为订单原价金额与订单优惠金额两个事实存储在事实表中；
4. 在选择维度和事实之前必须先声明粒度，计事实表时，粒度定义越细越好，一般从最低级别的原子粒度开始；
5. 在同一个事实表中不能有多种不同粒度的事实，粒度为票一级时，票支付金额和折扣金额这两个事实的粒度为 “票级”，与定义的粒度一致，订单支付金额和票数，属于订单级细粒度，不能放一起，一个订单可以支付多张票
6. 事实的单位要保持一致，元或者分。
7. 对事实的null值要处理 ，用0代替null
8. 使用退化维度提高事实表的易用性，谨慎使用退化维表，目的主要是为了减少下游用户使用时关联多个表的操作，直接通过退化维度。实现对事实表的过滤查询、控制聚合层次、排序数据以及定义主从关系等。

11.1.3 事实的设计准则

1. 事实完整性。尽可能多的获取所有度量
2. 事实一致性。明确存储每一个事实以确保度量的一致性，总价=数量x价格，这个在事实表中统一计算可以保证一致性
3. 事实可加性。如利润率等，但是更多的存储的是各类可加性事实的度量

11.1.4 事实表设计方法

选择业务过程及确定事实表类型 --> 声明粒度 --> 确定维度 --> 确定事实 --> 冗余维度

第一步：选择业务过程及确定事实表类型

• 思路：详细分析需求，对业务的整个生命周期进行分析，明确关键的业务步骤，从而选择与需求有关的业务过程；业务过程通常使用行为动词表示业务执行的活动；

  

• 该订单流转的业务过程有 4 个：创建订单 → 买家付款 → 卖家发货 → 买家确认收货；

• 根据所选的业务过程确定事实表类型；如，选择 “买家付款” 这个业务过程，则事实表类型应为只包含买家付款这一个业务过程的 “单事务事实表”；选择了所有 4 个业务过程，并且需要分享各业务过程的时间间隔，则事实表类型应为包含了所有 4 个业务过程的 “累积快照事实表”

第二步：声明粒度

• 意味着精确定义事实表的每一行所表示的业务含义；明确的粒度能够确保对实表中行的意思的理解不会产生混淆，保证所有的事实按照同样的细节层次记录；
• 尽量选择最细级别的原子粒度，以确保事实表的应用具有最大的灵活性；

第三步：确定维度

• 完成了粒度声明，就意味着确定了主键，对应的维度组合以及相关的维度字段也可以确定了；
• 选择维度的原则：应该选择能够描述清楚业务过程所处的环境的维度信息；如，淘宝订单 “付款事务事实表” 中，粒度为 “子订单”，相关的维度有买家、卖家、商品、收货人信息、业务类型、订单时间等；

第四步：确定事实

• 选择与业务过程有关的所有事实，且事实的粒度要与所声明的事实表的粒度一致；

第五步：冗余维度

• 冗余常用维度字段（商品类目），方便下游用户使用（过滤查询、控制聚合）

淘宝交易事务事实表（确定维度）

11.2 事务事实表

任何类型的事件都可被理解为一种事务。如物流过程中的揽货、发货、签收等。
<>
事务事实表，即正对这些过程构建的一类事实表，用以跟踪定义业务过程的个体行为，提供丰富的分析能力，作为数据仓库原子的明细数据，
<>
事实表具有稀疏性质

11.2.1 单事务事实表

针对每个业务过程设计一个事实表，可以方便地对每个业务过程进行独立的分析研究。

在1688交易流程中选择下单和支付两个业务过程设计事务事实表，确定业务过程后，确定子订单粒度，选择买家、卖家、商品、父订单、收货地区维度，事实包含分摊金额、支付金额等。

每天的下单记录进入当天的下单事务事实中，每天的支付进入当天。事实表稀疏性质，只有当天数据才会进入当天的事实表中

11.2.2 多事务事实表

将不同的事实放到同一个事实表中，即同一个事实表包含不同的业务过程。

方式一：不同业务过程的事实使用不同的事实字段存放。如淘宝交易事务事实表

淘宝交易事务事实表采取将不同业务过程的事实使用不同事实字段进行存放。淘宝交易事务事实有下单、支付和成功完结三个业务过程。有相同的粒度（子订单），没把发货这个业务过程加进来是因为发货的粒度更细。常用的维度比较一致（卖家、买家、收发货地区）。

那么如何处理多个事实呢？需要包含下单度量、支付度量、成功完成度量。不同的事实使用不同的字段存放，如果不是当前业务过程的度量，用零值处理

如何在表中标记属于哪个业务过程呢？ 针对每个业务过程打一个标签，标记当天是否是这个业务过程，标签互不相关。

方式二：不同业务过的事实采用同一个事实字段进行存放，但是增加一个业务过程标签

收藏和加购物车是比较常见的行为，包含收藏和删除商品这两个业务过程，用户加上商品的粒度，用户和商品维度，无事实的事实表，一般用来统计收藏或删除的次数。

多事务多事实表选择那种方式更好呢？

• 当不同业务过程的度量比较相似，差异不大时，可以采用第二种多事务事实表的设计方式，但是在同一周期内会存在多条记录
• 差异较大时，可以选择第一种将不同业务过程的度量使用不同字段冗余到表中。但是度量字段零值多

11.2.3 两种事实表比较

• 业务过程。是否放到同一个事实表中，要分析不同业务过程之间的相似性和业务源系统。
• 维度和粒度。当业务过程的粒度相同，同时拥有相似的维度时可采用多事务事实表
• 事实。单事务事实表处理上比较灵活和方便。如果业务过程的事实比较多会出现事实表零值或空值字段较多的情况
• 下游业务使用。单事务事实表更容易被理解
• 计算存储成本。业务过程数据来源一个业务系统，有相同粒度和维度，且维度多而事实不多的情况，可以用多事务事实表，加工计算成本低，存储节约。

11.3 周期快照事实表

事务事实表能很好地跟踪一个事件，并对其进行度量，提供分析能力。当需要些状态度量时，如账户余额，商品库存等，需要聚集与之相关的事务才能进行识别计算。
<>
周期快照事实表（快照事实表）：在确定的时间间隔内对实体的度量进行抽样，能容易地研究实体的度量值，不需要聚集长期的事务历史

11.3.1 特性

• 用快照采样状态。以预定的间隔采样状态度量，这种间隔联合一个或多个维度，将被用来定义粒度，每行都将包含记录所涉及状态的事实。如交易状态数据（年初截止到当日下单金额、截止昨天的成交量），可以每天通过事务事实表进行聚集
• 快照粒度。快照需要采样的周期以及什么将被采样。快照周期可以按天、月、季度， 维度可能不止一个，卖家和类目都可以。
• 密度与稀疏度。关键区别，快照事实表无论当天是否有业务过程发生，都会记录一行，为了方便确定状态
• 半可加性。半可加性事实不能根据时间维度获得有意义的汇总结果，如卖家快照事实表，无法对每天的历史至今的下单金额进行汇总，没有有意义

周期快照事实表产出模式

1. 从事实事务表进行汇总产出
2. 使用操作型系统的数据作为数据源进行加工

11.3.2 设计步骤

1. 确定快照事实表的快照粒度
2. 确定快照事实表采样的状态度量

单维度的每天快照事实表

1. 确定粒度，采样周期为天，针对卖家、商品、类目等维度的快照事实表。比如淘宝卖家历史至今汇总事实表
2. 确定状态维度，针对这个粒度确定需要采样的状态度量，如历史截止至今的下单金额

混合维度的每天快照事实表

只是在每天采样周期上针对多个维度进行采样，如反映不同买家对于不同卖家的下单支付金额。

全量快照事实表, 特殊的周期快照事实表

11.3.3 注意事项

1. 事务与快照成对设计，互相补充，快照表可以在事务事实的表的基础上加工得到，丰富了星形模型，降低了下游分析成本
2. 附加事实，一般保存采样周期结束时的状态量，有时会附加上一个采样周期的状态量
3. 周期到日期度量，有些统计周期时卖家历史至今的状态度量，有些也会关注季度至今。

11.4 累计快照事实表

研究事件之间时间间隔的需求
<>
累计快照事实表解决的最重要的问题：统计不同业务过程之间的时间间隔，建议将每个过程的时间间隔作为事实放入事实表中

11.4.1 特性

1. 数据不断更新。对实体的某一实例定期更新，事实事务表中有三条记录不会更新，累计快照事实表只有一条记录不断
   

2. 多业务过程日期（典型特征），用于计算业务过程之间的时间间隔。适用于有明确起止时间的短生命周期的实体，对于长生命周期的实体（周期快照事实表更合适）。

3. 能够保存全量数据，在公共明细层保存全量数据，如保留历史截至当前的所有交易数据

11.4.2 设计步骤

1. 选择业务过程。在交易订单的流转过程中：买家下单、买家支付、卖家发货、买家确认。事务统计中只关注下单、支付、确认三个过程；在统计事件时间间隔的需求中，卖家发货也是关键。
2. 确认粒度。用于考察实体的唯一实例，子订单在表中只有一行记录，时间发生时进行更新。
3. 确定维度。与事务事实表相同，维度有卖家、买家、店铺等。业务过程的时间字段：下单时间、支付时间、发货时间等。（其中杂项维度一般是枚举值的组合，每个组合生成一个代理键。但是实际中存在很多非枚举值，可以直接使用自然键标识具体的维度值）
4. 确认事实。需要将各业务过程对应的事实均放入事实表中，比如下单金额。建议将每个过程的时间间隔作为事实放入事实表中
5. 退化维度。有时维表比事实表还大，将各维度的常用属性退化到事实表

11.4.3 特殊处理

有些非一般的流程：下单 -> 关闭订单 | 买家申请退款 -> 卖家同意退款 -> 退款达成

需要注意情况：

• 业务过程的统一，流程结束、实体消亡的标识：交易完成和交易结束。
• 针对业务关键里程碑构建全面的流程，
• 循环流程的处理，解决一个业务过程存在多个里程碑日期的问题。
• 多源过程，考虑事实表的粒度问题。
• 业务过程取舍，大量的业务过程会使模型复杂度增加，所以要选择关键的里程碑。

11.4.4 物理实践

第一种：全量表的形式，以日期分区。 每天分区存储昨天的全量数据和今天的增量数据合并的结果。适用于全量数据比较少的情况。

第二种：全量表的变化形式。主要针对事实表数据量很大的情况，预测较短生命周期的业务实体从产生到消亡的时间间隔。比如设计最近200天的交易订单累计快照事实表，每天的分区存储最近200天的交易订单，200天前的存储在归档表中。

第三种：以业务实体的结束时间分区。每天的分区存放当天结束的数据，设计一个时间非常大的分区（9999-12-31）存放截止至今未结束的数。可能存在极特殊情况，业务系统无法标识业务实体的结束时间，比如物流订单），依赖其他公司的数据，且是批量回传无法保证准确率。解决方法一：使用相关业务系统的业务实体的结束标志作为此系统的结束标志，如订单结束了物流也结束了。解决方法二：使用前端业务系统确认口径或使用归档策略，可以用定期的归档时间作为结束日期。

11.5 三种事实表比较

• 事务事实表记录的事务层面的事实，用于追踪业务过程的行为，保存的是最原子的数据，也称为原子事实表。数据粒度通常是每个事务一条记录。一旦事务被提交，事实表数据被插入，不能更改，只能增量更新。
• 周期快照事实表的日期维度通常记录时间段的终止日，是这个时间段内一些聚集事实值或状态度量。一旦插入不能更改，只能增量更新。
• 累积快照事实表用来跟踪实体的一系列业务过程的进展情况，通常有多个日期字段

11.6 无事实的事实表

不包含事实或者度量的事实表，虽然没有明确的事实，但可以用来支持业务过程的度量

• 第一种是事件类的，记录事件的发生。 比如日志类事实表，用户浏览日志
• 第二种是条件、范围或资格类的，记录维度与维度多对多之间的关系。

11.7 聚集型事实表

通过汇总明细粒度数据来获得改进查询性能的效果，将使用频繁的公用数据通过聚集进行沉淀，这类聚集汇总睡，被叫做公共汇总层。

11.7.1 基本原则

• 一致性。确保聚集星形模型中的维度和度量和原始模型中的一致

• 避免单一表设计。不要在同一个表中存储不同层次的聚集数据。是在不行，可以显式地加入数据层级列以示区别。比如按天和按月汇总的交易额用两列存放。

• 聚集粒度可不同。聚集值只关心所需要查询的维度，不需要保持与原始明细粒度数据一样的粒度

• 数据共有性。如果有某个维度的聚集常用于数据分析中，就需要沉淀到聚集表中

• 不垮数据域。数据域是在较高层次上对数据进行分类聚集的的抽象

• 区分统计周期。表的命名上要能说明数据的统计周期

• 当子类目对应的一级类目发生变化时，原先存在的、已经被汇总的数据要挑战，简单强力方式：删除并重新聚集

11.7.2 聚集的基本操作

第一步：确定聚集粒度。如果只关心商品的交易额，可以根据商品维度聚集数据。

第二步：确定一致性上钻。关心是按照月汇聚还是按天汇总。

第三步：确定聚集事实。可能有多个事实的度量，明确是哪些.