离线数仓(五)【数据仓库建模】(3)https://developer.aliyun.com/article/1532392
我们把上面所有的派生指标拿出来分析:
原子指标 | 统计周期 | 业务限定 | 统计粒度 | ||
业务过程 | 度量值 | 聚合逻辑 | |||
页面浏览 | * | * | 最近1/7/30日 | 会话 | |
页面浏览 | during_time | sum() | 最近1/7/30日 | 会话 | |
页面浏览 | 1 | count() | 最近1/7/30日 | 会话 | |
页面浏览 | * | * | 最近1/7/30日 | 会话 | |
页面浏览 | 1 | count() | 最近1/7/30日 | 会话 | |
页面浏览 | 1 | count() | 最近1/7/30日 | 访客-页面 | |
页面浏览 | 1 | count() | 最近1/7/31日 | 访客-页面 | |
用户登录 | date_id | max() | 历史至今 | 用户 | |
用户登录 | date_id | max() | 历史至今 | 用户 | |
用户登录 | date_id | max() | 历史至今 | 用户 | |
用户登录 | date_id | max() | 历史至今 | 用户 | |
加购 | 1 | count() | 最近1/7/30日 | 用户 | |
下单 | 订单金额 | sum() | 最近1/7/30日 | 用户 | |
下单 | order_id | count(distinct()) | 最近1/7/30日 | 用户 | |
下单 | order_id | count(distinct) | 最近1/7/30日 | 用户 | |
下单 | order_id | count(distinct) | 最近1/7/30日 | 用户 | |
下单 | date_id | min() | 历史至今 | 用户 | |
下单 | date_id | max() | 历史至今 | 用户 | |
下单 | 1 | count() | 最近30日 | 用户-商品 | |
下单 | 1 | count() | 最近1/7/30日 | 用户-商品 | |
下单 | 1 | count() | 最近1/7/30日 | 用户-商品 | |
下单 | 1 | count() | 最近1/7/30日 | 用户-商品 | |
下单 | 1 | count() | 最近1/7/30日 | 用户-商品 | |
下单 | order_id | count(distinct) | 最近1/7/30日 | 省份 | |
下单 | 订单金额 | sum() | 最近1/7/30日 | 省份 | |
下单 | 订单原始金额 | sum() | 最近30日 | 订单使用优惠券(coupon_id不为null)且优惠券发布日期在最近30日内 | 优惠券 |
下单 | 优惠券优惠金额 | sum() | 最近30日 | 订单使用优惠券(coupon_id不为null)且优惠券发布日期在最近30日内 | 优惠券 |
下单 | 订单原始金额 | sum() | 最近30日 | 订单参与活动(activity_id不为null)且活动的发布日期在最近30日内 | 活动 |
下单 | 活动优惠金额 | sum() | 最近30日 | 订单参与活动(activity_id不为null)且活动的发布日期在最近30日内 | 活动 |
退单 | 1 | count() | 最近1/7/30日 | 用户-商品 | |
退单 | 1 | count() | 最近1/7/30日 | 用户-商品 | |
退单 | 1 | count() | 最近1/7/30日 | 用户-商品 | |
退单 | 1 | count() | 最近1/7/30日 | 用户-商品 | |
退单 | 1 | count() | 最近1/7/30日 | 用户 | |
退单 | 1 | count() | 最近1/7/30日 | 用户 | |
支付 | date_id | min() | 历史至今 | 用户 | |
支付 | order_id | count(distinct()) | 最近1/7/30日 | 用户 |
这样我们就可以清楚的看到表中存在很多相同的派生指标,那我们就可以依据这些公共的派生指标去给 DWS 层建表,但是我们并不是把业务过程相同、统计周期相同、统计粒度相同、度量值、聚合逻辑都相同的数据放到同一张汇总表,具体设计看下面的汇总表模型设计。
5.2.4 维度模型设计
维度模型的设计参照上述得到的业务总线矩阵即可。事实表存储在DWD层,维度表存储在DIM层。
5.2.5 汇总模型设计
汇总模型的设计参考上述整理出的指标体系(主要是派生指标)即可。汇总表与派生指标的对应关系是,一张汇总表通常包含业务过程相同、统计周期相同、统计粒度相同的多个派生指标。而不是非得度量值、聚合逻辑也都相同才放到一张汇总表中(不通需求的度量值和聚合逻辑总是不一样的)。
比如上面的表格中,我们可以发现:
原子指标 | 统计周期 | 业务限定 | 统计粒度 | ||
业务过程 | 度量值 | 聚合逻辑 | |||
页面浏览 | * | * | 最近1/7/30日 | 会话 | |
页面浏览 | during_time | sum() | 最近1/7/30日 | 会话 | |
页面浏览 | 1 | count() | 最近1/7/30日 | 会话 | |
页面浏览 | * | * | 最近1/7/30日 | 会话 | |
页面浏览 | 1 | count() | 最近1/7/30日 | 会话 | |
页面浏览 | 1 | count() | 最近1/7/30日 | 访客-页面 | |
页面浏览 | 1 | count() | 最近1/7/31日 | 访客-页面 |
其中存在完全相同结构的派生指标:
页面浏览 | 1 | count() | 最近1/7/30日 | 会话 |
页面浏览 | 1 | count() | 最近1/7/30日 | 访客-页面 |
但是我们并不会直接把这种完全相同派生指标的计算结果存储一份到 DWS 层,而是把具有业务过程相同、统计周期相同、统计粒度相同的多个派生指标计算结果分别存到汇总表中:
原子指标 | 统计周期 | 业务限定 | 统计粒度 | ||
业务过程 | 度量值 | 聚合逻辑 | |||
页面浏览 | * | * | 最近1/7/30日 | 会话 | |
页面浏览 | during_time | sum() | 最近1/7/30日 | 会话 | |
页面浏览 | 1 | count() | 最近1/7/30日 | 会话 | |
页面浏览 | * | * | 最近1/7/30日 | 会话 | |
页面浏览 | 1 | count() | 最近1/7/30日 | 会话 |
页面浏览 | 1 | count() | 最近1/7/30日 | 访客-页面 | |
页面浏览 | 1 | count() | 最近1/7/31日 | 访客-页面 |
业务过程相同,说明我们会用到同一张事实表;统计周期相同,说明会用到同一张事实表的同一天的数据;统计粒度相同,说明我们的每一行代表的含义是相同的。
汇总表与事实表的对应关系是?
一个汇总表只对应一个事实表(因为汇总表必须有相同的业务过程,而一个业务过程又对应一个事实表),但是一个事实表对应多个汇总表,因为我们的需求(派生指标)统计粒度和统计周期可能不同。
总结
现在是 2024-3-9 16:25 ,数仓建模的知识终于学完了,用了近一周。理论的学习还是非常有必要的,这是我现在越发体会到的。就比如最近背的面试题,你要说写代码用的上吗?那一般指定用不上,但是对你不论是理解代码还是二次开发都是必须熟悉的。就像 MapReduce 程序工作会让我们去写吗,那肯定不会,都是用 Hive SQL ,但是不了解行吗?就像 Flink 的水位线不去了解它怎么做到精确一次背后的原理,只会跟着视频敲代码那也绝对屁用没有。所以很多人说 Java 网上 SSM 十几个小时速成,我看完多练练就精通了,但是 SSM 背后的反射机制、注解、代理模式、单例模式、工厂模式这些东西自己不懂那只能说你的上限也就到这了。