B. 数据仓库 --- 建模技术 --- 事实表 --- 针对事实表的时间跟踪

B. 数据仓库 — 建模技术 — 事实表 — 针对事实表的时间跟踪

概述

存在三种基本事实表粒度：事务级别、周期快照和累积快照。个别情况下，在事实表中增加行有效时期、行截止日期和当前行标识是非常有用的，与采用类型2缓慢变化维度，在事实行有效时获取时间的方式类似。尽管不太常用，但该模型能够解决诸如缓慢变化库存平衡的场景，其中频繁周期快照可以在每个快照上加载同一行。

事务事实表

• 步骤 — 交易事务设计事实表
  • 业务分析：交易事务包括下单、支付、发货、完结四个业务过程
  • 确定粒度：同一个订单中可以包含多个在商品，每个商品对应一个子订单。在上述四个业务过程中下单、支付、完结选择子订单作为粒度，而发货业务过程包含物流信息，以父订单为粒度
  • 确定维度：卖家、买家、商品、商品类目、发货地区、收货地区、父订单一级杂项维度
  • 确定事实：每个业务过程有自己的事实，如下单过程的下单金额、下单数量；支付过程的支付金额、积分金额等
  • 冗余维度：为了提升效率，把常用的维度荣誉到事实表
• 实现方式
  • 单事务事实表：一个业务过程一张事实表，方便对每个业务做独立分析
  • 将不同业务过程放在同一个事实表中，又可以分为不同业务过程使用不同事实字段和不同业务过程使用相同事实字段两种
• 要点：是否采用混合事务事实表，还是为每个事务类型建立不同的事实表，需要有所权衡
  • 用户的分析需求是什么？
    • 用户分析数据的方式是什么？
    • 哪种方法能够最自然地与他们的业务为中心的期望符合？
  • 的确存在多个独特的业务过程吗？ — 跟源系统（业务系统）的设计也有关
    • 采购系统中，每个步骤都有不同的控制号，因此倾向于多事务，库存模型中，不同的库存事务是单一库存过程的组成部分，因此倾向于单一事实表设计
  • 多个源系统获取同样粒度的度量吗？
    • 本例中包含多个源系统：购买、仓库和应付账款。这种情况下应该采用不同的事实表
  • 事实的维度是什么？ — 可以使用维度矩阵展示信息
    • 不同事务的维度不尽相同，因此因此需要不同的事实表

周期快照事实表

• 特点
  • 统计的是间隔周期内的度量统计，如历史至今、自然年至今、季度至今等等
  • 周期快照表没有粒度的概念，取而代之的是周期+状态度量的组合，如历史至今的订单总数
  • 事实事务表是稀疏表，周期快照表是稠密表
    • 稀疏表：当天只有发生了操作才会有记录
    • 稠密表：当天没有操作也会有记录，便于下游使用
• 例子
  • 单维度的周期快照事实表
  • 混合维度的周期快照事实表
  • 全量快照事实表：对于状态一直变化的数据，用全量快照表统计至今最新的状态，如订单评价，好中差评会每天变化，事实表的粒度确定为每一条评价，加之冗余常用维表属性

累积快照事实表：获取多个过程里程碑，每个都包含日期外键并可能包含日期/时间戳。商业用户通常希望分析这些里程碑之间的滞后及延迟时间。有时这些延迟仅仅是日期上的差异，但某些情况下，延迟可能基于更复杂的业务规则。

• 特点
  • 数据不断更新：不同于前面说的两种事实表，累计快照事实表中的数据实例会定期更新。
  • 适用于业务过程有明确的起止时间的短生命周期场景，如交易订单、物流订单。长生命周期的实体记录完全可以由周期快照表实现，如商品、用户。
  • 业务的流程不是只有一种，如交易流程可能是1. 下单、支付、发货、确认2. 下单、关闭订单对于不同过程，要设计统一的结束标志，没有的业务时间置空
• 物理实现
  • 全量表：一般是日分区，每天存储前一天的全量数据和当天增量数据进行合并，保证每条数据的最新状态，此方式适用于数据量不大的情况
  • 全量变化表：累积事实表用于保存生命周期短的实例，所以可以根据业务实体从开始到结束的最大时间间隔，如交易业务最大时间跨度200天，每天保存的是过去200天的全量数据，200天之前的数据存储在归档表中。适用于数据量大的场景
  • 以业务结束时间分区：每天分区中存放的是当天结束的业务，然后用一个非常大的分区（如 3000-12-31）保存所有至今未结束的记录，这种方式不会浪费存储资源