阿里大数据之路：数据模型篇大总结

粒度的声明是事实表建模非常重要的一步，意味着精确定义事实表 的每一行所表示的业务含义，粒度传递的是与事实表度量有关的细节层次。明确的粒度能确保对事实表中行的意思的理解不会产生混淆，保证所有的事实按照同样的细节层次记录。

应该尽量选择最细级别的原子粒度，以确保事实表的应用具有最大的灵活性。同时对于订单过程而言，粒度可以被定义为最细的订单级别。比如在淘宝订单中有父子订单的概念，即一个子订单对应一种商品，如 果拍下了多种商品，则每种商品对应一个子订单:这些子订单一同结算 的话，则会生成一个父订单。那么在这个例子中，事实表的粒度应该选择为子订单级别。

确定维度

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

确定事实

事实可以通过回答“过程的度量是什么”来确定。应该选择与业务 过程有关的所有事实，且事实的粒度要与所声明的事实表的粒度一致。事实有可加性、半可加性、非可加性三种类型 ， 需要将不可加性事实分解为可加的组件。

比如在淘宝订单付款事务事实表中，同粒度的事实有子订单分摊的支付金额、邮费、优惠金额等。

冗余维度

在传统的维度建模的星形模型中，对维度的处理是需要单独存放在专门的维表中的，通过事实表的外键获取维度。这样做的目的是为了减少事实表的维度冗余，从而减少存储消耗。而在大数据的事实表模型设计中，考虑更多的是提高下游用户的使用效率，降低数据获取的复杂性，减少关联的表数量。所以通常事实表中会冗余方便下游用户使用的常用维度，以实现对事实表的过滤查询、控制聚合层次、排序数据以及定义主从关系等操作。

比如在淘宝订单付款事务事实表中，通常会冗余大量的常用维度字段，以及商品类目、卖家店铺等维度信息。

4.2 事务事实表

订单作为交易行为的核心载体，直观反映了交易的状况。订单的流转会产生很多业务过程，而下单、支付和成功完结三个业务过程是整个 订单的关键节点。获取这三个业务过程的笔数、金额以及转化率是日常 数据统计分析的重点，事务事实表设计可以很好地满足这个需求。本节 将介绍三种不同事务事实表的设计方式，以及在淘宝交易订单中关于邮 费和折扣分摊到子订单的算法。

4.2.1 设计过程

任何类型的事件都可以被理解为一种事务。比如交易过程中的创建 订单、买家付款，物流过程中的揽货、发货、签收，退款中的申请退 款、 申请小二介入等，都可以被理解为一种事务。事务事实表， 即针对这些过程构建的一类事实表，用以跟踪定义业务过程的个体行为，提供丰富的分析能力，作为数据仓库原子的明细数据。下面以淘宝交易事务事实表为例，阐述事务事实表的一般设计过程。

选择业务过程

图 4.1 给出了淘宝交易订单的流转过程，其中介绍了四个重要过程：创建订单、买家付款、 卖家发货、买家 确认收货，即下单、支付 、 发货和成功完结四个业务过程。这四个业务过程不仅是交易过程中的重要时间节点 ，而且也是下游统计分析的重点，因此淘宝交易事务事实表 设计着重从这四个业务过程进行展开 。

Kimball 维度建模理论认为，为了便于进行独立的分析研究，应该为每个业务过程建立一个事实表。对于是否将不同业务过程放到同一个事实表 中，将在下一节中详细介绍。

确定粒度

业务过程选定以后，就要针对每个业务过程确定一个粒度，即确定事务事实表每一行所表达的细节层次。下面先介绍淘宝订单的产生过程。

对于每一种商品产生的订单就称为子订单，子订单记录了父订单的订单号，并且有子订单标志。如果在同一个店铺只购买了一种商品，则会将父子订单进行合并，只保留一条订单记录。如图 4.2 和图 4.3 所示示例。

卖家发货这个业务过程可以选择子订单粒度，即将每个子订 单作为卖家发货事实表的一个细节。然而，在实际操作中发现，卖家发货更多的是物流单粒度而非子订单粒度，同 一个子订单可以拆开成多个物流单进行发货。在事务事实表设 计过程中，秉承确定为最细粒度的原则，因此对于卖家发货确定为物流单粒度，和其他三个业务过程不同，这样可以更好地给下游统计分析带来灵活性。

确定维度

选定好业务过程并且确定粒度后，就可以确定维度信息了。在淘宝交易事务事实表设计过程中，按照经常用于统计分析的场景，确定维度包含: 买家、卖家、商品、商品类目、发货地区、收货地区、父订单维度以及杂 项维度。由于订单的属性较多，比如订单的业务类型、是否无线交易、订单的 attributes 属性等，对于这些使用较多却又无法归属到上述买卖家或商品维度中的属性，则新建一个杂项维度进行存放，如图 4.4所示。

确定事实

作为过程度量的核心，事实表应该包含与其描述过程有关的所有事实。以淘宝交易事务事实表为例，选定三个业务过程一一下单、支付和 成功完结，不同的业务过程拥有不同的事实。比如在下单业务过程中， 需要包含下单金额、下单数量、下单分摊金额；在支付业务过程中，包含支付金额、分摊邮费、折扣金额、红包金额、积分金额；在完结业务过程中包含确认收货金额等。由于粒度是子订单，所以对于一些父订单上的金额需要分摊到子订单上，比如父订单邮费、父订单折扣等。

冗余维度

在确定维度时，包含了买卖家维度、商品维度、类目维度 、收发货维度等， Kimball维度建模理论建议在事实表中只保存这些维表的外键， 而淘宝交易事务事实表在 Kimball 维度建模基础之上做了进 一 步的优 化，将买卖家星级、标签、店铺名称、商品类型、商品特征、商品属性、 类目层级等维度属性都冗余到事实表中，提高对事实表进行过滤查询、统计聚合的效率，如图 4.5 所示 。

4.2.2 单事务事实表

单事务事实表，顾名思义，即针对每个业务过程设计一个事实表。这样设计的优点不言而喻大数据存储架构，可以方便地对每个业务过程进行独立的分析研究。1688 交易流程则采用这 种模式构建事务事实表。

1688 交易和淘宝交易相 似，主要流程也是下单、支付、发货和完结，而在这四个关键流程中 1688 交易选择下单和支付两个业务过程设 计事务事实表，分别是1688交易订单下单事务事实表和1688交易订单支付事务事实表。

选定业务过程后，将对每个业务过程确定粒度、维度和事实。对于 1688 交易订单下单事务事实表，确定子订单粒度，选择买家、卖家、商品、父订单、收货地区维度，事实包含下单分摊金额和折扣金额，如 图4.6 所示；而对于 1688 交易订单支付事务事实表 ，粒度和维度与交易订单下单事务事实表相同，所表达的事实则不 一样 ，包含支付金额、支付调整金额和支付优惠等，如图4.7 所示；

1688 交易针对下单和支付分别建立单事务事实表后，每天的下单记录则进入当天的下单事务事实表中，每天的支付记录进入当天的支付事务事实表中，由于事实表具有稀疏性质 ，因此只有当天数据才会进入当天的事实表中。下面以具体交易订单为例 ，展示单事务事实表的设计实例。

4.2.3 多事务事实表

多事务事实表，将不同的事实放到同一个事实表中，即同一个事实表包含不同的业务过程。多事务事实表在设计时有两种方法进行事实的处理：

如何选择：

4.2.4 两种事实表对比

业务过程

对于单事务事实表，一个业务过程建立一个事实表，只反映一个业务过程的事实 ；对于多事务事实表，在同 一个事实表 中反映多个业务过程。多个业务过程是否放到同一 个事实表中，首先需要分析不同业务过 程之间的相 似性和业务源系统。比如淘宝交易的下单、支付和成功完结 这三个业务过程是存在相似性的，都属于订单处理中的 一环，并且都来自于交易系统 ，因此适合放到同 一个事务事实表中。

粒度和维度

在考虑是采用单事务事实表还是多事务事实表时，另一个关键点就是粒度和维度，在确定好业务过程后，需要基于不同的业务过程确定粒度和维度，当不同业务过程的粒度相同，同时拥有相似的维度时，此时就可以考虑采用多事务事实表。如果粒度不同，则必定是不同的事实表。比如交易中支付和发货有不同的粒度，则无法将发货业务过程放到淘宝交易事务事实表中。

事实

对于不同的业务过程，事实往往是不同的，单事务事实表在处理事实上比较方便和灵活，仅仅体现同一个业务过程的事实即可， 而多事务事实表由于有多个业务过程， 所以有更多的事实需要处理。如果单一业务过程的事实较多，同时不同业务过程的事实又不相同，则可以考虑使 用单事务事实表，处理更加清晰 ; 若使用多事务事实表， 则会导致事实表零值或空值字段较多。

下游业务使用

单事务事实表对于下游用户而言更容易理解 ， 关注哪个业务过程就使用相应的事务事实表；而多事务事实表包含多个业务过程，用户使用时往往较为困惑。1688 和淘宝交易分别采用了这两种方式，从日常使用来看，对于淘宝交易事务事实表下游用户确实有 一定的学习成本 。

计算存储成本

针对多个业务过程设计事务事实表，是采用单事务事实表还是多事务事实表，对于数据仓库的计算存储成本也是参考点之 一 ，当业务过程 数据来源于同 一个业务系统，具有相同的粒度和维度，且维度较多而事实相对不多时，此时可以考虑使用多事务事实表，不仅其加工计算成本 较低，同时在存储上也相对节省，是一种较优的处理方式。

4.2.5 父子事实的处理方式

4.2.6 事实的设计准则

事实完整性：尽可能多地获取所有的度量

事实一致性：事实表中统一计算可以保证度量的一致性（比如金额由数量*单价先在事实表算出来）

事实可加性：事务事实表中关注 更多的是可加性事实，下游用户在聚合统计时更加方便

4.3 周期快照事实表

4.3.1 特性

用快照采样状态

快照粒度

密度与稀疏性

半可加性

4.3.2 实例

4.3.3 注意事项

事务与快照成对设计

附加事实

周期到日期度量

4.4 累积快照事实表

4.4.1 设计过程

4.4.2 特点

数据不断更新

多业务过程日期

4.4.3 特殊处理

非线性过程

多源过程

业务过程取舍

4.4.4 物理实现

全量表的形式：此全量表一般为日期分区表，每天的 分区存储昨天的全量数据和当天的增量数据合并的结果，保证每条记录 的状态最新。此种方式适用于全量数据较少的情况。

全量表的变化形式：比如针对交易订单，我们以 200 天作为订单从产生到消亡的最大间隔。设计最近 200 天的交易订单累积快照事实表，每天的分 区存储最近 200 天的交易订单而 200 天之前的订单则按照 gmt_create 创 建分区存储在归档表中。

业务实体的结束时间分区：每天的分区存放当天结 束的数据，设计一个时间非常大的分区，比如 3000-12-31 ，存放截至当前未结束的数据。由于每天将当天结束的数据归档至当天分区中，时间 非常大的分区数据量不会很大， ETL 性能较好；并且无存储的浪费，对于业务实体的某具体实例，在该表的全量数据中唯一。但接口等原因，存在结束标志的确认问题，有以下两个方案：

4.5 三种事实表的比较

4.6 无事实的事实表

4.7 聚集型事实表DWS

4.7.1 聚集的基本原则

4.7.2 聚集的基本步骤

确定聚集维度

在原始明细模型中会存在多个描述事实的维度，如日期、商品类别、 卖家等，这时候需要确定根据什么维度聚集，如果只关心商品的交易额 情况，那么就可以根据商品维度聚集数据。

确定一致性上钻

确定聚集事实

4.7.3 阿里公共汇总层

基本原则

交易汇总表设计

4.7.4 聚集补充说明

欢迎加入 大数据 |数仓技术交流群 。

（编辑：武汉站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!