大数据开发工程师需要了解的数仓中事实表的设计

Posted <一蓑烟雨任平生>

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了大数据开发工程师需要了解的数仓中事实表的设计相关的知识,希望对你有一定的参考价值。

(1)如何正确看待事实表

(2)企业中事实表的设计原则

原则一:尽可能包含所有与业务过程相关的事实
在事实表中应该尽量包含所有与业务过程相关的事实,即使存在冗余,但是因为事实通常为数字类型,带来的存储开销也不会很大。

原则二:只选择与业务过程相关的事实
比如在订单的下单这个业务过程的事实表设计中,不应该存在支付金额这个标识支付业务过程的事实。

原则三:分解不可加性事实为可加的组件
比如订单的优惠率,应该分解为订单原价金额与订单优惠金额两个事实存储在事实表。

原则四:在选择维度和事实之前必须先声明粒度
建议从最低级别的原子粒度开始,因为原子粒度最大限度的灵活性。

原则五:在同一个事实表中不能有多种不同粒度的事实
事实表中的所有事实需要与表定义的粒度保持一致,在同一个事实表中不能有多种不同粒度的事实。

原则六:事实的单位要保持一致
对于同一个事实表中事实的单位,应该保持一致。比如原订单金额、订单优惠金额、订单运费金额这三个事实,应该采用一致的计量单位,统一为元或者分。

原则七:对事实的NULL值要处理
NULL值对常用数字类型字段的SQL过滤条件都不生效,建议用0补充。

原则八:使用退化维度提高事实表的易用性
通过增加冗余存储的方式减少计算开销,提高使用效率,大多数会采用退化维度的方式。

(3)事物事实表的设计流程

第一步:选择业务过程及确定事实表类型
分析整个业务生命周期,明确关键业务步骤,选择与需求有关的业务过程。

电商交易订单的流转过程:

第二步:声明粒度
精确定义事实表的每一行所表示的业务含义,粒度传递的是与事实表度量有关的细节层次。
应该尽量选择最细级别的原子粒度

第三步:确定维度
选择能描述清楚业务过程所处环境的维度信息。


第四步:确定事实
确定过程度量,将不可加事实分解为可加。

第五步:冗余维度

通常事实表中会冗余方便下游用户使用的常用维度。

(4)深入事物事实表的设计

单事务事实表设计案例

多事务事实表
多事务事实表,将不同的事实放到同一个事实表中,即同一个事实表包含不同的业务过程。

多事务事实表在设计时有两种方法进行事实的处理:

  • 第一种:不同业务过程的事实使用不同的事实字段进行存放

比如交易事务事实表,可以把流程中的下单、支付、成功完结三个业务过程放进去。


  • 第二种:不同的业务过程的事实使用同一个事实字段进行存放,但增加一个业务过程标签比如商品收藏事务事实表。

单事务事实表与多事务事实表的比较

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

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

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

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

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

(5)怎么理解周期快照事实表

快照事实表的设计有些区别与事务事实表设计的性质。事务事实表的粒度能以多种方式表达,但快照事实表的粒度通常以维度形式声明;

事务事实表是稀疏的,但快照事实表是稠密的;



单维度的每天快照事实表:


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

(6)累计快照事实表的设计

设计过程
第一步:选择业务过程
比如:统计事件时间间隔的需求,买家付款与卖家发货的时间间隔,卖家发货与买家确认
收获的时间间隔。

第二步:确定粒度
对子订单的事件发生时间进行更新。

第三步:确定维度
四个业务过程对应的时间字段。

第四步:确定事实
累计快照事实表解决的最最要的问题是统计不同业务过程之间的时间间隔,建议将每个过程的时间间隔作为事实放在事实表中。


第五步:退化维度
在物理实现中将各维度的常用属性退化到事实表中,以大大提高对事实表的过滤查询。

累计事实表的特点

(7)三种事实表的应用场景


以上内容仅供参考学习,如有侵权请联系我删除!
如果这篇文章对您有帮助,左下角的大拇指就是对博主最大的鼓励。
您的鼓励就是博主最大的动力!

以上是关于大数据开发工程师需要了解的数仓中事实表的设计的主要内容,如果未能解决你的问题,请参考以下文章

大数据开发工程师需要了解的数仓中事实表的设计

大数据开发工程师需要了解的数仓中事实表的设计

大数据开发工程师需要了解的数仓中事实表的设计

大数据开发工程师需要了解的数仓中的维度设计

大数据开发工程师需要了解的数仓中的维度设计

大数据开发工程师需要了解的数仓中的维度设计