系列文章目录
前言
一、数据仓库建模
数仓建模中主要提供两种理论来进行数仓建模操作: 三范式建模和维度建模理论
三范式建模(即关系建模): 主要是存在关系型数据库建模方案上, 主要规定了比如建表的每一个表都应该有一个主键, 数据要经历的避免冗余发生等等,严格遵守第三范式(3NF)
维度建模: 主要是存在分析性数据库建模方案上, 主要一切以分析为目标, 只要是利于分析的建模, 都是OK的, 允许出现一定的冗余, 表也可以没有主键
【1】、三范式
自下而上的,从数据出发
基础概念
依赖 x→y
部分依赖 多个x对应一个y 多对一关系
完全依赖 y完全由x确定 一对一关系
主属性、非主属性、码的辨别
第一步画出函数关系(依赖)
主属性:可以作为x的
非主属性 :剩余的
码的判断 取出的码能与剩余构成的集合,形成依赖,码不是唯一的(多个组成)
第一范式:表创建成功即满足第一范式
但存在数据冗余与
增:无法单独插入(缺少其他属性)
删:删除某字段所有记录,其他字段同时被删除
改: 修改繁琐,修改一个字段值,需修改多条
四项数据问题
第二范式 消除了非主属性对码的部分依赖
改进了冗余与修改繁琐问题,通过分表消除依赖
第三范式 消除了非主属性对码的传递依赖
改进了增删问题,通过分表消除依赖
但满足三范式仍然可能存在 增删改问题
造成原因:主属性 对码存在部分与传递函数依赖
因此继续递进存在新范式,暂且不做讲述
事实表中的每行数据代表一个业务事件(下单、支付、退款、评价等)。
【2】、维度建模
自上而下的,从决策需求出发
(1)基本概念
模型,模型是映射 “事实” 的东西,构建这个东西的动作就叫做建模。
维度,就是我们要进行分析的角度。
例如品牌的维度分析,日期维度分析
指标:
衡量数据,指标是指可以按总数或比值衡量的具体维度元素。例如,维度“城市”可以关联指标“人口”,其值为具体城市的居民总数。
维度和指标的关系:
虽然维度和指标可以独立使用,但常见的还是相互结合使用。维度和指标的值以及这些值之间的关系,使您的数据具有了意义。
为了挖掘尽可能多的深层次信息,维度通常与一个或多个指标关联在一起。例如,维度“城市”可以与指标“人口”和“面积”相关联。有了这些数据,系统还可以创建“人口密度”等比值指标,带来有关这些城市的更详细的深入信息。
度量:
事实表和维度交叉汇聚的点,度量和维度构成OLAP的主要概念,这里面对于在事实表或者一个多维立方体里面存放的数值型的、连续的字段,就是度量。这符合上面的意思,有标准,一个度量字段肯定是统一单位,例如元、户数。如果一个度量字段,其中的度量值可能是欧元又有可能是美元,那这个度量可没法汇总。在统一计量单位下,对不同维度的描述。
指标与度量的关系:
这就得说到指标,我愿意表述为"它是表示某种相对程度的值"。区别于上面的度量概念,那是一种绝对值,尺子量出来的结果,汇总出来的数量等。而指标至少需要两个度量之间的计算才能得到,例如收入增长率,用本月收入比上上月收入。当然可能指标的计算还需要两个以上的度量。
(2)建模流程
选择业务过程→声明粒度→确认维度→确认事实
维度建模的两个核心概念:事实表和维度表
流程
(1)选择业务过程
在业务系统中,挑选我们感兴趣的业务线,比如下单业务,支付业务,退款业务,物流业务,一条业务线对应一张事实表。
(2)声明粒度
数据粒度:指数据仓库的数据中保存数据的细化程度或综合程度的级别。
通俗来说就是一条新增的记录
声明粒度意味着精确定义事实表中的一行数据表示什么,应该尽可能选择最小粒度,以此来应各种各样的需求。
举例:典型的粒度声明如下:
订单事实表中一行数据表示的是一个订单中的一个商品项。
支付事实表中一行数据表示的是一个支付记录。
(3)确定维度
维度的主要作用是描述业务是事实,主要表示的是“谁,何处,何时”等信息。
确定维度的原则是:后续需求中是否要分析相关维度的指标。例如,需要统计,什么时间下的订单多,哪个地区下的订单多,哪个用户下的订单多。需要确定的维度就包括:时间维度、地区维度、用户维度。
(4)确定事实
此处的“事实”一词,指的是业务中的度量值(次数、个数、件数、金额,可以进行累加),例如订单金额、下单次数等。
在DWD层,以业务过程为建模驱动,基于每个具体业务过程的特点,构建最细粒度的明细层事实表。事实表可做适当的宽表化处理。
事实表和维度表的关联比较灵活,但是为了应对更复杂的业务需求,可以将能关联上的表尽量关联上。
事实表与维度表
(1)事实表
事实表中的每行数据代表一个业务事件(下单、支付、退款、评价等)
事务型事实表
以每个事务或事件为单位,例如一个销售订单记录,一笔支付记录等,作为事实表里的一行数据。一旦事务被提交,事实表数据被插入,数据就不再进行更改,其更新方式为增量更新。
周期型快照事实表
周期型快照事实表中不会保留所有数据,只保留固定时间间隔的数据,例如每天或者每月的销售额,或每月的账户余额等,只关注每个时间点的数据。
例如购物车,有加减商品,随时都有可能变化,但是我们更关心每天结束时这里面有多少商品,方便后期统计分析。
累积型快照事实表
**累计快照事实表用于跟踪业务事实的变化。**例如,数据仓库中可能需要累积或者存储订单从下订单开始,到订单商品被打包、运输、和签收的各个业务阶段的时间点数据来跟踪订单声明周期的进展情况。当这个业务过程进行时,事实表的记录也要不断更新
(2)维度表
在设计维度表时,如果对其进行规范化,得到的维度模型称为雪花模型,如果对其进行反规范化,得到的模型称为星型模型。
规范化:是指使用一系列范式设计数据库的过程,其目的是减少数据冗余,增强数据的一致性。通常情况下,规范化之后,一张表的字段会拆分到多张表。
反规范化:是指将多张表的数据冗余到一张表,其目的是减少join操作,提高查询性能。
在设计维度表时,如果对其进行规范化,得到的维度模型称为雪花模型,如果对其进行反规范化,得到的模型称为星型模型
第一种: 星型模型
特点: 只有一个事实表, 那么也就意味着只有一个分析的主题, 在事实表的周围围绕了多个维度表, 维度表与维度表之间没有任何的依赖
反映数仓发展初期最容易产生模型
第二种: 雪花模型
特点: 只有一个事实表, 那么也就意味着只有一个分析的主题, 在事实表的周围围绕了多个维度表, 维度表可以接着关联其他的维度表
反映数仓发展出现了畸形产生模型, 这种模型一旦大量出现, 对后期维护是非常繁琐, 同时如果依赖层次越多, SQL分析的难度也会加大
此种模型在实际生产中,建议尽量减少这种模型产生
第三种: 星座模型
特点: 有多个事实表, 那么也就意味着有了多个分析的主题, 在事实表的周围围绕了多个维度表, 多个事实表在条件符合的情况下, 可以共享维度表
二、数仓分层
数仓分仓不是绝对的,是根据业务需求变化的
数仓分层的意义
合理的分层,能够使数据体系更加清晰,使复杂问题得以简化,而在未分层的情况下,数据之间的耦合性与业务耦合性是不可避免的,当源业务系统的业务规则发生变化时,可能影响整个数据的清洗过程。
接下来演示一种
事实表存储在DWD层,维度表存储在DIM层。
服务层DWS
三、数据仓库构建流程
【数据调研】
数据调研重点要做两项工作,分别是业务调研和需求分析。这两项工作做的是否充分,直接影响着数据仓库的质量。
1、业务调研
业务调研的主要目标是熟悉业务流程、熟悉业务数据。
熟悉业务流程要求做到,明确每个业务的具体流程,需要将该业务所包含的每个业务过程一一列举出来
熟悉业务数据要求做到,将数据(包括埋点日志和业务数据表)与业务过程对应起来,明确每个业务过程会对哪些表的数据产生影响,以及产生什么影响。产生的影响,需要具体到,是新增一条数据,还是修改一条数据,并且需要明确新增的内容或者是修改的逻辑。
2、需求分析
典型的需求指标如,最近一天各省份手机品类订单总额。
分析需求时,需要明确需求所需的业务过程及维度,例如该需求所需的业务过程就是买家下单,所需的维度有日期,省份,商品品类。
3、总结
做完业务分析和需求分析之后,要保证每个需求都能找到与之对应的业务过程及维度。若现有数据无法满足需求,则需要和业务方进行沟通,例如某个页面需要新增某个行为的埋点。
【明确数据域】
数据仓库模型设计除横向的分层外,通常也需要根据业务情况进行纵向划分数据域。
划分数据域的意义是便于数据的管理和应用。
通常可以根据业务过程或者部门进行划分,本项目根据业务过程进行划分,需要注意的是一个业务过程只能属于一个数据域。
【构建业务总线矩阵】
业务总线矩阵中包含维度模型所需的所有事实(业务过程)以及维度,以及各业务过程与各维度的关系。矩阵的行是一个个业务过程,矩阵的列是一个个的维度,行列的交点表示业务过程与维度的关系。
一个业务过程对应维度模型中一张事务型事实表,一个维度则对应维度模型中的一张维度表。所以构建业务总线矩阵的过程就是设计维度模型的过程。但是需要注意的是,总线矩阵中通常只包含事务型事实表,另外两种类型的事实表需单独设计。
后续的DWD层以及DIM层的搭建需参考业务总线矩阵。
参考原文
四、 明确统计指标
明确统计指标具体的工作是,深入分析需求,构建指标体系。构建指标体系的主要意义就是指标定义标准化。所有指标的定义,都必须遵循同一套标准,这样能有效的避免指标定义存在歧义,指标定义重复等问题。
1)指标体系相关概念
(1)原子指标
原子指标基于某一业务过程的度量值,是业务定义中不可再拆解的指标,原子指标的核心功能就是对指标的聚合逻辑进行了定义。我们可以得出结论,原子指标包含三要素,分别是业务过程、度量值和聚合逻辑。
例如订单总额就是一个典型的原子指标,其中的业务过程为用户下单、度量值为订单金额,聚合逻辑为sum()求和。需要注意的是原子指标只是用来辅助定义指标一个概念,通常不会对应有实际统计需求与之对应。
(2)派生指标
派生指标基于原子指标,其与原子指标的关系如下图所示。
与原子指标不同,派生指标通常会对应实际的统计需求。请从图中的例子中,体会指标定义标准化的含义。
(3)衍生指标
衍生指标是在一个或多个派生指标的基础上,通过各种逻辑运算复合而成的。例如比率、比例等类型的指标。衍生指标也会对应实际的统计需求。
2)指标体系对于数仓建模的意义
通过上述两个具体的案例可以看出,绝大多数的统计需求,都可以使用原子指标、派生指标以及衍生指标这套标准去定义。同时能够发现这些统计需求都直接的或间接的对应一个或者是多个派生指标。
当统计需求足够多时,必然会出现部分统计需求对应的派生指标相同的情况。这种情况下,我们就可以考虑将这些公共的派生指标保存下来,这样做的主要目的就是减少重复计算,提高数据的复用性。
这些公共的派生指标统一保存在数据仓库的DWS层。因此DWS层设计,就可以参考我们根据现有的统计需求整理出的派生指标。
参考原文