大数据：事实表设计

目录：

1. 事实表基础
   1. 事实表特征
   2. 事实表设计原则
   3. 事实表设计方法
2. 事务事实表
   1. 设计过程
   2. 单事务事实表
   3. 多事务事实表
   4. 两事实表对比
   5. 父子事实的处理方式
   6. 事实的设计原则
3. 周期快照事实表
   1. 特性
   2. 实例阐述周期快照事实表设计过程
   3. 注意事项
4. 累积快照事实表
   1. 设计过程
   2. 特点
   3. 特殊处理
   4. 物理处理
5. 三种事实表的比较
6. 无事实的事实表
7. 聚集型事实表
   1. 聚集的基本原则
   2. 聚集的基本步骤
   3. 阿里的公共汇总层
   4. 聚集补充说明

一、事实表基础

1、事实表特征

• 事实表是围绕着业务过程来设计的，通过获取描述业务过程的度量来表达业务过程，包含了引用的维度和与业务过程有关的度量；

• 事实表的作用：度量业务过程；

• 事实表的粒度：事实表中，一条记录所表达的业务细节程度；

• 事实表中，所有事实需要与表定义的粒度保持一致，在同一个事实表中，不能有多种不同粒度的事实；

• 粒度的表述方式：
  1. 维度属性组合所表示的细节程度；（一般适用于 “聚集性事实表”）
  2. 所表示的具体业务含义；

• 事实的类型：为整型或浮点型的十进制数，有三种事实类型：
  1. 可加型事实：可以按照与事实表相关的任意维度汇总，且汇总结果有意义；
  2. 半可加型事实：只能按照特定维度汇总，不能对所有维度获得有意义的汇总；（如，事实可以进行汇总相加，但是汇总结果没有意义）
  3. 不可加型事实：完全不具有可加性，比如比率型事实；
     • 对于不可加性的事实，可以分解为可加的组件来实现聚集；

• 退化维度：存储在事实表中的维度列；
  •  退化维度也可以用来进行事实表的过滤查询、实现聚合操作等；

• 事实表的 3 种类型：

1. 事务事实表
   • 也称原子事实表，描述业务过程，跟踪控件或时间上某点的度量事件，保存的是最原子的数据；
2. 周期快照事实表
   • 以一个周期为时间间隔，来记录事实，一般周期可以是每天、每周、每月、每年等；
3. 累积快照事实
   • 用来描述过程开始和结束之间的关键步骤事件，覆盖过程的整个生命周期，通常具有多个日期字段来记录关键时间点；
   • 当过程随着生命周期不断变化时，记录也会随着过程的变化而被修改；

2、事实表设计 8 大原则

• 原则 1：尽可能包含所有与业务过程相关的事实
  • 分析哪些事实与业务过程相关，是设计过程中非常重要的关注点；
  • 在事实表中，尽量包含所有与业务过程相关的事实，即使存在冗余，由于事实通常是数字型，存储开销不会太大；

• 原则 2：只选择与业务过程相关的事实
  • 如，订单的下单这个业务过程，事实表中不应该存在支付金额这个表示支付业务过程的事实；

• 原则 3：分解不可加性事实为可加的组件
  • 如，订单的优惠率，应分解为订单原价金额与订单优惠金额两个事实存储在事实表中；

• 原则 4：在选择维度和事实之前必须先声明粒度
  • 粒度用于确定事实表中一行所表示业务的细节层次，决定了维度模型的扩展性；
  • 每个维度和事实必须与所定义的粒度保持一致；
  • 设计事实表时，粒度定义越细越好，一般从最低级别的原子粒度开始；
    • 因为原子粒度提供了最大限度的灵活性，可以支持无法预期的各种细节层次的用户需求；

• 原则 5：在同一个事实表中不能有多种不同粒度的事实
  • 疑问：怎么判断不同事实的粒度是否相同？
  • 例：一个不规范的 “机票支付成功事务事实表”
  • 
    • 粒度为票一级；（实际业务中，一个订单可以同时支付多张票）
    • 票支付金额和票折扣金额，两个事实的粒度为 “票级”，与定义的粒度一致；
    • 订单支付金额和订单票数，两个事实的粒度为 “订单级”，属于上一层订单级数据，与 “票级” 事实表的粒度不一致，且不能进行汇总；
      • 如果，以订单金额和订单票数这两个维度汇总总金额和总票数，会造成大量的重复计算；

• 原则 6：事实的单位要保持一致
  • 如，订单金额、订单优惠金额、订单运费这 3 个事实，应该采用统一的计量单位，统一为元或者分，以方便使用；

• 原则 7：对事实的 null 值要处理
  • 原因：在数据库中，null 值对常用数字型字段的 SQL 过滤条件都不生效；如，大于、小于、等于、大于或等于、小于或等于；
  • 处理：用 0 代替 null ；
• 原则 8：使用退化维度提高事实表的易用性
  1. 事实表中存储各种类型的常用维度信息，较少下游用户使用时关联多个表的操作；
  2. 通过退化维度，可以实现对事实表的过滤查询、控制聚合层次、排序数据、定义主从关系等；
  • 易用性：对事实表，更较少关联操作、过滤查询、控制聚合层次、排序数据、定义主从关系等；

• 在 Kimball 的维度建模中，通常按照星形模型的方式设计，通过事实表的外键关联专门的维表，这种方式来获取维度，谨慎使用退化维表；这与大数据领域的事实表设计不一样；
  • 思路：通过增加冗余存储，减少计算开销，提高使用效率；

3、事实表设计方法

• Kimball 的维度模型设计 4 步法：选择业务过程、声明粒度、确定维度、确定事实；

• 当前的互联网大数据环境，维度模型的设计，是基于 Kimball 的四步维度建模方法进行了更进一步的改进：

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

  • 思路：详细分析需求，对业务的整个生命周期进行分析，明确关键的业务步骤，从而选择与需求有关的业务过程；
  • 以实例说明：如何选择业务过程？如何确定事实表类型？
    • 例：淘宝的一个交易订单
    • 
      1. 分析业务的生命周期：如上图，业务过程通常使用行为动词表示业务执行的活动；
      2. 明确关键的业务步骤：该订单流转的业务过程有 4 个：创建订单 → 买家付款 → 卖家发货 → 买家确认收货；
      3. 根据业务需求，选择与维度建模有关的业务过程；
         • 如，是选择 “买家付款” 这个业务过程，还是选择 “创建订单” 和 “买家付款” 这两个业务过程，具体根据业务情况来定；
      4. 根据所选的业务过程确定事实表类型；
         • 如，选择 “买家付款” 这个业务过程，则事实表类型应为只包含买家付款这一个业务过程的 “单事务事实表”；
         • 如，选择了所有 4 个业务过程，并且需要分享各业务过程的时间间隔，则事实表类型应为包含了所有 4 个业务过程的 “累积快照事实表”；

• 第二步：声明粒度

  • 粒度的作用：
    1. 粒度的声明，意味着精确定义事实表的每一行所表示的业务含义；
    2. 明确的粒度能够确保对实表中行的意思的理解不会产生混淆，保证所有的事实按照同样的细节层次记录；
  • 粒度的选择：尽量选择最细级别的原子粒度，以确保事实表的应用具有最大的灵活性；
    1. 灵活性：支持无法预期的各种细节层次的用户需求；
    2. 对于订单级别，粒度可以定义为最细的订单级别；（如，父子订单，事实表的粒度可以定 “子订单级别” ；）

• 第三步：确定维度

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

• 第四步：确定事实

  • 确定原则：选择与业务过程有关的所有事实，且事实的粒度要与所声明的事实表的粒度一致；
  • 思路：可以通过回答 “过程的度量是什么” 来确定；
  • 注意：将不可加性事实分解为可加的组件；（分解的原则：可以通过分解后的可加的属性值，计算得到不可加性事实）

• 第五步：冗余维度

  • 冗余维度：给事实表添加下游用户常用的维度；
  • 作用：
    1. 提高下游用户使用效率，降低数据获取的复杂性；
    2. 方便实现对事实表的过滤查询、控制聚合层次、排序数据、定义主从等操作；

二、事务事实表

• 事实事务表：也称原子事务表，跟踪控件或时间的某点的度量事务，确保最原子的数据；

• 任何类型的时间都可以被理解为一种事务；
  • 如，交易过程中的创建订单、买家付款；物流过程中的揽活、发货、收件；退款过程中的申请退款、申请小二介入等；都可以被理解为一种事务；

• 事实事务表，就是针对这些事务的过程构建的一类事实表，用以跟踪定义业务过程的个体行为，提供丰富的分析能力，作为数据仓库原子的明细层数据；

 

1、设计过程

• 以 “淘宝交易事务事实表” 为例，阐述事务事实表的一般设计过程：
  • 

　1/1）选择业务过程

• 淘宝交易订单的流转过程，一共有 4 个重要过程：创建订单、买家付款、卖家发货、买家确认收货，即下单、支付、发货、成功完结 4 个业务过程；
• 淘宝交易事务事实表的设计，应着重从这 4 个业务过程展开；
• Kimball 维度建模理论认为，为了便于进行独立的分析研究，应该为每个业务过程建立一个事实表；

　1/2）确定粒度

• 业务过程选定后，要针对每个业务过程确定一个粒度，即确定事务事实表每一行所表达的细节层次；

1. 详细分析业务细节
   • 两类卖家：一类是没有店铺的，出售闲置的或二手的；一类是有店铺的，出售新商品；
   • 两种交易方式：一种是选定商品直接购买，产生一个交易订单；一种是将多种商品先加入购物车，然后一起结算，此时每个商品都会产生一个订单，同时对于同一个店铺额外产生一个订单，即父订单；
     1.  同一家店铺购买的多种商品，父订单会承载订单物理、店铺优惠等信息；
     2. 子订单记录了父订单的订单号，并且有子订单标志；（如，下图 11.3）
     3. 如果一个店铺只购买一种商品，子订单即为父订单，两者合并，只保留一条记录；（如，下图 11.2）
     • 
2. 为事务事实表确定粒度
   • 四个重要业务过程，要对每一个过程确定一个粒度：下单、支付、成功完结三个业务过程，选择交易子订单粒度，即每个子订单为事务事实表的一行；
   • 卖家发货，这个业务在实际中更多的是 “物流单粒度” ，而非 “子订单粒度”，同一个子订单可以拆开成多个物流单进行发货；秉承 “确定最细粒度原则”，对于 “卖家发货” 确定为 “物流单粒度”；

　1/3）确定维度

1. 按照经常用于统计分析的场景，确定维度包含：买家、卖家、商品、商品类目、发货地区、收货地区、父订单维度、杂项维度；
2. 杂项维度，由于订单的属性较多，如，订单的业务类型、是否无线交易、订单的 attributes 属性等，对于这些使用较多却又无法归属到上述维度的属性，则要新建一个杂项维度进行存放；
   • PK（Primary Key）：主键；
   • FK（ Foreign Key）：外键；（指其它子维表的主键，相对于主维表来说是主维表的外键）
   • 

 　1/4）确定事实

• 作为过程度量的核心，事实表应该包含与其描述过程（下单、支付、成功完结，三个主要过程）有关的所有事实；
• 逐个业务过程进行分析：
  • 由于粒度是子订单，父订单上的金额需要分摊到子订单上，如父订单邮费、父订单折扣等；（怎么分摊呢）
  1. 下单业务过程：下单金额、下单数量、下单分摊金额（也就是子订单商品金额）；
  2. 支付业务过程：支付金额、分摊邮费、折扣金额、红包金额、积分金额；
  3. 完结业务过程：确定收货金额；

 　1/5）冗余维度

• 冗余维度：将常用的维度退化到事实表中；便于下游更方便的使用：过滤查询、统计聚合等；

• 将买家星级、卖家星级、标签、店铺名称、商品类型、商品特征、商品属性、类目层级等常用维度属性，都冗余到事实表中；

• Kimball 维度建模理论建议，在事实表中只存放个维表的外键（也就是各个维度表自己的主键，只是相对于事实表，称它们为外键）

• 

　1/6）其它

• 在设计过程中遗留一个问题，对于单一事实表中是否包含多个业务过程，还没有给出定论；

2、单事务事实表

• 单事务事实表：针对每一个业务过程设计一个事实表；
• 优点：方便的对每个业务过程进行独立的分析研究；

• 以阿里的 1688 交易流程为例：

1. 选择业务过程

   • 1688 交易流程也分为 4 个主要业务过程：下单、支付、发货、完结；
   • 1688 交易选择下单和支付两个业务过程设计事务事实表，分别是：1688 交易订单下单事务事实表、1688 交易订单支付事务事实表；

2. 对每个业务过程确定粒度、维度、事实

   • 1688 交易订单下单事务事实表：

     1. 粒度：子订单级粒度；

     2.  维度：买家、卖家、商品、父订单、收货地区等；

     3.  事实：下单分摊金额、折扣金额等；

   • 1688 交易订单支付事务事实表：

     1. 粒度：子订单级粒度；

     2.  维度：买家、卖家、商品、父订单、收货地区等；

     3.  事实：支付金额、支付调整金额、支付优惠等；

   • 

3. 详情实例

   • 每天的下单记录进入当天的下单事务事实表中，每天的支付记录进入当天的支付事务事实表中；
   • 由于事实表具有稀疏性质，因此只有当天数据才会进入当天的事实表中；
   • 

3、多事务事实表

• 多是为事实表：同一个事实表包含多个不同的业务过程；

• 两种事实处理方式：
  1. 不同业务过程的事实，使用不同的事实字段存放；
  2. 不同业务过程的事实，使用同一个事实字段存放，但增加一个业务过程标签；

• 以淘宝交易事务事实表和淘宝收藏商品事务事实表为例，阐述多事务事实表设计过程：

　3/1）淘宝交易事务事实表设计过程

1. 分析交易流程，选择主要业务过程
   • 四个主要业务过程：下单、支付、发货、完结；
2. 确定每个业务过程的粒度
   • 下单业务过程：子订单粒度；
   • 支付业务过程：子订单粒度；
   • 发货业务过程：物流单粒度；（由于 “物流单粒度” 比 “子订单粒度” 更细，秉承 “最细粒度原则”，选择 “物理粒度”；
   • 成功完结业务：子订单粒度；
3. 确定事实表数量
   • 相同粒度的业务过程存放到同一个事实表中：淘宝交易事务事实表（存放下单、支付、完结业务数据）、淘宝交易物理事务事实表（存放发货业务数据）；
4. 确定维度和事实
   1. 确定维度
      • 分别分析统计各个业务过程的维度；将同一事实表中的业务的维度合并汇总；（不同的业务过程的维度，将含义相同的维度同一为一个维度）
      • 冗余常用维度到事实表中；
   2. 确定事实
      1. 分别分析统计各个业务过程中的相关事实；
      2. 处理不同业务的事实：
         • 针对每个度量都使用一个字段进行保存，即不同的事实永不不同的字段保存；
         • 如果不是当前业务的度量，采用零值处理；（如，下单业务过程，支付度量和成功完结度量全部置为 0 ；）
   3. 在事实表中，对不同业务过程进行标记
      • 淘宝交易事务事实表中包含 3 个业务过程，下单、支付、完结，则在事实表中添加：是否当天下单、是否当天支付、是否当天完结，3 种标签；

• 
• 
• 

　3/2）淘宝收藏商品事务事实表设计过程

1. 业务分析
   • 确定业务过程：收藏商品、删除商品；
2. 确定粒度
   • 思想：无论是收藏商品还是删除商品，都是用户对商品的操作，因此两个业务过程的粒度都可以确定为：用户加上商品；
   • “用户加上商品”，根据该粒度，可以很直观的连接业务过程，即为收藏业务；
3. 确定维度和事实
   1. 确定维度
      • 收藏商品业务过程：用户、商品；
      • 删除商品业务过程：用户、商品；
      • 冗余常用维度：商品类目、商品所属卖家等；
   2. 确定事实
      • 收藏商品业务过程和删除双排业务过程，它们的事实主要是商品价格；
      • 事实处理：使用功能同一个字段存放不同业务过程的事实；
      • 扩展：一般收藏事务表更多的是无事实的事实表，用于统一收藏或删除次数的；

• 

　3/3）多事务事实表的选择

• 当不同业务过程的度量比较相似、差异不大时，可以采用上述的第二种多事务事实表的设计方式（淘宝收藏事务事实表），使用同一个字段来表示度量数据；
  • 存在问题：在同一个周期内会存放多条记录；

• 当不同业务过程的度量差异较大时，可以选择第一种多事务事实表的设计方式（淘宝交易事务事实表）；将不同业务过程的度量使用不同字段冗余到表中，非当前业务过程则置零表示；
  • 存在问题：度量字段零值较多；

4、两种事实表对比

• 多事务事实表与单事务事实表对比分析：

　4/1）业务过程

• 单事务事实表：一个业务过程建立一个事实表，只反映一个业务过程的事实；

• 多事务事实表：同一个事实表中反映多个业务过程；
  • 多个业务过程是否能放在同一事实表：分析不同业务过程之间的相似性和业务源系统；
    • 业务过程相似性判断：根据不同业务过程的维度和事实的重合情况；
    • 如，淘宝交易系统中的下单、支付、成功完结这 3 个业务过程，存在相似性，都属于订单处理中的一环，并且都来自于交易系统；

 　4/2）粒度和维度

• 如果不同业务的粒度相同，且同时拥有相似的维度时，可以选择多事务事实表；
• 如果各个业务的粒度不同，则必须建立不同的事实表；

　4/3）事实

• 处理事实的方式不同：
  1. 单事务事实表，能方便灵活的处理事实，仅仅体现同一个业务过程的事实即可；
  2. 多事务事实表，由于有多个业务过程，所有需要处理更多的事实；

• 事实表选择：
  • 如果单一业务过程的事实较多，同时不同业务过程的事实又不相同，则考虑使用单事务事实表；（如果使用多事务事实表，会导致事实表零值或空值比较多）

　4/4）下游业务使用

• 单事务事实表，对下游用户而言更容易理解，关注哪个业务过程就使用相应的事务事实表；
• 多事务事实表，包含多个业务过程，用户使用时往往较为困惑；

　4/5）计算存储成本

• 当业务过程数据来源于同一个业务系统，具有相同的粒度和维度，且维度较多而事实相对不对时，可以考虑使用多事务事实表，不仅其加工计算成本低，在存储上也相对节省；

　4/6）单事务事实表和多事务事实表的比较

• 

5、父子事实的处理方式

1. 以子订单为粒度，分摊父订单的事实；
2. 将所有业务过程的度量，全部带进事务事实表中，包含父事实，也一起冗余到事实表中；
   • 为了下游用户使用，也将粒度不同的父事实冗余到子粒度的事实表中；
   •  仅拥有父子事实的处理，可将不同粒度的事实冗余到一个事实表中；弱不是父子事实，且粒度不同，不能冗余同一个事实表；

• 例：淘宝交易系统，在同一家店铺一次购买多个商品，每个商品都会产生一个订单，而这几个商品一起产生一个父订单；
  • 父订单事实：订单总额、支付总额、支付邮费等；
  • 确定粒度：根据粒度最细原则，以子订单为粒度；
  • 以子订单为粒度，需要将父订单的事实进行分摊；
  • 将说有的事实（包括父订单的事实），全部冗余到淘宝交易事务事实表内；

6、事实的设计准则

　6/1）事实完整性

• 事实表应包含与其描述的过程有关的所有事实，尽可能多的获取所有的度量；

• 事实表中所有的事实，粒度必须一致；（父子事实除外）否则只能创建多个事实表，存放多种粒度的事实；

　6/2）事实一致性

• 在确定事务事实表时，明确存储每一个事实，以确保度量的一致性；

• 度量一致性：度量单位一直、度量字段一直（是单字段还是组合字段）；
  • 如，在淘宝交易事务事实表中，是父子订单时，虽以子订单为粒度，但也要明确下单金额和下单有效金额；虽然下游用户可以通过子订单支付金额和子订单下单有效金额汇总计算，但是在事实表中统一计算可以保证度量的一致性；

　6/3）事实可加性

• 将非可加性事实拆成组合的可加性事实；

• 如，分摊比例、利润率等，虽然它们也是下游分析的关键点，但往往在事务事实表中关注更多的是可加性事实，下游用户在聚合统计时更加方便；

三、周期快照事实表

• 作用：存储一些状态度量；
  • 状态度量：如账户余额、商品库存、卖家累积交易额等状态；
  • 数据的特点：一般需要聚合与之相关的事务，才能识别或者通过计算得到；

• 背景：由于通过事务事实表的一些数据进行聚合得到这些状态度量时，效率非常低下，特别是事务事实表数据量非常大的时候；

• 事实：随着时间变化，表中的每一行数据，都是截至当前采用周期时的最新状态度量；

• 粒度：一般可以用采样周期以及什么将被采样作为周期快照事实表的粒度；
  • 一般采用的内容是一个或多个维度，所以周期快照事实表的粒度通常也是被多维声明的；

• 存储过程：（例：卖家历史至今下单金额）
  1. 采样，也就是聚集一个周期内产生的所有交易订单，统计计算这些订单的下单金额总和；
  2. 将本周期内采样汇总的数据，与历史截至上一周期的卖家下单总金额，进行汇总；
  3. 将汇总的金额存储在周期快照事实表中；（即每行的数据：历史截至该行所在周期的卖家下单金额）

• 事务事实表可以很好的跟踪一个事件，并对其进行度量，以提供丰富的分析能力；

• 背景：当需要一些状态度量，如，账户余额、买卖家星级、商品库存、卖家累积交易额等，则需要聚集与这些状态度量相关的一些事物，进行统计计算分析才能得到；或者通过聚合事物也无法识别这些状态量；对于这些状态量，事物事实表是无效率的；
  • 例：卖家累积交易金额，如果需要查看卖家年初至今，一长时间段的交易额，使用事务事实表进行统计汇总可以得到，但是随着时间跨度变大，聚集效率会越来越低；

• 周期快照事实表：也称 “快照事实表”，在确定的时间间隔内，对实体的度量进行抽样，这样可以很容易的研究实体的度量值，而不需要聚集长期的事务历史；
  • 事实表中的事实，以周期为间隔记录一行，每次记录的事实都是历史至今的汇总数据或者统计计算后的数据；

• 快照事实表在阿里数据仓库中的设计和应用：
  • 以淘宝交易结束后的评价数据、卖家的累积支付金额、买卖家星级等事实表的设计为例；
  • 周期快照事实表的 2 种产出模式（或者说从哪里采样数据，具体使用哪种方式，要看采样数据的来源）：
    1. 从事务事实表进行汇总产出；（常见产出模式）
    2. 直接使用操作型系统的数据，作为周期快照事实表的数据源进行加工；（如，淘宝卖家星级、卖家 DSR 事实表等）

1、特性

• 与事务事实表对比：
  • 粒度：事务事实表的粒度能以多种方式表达，快照事实表的粒度通常以维度形式声明；
  • 事务事实表是稀疏的，但是快照事实表是稠密的；
  • 事实：事务事实表中的事实是完全可加的，但快照模型将至少包含一个用来展示半可加性质的事实；

　1/1）用快照采样

• 快照事实表周期性的采样状态度量；

• 快照周期联合一个或多个维度，将被用来快照事实表的粒度，事实表的每行都将包含记录所涉及状态的事实；

• 例：淘宝交易卖家自然年汇总事实表；
  • 业务需求：淘宝活动运营小二或者卖家，需要经常查看一些交易状态数据，如，自然年至今的下单金额、支付金额、支付买家数、支付商品件数等状态度；
    • 对于卖家，可能每天早上都想看一下截至昨天的成交情况；
    • 对于小二，可能在频繁的活动周期就需要查看一次成交情况；
  • 如果使用事务事实表进行聚集，带来的问题是：随着时间跨度增大，聚集效率会越来越低；因此需要设计快照事实表进行状态的度量；
  • 采用周期：天；
  • 下图所示的快照事实表，记录了每个卖家的下单和支付情况：
• 

　1/2）快照粒度

• 粒度：采用周期 + 样本内容；
• 如，在淘宝交易卖家快照事实表中，粒度被理解为 “每天针对卖家的历史截至当日的下单支付金额进行快照”；
  • 相当于每天记录一次历史至今的下单支付总金额；
  • 事实表中的数据，每周期记录一行，每次记录的数据：历史至今的下单支付金额（销售总额）；
  • 快照周期根据业务需求情况而定，事实表维度也不只一个，还包括卖家和类目；

　1/3）密度与稀疏性

• 事务事实表是稀疏的：只有当天发生的业务过程，事实表才会记录该业务过程的事实，如下单、支付等；

• 快照事实表是稠密的：无论当天是否有业务过程发生，都会记录一行；无论当天发生多少业务过程，也只会记录一行；
  • 如，针对卖家的历史至今的下单和支付金额，无论当天卖家是否有下单事实，都会给该卖家记录一行；

• 稠密性的重要性：如果在每个周期内不记录行，就会和事务事实表一样，那么确定状态将变得非常困难；

　　　　 

　1/4）半可加性

• 快照事实表中收集到的状态度量都是半可加的；
  • 根据时间维度进行统计汇总的结果是没有意义的；
  • 半可加性事实：只能根据特定维度汇总，不能根据表的所有维度汇总，且汇总结果要有意义；
  • 虽不可以进行汇总，但可以计算一些平均值，如，一个周期内平均每个订单的平均金额；

2、实例周期快照事实表设计过程

• 设计步骤：
  1. 确定快照事实表的快照粒度；
  2. 确定快照事实表采用的状态度量；

　2/1）单维度的每天快照事实表

• 单维度的每天快照事实表：只针对一个维度进行状态度量汇总，如，卖家、商品等；

1. 确定粒度
   • 粗略的讲，粒度就是周期 + 采样的状态度量；表示，按周期汇总记录关于谁的状态度量；
   • 例：以天为周期，卖家历史至今事实汇总；
     • 理解，所有的与卖家有关的状态的度量，历史至今的汇总；
     • 事实，可以是多个状态度量：历史截至当日下单金额、历史截至当日买家数、历史截至今日浏览 PV、历史截至当日浏览 UV 等；只要是与卖家相关的状态度量，都可以统计到一个 “淘宝卖家历史至今快照事实表” 中；
   • 采样周期为每天，针对卖家、买家、商品、类目、地区等维度的快照事实表；如，淘宝卖家历史至今汇总事实表、淘宝商品自然月至今汇总事实表等；
   • 不同的采样粒度确定了不同的快照事实表；
2. 确定状态度量
   • 根据粒度和业务需求，确定需要采样哪些状态度量；
   • 例 1：粒度为 “卖家历史至今的状态度量” 的 “淘宝卖家历史至今汇总事实表”；
     • 
   • 例 2：粒度为 “商品历史至今的状态度量” 的 “淘宝商品历史至今快照事实表”；
     • 

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

• 混合维度的每天快照事实表：在每天的采样周期上，针对多个维度进行采样；
• 例：淘宝买卖家历史至今快照事实表，采样周期是每天，维度是卖家和买家，反映的是不同买家对于不同卖家的下单支付金额，如下图：
  • 

• 周期快照事实表的 2 种产出模式：
  1. 从事务事实表进行汇总产出；（常见产出模式）
  2. 直接使用操作型系统的数据，作为周期快照事实表的数据源进行加工；（如，淘宝卖家星级、卖家 DSR 事实表等）

　2/3）直接使用操作型系统的数据作为周期快照事实表的数据源进行加工

• 淘宝卖家信用分和 DSR 快照事实表：
  • 业务分析：淘宝卖家服务评价系统中，在淘宝店铺交易成功后，进行一次好中差评以及 DSR 评价（包括物理服务、描述相符、服务态度），淘宝卖家信用就是基于好中差评计算得出的，DSR 评分会累积计算一个综合分；
    • 
    • 
  • 卖家信用分和 DSR 评分都是在操作型系统中计算完成的，阿里数据仓库关于淘宝卖家信用分和 DSR 快照事实表，是直接采用操作型系统数据进行设计加工；
  • 采样周期是每天，针对卖家维度的统计，状态度量就是卖家信用分和 DSR 评分，如下图：
    • 

　2/4）全量快照事实表

• 特点：除了状态度量，还冗余其它维度；（体现了 “全量”）
• 以淘宝好中差评快照事实表为例，阐述全量快照事实表设计方法：
  1. 确定粒度
     • 业务过程分析，确定采样周期：淘宝好中差评每天都在变化，下游统计分析也是每天都在进行的，因此确定采样周期为每天；
     • 需求及业务过程分析，确定粒度：该例中的采样维度比较特殊，是针对评价本身，即每天按照评价进行采样的，每一条好中差评价就是快照事实表的最细粒度；
  2. 确定状态度量
     • 分析业务，确定状态度量：对于好中差评价的度量，关注更多的是评价本身，即没有类似于金额、商品数这样的度量，因此设计为无事实的事实表，更多关注评价的状态；
  3. 冗余维度
     • 对于全量快照事实表，需要冗余维度，如，本例的 “好中差评快照事实表”，冗余了子订单维度、商品维度、评论者维度、被评论者维度以及杂项维度，包括评论内容、是否匿名等信息；
     • 如下图所示：
       • 

3、注意事项

　3/1）事务事实表与快照事实表成对设计

• 数据仓库维度建模时，事务事实表和快照事实表往往都成对设计，互相补充，以满足更多的下游统计分析需求；特别是在事务事实表的基础上，可以加工快照事实表；

　3/2）附加事实

• 附加的事实：上一个采样周期的状态度量；
• 快照事实表在确定状态度量时，一般都是保存采样周期结束时的状态度量；但是也有分析需求需要关注上一个采样周期结束时的状态度量，而又不愿意多次使用快照事实表，因此一般设计周期快照事实表时会附加一些上一个采样周期的状态度量；

 　3/3）周期到日期度量

• 实际应用中，除了需要在每个周期内记录历史至今的汇总数据，也有需要关注自然年至今、季度至今、财年至今的一些状态度量；
• 根据需求要求，在设计周期快照事实表时添加这些日期状态度量；

四、累积快照事实表

• 累积快照事实表（或称 “累积周期快照事实表”）：统计记录不同业务过程之间的时间间隔；

• 使用场景：具有较明确起止时间的短生命周期的实体，如交易订单、物流订单等，对于实体的每一个实例，都会经历从诞生到消亡等一系列步骤；
  • 对于商品、用户等具有长生命周期的实体，一般采用周期快照事实表；

• 存储：一般以天为分区，根据当天新增的数据，更新昨天的全量数据，以及添加新的实体数据，然后存储最新的全量数据；
  • 昨天的全量数据：并不是指昨天一天的新增数据，而是指创表开始至昨天所累积的全量数据；
  • 只有一份全量数据，并不是每天存储一份对应于当天来说的最新的全量数据；

• 实际业务需求，如淘宝交易系统，除了统计下单 / 支付 / 确定收货的子订单数、GMV 等，还需要统计买家下单到支付的时长、买家支付到卖家发货的时长、买家从下单到确认收货的时长等；如果使用事务事实表进行统计，则逻辑复杂且性能很差；
  • 对于类似于研究事件之间时间间隔单需求，采用累积快照事实表解决；

1、设计过程

• 累积快照事实表的建模过程和事务事实表相同，适用维度建模的步骤：（以淘宝交易流程为例）

　1/1）第一步：选择业务过程

• 分析交易系统，选择 4 个主要业务过程：下单、支付、发货、确认收货；
• 由于是统一事件时间间隔，卖家发货也我关键环节；

　1/2）确定粒度

• 业务分析，统计事件间的时间间隔，这些事件也是基于订单中的事件；因此，累积快照事实表的粒度也选择 “子订单粒度”；
• 粒度确定：与事务事实表一样，粒度也是 “子订单级“ ；

　1/3）确定维度

• 主要维度确定：与事务事实表一样，维度主要有买家、卖家、店铺、商品、类目、发货地区、收货地区等；

• 时间维度：四个业务过程对应的时间字段，格式为日期 + 时间，分别为下单时间、支付时间、发货时间、确认收货时间，对应于日期维表；
  • 时间维度表示：在实际使用时会使用视图或 SQL 别名的方式表示 4 个日期角色维度，类似于发货地区维度和收货地区维度；

• 杂项维度：在交易订单表中，存在很多与订单相关的属性，如订单类型、子类型、支付状态、物理状态、attributes、options 等；
  • 数据仓库建模理论中杂项维度设计：杂项维度无自然键，一般是枚举值的组合，对于每个组合生成一个代理键；
  • 实际中杂项维度设计：直接使用自然键标识具体的纬度值；（如下图的子订单维度和父订单维度）

• 

　1/4）确定事实

1. 各业务过程对应的事实均放入累积快照事实表；
2. 每个业务过程之间的时间间隔作为事实；

• 

 　1/5）退化维度

• 思想 1：在大数据的事实模型设计中，更多的是考虑下游用户的使用效率，降低数据获取的复杂性，减少关联的表数；
• 思想 2：大数据时代，很多维度表比事实表还大，如淘宝几十亿的商品、几亿的买家等，在分布式数据仓库系统中，事实表和维表关联的成本很高；

• 基于上述两种思想，在传统的维度模型设计完成之后，在物理实现中，将各维度的常用属性退化到事实表中，以大大提高对事实表的过滤查询、统计聚合等操作的效率；

2、特点

　2/1）数据不断更新

• 事务事实表记录事务发生时的状态，对于实体的某一实例不再更新；
• 累积快照事实表对实体的某一实例定期更新；（如，淘宝交易累积快照事实表，一个子订单只记录一行信息，随时间和业务的发展，定期对该行数据进行更新）

• 例：淘宝交易

1. 事务事实表数据记录形式
   • 
2. 累积快照事实表数据记录的形式
   • 一个子订单只有一条记录，针对此记录不断更新；（首列的日期，为最新的更新日期）
   • 

　2/2）多业务过程日期

• 累积快照事实表的使用：
  1. 适用于具有较明确起止时间的短生命周期的实体，如交易订单、物流订单等，对于实体的每一个实例，都会经历从诞生到消亡等一些列步骤；
  2. 存放全量数据
     • 如，淘宝交易，需要保留历史截至当前的所有交易数据：
       1. 方式 1：在 ODS 层保留和源系统结构完全相同的数据；
          • 弊端：使用时需要关联维度，较为麻烦；（所以需要在公共明细层需要保留一份全量数据）
       2. 方式 2：在 DWD（事实明细层）使用累积快照事实表，存放加工后的事实，并将各维度常用属性和订单杂项退化到此表，形成全量数据；

3、特殊处理

　3/1）非线性过程

• 以 淘宝交易系统为例说明：

1. 各种线性业务过程实例
   • 下单 → 支付 → 发货 → 确认收货；
   • 下单 → 关闭订单；
   • 下单 → 支付 → 关闭订单  &  买家申请退款 → 卖家同意退款 → 退款达成，或者，买家申请退款 → 卖家不同意退款 → 退款关闭；
2. 非线性业务过程实例
   • 买家申请退款 → 卖家不同意退款 → 买家申请退款 → 卖家不同意退款 → 。。。。一直到退款达成或关闭；
3. 处理不同类型的非线性业务过程
   1. 业务过程的统一
      • 如，在设计累积快照事实表时，一个子订单结束的标志，不但可以是 “交易完成”，还可以是 “关闭订单”；所以要统一术语为：交易结束；
   2. 针对业务关键里程碑构建全面的流程；
      • 思路：统一使用完整的全业务流程 —— 下单 → 支付 → 发货 → 确认收货；对于没有支付和没有发货的交易订单，用全流程覆盖，相关的业务过程的时间字段和事实置空；
   3. 循环流程的处理
      • 场景：一个业务过程存在多个里程碑日期；
      • 处理：使用业务过程的第一次发生日期或者最后一次发生的日期；

　3/2）多源过程

• 多源：针对多个业务过程建模时，各个业务过程可能来自于不同的系统或者来源于不同的表；
• 针对多源业务建模，主要考虑事实表的粒度问题；

• 例：淘宝交易系统
  • 主业务流程：下单 → 支付 → 发货 → 确认收货；
  • 退款业务流程：
    • 下单 → 支付 → 买家申请退款 → 卖家同意退款 → 退款达成 → 交易关闭；
    • 下单 → 支付 → 发货 → 买家申请退款 → 卖家同意退款 → 退款达成 → 交易关闭；
    • 下单 → 支付 → 发货 → 买家申请退款 → 卖家同意退款 → 退款达成 → 交易关闭；
  • 处理：如果需要将退款业务过程加入 “淘宝交易累积快照事实表” 中，需要和商业用户确定存在多次退款时如何取舍，确保粒度不变；

　3/3）业务过程取舍

• 问题：当拥有大量业务过程时，模型的实现复杂度增加，特别是对于多源业务过程，模型的耦合度过高；
• 思路：设计累积快照事实表时，不要把所有业务都添加进去，要跟商业用户需求，选取关键的里程碑；
• 处理：根据商业用户需求，选取关键的里程碑；
  • 有些业务系统有多种业务流程，如退款业务流程，包含多个里程碑，在进行建模时，考虑到模型的实现复杂度和模型的耦合度，要根据商业用户需要选取关键的里程碑；
  • 里程碑：业务系统中的完整业务流程；（如，下单 → 支付 → 发货 → 确认收货、下单 → 支付 → 关闭订单、下单 → 关闭订单，这些业务过程中，只有 “下单 → 支付 → 发货 → 确认收货” 才是里程碑过程）

4、物理实现

• 逻辑模型和物理模型密不可分，针对累积快照事实表模型设计，有不同的实现方式：

　4/1）方式 1：全量表的形式

• 特点：为日期分区表，每天的分区，存储昨天的全量数据和当天的增量数据合并的结果，保证每条记录的状态最新；
  • 合并的具体操作：更新昨天的实体的数据，添加当天新增的实体的数据；

• 适用情况：全量数据较少的情况；
  • 如果数据量很大，此全量表的数据量不断膨胀，存储了大量永远不再更新的历史数据，对 ETL 和分析统计性能影响较大；

　4/2）方式 2：全量表的变化形式

• 变化：指设置存储时间间隔，只存储一段时间间隔的数据（如，200 天内的数据、或者一个自然年的数据），本段时间间隔前的数据存储在归档表；
• 使用情况：主要针对事实表数据量很大的情况；
• 弊端：如设置时间间隔为 200 天，而有些商业需求需要保留多天的分区数据，由于数据量较大，存储消耗较大；
  • 多天的分区数据：如，连续 3 天的分区数据，即保留 3 份全量数据；
    • 如，200 天，存储开始的第 10 天，则保留第 8 天、第 9 天、第 10 天这三天每天的最新的全量数据；存储开始的第 150 天，则保留第 148 天、第 149 天、第 150 天这三天每天的最新的全量数据；
• 例：淘宝交易订单累积快照事实表，快照周期为 “每天”，以 200 天作为订单从产生到消亡的最大时间间隔；200 天以前的订单，按照 gmt_create 创建分区存储在归档表中；
  • 实体：指相对于网络的虚拟实体，如，用户、卖家、商品、订单等；一般是网络中有名称的个体；
  • 实体消亡：相对于实体产生及存在的生命周期而言的，如：
    • 订单从创建到交易结束，是订单的生命周期，交易完成或关闭就是订单的消亡；
    • 用户从注册到注销，是用户的生命周期，用户注销就是用户实体的消亡；

　4/3）方式 3：以业务实体的结束时间分区

• 存储方式：
  1. 设置全量事实表的分区为天；
  2. 在设计一个非常大的分区，用于存放截至当前未结束的实体；
  3.  每天从大的分区中，将结束的实体数据归档到全量事实表中的当天分区中；

• 优点：
  1. ETL 性能较好：由于每天将当天结束的数据归档至全量表的当天分区中，时间非常大的分区中的数据量不会很大，所以 ETL 性能较好；
  2. 无存储的浪费：因为对于业务实体的具体实例，在时间非常大的分区中的全量数据中唯一；

• 可能存在的极限情况：业务系统无法识别业务实体的结束时间；
  • 如，业务系统调用接口很多，依赖的系统复杂，最终无法判断业务实体是否已经消亡；
  • 例：菜鸟的物流订单，由于其依赖物流公司的数据，和大量的物流公司存在接口，按照约定，物流公司会向菜鸟回传运单的流转信息，但无法保证 100%准确；且一般为批量回传，菜鸟订单系统根据批量数据更新物流订单的结束标志几乎无法实现。
    • 问题：前台业务系统没有物流订单的结束时间，那么如何设计物流订单累积快照事实表呢？ 
    • 两种处理方式：
      1. 方式 1：使用相关系统的业务实体的结束标志作为此业务系统的结束标志；
         • 如，物流订单，可以使用交易订单；理论上交易订单完结了，则物流订单已经完结；
      2. 方式 2：和前端业务确定口径或使用前端归档策略；
         • 确定口径：就是跟前端业务系统确定从业务实体的产生到消亡的最大时间间隔；
         • 使用前端业务系统的归档时间作为业务实体的结束时间；（因为，针对大量的数据，前端系统会定期对历史数据进行归档，避免业务库性能的下降）

五、三种事实表的比较

• 三种事实表：事务事实表、周期快照事实表、累积快照事实表；
• 场景：一些业务过程可能只需要一种事实表，而另一些业务过程可能需要两种或三种事实表，三种事实表相互补充，给出业务的完整描述；

• 

1. 事务事实表
   • 作用 / 特点：
     1. 记录事务层面的事实，用于跟踪业务过程的行为，并支持几种描述行为的事实（也就是可以同时存放多个粒度相同的业务过程）；
     2. 保存的是最原子的数据，也称为 “原子事实表”；
     3. 表中的数据在事务发生后产生；数据的粒度通常是每个事务一条记录；
     4. 一旦事务被提交，事实表数据被插入，数据就不能更改，其更新方式为增量更新；（因为其记录的是业务过程的事务，而发生过的事务是不能被抹除的）
2. 周期快照事实表
   • 作用 / 特点：
     1. 以固定的或者有规律的时间间隔来记录事实；
     2. 周期快照事实表的日期维度通常记录时间段的终止日期；（一般是一个周期结束时的时间，或者是历史至 7 月 1 日，则 7 月 1 日就是一个终止时间）
     3. 表中记录的事实，是一个时间段内一些聚集事实值或者状态度量；（一个时间段：如，历史至今、历史至 7 月 1 日、自然年至今、自然月至今等时间段，并不是指一个周期时间段）
     4. 事实表的数据一旦插入就不能更改，更新方式为增量更新；
3. 累积快照事实表
   • 作用 / 特：
     1. 用来跟踪实体的一系列业务过程的进展情况；
     2. 通常有多个日期字段，用于研究业务过程中的里程碑过程的时间间隔；
     3. 会有一个用于指示最后更新日期的附加日期字段；（一般就是实体消亡时的日期）
     4. 事实表中许多日期在首次加载是是不知道的；
     5. 事实表中的数据可以进行更新，来补充业务状态变更时的日期信息和事实；

六、无事实的事实表

• 无事实的事实表：不包含事实或度量的事实表；
• 常见的无事实的事实表主要有 2 类：

1. 第一类：事件类的，记录事件的发生；
   • 最常见的是日志类事实表；
     • 如，用户的浏览日志，某会员在某时间点浏览了淘宝首页、某会员在某时间点浏览了某卖家的店铺中的某商品详情页等；
     • 对于每次点击，其事实为 1，但一般不会保存此事实；
2. 第二类：条件、范围或资格的，记录维度与维度多对多之间的关系；
   • 如，客户和销售人员的分配情况、产品的促销范围等；

七、聚集型事实表

• 数据仓库的性能是数据仓库建设是否成功的重要标志之一；

• 思想：通过汇总事务事实表中的数据，得到一些常用的汇总数据，这样下游用户需要一些汇总数据时，可以直接从聚集事实表中直接查询已经提前汇总好的数据，不需要在进行汇总。
  • 汇总的数据：一般是下游用户经常需要汇总查询的数据；由数据工程师提前汇总好，并将汇总好的一些数据聚集到聚集事实表中；
  • 例：如卖家最近 1 天的交易回欧洲那个表、卖家最近 N 天的交易汇总表、卖家自然年交易汇总表等；

• 聚集：主要是通过汇总明细粒度数据，来获得改进查询性能的效果；
  • 明细粒度数据：DWD 层的事实表，在聚集表设计时，主要使用 事务事实表 的数据进行聚集汇总；
  • DWD 层数据：事实明细层数据，主要存储三大类型的事实表；（事务事实表、周期快照事实表、累积快照事实表）

• 作用 / 优点：
  1. 减少数据仓库在响应查询时必须的工作量，能够快速响应查询；
  2. 有利于减少不同用户访问明细数据带来的不一致问题；

• 弊端：需要事先对聚集性事实表进行加载和维护，会给 ETL 带来更多的挑战；

• 阿里将使用频繁的公共数据，通过聚集进行沉淀，如卖家最近 1 天的交易回欧洲那个表、卖家最近 N 天的交易汇总表、卖家自然年交易汇总表等；这类聚集汇总数据，被叫作 “公共汇总层”；

1、聚集的基本原则

　1/1）一致性

• 思想：聚集表必须提供与查询明细粒度数据一致的查询结果；
• 确保一致性的方法：确保聚集星形模型中的维度和度量，与原始模型中的维度和度量保持一致；

　1/2）避免单一表设计

• 思想：不要在同一个表中存储不同层次的聚集数据；
  • 如果一个表中存储了不同层次的聚集数据，将会导致双重计算或者更糟糕的事情；
    • 不同层次的聚集数据：如，按 7 天汇总的交易额和按 30 天汇总的交易额，虽然都是交易额，却是不同层次的聚集数据；
    • 如，在聚集表中，有些行存放按天汇总的交易额，有些行存放按月汇总的交易额，这将会让使用者产生误用，导致重复计算；
    •  解决方法：把按天与按月汇总的交易额用两列存放，并在列明或者列注释上啊能分辨出来；

　1/3）聚集粒度可不同

• 聚集并不需要保持  与原始明细粒度数据  一样的粒度，聚集只关心所需要查询的维度。
• 如，订单涉及的维度有商品、买家、卖家、地域等，可以按照商品汇总一天的交易额、也可以按照卖家火鬃一天的营业额（交易额）、也可以按照商品与地域汇总一月的交易额；

2、聚集的基本步骤

　2/1）第一步：明确聚集维度

• 维度：必须是描述事实的维度；
• 维度选择：根据所关心的数据（也就是需要聚集的数据），选择通过哪些维度可以聚集到这些数据；
• 例：有日期、商品类别、卖家等维度；用户关心的是 “商品的交易额情况“ ；选择商品维度维度聚集数据；

　2/2）第二步：确定一致性上钻

• 操作：了解用户需求，然后按照他们想要的进行聚集；
  • 确定是按月汇总还是按天汇总，是按照商品汇总还是按照类目汇总；
  • 如果按照类目汇总，还需要关心是按照大类目汇总还是按照小类目汇总；

　2/3）第三步：确定聚集事实

• 在原始明细模型中，可能有多个事实的度量，如交易中的交易额、交易数量等，此时要明确是按照交易额汇总还是按照成交数量汇总；

3、阿里的公共汇总层

　3/1）基本原则

• 除了聚集的基本原则外，阿里建设公共汇总层还必须遵循以下原则：

1. 数据公用性
   • 一般聚集表中会有多种汇总，而且基于某个维度的汇总经常用于数据分析，因此，有必要把明细数据经过汇总沉淀到聚集表中；
2. 不跨数据域
   • 数据域是在较高层次上对数据进行分类聚集的抽象；阿里以业务过程进行对数据域进行分类；
     • 如，交易统一划到交易域下，商品的新增、修改放到商品城下；
3. 区分统计周期
   • 在表的命名上要能说明数据的统计周期，如，_1d 表示最近 1 天、_td 表示截至当天、_nd 表示最近 N 天；

　3/2）交易汇总表设计

• 聚集是指针对原始明细粒度的数据（DWD 层的三类事实表存放的数据）进行汇总；

1. 分析事实表
   • 例：已有 “交易订单明细模型”，如图：
   • 
     1. 找出与事实相关联的维度：商品、卖家、买家等；
        • 也就是找出含有可聚集事实的维度；
     2. 找出所有潜在的聚集
        • 如下表：可以看出聚集的组合可能性为各个维度属性个数的乘积：2 x 2 x 2 x 2 x 3 x 5 .....；
          • 
2. 设计聚集表
   1. 按商品粒度汇总
      1. 确定聚集维度 —— 商品；
      2. 确定一致性上钻 —— 按商品（商品 ID）最近一天汇总；
      3. 确定聚集事实 —— 下单量、交易额；
      • 按商品聚集的星形模型，如下图：
        • 
      • 总结：聚集的事实都是原始模型中的事实，聚集的维度也我原始模型维度中的商品维度，去掉了其它不关心的维度；
   2. 按卖家粒度汇总
      1. 确定聚集维度 —— 卖家；
      2. 确定一致性上钻 —— 按卖家（卖家 ID）最近 7 天和最近 30 天汇总；
      3. 确定聚集事实 —— 交易额；
      • 按卖家聚集的星形模型，如下图：
        • 
          • 卖家 NICK：指淘宝的旺旺号、用户名，也就是登录时的会员名；
      • 总结：按照聚集原则规范，应避免将不同层级的数据放在一起，因此，选择两列存放 7 天和 30 天的事实，但是需要在列名和字段注释上说明清楚；
   3. 按卖家、买家、商品粒度汇总
      1. 确定聚集维度 —— 卖家、买家、商品；
      2. 确定一致性上钻 —— 按卖家（卖家 ID）、买家（买家 ID）、商品（商品 ID）最近 1 天汇总；
      3. 确定聚集事实 —— 交易额；
      • 按卖家、买家、商品聚集的星形模型，如下图：
        • 
      • 总结：聚集的粒度越细，记录的条数越多，就会越接近原始明细模型的粒度；
   4. 按二级类目汇总
      1. 确定聚集维度 —— 类目；
      2. 确定一致性上钻 —— 按最近 1 天类目维度的二级维度属性汇总；
      3. 确定聚集事实 —— 交易额；
      • 按二级类目聚集的星形模型，如下图：
        • 
      • 总结：与之前的 3 个聚集表不同的是，这个聚集模型不是根据维度主键属性进行的聚集，而是根据类目的层次维度属性进行的上钻聚集；

4、聚集补充说明

　4/1）聚集不是跨越事实的

• 聚集是针对原始星形模型进行的汇总，为了获取和查询与原始模型一致的结果，聚集的维度和度量必须与原始模型保持一致，因此，聚集是不跨越事实的；
• 横向钻取是针对多个事实基于一致性维度进行的分析，很多时候采用融合事实表，预先存放横向钻取的结果，从而提高查询性能；
  • 融合事实表是一种导出模式而不是聚集；

　4/2）聚集带来的问题

• 增加了 ETL 维护的难度；
  • 如，当子类目对应的一级类目发生变更时，先前存在的、已经被汇总到聚集表中的数据，需要被重新调整；这一额外工作随着业务复杂性的增加，会导致多数 ETL 人员选择简单强力的方法，删除并重新聚集数据；