1)HDFS用户行为数据
2)HDFS业务数据
3)针对HDFS上的用户行为数据和业务数据,我们如何规划处理?
(1)保持数据原貌不做任何修改,起到备份数据的作用。
(2)数据采用压缩,减少磁盘存储空间(例如:原始数据100G,可以压缩到10G左右)
(3)创建分区表,防止后续的全表扫描
DIM层DWD层需构建维度模型,一般采用星型模型,呈现的状态一般为星座模型。
维度建模
(1)为什么维度建模,不选三范式建模
从分析决策的需求出发构建模型,为分析需求服务,重点关注用户如何快速的完成需求分析,具有较好的大规模复杂查询的响应性能
(2)基本概念介绍
【业务过程】:下订单
【粒度】:每笔订单(拆分为单个物品)
【维度】:地域、年龄、渠道等(可供分析的角度)
【事实/度量】:订单金额等(可用于分析的数据)
一般维度建模步骤(全程6步,主要步骤有4步)
维度建模主要按照以下四个步骤:
选择业务过程→声明粒度→确认维度→确认事实
(1)选择业务过程
在业务系统中,挑选我们感兴趣的业务线,比如下单业务,支付业务,退款业务,物流业务,一条业务线对应一张事实表。
(2)声明粒度
数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别。
声明粒度意味着精确定义事实表中的一行数据表示什么,应该尽可能选择最小粒度,以此来应各种各样的需求。
典型的粒度声明如下:
订单事实表中一行数据表示的是一个订单中的一个商品项。
支付事实表中一行数据表示的是一个支付记录。
(3)确定维度
维度的主要作用是描述业务是事实,主要表示的是“谁,何处,何时”等信息。
确定维度的原则是:后续需求中是否要分析相关维度的指标。例如,需要统计,什么时间下的订单多,哪个地区下的订单多,哪个用户下的订单多。需要确定的维度就包括:时间维度、地区维度、用户维度。
(4)确定事实
此处的“事实”一词,指的是业务中的度量值(次数、个数、件数、金额,可以进行累加),例如订单金额、下单次数等。
在DWD层,以业务过程为建模驱动,基于每个具体业务过程的特点,构建最细粒度的明细层事实表。事实表可做适当的宽表化处理。
事实表和维度表的关联比较灵活,但是为了应对更复杂的业务需求,可以将能关联上的表尽量关联上。
时间 |
用户 |
地区 |
商品 |
优惠券 |
活动 |
度量值 |
|
订单 |
√ |
√ |
√ |
运费/优惠金额/原始金额/最终金额 |
|||
订单详情 |
√ |
√ |
√ |
√ |
√ |
√ |
件数/优惠金额/原始金额/最终金额 |
支付 |
√ |
√ |
√ |
支付金额 |
|||
加购 |
√ |
√ |
√ |
件数/金额 |
|||
收藏 |
√ |
√ |
√ |
次数 |
|||
评价 |
√ |
√ |
√ |
次数 |
|||
退单 |
√ |
√ |
√ |
√ |
件数/金额 |
||
退款 |
√ |
√ |
√ |
√ |
件数/金额 |
||
优惠券领用 |
√ |
√ |
√ |
次数 |
至此,数据仓库的维度建模已经完毕,DWD层是以业务过程为驱动。
DWS层、DWT层和ADS层都是以需求为驱动,和维度建模已经没有关系了。
DWS和DWT都是建宽表,按照主题去建表。主题相当于观察问题的角度。对应着维度表。
DWS层和DWT层统称宽表层,这两层的设计思想大致相同,通过以下案例进行阐述。
1)问题引出:两个需求,统计每个省份订单的个数、统计每个省份订单的总金额
2)处理办法:都是将省份表和订单表进行join,group by省份,然后计算。同样数据被计算了两次,实际上类似的场景还会更多。
那怎么设计能避免重复计算呢?
针对上述场景,可以设计一张地区宽表,其主键为地区ID,字段包含为:下单次数、下单金额、支付次数、支付金额等。上述所有指标都统一进行计算,并将结果保存在该宽表中,这样就能有效避免数据的重复计算。
3)总结:
(1)需要建哪些宽表:以维度为基准。
(2)宽表里面的字段:是站在不同维度的角度去看事实表,重点关注事实表聚合后的度量值。
(3)DWS和DWT层的区别:DWS层存放的所有主题对象当天的汇总行为,例如每个地区当天的下单次数,下单金额等,DWT层存放的是所有主题对象的累积行为,例如每个地区最近7天(15天、30天、60天)的下单次数、下单金额等。
对电商系统各大主题指标分别进行分析。