离线数仓(五)【数据仓库建模】(1)https://developer.aliyun.com/article/1532389
第5章 数据仓库设计
5.1 数据仓库分层规划
优秀可靠的数仓体系,需要良好的数据分层结构。合理的分层,能够使数据体系更加清晰,使复杂问题得以简化。以下是该项目的分层规划。
分层的目的就是为了提高开发效率,就比如我之前开发一个桌面软件,因为比较复杂加上自己没有相关经验,导致开发过程有大量的代码冗余,这不要紧,主要是屎山难以维护,我的好多工作需要不断返工 ,对之前设计不合理的地方不断修改,但是屎山牵一发动全身,导致我最后狼狈无比,落荒而逃,只能择日重构整个项目。
- ODS 层:只做数据准备(把数据原封不动从 HDFS 映射到 Hive 表中)不做数据处理
- DWD 层:存放维度模型中的事实表
- DIM 层:存放维度模型中的维度表
- DWS 层:存放后面计算需要的公用中间计算结果,减少重复计算。(DWS 层的数据大多来自 DWD 层)
- ADS 层:存放各项统计指标的结果
5.2 数据仓库构建流程
- 数据调研:业务调研(调研的是业务系统中的数据,要熟悉业务逻辑)和需求分析(数仓后续的应用的需求)
- 明确数据域:对数据进行分类,为的是从业务系统中快速的找到我们希望得到的数据
- 构建业务总线矩阵:其实就是一个二维表格,行代表业务过程,列代表维度,如果业务过程和某个维度有关联就打对钩,最终总线矩阵构建好之后,其实我们的维度模型也基本构建完成了
- 维度模型设计:构建 DWD 层和 DIM 层。维度模型设计由业务驱动是因为我们的事实表取决于业务系统中业务过程,我们的维度表取决于业务系统中的环境,它们和我们后面的指标并没有太大关系。
- 明确统计指标:要做汇总模型就必须明确统计指标,为的是找到统计指标需要的中间计算结果。这个过程会对报表需求进行分析,整理出指标体系,我们可以根据指标体系找到需要存储在 DWS 层的中间计算结果。
- 汇总模型设计:完全依赖于统计指标需求,因为只要知道了需求才能知道要存储哪部分中间结果,所以汇总模型设计是需求驱动的。
5.2.1 数据调研
数据调研重点要做两项工作,分别是业务调研和需求分析。这两项工作做的是否充分,直接影响着数据仓库的质量。
1)业务调研
业务调研的主要目标是熟悉业务流程、熟悉业务数据。
熟悉业务流程要求做到,明确每个业务的具体流程,需要将该业务所包含的每个业务过程一一列举出来。
熟悉业务数据要求做到,将数据(包括埋点日志和业务数据表)与业务过程对应起来,明确每个业务过程会对哪些表的数据产生影响,以及产生什么影响。产生的影响,需要具体到,是新增一条数据,还是修改一条数据,并且需要明确新增的内容或者是修改的逻辑。
下面业务电商中的交易为例进行演示,交易业务涉及到的业务过程有买家下单、买家支付、卖家发货,买家收货,具体流程如下图。
比如我们要建一张加购表(事务事实表),那么我们就需要知道这个业务过程(加购操作)会对哪些表产生影响。首先我们要从业务数据中获取加购操作的信息加载到事实表,就需要有 cart_info 的 binlog 变更日志,Maxwell 的输出是 json 格式的,对于加购表来说,我们需要知道 type=insert 的数据一定是加购操作,至于 type=update 的语句我们需要判断它修改的是哪个字段,如果修改的是 sku_num (商品数量)并且数值是变大的,那这也是加购操作。
2)需求分析
典型的需求指标如,最近一天各省份手机品类订单总额。
分析需求时,需要明确需求所需的业务过程及维度,例如该需求所需的业务过程就是下单这个行为,所需的维度有日期,省份,商品品类。
3)总结
做完业务分析和需求分析之后,要保证每个需求都能找到与之对应的业务过程及维度。若现有数据无法满足需求,则需要和业务方进行沟通,例如某个页面需要新增某个行为的埋点。
5.2.2 明确数据域
数据仓库模型设计除横向的分层外,通常也需要根据业务情况进行纵向划分数据域。划分数据域的意义是便于数据的管理和应用。其实就是方便开发时分工以及之后取数据更快一些。
通常可以根据业务过程或者部门进行划分,本项目根据业务过程进行划分,需要注意的是一个业务过程只能属于一个数据域。因为划分数据域按照业务过程分,所以也就相当于在 DWD 层准备事实表,以及 DWD 上层的 DWS 层的汇总表也会进行划分数据域,它和 DWD 层是一一对应的。但是 DIM 层就不需要划分数据域,因为一张维度表可能被多个事实表关联,所以无法确定它是哪个数据域。
所以,只有在 DWD 层和 DWS 层会进行数据域的划分,DIM 层不会进行数据域的划分。
下面是本数仓项目所需的所有业务过程及数据域划分详情。
数据域 |
业务过程 |
交易域 |
加购、下单、取消订单、支付成功、退单、退款成功 |
流量域 |
页面浏览、启动应用、动作、曝光、错误 |
用户域 |
注册、登录 |
互动域 |
收藏、评价 |
工具域 |
优惠券领取、优惠券使用(下单)、优惠券使用(支付) |
这里也有一些业务过程我们并没有选择,比如交易域中还可以有:减购、确认收货等,但是我们在学习事务型事实表的设计流程中说过,选择自己感兴趣的业务流程,也就是我们需求指标需要用到的业务过程,所以这里没有选择。但是如果前瞻性的创建也不是不行。
流量域相关的业务过程我们并不能直接从业务系统中直接拿到,而是得从用户行为日志中去获取。
5.2.3 构建业务总线矩阵
业务总线矩阵中包含维度模型所需的所有事实(业务过程)以及维度,以及各业务过程与各维度的关系。矩阵的行是一个个业务过程,矩阵的列是一个个的维度,行列的交点表示业务过程与维度存在关联关系。
一个业务过程对应维度模型中一张事务型事实表,一个维度则对应维度模型中的一张维度表。所以构建业务总线矩阵的过程就是设计维度模型的过程。但是需要注意的是,总线矩阵中通常只包含事务型事实表,另外两种类型的事实表(周期快照、累积快照)需要单独设计。
按照事务型事实表的设计流程我们就可以得到业务总线矩阵:选择业务过程 -> 声明粒度 -> 确认维度 -> 确认事实 。
数据域 | 业务过程 | 粒度 | 维度 | 度量 | ||||||||||
时间 | 用户 | 商品 | 地区 | 活动(具体规则) | 优惠券 | 支付方式 | 退单类型 | 退单原因类型 | 渠道 | 设备 | ||||
交易域 | 加购物车 | 一次加购物车的操作 | √ | √ | √ | 商品件数 | ||||||||
下单 | 一个订单中一个商品项 | √ | √ | √ | √ | √ | √ | 下单件数/下单原始金额/下单最终金额/活动优惠金额/优惠券优惠金额 | ||||||
取消订单 | 一次取消订单操作 | √ | √ | √ | √ | √ | √ | 下单件数/下单原始金额/下单最终金额/活动优惠金额/优惠券优惠金额 | ||||||
支付成功 | 一个订单中的一个商品项的支付成功操作 | √ | √ | √ | √ | √ | √ | √ | 支付件数/支付原始金额/支付最终金额/活动优惠金额/优惠券优惠金额 | |||||
退单 | 一次退单操作 | √ | √ | √ | √ | √ | √ | 退单件数/退单金额 | ||||||
退款成功 | 一次退款成功操作 | √ | √ | √ | √ | √ | 退款件数/退款金额 | |||||||
流量域 | 页面浏览 | 一次页面浏览记录 | √ | √ | √ | √ | √ | 浏览时长 | ||||||
动作 | 一次动作记录 | √ | √ | √ | √ | √ | √ | √ | 无事实(次数1) | |||||
曝光 | 一次曝光记录 | √ | √ | √ | √ | √ | √ | √ | 无事实(次数1) | |||||
启动应用 | 一次启动记录 | √ | √ | √ | √ | √ | 无事实(次数1) | |||||||
错误 | 一次错误记录 | √ | √ | √ | √ | 无事实(次数1) | ||||||||
用户域 | 注册 | 一次注册操作 | √ | √ | 无事实(次数1) | |||||||||
登录 | 一次登录操作 | √ | √ | √ | √ | √ | 无事实(次数1) | |||||||
工具域 | 领取优惠券 | 一次优惠券领取操作 | √ | √ | √ | 无事实(次数1) | ||||||||
使用优惠券(下单) | 一次优惠券使用(下单)操作 | √ | √ | √ | 无事实(次数1) | |||||||||
使用优惠券(支付) | 一次优惠券使用(支付)操作 | √ | √ | √ | 无事实(次数1) | |||||||||
互动域 | 收藏商品 | 一次收藏商品操作 | √ | √ | √ | 无事实(次数1) | ||||||||
评价 | 一次取消收藏商品操作 | √ | √ | √ | 无事实(次数1) |
后续的DWD层以及DIM层的搭建需参考业务总线矩阵。
离线数仓(五)【数据仓库建模】(3)https://developer.aliyun.com/article/1532392