【累积快照事实表】

针对淘宝交易，设计了淘宝交易下单／支付／确认收货事务事实表，
用于统计下单／支付／确认收货的子订单数、 GMV 等。
但仍然有很多需求，此事务事实表很难满足，比如统计买家下单到支付的时长、买家支付到卖家发货的 时长、买家从下单到确认收货的时长等。如果使用事务事实表进行统计，则逻辑复杂且性能很差。
对于类似于研究事件之间时间间隔的需求，
采用累积快照事实表可以很好地解决。

11.4.1 设计过程

对于累积快照事实表，其建模过程和事务事实表相同，适用于维度
建模的步骤。下面详述淘宝交易累积快照事实表的设计过程，并讨论和
事务事实表的设计差异。

第一步：选择业务过程。

在“事实表基础”一节中讲解了淘宝交易订单的流转过程，
主要有四个事件，即买家下单、买家支付、卖家发货、买家确认收货业务过程。对于这四个业务过程，在事务统计中只关注下单、支付和确认收货三个业务过程；而在统计事件时间间隔的需求中，
卖家发货也是关键环节。所以针对淘宝交易累积快照事实表，我们选择
这四个业务过程。

第二步：确定粒度。

在“事务事实表”中提到，对于淘宝交易，业
务需求一般是从子订单粒度进行统计分析，所以选择子订单粒度。淘宝
交易事务事实表的粒度也是子订单，但通常对于子订单的每个事件都会
记录 行，对于多事件事实表，如果子订单同一周期发生多次事件则记
录一行；而对于累积快照事实表，用于考察实体的唯一实例，所以子订
单在此表中只有一行记录，事件发生时，对此实例进行更新。

第三步：确定维度。

与事务事实表相同，维度主要有买家、卖家、
店铺、商品、类目、发货地区、收货地区等。四个业务过程对应的时间
段，格式为日期＋时间，分别为下单时间、支付时间、发货时间、确
认收货时间，对应于日期维表，图 1.24 中未标识。在实际使用时会使
用视图或 SQL 别名的方式表示四个日期角色维度，类似于发货地区维
度和收货地区维度。
在交易订单表中，存在很多与订单相关的属性，
如订单类型、子类型、支付状态、物流状态、 attributes、options 等。
对于类似的属性字段，无法归属到已有的商品等维度中，所以新建杂项维度存放。在数据仓库
建模理论中，杂项维度无自然键，一般是枚举值的组合 ，对于每个组合
生成一个代理键。但在实际建模中，存在很多非枚举值 ，且对于每个订
都不相同，如订单的 attributes options 属性。所以实际中杂项维度
设计时，也可以直接使用自然键标识具体的维度值，如图 .24 中所示
的子订单维度和父订单维度。

第四步：确定事实。

对于累积快照事实表，需要将各业务过程对应的事实均放人事实表中。
比如淘宝交易累积快照事实表，包含了各业务过程对应的事实，
如下单对应的下单金额，支付对应的折扣、邮费和支付金额，
确认收货对应的金额等。
累积快照事实表解决的最重要的问题是统计不同业务过程之间的时间间隔，
建议将每个过程的时间间隔作为事实放在事实表中。
在淘宝交易累积快照事实表建模中，
由于每个过程的时间间隔计算逻辑简单，
因此并未加人事实表中，
如图 1.25 所示。

第五步：退化维度。

在大数据的事实表模型设计中，更多的是考虑
提高下游用户的使用效率，降低数据获取的复杂性，减少关联的表数量。
一方面，存储成本降低了，而相比之下 CPU 成本仍然较高；另一方面，
在大数据时代，很多维表比事实表还大，如淘宝几十亿的商品、几亿的
买家等，在分布式数据仓库系统中，事实表和维表关联的戚本很高。所
以在传统的维度模型设计完成之后，在物理实现中将各维度的常用属性
退化到事实表中，以大大提高对事实表的过滤查询、统计聚合等操作的
效率，具体详情不再赘述。

11.4.2 特点
1、数据不断更新
事务事实表记录事务发生 时的状态，对于实体的某一实例不再更新，
而累积快照事实表则对实体的某一实例定期更新。以淘宝交易为例，
表11.3、11.4 和11.5 通过实例展示了事务事实表的情况，假设采用多事务事实表：对于 orderl 订单， 2015-11-12 支付后，产生新的支付
记录， 2015-11-1 的数据不会更新。截至 2015-11-13 ，买家确认收货后，
共产生3条记录。

1. 多业务过程日期
   累积快照事实表适用于具有较明确起止时间的短生命周期的实体，
   比如交易订单、物流订单等，对于实体的每 个实例，都会经历从诞生
   到消亡等一系列步骤。对于商品、 用户等具有长生命周期的实体，
   一般采用周期快照事实表更合适。
   累积快照事实表的典型特征是多业务过程日期，用于计算业务过程
   之间的时间间隔 。但结合阿里 巴巴数据仓库模型建设的经验，对于累积
   快照事实表，还有一个重要作用是保存全量数据。对于淘宝交易，需要
   保留历史截至当前的所有交易数据，其中 种方式是在 ODS 层保留和
   源系统结构完全相同 的数据 但由于使用时需要关联维度，较为麻烦，
   所以在公共明细层需要保留一份全量数据，淘宝交易累积快照事实表就
   承担了这样的作 一一存放加工后的事实，并将各维度常用属性和订单
   杂项维度退化到此表中。通常用于数据探查、统计分析、数据挖掘等。

11.4.3 特殊处理
1 非线性过程
如前面章节所提到的，淘宝交易流程一般经过如下四个业务过程
下单→支付→发货→确认收货
但并不是所有的交易都会走此流程。比如买家下单之后不支付，可
以自己关闭订单或者经过一段时间后系统自动关闭订单。此时交易流程
如下：
下单→关闭订单
买家下单并支付之后，可以申请退款，卖家同意后，交易关闭。此
时交易流程如下：
下单→支付→关闭订单
在特殊情况下，流程可能会回转。比如在退款过程中，正常流程可
能是
买家申请退款→卖家同意退款→退款达成
或者
买家 申请退款→卖家不同意退款→退款关闭
但由于买家和卖家之间未达成协议，卖家不同意买家的退款，此时
流程可能是
买家申请退款→卖家不同意退款→买家申请退款→卖家不同意退
…一直到退款达成或关闭
针对非线性过程，处理情况主要有以下几种
( 1 ）业务过程的统
比如流程结束标志的统 ，最开始设计交易累积快照事实表时，
交易完成作为结束标志；进一步了解业务之后，发现交易关闭也是交易
结束的 个分支，所以将交易结束作为流程结束、实体消亡的标志，
括交易完成和交易结束两种情况。
(2 ）针对业务关键里程碑构建全面的流程
比如淘宝交易，全流程可能是下单→支付→发货→确认收货。对于
没有支付或没有发货的交易订单，全流程仍然可以覆盖，相关业务过程
的时间字段和事实置空。
(3 ）循环流程的处理
主要问题是解决一个业务过程存在多个里程碑日期的问题。使用业
务过程第 次发生的日期还是最后一次发生的日期，决定权在商业
户，而不是设计或开发人员。
2. 多源过程
针对多业务过程建模时，业务过程可能来自于不同的系统或者来
于不同的表，其对于累积快照事实表的模型设计没有影响，但会影响
ETL 开发的复杂程度。对于淘宝交易累积快照事实表，除了上述提到的
下单→支付→发货→确认收货流程，假设需要关注交易子订单退款业务
或者物流业务， 时会涉及交易、售后、物流 个业务源系统。
退款业务流程如下
下单→支付→买家申请退款→卖家同意退款 退款达成→交易关闭