【读书笔记】阿里巴巴大数据实践：事实表设计（第11章）

本文链接：https://blog.csdn.net/xiaoyangyangxiong/article/details/134349047

第11章事实表设计

一句话评论：“事实” 是数仓建模的核心，几乎所有数仓动作的最终目的就是从不同维度、角度对“事实”进行计算，以此进行数据监控、洞察和预测，本章将讲述事实表理论基础和阿里巴巴的设计实践。

1 事实表基础

（1）事实表特性

度量的类型：可加/半可加/不可加
事实表的类型：事务事实表/周期快照/累计快照

（2）设计原则

尽可能多的事实
相关的事实
分解维可加性的事实
声明粒度
事实的单位一致
null处理（零值填充）
维度退化

（3）设计方法

step1：选择业务过程及确定事实表的类型。业务过程常常是一个动词，例如“买家下单”、“买家付款”等。若选择“买家付款”这一业务过程，则确定事实表为“单事物事实表”。
step2：声明粒度。尽量选择最细级别的原子粒度。
step3：确定维度。声明粒度，意味着确定了主键，再据此选择相关的维度字段即可，例如主键确定为【子订单号】，则相关的维度有买家、卖家、商品、收货人、订单时间等。
step4：确定事实。“过程的度量是什么”，与该过程相关的所有事实，例如支付金额、邮费、优惠金额。ps.注意将“优惠金额”分解为可加的事实（可以按子订单金额比例分摊？）。
step5：冗余维度。提高使用效率。

2 事务事实表

（1）单事务事实表

对每个业务过程设计一个事实表，也是Kimball维度建模理论所提倡的。例如，对于【买家下单】和【买家支付】：分别构建事实表，每个事实表只记录一个业务过程，优点是便于理解。

（3）多事务事实表

将多个事实放在同一个事实表中，同一个事实表包含多个业务过程。具体有两种设计方法：
- ①使用不同的事实字段，例如淘宝交易事务事实表，包括下单、支付、完结成功三个业务过程。适合粒度一致、维度相差不大、但度量差异较大的业务过程。
- ②使用同一个事实字段，但增加一个业务过程标签字段，例如淘宝收藏商品事务事实表，包括添加收藏和删除收藏2个业务过程。适合粒度一致、度量较为相似、维度几乎完全一致的业务过程。

（4）父子事实的处理

特别地，可以通过分摊父订单的金额将所有业务过程的度量全部带进淘宝交易事务事实表中。包括下单数量、商品价格、子订单折扣、下单分摊比例等。

（5）事实的设计准则

完整性（尽可能多）
一致性（例如，下单商品数量和商品价格可以计算出下单金额，但下单金额、下单有效金额度量仍要保留，以保持一致性）
事实可加性（注意保留将不可加的事实分解为可加的，例如利润率等不可加，但事实表中仍要保留计算该利润率的可加性度量，即利润和成本金额）

3 周期快照事实表

当需要一些状态度量时，事务事实表的效率就比较低了。例如，账户余额、买卖家星级、商品库存、卖家累计交易额等。
快照事实表在确定的时间间隔对实体的度量进行抽样，这样可以很容易的研究实体的度量值，而不必聚集长期的事务历史。

（1）快照事实表的特性

粒度：事务事实表的粒度可以用多种方式表达，但快照事实表的粒度通常以多个维度形式声明。
密度：事务事实表是稀疏的，有交易产生时才会增加记录；快照事实表时稠密的，即使没有交易产生，也会产生一条记录。
可加性：事务事实表中的事实完全时可加的，但快照事实表将至少包含一个用来展示半可加性质的事实。例如每天记录的【历史至当日的下单金额】不可加，但可以计算一些平均值。

（2）设计快照事实表

单维度的快照事实表：
- step1 确定粒度，采样周期为每天，针对卖家、买家、商品、类目、地区等维度进行采样的快照事实表。
- step2 确定状态度量，例如淘宝卖家历史至今汇总事实表，包括历史至当日下单金额、历史至当日支付金额、历史至当日浏览PV等度量。
混合维度的快照事实表：与单维度的区别是，每天的采样周期针对多个维度进行采样，例如卖家+买家维度。
单维度和混合维度的快照事实表都可以从事务事实表汇总产出，另一种产出方式是，直接使用操作型系统的数据作为周期快照事实表的数据源进行加工，比如淘宝卖家信用分、卖家DSR事实表等：
- 卖家信用分事实表：在操作型系统中根据好（1分）中（0分）差评（-1分）计算，数仓每天直接使用操作型系统计算好的数据
- 卖家DSR事实表：DSR是指”与描述相符“、”服务态度“和”物流服务“，1-5分，也是在操作型系统中计算好。
全量快照事实表：粒度为每天针对每一条评论采样，维度就是评论本身，每一条拼接就是表的最细粒度。确定状态度量为无，即设计为无事实的事实表，更多的关注评价本身。
注意：
- 事务与快照成对设计：事务事实表和快照事实表通常成对出现，相互补充。
- 附加事实：有需要的话可以附加上一个采样周期的状态度量。
- 周期到日期度量：历史截至当日、自然月截至当日、卖家财年截至当日、季度至今、财年至今等。

4 累计快照事实表

（1）设计过程

step1 选择业务过程。因为想要研究买家下单、买家支付、卖家发货和买家确认收货这4个业务过程之间的时间间隔，所以累计快照事实表将关注这4个环节，比事务事实表多一个”卖家发货“的环节。
step2 确定粒度。假如将粒度定位”子订单“的级别，那么对于每一条子订单（实例）在逻辑控制事实表中只会有一条记录，其业务过程中的变更将通过存量记录更新来实现。
step3 确定维度。选择与4个业务过程相关的维度即可，例如买家、卖家、店铺、类目、发货地区、收获地区等维度。
step4 确定事实。选择与4个业务过程相对应的事实即可，例如下单金额、支付金额、支付对应的折扣、邮费等。
step5 退化维度。由于分布式数据库的表关联成本较高，所以将各维度中常用属性退化到事实表中，将提高下游使用数据的效率。

（2）特点

实体的某一实例（就是某一行记录）会定期更新，而事务事实表中实体的某一实例插入后就不会再更新。
多业务过程日期。累计快照事实表适合具有明确起止时间的短生命周期的实体，比如交易订单、物流订单，每一行记录（实例）都会具有多个里程碑日期，并且附带一个指示结束的日期属性。对于商品、用户等具有长生命周期的实体，一般采用周期快照事实表。

（3）特殊处理

非线性过程：交易流程一般是下单–支付–发货-确认收货，但并非所有的订单都会走这个流程，比如下单–支付–退款–卖家同意退款–退款成功，或者卖家不同意退款等情况。处理方法主要有：
- 针对业务关键里程碑构建全面的流程。对于没有支付或者发货的交易订单，相关业务过程的时间和事实置空，覆盖多种交情况。
- 循环流程的处理：如何解决一个业务过程存在多个里程碑日期的问题？比如买家申请退款–卖家不同意–买家再次申请–卖家不同意–…，究竟使用第一次申请的日期还是最后一次，决定权在商业用户手里？
多源过程：当数据来源与不同系统时，需要特别考虑粒度的问题。
业务过程取舍：比如在循环流程中，是否每一个申请日期和拒绝日期都要记录？并不是，要选取最关键的里程碑日期。

（4）物理实现

全量表。日期分区表，每天的分区存储昨天的全量和当天的增量数据full outer join的结果，保证每条记录的状态是最新的。适合全量数据较少的情况。
全量表的变化形式。每天的分区存储最近200天（存储在归档表中）的交易订单，需要保留多天的分区数据，存储消耗较大。
**以业务实体的结束时间分区。**每天的分区存放当天结束的数据，当天未结束的数据则一起存放在一个时间非常大的分区中（比如9999-12-31），这样存储浪费比较少。特别地，业务系统可能无法精确识别结束时间，需要对此进行特别处理（比如使用相关业务系统的结束标志、与前端业务系统确定口径等）。

5 三种事实表的比较

	事务事实表	周期快照事实表	累计快照事实表
时期/时间	事务时间是离散的	有规律的时间间隔	用于时间跨度不大但不确定的工作流
日期维度	事务日期	快照日期	涉及多个业务过程里程碑日期
粒度	每行是实体的一个事务（常用于汇总）	每行代表某时间周期的一个实体（常使用其截面）	每行包括一个实体的全生命周期
事实	事务事实	累计事实（常由事务事实汇总产生）	业务过程事实+时间间隔事实
事实表加载	插入新行	插入新行	插入新行+更新旧行
事实表更新	增量更新	增量更新	存量+增量更新