【大数据之路】数据模型篇 《四》事实表设计 【搬运小结】

文章目录

  • 【大数据之路】数据模型篇 《四》事实表设计
    • 1 事实表基础
      • 1.1事实表特性
      • 1.2事实表设计原则
      • 1.3事实表设计方法
    • 2 事务事实表
      • 2.1设计过程
      • 2.2单事务事实表
      • 2.3多事务事实表
      • 2.4两种事实表对比
      • 2.5父子事实的处理方式
      • 2.6事实的设计准则
    • 3 周期快照事实表
      • 3.1特性
      • 3.2实例
      • 3.3注意事项
    • 4 累积快照事实表
      • 4.1设计过程
      • 4.2特点
    • 5 三种事实表的比较
    • 6 无事实的事实表
    • 7 聚集型事实表
      • 7.1聚集的基本原则
      • 7.2聚集的基本步骤
      • 7.3阿里公共汇总层
      • 7.4聚集补充说明

【大数据之路】数据模型篇 《四》事实表设计

1 事实表基础

1.1事实表特性

事实表作为数据仓库维度建模的核心,紧紧围绕着业务过程来设计。事实表中一条记录所表达的业务细节程度被称为粒度。通常粒度可以通过两种方式来表述: 一种是维度属性组合所表示的细节程度;一种是所表示的具体业务含义。

维度属性也可以存储到事实表中 , 这种存储到事实表中的维度列被称为 “退化维度"。

事实表有三种类型: 事务事实表、周期快照事实表和累积快照事实表。

1.2事实表设计原则

原则1:尽可能包含所有与业务过程相关的事实
原则2:只选择与业务过程相关的事实
原则3:分解不可加性事实为可加的组件
原则4:在选择维度和事实之前必须先声明粒度
原则5:在同一个事实表中不能有多种不同粒度的事实
原则6:事实的单位要保持一致
原则7:对事实的null值要处理
原则8:使用退化维度提高事实表的易用性

1.3事实表设计方法

选择业务过程、声明粒度、确定维度、确定事实、冗余维度

2 事务事实表

2.1设计过程

以淘宝订单流转的业务过程举例有四个:创建订单、买家付款、卖家发货、买家确认收货。

在选择了业务过程以后,相应的事实表类型也随之确定了。比如选择买家付款这个业务过程,那么事实表应为只包含买家付款这一个业务过程的单事务事实表;如果选择的是所有四个业务过程,并且需要分析各个业务过程之间的时间间隔,那么所建立的事实表应为包含了所有四个业务过程的累积快照事实表。

经过声明粒度、确定维度、确定事实后,出于效率和资源考虑,将常用维度退化到事实表中,如下图所示:
【大数据之路】数据模型篇 《四》事实表设计 【搬运小结】_第1张图片
为了提高对事实表进行过滤查询冗余维表的外键到事实表中。
【大数据之路】数据模型篇 《四》事实表设计 【搬运小结】_第2张图片

2.2单事务事实表

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

2.3多事务事实表

多事务事实表,将不同的事实放到同一个事实表中,即同一个事实表包含不同的业务过程。多事务事实表在设计时有两种方法进行事实的处理:不同业务过程的事实使用不同的事实字段进行存放;不同业务过程的事实使用同一个事实字段进行存放,但增加一个业务过程标签。

2.4两种事实表对比

2.4.1业务过程

分析不同业务过程之间的相似性和业务源系统。适合的可以放到同一个事务事实表中。

2.4.2粒度和维度

当不同业务过程的粒度相同,同时拥有相似的维度时,此时就可以考虑采用多事务事实表。

2.4.3事实
单事务事实表在处理事实上比较方便和灵活,如果单一业务过程的事实较多,同时不同业务过程的事实又不相同,则可以考虑使用单事务事实表。

2.4.4下游业务使用

单事务事实表对于下游用户而言更容易理解,关注哪个业务过程就使用相应的事务事实表。

2.4.5计算存储成本

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

2.5父子事实的处理方式

淘宝交易父子订单,在同一个店铺同时下单多种商品,不仅每种商品有一个子订单,而且这几个子订单会再单独产生一个父订单。下单和支付都是在父订单粒度上完成的。通过分摊父订单的金额将所有业务过程的度量全部带进淘宝交易事务事实表中,将父子事实同时冗余到事务表中。

2.6事实的设计准则

1.事实完整性,即尽可能多地获取所有的度量。
2.事实一致性,明确存储每一个事实以确保度量的一致性。
3.事实可加性,比如分摊比例、利润率等,关注更多的是可加性事实,下游用户在聚合统计时更加方便。

3 周期快照事实表

3.1特性

快照事实表以预定的间隔采样状态度量。可以按照日、月或者季度来统计。

3.2实例

单维度的每天快照事实表。(1) 确定粒度(2)确定状态度量
【大数据之路】数据模型篇 《四》事实表设计 【搬运小结】_第3张图片
【大数据之路】数据模型篇 《四》事实表设计 【搬运小结】_第4张图片

混合维度的每天快照事实表。混合维度相对于单维度,只是在每天的采样周期上针对多个维度进行采样。
【大数据之路】数据模型篇 《四》事实表设计 【搬运小结】_第5张图片

全量快照事实表
【大数据之路】数据模型篇 《四》事实表设计 【搬运小结】_第6张图片

3.3注意事项

事务与快照成对设计
数据仓库维度建模时,对于事务.事实表和快照.事实表.往往都是成对设计的,互相补充,以满足更多的下游统计分析需求。

附加事实
一般在设计周期快照事实表时会附加一些上一个采样周期的状态度量。

周期到日期度量
设计周期快照事实表时,就针对多种周期到日期的度量设计了不同的快照事实表,比如淘宝卖家财年至今的下单金额、淘宝商品自然年至今的收藏次数等。

4 累积快照事实表

对于研究事件之间时间间隔的需求,采用累积快照事实表可以很好的解决。

4.1设计过程

对于累积快照事实表,其建模过程和事务事实表相同,适用于维度建模的步骤。
第一步:选择业务过程。淘宝交易订单的流转过程,在事务统计中只关注下单、支付和确认收货三个业务过程;而在统计事件时间间隔的需求中,卖家发货也是关键环节。所以针对淘宝交易累积快照事实表。
第二步:确定粒度。
对于多事件事实表,如果子订单同一周期发生多次事件则记录一行;而对于累积快照事实表,用于考察实体的唯一实例,所以子订单在此表中只有一行记录,事件发生时,对此实例进行更新。
第三步:确定维度。与事务事实表相同。
第四步:确定事实。对于累积快照事实表,需要将各业务过程对应的事实均放人事实表中。

4.2特点

1.数据不断更新
2.多业务过程日期,适用于具有较明确起止时间的短生命周期的实体。

5 三种事实表的比较

【大数据之路】数据模型篇 《四》事实表设计 【搬运小结】_第7张图片

6 无事实的事实表

第一种是事件类的,记录事件的发生。对于每次点击,其事实为1,但一般不会保存此事实。
第二种是条件、范围或资格类的, 记录维度与维度多对多之间的关系“。比如客户和销售人员的分配情况、产品的促销范围等。

7 聚集型事实表

聚集主要是通过汇总明细粒度数据来获得改进查询性能的效果。

7.1聚集的基本原则

一致性。聚集表必须提供与查询明细粒度数据一致的查询结果。
避免单一表设计。不要在同一个表中存储不同层次的聚集数据;否则将会导致双重计算或出现更糟糕的事情。
聚集粒度可不同。聚集并不需要保持与原始明细粒度数据一样的粒度,聚集只关心所需要查询的维度。

7.2聚集的基本步骤

第一步: 确定聚集维度。
第二步:确定一致性上钻。
第三步:确定聚集事实。

7.3阿里公共汇总层

1.基本原则
·数据公用性。
·不跨数据域。
·区分统计周期。

7.4聚集补充说明

1.聚集是不跨越事实的
聚集是针对原始星形模型进行的汇总,为了获取和查询与原始模型一致的结果,聚集的维度和度量必须与原始模型保持一致,因此聚集是不跨越事实的。
2.聚集带来的问题
聚集会带来查询性能的提升,但聚集也会增加ETL维护的难度。当子类目对应的一级类目发生变更时,先前存在的、已经被汇总到聚集表中的数据需要被重新调整。这一额外工作随着业务复杂性的增加,会导致多数ETL人员选择简单强力的方法,删除并重新聚集数据。

你可能感兴趣的:(【大数据之路】数据模型篇,大数据,数据仓库,数据库)