第二章笔记数据模型篇

第八章建模综述

为什么需要数据建模:

• 性能:快速查询所需要的数据,减少数据IO吞吐率
• 成本:降低存储和计算成本
• 效率:提高数据使用效率
• 质量:改善数据统计口径的不一致性

维度模型

设计步骤:

• 选择要分析决策的业务过程:
  单业务过程,例:交易的支付,退款;
  事件状态,例:当前账户余额;
  业务事件组成的业务流程
• 选择粒度:细分的程度,粒度是维度的组合.
• 识别维表:设计维表,维度属性
• 选择事实:确定分析需要衡量的指标
  数据公共层建设的目的是着力解决数据存储和计算的共享问题

第九章数据整合及管理体系

建设方法论核心:从业务架构设计到模型设计,从数据研发到数据服务,做到数据可管理,可追溯,可规避重复建设
数据接入层:ods;数据中间层:dwd和dws层

阿里体系架构图.jpg

名词解释:

• 业务板块:根据业务属性划分独立的业务板块,板块之间的指标和业务重叠性小.
• 规范定义:维度建模为基础构建总线矩阵 阿里规范定义.jpg
• 数据域:面向业务分析,将业务过程或者维度进行抽象的集合.
  维度:指度量的环境,例:买家下单事件,买家是维度.
  不轻易变动,无影响被包含已有数据域和扩展新数据域
• 业务过程:业务事件,例:下单,支付,退款;不可拆分的行为事件,业务过程下定义指标.
• 时间周期:统计的时间范围或时间点,例:最近30天,自然周,截至当日
• 修饰类型:从属于某个业务域,例:日志域的访问终端类型,涵盖pc端,无线端等修饰词.
• 修饰词:除了统计维度以外指标的业务场景限定抽象;属于修饰类型.
• 度量/原子指标:业务事件下的度量,不可再拆分指标,明确业务含义的名词,例:支付金额,有确定的英文字段名,数据类型和算法说明.
• 维度:业务的一类属性,例:地理维度(国家,地区等),事件维度(年,季,月,周,日).
• 维度属性:属于一个维度,例:地理维度里的国家
• 派生指标:等于一个原子指标+多个修饰词(可选,或,且的关系由业务决定)+时间周期;例:派生指标,最近1天海外买家支付金额(原子指标:支付金额,最近1天为时间周期,海外为修饰词,买家作为维度,不作为修饰词),归属原子指标,与修饰词数据域无关.
  如果遇到同时有两个行为发生,需要多个修饰词,生成一个派生指标的情况,选择时间靠后的行为创建原子指标,选择时间靠前的行为创建修饰词.

模型设计

• 操作数据层(ODS):同步,结构化,累积历史,清洗数据
  数据准备区,离线数据和准实时数据
• 公共维度模型层(CDM)
  明细宽表数据层(DWD):事实数据,维度数据,将维度退化到事实表中,提高明细表的易用性.
  面向业务过程建模:事务型事实宽表,周期性快照事实宽表,累积快照事实宽表.
  汇总宽表数据层(DWS):明细宽表,提高复用性;逻辑汇总宽表,公共指标统一加工;数据分析维表,一致性维度.
  面向分析主题建模:买家,卖家,买卖家,商品,全站,行业,会员,地区.
• 应用数据层(ADS):个性化指标:不公用,复杂性(指数型,比值型,排名型指标);应用组装:大宽表集市,横标转纵表,趋势指标串.存放的是结果数据.
  数据调用优先使用公共维度层数据,没有数据进行评估是否需要建设公共层数据,不需要时去使用操作数据层数据,ADS层数据不对外提供数据服务.

基本原则

1.高内聚,低耦合:将业务相近或者相关,粒度相同的数据设计为一个逻辑或者物理模型;将高概率同时访问的数据放一起,低概率访问数据分开存放.
2.核心模型与扩展模型分离:不能让扩展模型的字段过度侵入核心模型,以免破坏核心模型的架构简洁性和可维护性.
3.公共处理逻辑下沉及单一: 不要让公用的处理逻辑暴露给应用层实现,不要让公共逻辑多处同时存在.
4.成本与性能平衡:不宜过度冗余和数据重复
5.数据可回滚:处理逻辑不变,在不同时间多次运行数据结果确定不变
6.一致性:具有相同含义的字段在不同表中的命名必须相同.
7.命名清洗,可理解

模型实施

1.业务调研:业务领域,业务线的业务有什么共同点和不同点,以及各个业务线可以细分为哪几个业务模块,每个业务模块的业务流程.

实施工作流程.jpg

2.架构设计

数据域划分: 数据域划分.jpg
构建总线矩阵:明确每个数据域下有哪些业务过程;业务过程与哪些维度相关,定义每个数据域下的业务过程和维度.
业务过程.jpg

3.规范定义:定义指标体系,原子指标,修饰词,时间周期,派生指标
4.模型设计:维度和属性的定义,维度,明细事实表和汇总事实表的模型设计.

第十章维度设计

1. 设计基础
   度量称为事实,环境描述为维度,维度所包含的表示维度的列,称为维度属性,维度的作用一般是查询约束,分类汇总以及排序等.
   维度和维度属性的获取:一方面在报表中获取;一方面和业务人员交流获取.常出现在"按照"语句内,例:
   用户要"按照"月份和产品来查看销售情况,
   维度使用主键标识唯一性:代理键:处理缓慢变化维和自然键,业务含义的键.
   对于前台应用系统来说,商品ID是代理键;对数据仓库来说,商品id属于自然键.

维度设计就是确定维度属性的过程

• 选择维度或新建维度:保证维度的唯一性.
• 确定主维表
• 确定相关维表
• 确定维度属性
  1.尽可能生成丰富的维度属性
  2.尽可能多地给出包括一些富有意义的文字性描述
  3.区分数值型属性和事实
  4.尽量沉淀出通用的维度属性

维度的层次结构
层次方式或一对多的方式互相关联
钻取:一层一层扩展,向下钻取更详细,向上钻取更汇总

• 最高层次
• 钻取至行业层次
• 钻取至一级类目层次

规范化和反规范化
联机事务处理系统(OLTP):采用雪花模型:属性被实例化为一系列维度,非单一维度(mysql中的)
联机分析处理系统(OLAP)(数仓采用)
反规范化:将维度的属性和层次合并到单一维度中的操作(数仓采用),方便易用性能好
雪花模型:事实表维度表分支维度表
星型模型:事实表_维度表

一致性维度和交叉探查
交叉探查:将不同数据域的商品的事实合并在一起进行数据探查,如计算转化率等.
维度格式和内容要保持一致,否则查探结果错误
维度一致性的表现形式

• 共享维度
• 一致性上卷,一个维度属性是另一个维度属性的子集,公共维度属性结构和内容相同.
• 交叉属性,两个维度具有部分相同的维度属性.

2. 维度设计高级主题
   维度整合
   数据仓库是一个面向主题的,集成的,非易失的且随时间变化的数据集合,用来支持管理人员的决策.
   应用之间的差异:

• 应用在编码,命名习惯,度量单位等方面
• 应用处于性能和可扩展性的考虑,采用不同的物理实现.

进行数据集成:

• 命名规范统一
• 字段类型统一
• 公共代码及代码移植统一
• 业务含义相同的表统一;集成方式:主从表设计方式,直接合并,不合并.

表级别的整合:

• 垂直整合:不同来源表包含相同的数据集,只是存储的信息不同
• 水平整合:不同来源表包含不同数据集,不同子集之间无法交叉,可以存在部分交叉.
  采用将来源表各个子集的自然键作为联合主键的方式,并且在物理实现时将来源字段作为分区字段.

水平拆分
维度通常可以按照类别或类型进行细分.
如何设计维度:

• 方案一将维度的不通分类实例化为不同维度,同时在主维度中保存公共属性.
• 方案二维护单一维度,包含所有可能的属性.
  方案选择:扩展性,效能,易用性
  当维度属性随类型变化较大时采用方案一;核心维度稳定采用方案二;相关性较低的业务采用方案一.

垂直拆分
维度设计时,依据维度设计的原则,尽可能丰富维度属性,同时进行反规范化处理.
按照扩展性,产出时间,易用性
主维表存放稳定,产出时间早,热度高的属性,从维表存放变化较快,产出时间晚,热度低的属性.

历史归档
面对庞大的数据量,如何设计模型,如何降低存储,如何让下游方便获取数据.

• 策略一同前台归档策略,在数仓实现前台的归档算法,定期归档.适用于逻辑简单且变更不频繁的情况.
• 策略二同前台归档策略,采用数据库变更日志的方式.(推荐采用)
• 策略三数据仓库自定义归档策略.

3. 维度变化
   缓慢变化维
   处理维度的变化的方式

• 重写维度值.不保留历史数据,始终取最新数据.
• 插入新的维度行.
• 添加维度列.(推荐采用)

快照维表(不推荐不采用)
为什么不使用代理键?
原因一数据量大,分布式系统不存在事务概念,某条记录每次生成相同的代理键难度大.
原因二代理键会增加ETL的复杂性,开发和维护成本更高.
如何处理缓慢变化维?
每天保留一份全量快照数据.
弊端:无变化也会进行存储,存储资源浪费.

极限存储
历史拉链存储:利用维度模型中缓慢变化维的第二种处理方式
增加两个时间戳字段,将所有以天为粒度的变更数据都记录下来.
会导致分区过多:

• 透明化:把对极限存储前的表的查询转换成对极限存储表的查询.
• 分月做历史拉链表
  不适用于产出量低,变化频率高的数据
  优化:
  在做极限存储前有一个全量存储表,全量存储表仅保留最近一段时间的全量分区数据,历史数据通过映射的方式关联到极限存储表.即用户只访问全量存储表,对用户来说极限存储表是不可见的
  对于部分变化频率频繁的字段需要过滤,单独作为一个子表.

微型维度(不推荐未使用)
避免维度过度增长.
通过将一部分不稳定的属性从主维度表中移出,并将它们放置到拥有自己代理键的新表中来实现.
属性相互之间没有直接联系,不存在自然键.
通过为每个组合创建新行的一次性过程来加载数据.

• 微型维度的极限性
• ETL逻辑复杂
• 破坏了维度的可浏览性

4. 特殊维度
   递归层次
   某维度实例值的层次关系,均衡层次结构和非均衡层次结构
   层次结构扁平化(推荐使用)
   出现类目为空的情况,由上级类目进行回填.
   层次桥接表(就是mysql的多对多表关联,不推荐)
   适合解决更宽泛的分析问题,灵活性好;但复杂性高,使用成本高.

行为维度
类似的维度,都和事实相关,如交易,物流等
行为维度划分种类:

• 另一个维度的过去行为
• 快照事实行为维度
• 分组事实行为维度,将数值型事实转化为枚举型
• 复杂逻辑事实行为维度,通过复杂算法加工或多个事实综合加工得到
  两种处理方式:
• 将其冗余至现有的维表中
• 加工成单独的行为表
  采用哪种方式:避免维度过快增长,避免耦合度过高.

多值维度
事实表的一条记录在某维表中 有多条记录与之对应.
处理方式:

• 降低事实表粒度(很多时候不能降低)
• 采用多字段
• 桥接表(不推荐)

杂项维度
由操作型系统中的指示符或者标志字段组合而成的,不在一致性维度之列
一个事实表中可能会存在多个类似的字段,解决方案就是建立杂项维度,将这些字段建立到一个维表中,在事实表中只需要保存一个外键即可.

第11章事实表设计

1. 事实表基础
   事实表特性
   引用的维度和与业务过程有关的度量.
   粒度通过两种方式表述:一种是维度属性组合所表示的细节程度;一种是所表示的具体业务含义.
   度量业务的事实分为:

• 可加性.可以按照与事实表关联的任意维度进行汇总.
• 半可加性,事实只能按照特定维度汇总,不能对所有维度汇总.
• 不可加性.比率型事实
  退化维度:存储到事实表中的维度列.

事实表三种类型:

• 事务事实表.用来描述业务过程,跟踪空间或时间上某点的度量事件,保存的是最原子的数据,也称为原子事实表
• 周期快照事实表.以具有规律性的,可预见的时间间隔记录事实,时间间隔如,每天,每月,每年等.
• 累积快照事实表.用来表述过程开始和结束之间的关键步骤事件,覆盖过程的整个生命周期,通常具有多个日期字段来记录关键时间点,当过程随着生命周期不断变化时,记录也会随着过程的变化而被修改.

事实表设计原则:

• 尽可能包含所有与业务过程相关的事实
• 只选择与业务过程相关的事实
• 分解不可加事实为可加性的组件
• 在选择维度和事实之前必须先声明粒度
• 在同一个事实表中不能有多种不同粒度的事实
• 事实的单位保持一致
• 对事实的null值处理,数值型建议填充0
• 使用退化维度提高事实表的易用性

事实表设计方法:选择业务过程,声明粒度,确定维度,确定事实.
一步:选择业务过程及确定事实表类型
明确业务需求以后,需要进行详细的需求分析,对业务的整个生命周期进行分析,明确关键业务步骤,从而选择与需求有关的业务过程.
订单流转案例:
买家下单-创建订单-等待买家付款-买家付款-等待卖家发货-卖家发货-等待买家确认收货-买家确认收货-交易成功
业务过程通常使用行为动词表示业务的执行活动,业务过程有四个:创建订单,买家付款,卖家发货,买家确认收货
二步声明粒度:事实表的粒度应该选择为子订单级别.
三步确定维度
四步确定事实
五步冗余维度

2. 事务事实表
   设计过程
   任何类型的事件都可以被理解为一种事务,针对事务过程构建的事实表,用以跟踪定义业务过程的个体行为,提供丰富的分析能力,作为数据仓库原子的明细数据.
   看具体案例

单事务事实表
对每个业务过程设计一个事实表

多事务事实表
同一个事实表包含不同的业务过程.
两种方式:

• 不同的业务过程事实采用不同的事实字段进行存放:淘宝交易事务事实表
• 不同的业务过程事实使用同一事实字段进行存放,增加业务过程标签字段:淘宝收藏商品事务事实表
  淘宝交易事务事实表:
  如何处理多个事实:不是当前业务过程的度量,采取零值处理方式.
  不同业务过程如何标记:针对每一个业务过程打一个标签维度表,标记当天是否是这个业务过程.

多事务事实表选择:

• 采用第二种情况:当不同业务过程的度量比较相似,差异不大时.
• 采用第一种情况:当不同的业务过程差异较大时.

对比: 单事务与多事务事实表对比.jpg

父子事实的处理方式:冗余到事务表中.

事实的设计准则

• 事实完整性.尽可能获取所有的度量
• 事实一致性:确保度量一致性
• 事实可加性:

3. 周期快照事实表(就是时间段的数据表)
   在确定的间隔内对实体的度量进行抽样.

特性
快照事实表的粒度通常以维度形式声明.
事务事实表稀疏的,快照事实表是稠密的.
事务事实表的事实是完全可加的,快照模型将至少包含一个用来展示半可加性质的事实.

• 快照采样状态
• 快照粒度
• 密度与稀疏性
• 半可加性

实例:
确定快照粒度.
确定采样的状态度量.

• 单维度的每天快照事实表
• 混合维度的每天快照事实表
• 全量快照事实表

注意事项

• 事务与快照成对设计:事务事实表基础上加快照事实表
• 附加事实:一般在设计周期快照事实表时会附加一些上一个采样周期的状态度量.
• 周期到日期度量:

4. 累积快照事实表
   研究事件之间时间间隔的需求.
   设计过程:四步
   特点:

• 数据不断更新
• 多业务过程日期:用于计算业务过程之间的时间间隔;保存全量数据
  在公共明细层需要保存一份全量数据,存放加工后的事实,并将各维度常用属性和订单杂项维度退化到此表中.
  用于数据探查,统计分析,数据挖掘.

特殊处理

• 非线性过程:处理情况主要有:业务过程的统一,针对业务关键里程碑构建全面的流程,循环流程的处理.
• 多源过程
• 业务过程取舍

物理实现
累积快照事实表模型设计

• 全量表形式:一般为日期分区表,每天的分区存储昨天的全量数据和当天的增量数据合并的结果,保证每条记录的状态最新.适用于全量数据较少的情况.
• 全量表的变化形式:主要针对事实表数据量很大的情况.较短生命周期的业务实体一般从产生到消亡都有一定的时间间隔.
• 以业务实体的结束时间分区.可能存在极特殊情况,业务系统无法标识业务实体的结束时间.方式一:使用相关的业务系统的业务实体的结束标志作为此业务系统的结束标识.方式二:和前端业务系统确定口径或使用前端归档策略.

5. 三种事实表比较

   
   三种事实表对比.jpg

6. 无事实的事实表
   不包含事实或度量的事实表

• 事件类,记录事件的发生
• 条件,范围或资格类的,记录维度与维度多对多之间的关系.

7. 聚集型事实表
   聚集主要是通过汇总明细粒度数据来获取改进查询性能的效果.
   使用频繁的公用数据,通过聚集进行沉淀.
   聚集汇总数据在公共汇总层

基本原则:

• 一致性.必须提供与查询明细粒度数据一致的查询结果.方法是确保聚集星型模型中的维度和度量与原始模型中的维度度量保持一致.
• 避免单一表设计.不在同一个表中存储不同层次的聚集数据.方法一:聚集时显式地加入数据层级列以示区别.方法二:把按天按月汇总的交易额用两列存放,注意在列名能分辨出来.
• 聚集粒度可不同.

聚集的基本步骤

• 确定聚集维度
• 确定一致性上钻.
• 确定聚集事实.

公共汇总层
基本原则

• 数据公用性
• 不跨数据域
• 区分统计周期
  交易汇总表设计
  聚集是指针对原始明细粒度的数据进行汇总
• 按商品粒度汇总
• 按卖家粒度汇总
• 按买家,卖家,商品粒度汇总
• 按二级类目汇总

聚集补充说明

• 聚集是不跨越事实的:聚集是针对原始星型模型的汇总,聚集的维度和度量必须与原始模型保持一致,聚集不跨越事实.融合事实表是一种导出形式而不是聚集.
• 聚集带来的问题.当类目进行变更时,聚集表需要重新调整,方法:删除重新聚集.