OneData:
一致性的指标定义、模型设计以及配套工具(表命名、字段命名、指标命名)
OneService:
对外提供接口的方式提供服务。主要三大类:简单数据查询服务、复杂数据查询服务(集团用户识别、用户画像)、实时数据推送服务
三种模型:
星型模型
- 以事实表为中心,所有维度表直接连接在事实表上 像星星一样
- 维表直接没有关联
雪花模型
- 雪花模型的维度表可以拥有维度表
- 缺点:查询性能低 因为需要join多层维表
星座模型
- 星型模型是基于一张事实表的,星座模型是基于多张事实表的,而且共享维度信息。
- 业务发展后期,大部分维度建模都是星座模型
星型模型 雪花模型的不同
- 维度的层级不同,标准的星型模型只有一级维表,而雪花模型可能会有多级维表
维度建模的步骤
四步骤:选择业务过程→声明粒度→确认维度→确认事实
DWD层需构建维度模型,一般采用星型模型,呈现的状态一般为星座模型。
选择业务过程
在业务系统中,挑选我们感兴趣的业务线,比如下单业务,支付业务,退款业务,物流 业务,一条业务线对应一张事实表。
如果是中小公司,尽量把所有业务过程都选择。
如果是大公司(1000多张表),选择和需求相关的业务线。
声明粒度
数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别。 声明粒度意味着精确定义事实表中的一行数据表示什么,应该尽可能选择最小粒度,以此来应各种各样的需求。
典型的粒度声明如下: 订单当中的每个商品项作为下单事实表中的一行,粒度为每次。 每周的订单次数作为一行,粒度为每周。
每月的订单次数作为一行,粒度为每月。
如果在DWD层粒度就是每周或者每月,那么后续就没有办法统计细粒度的指标了。所以建议采用最小粒度。
确定维度
维度的主要作用是描述业务是事实,主要表示的是“谁,何处,何时”等信息。
确定维度的原则是:后续需求中是否要分析相关维度的指标。例如,需要统计,什么时间下的订单多,哪个地区下的订单多,哪个用户下的订单多。需要确定的维度就包括:时间 维度、地区维度、用户维度。
维度表:需要根据维度建模中的星型模型原则进行维度退化。
确定事实
此处的“事实”一词,指的是业务中的度量值(次数、个数、件数、金额,可以进行累加),例如订单金额、下单次数等。
在DWD层,以业务过程为建模驱动,基于每个具体业务过程的特点,构建最细粒度的明细层事实表。事实表可做适当的宽表化处理。 事实表和维度表的关联比较灵活,但是为了应对更复杂的业务需求,可以将能关联上的表尽量关联上。如何判断是否能够关联上呢?在业务表关系图中,只要两张表能通过中间表能够关联上,就说明能关联上。
构建总线矩阵
| 时间 | 用户 | 地区 | 商品 | 优惠券 | 活动 | 编码 | 度量值 | |
|---|---|---|---|---|---|---|---|---|
| 订单 | √ | √ | √ | √ | 件数/金额 | |||
| 订单详情 | √ | √ | √ | √ | 件数/金额 | |||
| 支付 | √ | √ | √ | 金额 | ||||
| 加购 | √ | √ | √ | 件数/金额 | ||||
| 收藏 | √ | √ | √ | 个数 | ||||
| 评价 | √ | √ | √ | 个数 | ||||
| 退款 | √ | √ | √ | 件数/金额 | ||||
| 优惠券领用 | √ | √ | √ | 个数 |
