数仓中各类型表的示例

概念性知识只是告知思想,对于实际中的应用确没有很好的区分

事实表

事实表,如果按数仓工具箱的划分可以划分为3类
    事务,周期性快照,累计快照

事务事实表

以电商行业为例
买家下单->创建订单->等待买家付款->买家付款->等待卖家发货->卖家发货->等待买家确认收货->买家确认收货->交易成功

1.选择业务过程
    上面的订单流转过程,主要有四个重要过程:订单创建,买家付款,卖家发货,买家确认
    也可以说是下单,支付,发货,成功完结四个业务过程
    对于Kimball维度建模理论,应该对这四个业务过程单独去建立事实表
    然而实际上并不会这样去做emm
2.声明粒度
    购过物的人都知道,像一笔主订单,可能附带多个商家的子订单
    那么我们声明粒度的时候,能声明到主订单就行了么,答案肯定是不行
    那样就没有办法区分这笔订单到底归属哪个商家
3.确认维度
    在声明粒度之后,我们大致能得到一份初始的表结构
    我们应该在这个表结构上进行维度的提取
    像商家,买家,商品,类目,收货地区,发货地区等
4.确认事实
    上面的操作完成之后,我们的事实表也就出来了
    商家,买家,主订单ID,子订单ID,商品ID,商品类目,收货地区,发货地区,下单时间,付款时间,收货时间,金额,数量
5.维度退化
    这一步可有可无,主要是将一些后续常用的维度信息,保留在事实表内
    如:店铺名,买家名,商品名等

周期性快照事实表

emm,这种事实表你要是光理论,我觉得能看懵
而且对应到实际中去,怎么给他进行分层呢,划到哪层都不适合
除非新开一层his

单维度/混合维度每天快照事实表
1.声明粒度
    确定针对卖家,买家,商品,类目,地区等维度的快照事实表
    如:卖家历史至今快照事实表
2.确定度量
    确定针对这个粒度需要采样的状态度量
    如:历史截止当日{下单金额,下单买家数,支付金额,支付买家数,浏览PV,浏览UV}
最终的表设计
    (混合维)业务日期,卖家ID,买家ID,历史截止当日{下单金额,下单子订单数,支付金额,支付子订单数......}
    (单维)业务日期,商品ID,历史截止当日{下单金额,下单买家数,支付金额,支付买家数,浏览PV,浏览UV,加购物车次数,收藏次数......}

累计快照事实表

其实很简单进行理解,就是保留一份和目前业务系统中某一时间状态一致的数据
像事务事实表,下单,支付,收货在不同的3天完成
那么在整张表中,就会有3条数据,每个天分区一条

对于累计快照事实表来说,在整张表中,就一条数据,就最新的那条数据

全量表:一般就是日分区,每天拉取一份全量的业务数据,不适用数据量大的场景
全量变化表:累计快照事实表只用于保存生命周期短的数据
所以可以拉取业务最大时间间隔的全量数据
拉链表:每天分区中存储当天结束的业务,用一个非常大的分区(9999-12-31)保存未结束的记录

聚集事实表

这一类事实表,分层可以看做为DWS层,对不同粒度进行一系列上卷产生的
如: 
卖家ID,买家ID,类目ID,商品ID,最近一天{交易额,订单量......}
卖家ID,买家ID,类目ID,最近一天{交易额,订单量,商品数......}
卖家ID,买家ID,最近一天{交易额,订单量,商品数,类目数......}
卖家ID,最近一天{交易额,订单量,商品数,类目数,买家数......}

---

维度表

维度
维度建模中,度量称为事实,环境描述称为维度,维度是分析事实需要的多样环境

维度属性
维度所包含的表示维度的列,称为维度属性
一般是查询约束,分类汇总以及排序等

设计方法
选择维度或新建维度:保证维度的唯一性
确定主维表:一般是ODS表,直接从业务系统同步
确定相关维表:不同业务系统或同一业务系统中表存在关联性
    梳理业务,确定哪些表与主维表存在关联关系,选择其中一些表用于生成维度属性
确定维度属性:从主维表选择维度属性或生成新的维度属性
    再从相关维表中选择维度属性或生成维度属性
    维度属性尽可能给出文字性描述(商品ID,商品名称,类目ID,类目名称等)

维度层次结构
维度一些描述属性以层次方式或一对多的方式相关联,可以被理解为包含连续主从关系的属性层次
如:商品->类目->行业
类目又有叶子类目->二级类目->一级类目
这样就可以一层层上卷或下钻

雪花和星型模式
雪花为维表之间仍然有维表间的层次关联关系
如:商品维表有类目ID然后可以关联类目维表,类目又可以关联行业
星型为维度属性层次合并到单个维度中
如:商品维表中直接包括类目,行业等其他层次维度属性
雪花复杂性上升,表存储节约,表关联可能复杂
星型降低复杂性,减少表关联,用空间换简明性