[网络协议]大数据--数据仓库--事实表设计

目录

第三章：事实表设计

3.1 事实表设计原则

3.2 事实表设计方法

3.3 事实表分类

3.3.1 事务事实表

3.3.2 周期快照事实表

3.3.3 累积快照事实表

3.3.4 三种事实表比较

第三章：事实表设计

3.1 事实表设计原则

原则1：尽可能包含所有与业务过程相关的事实

????????事实表设计的目的是为了度量业务过程，所以应该分析那些事实与业务过程有关。在事实表中应该尽量包含所有与业务过程相关的事实，即使存在冗余。

原则2：只选择与业务过程相关的事实

????????在选择事实的时候，只选择与业务过程相关的事实。比如在订单的下单这个业务过程的事实表设计中，不应该存在支付金额这个表示支付业务过程的事实。

原则3：分解不可加性事实为可加的组件

????????对于不具备可加性条件的事实，需要分解为可加的组件。比如订单的优惠率，应该分解为订单的原金额和订单的优惠金额两个事实存储在事实表中。

• 可加事实：对任意维度都可以分组汇总，例如订单量

• 半可加事实：对部分维度可以分组汇总，例如余额

• 不可加事实：对任何维度都不可分组汇总，例如比率，模型中可以保留分子，分母从而转成可加事实。

原则4：在选择维度和事实前必须先声明粒度

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

原则5：在同一个事实表中不能有多种不同粒度的事实

????????事实表中所有事实需要与表定义的粒度保持一致

• 事务型事实表（原子事实表）：通常是明细表，拥有最丰富的的维度信息和最细粒度的事实，一般具有退化维度。

• 周期型事实表：通常是汇总表，关注某个固定周期内的聚合事实，一般由原子事实加工产出，维度上可以有所缩减

• 累积型事实表：关注业务的整个过程（物流），单条数据会随着时间的变化而更新，一般需要重跑或者全量处理数据。例如哈罗单车用户骑行过程，会关注几个关键里程，开锁，关锁，支付，评价

原则6：事实的单位要保持一致

????????对于同一个事实表中事实的单位，应该保持一致。比如原订单金额，订单优惠金额，订单运费金额这三个事实，应该采用一致的计量单位。

原则7：对事实的null值要进行处理

????????对事实的null值要进行处理，因为在数据库中null值对常用数字型字段的sql过滤条件都不生效，比如大于，小于，等于都建议使用零值进行填充，或者使用-999进行兜底。

原则8：使用退化维度提供事实表的易用性

????????在大数据领域的事实表设计中，则大量采用退化维度的方式，在事实表中存储各类型的常用维度信息。这样设计的目的是为了减少下游用户使用时关联多个表的操作，直接通过退化维度实现对事实表的过滤查询，控制聚合层次等。通过冗余存储的方式减少计算开销，提高使用效率。

3.2 事实表设计方法

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

????????在明确业务需求后，接下来需要进行详细的需求分析，对业务的整个生命周期进行分析，明确关键的业务步骤，从而选择与需求项相关的业务过程。

?

第二步：声明粒度

????????粒度的声明是是事实表建模中非常重要的一步，意味着准确定义事实表的每一行所表示的业务含义，粒度传递的是与事实表度量有关的细节层次。

第三步：确定维度

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

第四步：确认事实

????????事实可以回答“过程的度量是什么”来确定，应该选择与业务过程有关的所有事实，且事实的粒度要与所声明的事实表粒度一致，

3.3 事实表分类

3.3.1 事务事实表

• 单事务事实表：

????针对每个业务过程设计一个事实表，可以方便对每个业务过程进行独立的分析研究。

• 多事务事实表：将不同的事实放在同一个事实表中，即同一个事实表包含不同的业务过程。

• 单事务事实表和多事务表的比较：

3.3.2 周期快照事实表

• 周期快照事实表使用场景

????事务型事实表可以很好跟踪一个事件，并对其进行度量，以提高丰富的计算能力。然而，当需要一些状态度量时候，比如账户余额，买卖家星级，商品库存，卖家累积交易额，停车围栏剩余车辆，车辆小哥今天近一周累积装车订单数据等，则需要聚集与之相关的事务进行识别计算。以上使用周期快照事实表可以很好的解决。周期快照事实表简称快照事实表。

• 周期快照事实表特性

????快照事实表在确定时间间隔内对实体的度量进行抽样，这样就可以很容易研究实体的度量值，而不需要聚集长期的事务历史。事务事实表的粒度可以用多种方式表达，但是事实表的粒度通常以维度形式进行声明；事务型事实表是稀疏的，但是快照事实表是稠密的；事务事实表中的事实完全可加的，但是快照模型将至少包含一个用来展示半可加性质的事实（例如余额）。

• 周期型快照事实表与事务性事实表的比较

注意1：我们从ods同步到fact层的表一般都是事务性事实表（简单业务系统）或者累积事务性事实表（初步的累积,主要是微服务架构已经把几个小的业务过程累积到一个系统里面了）。

注意2：虽然我们同步的方式是每天一个快照全量，但是我们fact层的这些同步过来的事实表并不是周期快照事实表，而只是同步方式选择的是每日快照的方式。

注意3：一般哈罗单车定位/流水这种才是事务型事实表，一般业务系统过来的已经都是累积快照事实了。

3.3.3 累积快照事实表

1.适用范围：

????????对于统计买家下单到支付的时长，买家支付到卖家发货的时长，买家从下单到确认收货的时长等。如果使用事务事实表进行统计，则逻辑复杂且性能很差。对于类似研究时间之间的间隔的需求，采用累积快照事实可以很好的解决。

???????对于累积快照事实表，需要将各业务过程对应的事实均放入事实表中。累积快照事实表解决的问题是统计不同业务过程之间的时间间隔，建议将每个过程的时间间隔作为事实放在事实表中。

???????累积快照事实表适用于具有明确起止时间的短生命周期的实体，比如订单交易，物流订单等，对于实体的每一个实例，都会经历从诞生到消亡等一系列步骤；顺便提一句，对于商品，用户等具有长生命周期的实体，比如交易订单，一般适用周期快照事实表更合适。

????????累积快照事实表的典型特征是多业务过程日期，用于计算业务过程之间的时间间隔。另外，对于累积快照事实表，还有一个重要作用就是保存全量数据。

2.物理实现

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

3.3.4 三种事实表比较

1）事务型事实表和周期型快照事实表和累积快照事实表的区别

2）多事务事实和累积快照事实表的区别

• 多事务事实表：是指从一个业务系统里面可能会有多个业务过程，但是他们只产生一张表，所以这个过程不是我们进行累积合并的，而是后台自己产生的；]

• 累积快照事实表：是指从不同业务系统产生的多个事实表，我们进行累积，把多个业务过程里面的字段进行加工和业务累积得到的一个累积快照事实表。