数仓建模
2023-06-19 17:01:27 3 举报AI智能生成
登录查看完整内容
基于阿里数仓和美团数仓整理的数仓分层理论
作者其他创作
大纲/内容
1）HDFS用户行为数据
2）HDFS业务数据
3) 爬虫数据
数据来源
（1）保持数据原貌不做任何修改，起到备份数据的作用。
例如：原始数据100G，可以压缩到10G左右
（2）数据采用压缩，减少磁盘存储空间
（3）创建分区表，防止后续的全表扫描
处理规划
2.4.1 ODS层
DWD层需构建维度模型，一般采用星型模型，呈现的状态一般为星座模型。
选择业务过程→声明粒度→确认维度→确认事实
在业务系统中，挑选我们感兴趣的业务线，比如下单业务，支付业务，退款业务，物流业务，一条业务线对应一张事实表。
中小公司，尽量把所有业务过程都选择。
大公司（1000多张表），选择和需求相关的业务线。
（1）选择业务过程
数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别。
是什么
声明粒度意味着精确定义事实表中的一行数据表示什么，应该尽可能选择最小粒度，以此来应各种各样的需求。
粒度的声明原则:
订单当中的每个商品项作为下单事实表中的一行，粒度为每次。
每周的订单次数作为一行，粒度为每周。
每月的订单次数作为一行，粒度为每月。
如果在DWD层粒度就是每周或者每月，那么后续就没有办法统计细粒度的指标了。所有建议采用最小粒度。
典型的粒度声明：
（2）声明粒度
维度的主要作用是描述业务是事实，主要表示的是“谁，何处，何时”等信息。
例如，需要统计，什么时间下的订单多，哪个地区下的订单多，哪个用户下的订单多。需要确定的维度就包括：时间维度、地区维度、用户维度。
后续需求中是否要分析相关维度的指标。
维度表：需要根据维度建模中的星型模型原则进行维度退化。
确定维度的原则是：
（3）确定维度
此处的“事实”一词，指的是业务中的度量值，例如订单金额、下单次数等。
在DWD层，以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的明细层事实表。事实表可做适当的宽表化处理。
（4）确定事实
维度建模一般按照以下四个步骤：
事实表和维度表的关联比较灵活，但是为了应对更复杂的业务需求，可以将能关联上的表尽量关联上。
时间 用户 地区 商品 优惠券 活动 编码 度量值
订单 √ √ √ √ 件数/金额
订单详情 √ √ √ 件数/金额
支付 √ √ 金额
加购 √ √ √ 件数/金额
收藏 √ √ √ 个数
评价 √ √ √ 个数
退款 √ √ √ 件数/金额
优惠券领用 √ √ √ 个数
如何判断是否能够关联上呢？在业务表关系图中，只要两张表能通过中间表能够关联上，就说明能关联上。
事实表和维度表的关联
2.4.2 DWD层
DWS层统计各个主题对象的当天行为，服务于DWT层的主题宽表。
（1）问题引出：两个需求，统计每个省份订单的个数、统计每个省份下单的总金额
地区宽表的字段设计为：下单次数、下单金额、支付次数、支付金额等。只需要和每个事实表一次join。
那怎么设计能避免重复计算呢？
（2）处理办法：都是将省份表和订单表进行join，然后计算。相当于类似的需求重复join计算了两次。
需要建哪些表：以维度为基准，去关联对应多个事实表
宽表里面的字段：是站在不同维度的角度去看事实表，重点关注事实表聚合后的度量值。
分支主题
（3）总结：
（4）DWS层宽表包括：每日设备行为、每日会员行为、每日商品行为、每日活动统计、每日地区统计。
DWS处理过程
2.4.3 DWS层
DWT层统计各个主题对象的累积行为。
（1）需要建哪些表：和DWS层一样。以维度为基准，去关联对应多个事实表
例如，订单事实表的度量值是下单次数、下单金额。订单事实表的行为是下单。我们站在用户维度表的角度去看订单事实表，重点关注订单事实表至今的累积下单次数、累积下单金额和某时间段内的累积次数、累积金额，以及关注下单行为的首次时间和末次时间。
（2）宽表里面的字段：我们站在维度表的角度去看事实表，重点关注事实表度量值的累积值、事实表行为的首次和末次时间。
2.4.4 DWT层
对电商系统各大主题指标分别进行分析。
2.4.5 ADS层
DWD层是以业务过程为驱动。
DWS层、DWT层和ADS层都是以需求为驱动，和维度建模已经没有关系了。
DWS和DWT都是建宽表，按照主题去建表。主题相当于观察问题的角度。对应着维度表。
总结
数仓建模
0 条评论
回复 删除
下一页
