阿里巴巴大数据之路-数据模型篇
一、大数据领域建模综述
1、典型的数据仓库建模方法论
ER模型：数据仓库之父Bill Inmon提出从全企业的高度设计一个3NF模型，用ER模型来描述企业业务。数据仓库中的3NF与OLTP系统中的3NF的区别在于数据仓库是站在企业角度面向主题的抽象，而不是针对某个具体业务流程的实体对象关系的抽象。其具有几个特点--需要全面了解企业业务和数据，实施周期长，对建模人员的能力要求非常高。ER模型的典型代表是Teradata公司发布的金融业务模型FS-LDM。
维度模型：数据仓库领域的Ralph Kimball大师所倡导的，维度建模从分析决策的需求出发构建模型，为分析需求服务，因此它重点关注用户如何更快速地完成需求分析，同时具有较好的大规模复杂查询的响应性能。其典型的代表是星兴模型，以及在一些特殊场景下使用的雪花模型。
2、阿里巴巴数据模型实践综述
第一个阶段：只有两层--ODS+DSS
第二个阶段：ODL（操作数据层）+BDL（基础数据层）+IDL（接口数据层）+ADL（应用数据层）；ODL和源系统保持一致，BDL希望引入ER模型构建一致的基础数据模型，IDL基于维度模型方法构建集市层，ADL完成应用的个性化和基于展现需求的数据组装。实际情况是，ER模型迟迟不能产出，因此得到一个经验--在不太成熟、快速变化的业务面前，构建ER模型的风险非常大，不太适合去构建ER模型。
第三个阶段：选择以Kimball的维度建模为核心理念的模型方法论，同时对其进行一定的升级和扩展，构建阿里巴巴集团的公共层模型数据架构体系。
阿里巴巴数据公共层建设的指导方法是一套统一化的集团数据整合及管理的方法体系（OneData），其包括一致性的指标定义体系、模型设计方法体系以及配套工具。
二、阿里巴巴数据整合及管理体系
1、目标：可管理、可追溯、可规避重复建设。
2、规范定义：以维度建模作为理论基础，构建总线矩阵，划分和定义数据域、业务过程、维度、度量/原子指标、修饰类型、修饰词、时间周期、派生指标。
指标定义：事务型指标--指对业务活动进行衡量的指标，例如新发商品数、新增会员数等。存量型指标--指对实体对象某些状态的统计，例如商品总数、会员总数。复合型指标--包括比率型、比例型、变化量型、变化率型等。
指标命名规范：需要对原子指标、派生指标进行命名规范。
3、模型层次
模型设计原则：高内聚低耦合、核心模型与扩展模型分离、公共处理逻辑下沉及单一、成本与性能平衡、数据可回滚、一致性、命名清晰可理解。
模型实施方法：Kimball模型实施方法、OneData模型实施方法（见下图）。
三、维度设计
1、基本概念：在维度建模中，将度量成为“事实”，将环境称为“维度”。代理键和自然键--例如，对于前台应用系统来说，商品ID是代理键；而对于数据仓库系统来说，商品ID则属于自然键。
2、规范化和反规范化：当属性层次被实例化为一系列维度，而不是单一维度时被称为雪花模型。大多数OLTP系统模型采用雪花模型这种规范化操作。采用雪花模型，除了可以节约一部分存储外，对于OLAP系统来说没有其他效用，而现阶段存储的成本很低，所以在实际应用中几乎总是使用维表的空间来换取简明性和查询性能。
3、维度整合
命名规范的统一
字段类型的统一
公共代码及代码值的统一
业务含义相同的表的统一：通常有3种方式--主从表（将多个表都有的字段放在主表中，而从属信息分别放在各自的从表中）、直接合并、不合并，具体可以根据源表重合度及差异等状况确定。
垂直整合：不同的来源表包含相同的数据集，比如淘宝会员在源系统中有多个表，包括会员基础信息表、会员扩展信息表等，可以尽量垂直整合到会员维度模型中。
水平整合：不同的来源表包含不同的数据集，不同子集之间无交叉，也可以存在部分交叉，如果要整合则可以采用各子集的自然键作为联合主键的方式来实现。
4、维度拆分
水平拆分：比如商品表，可以分为淘宝商品、天猫商品、飞猪商品等，而飞猪航旅商品与普通的淘系商品有相同的地方，也有不同的地方，那么如何处理呢？方案1是将维度的不同分类实例化为不同的维度，同时在主维度中保存公共属性；方案2是维度单一维度，包含所有可能的属性。可以根据维度不同分类的属性差异情况、及业务的关联程度确定采用哪种方案。
垂直拆分：出于扩展性、产出时间、易用性等方面的考虑，设计主从维度，主维表存放稳定、产出时间早、热度高的属性，从维表存放变化较快、产出时间晚、热度低的属性，比如商品主维表在每日的1：30左右产出，而商品扩展维度在每日的3：00左右产出。
5、维度变化
缓慢变化维：有三种处理方式--1、重写维度值，不保留历史数据；2、插入新的维度行，保留历史数据，这种方式不能将变化前后记录的事实归一化为变化前或变化后的维度；3、添加维度列，记录新旧维度值，可以解决方案2的不足。
阿里巴巴内部处理缓慢变化维的方法是采用快照维表方式。
6、特殊维度
递归维度：可以直接采用递归模型支撑递归维度，但很多工具不支持递归SQL，且递归SQL成本高，所以可以在维度模型中对层次结构进行扁平化处理。大部分时候，扁平化设计足够满足需求了。
多值维度：常见的有三种处理方式--1、降低事实表的粒度，避免出现多值；2、采用多字段来处理多值维度（如果值的数量固定）；3、采用桥接表来表达一对多关系（复杂成本高需慎重）。
四、事实表设计
1、事实表特性：作为度量业务过程的事实，有可加性、半可加性（一般是时间维度不可加）、不可加性。
2、事实表类型
事务事实表：用来描述业务过程，跟踪空间或时间上某点的度量事件，保存的是最原子的数据，也称为原子事实表。
周期快照事实表：以具有规律性、可预见的时间间隔记录事实，时间间隔如每天、每月、每年等。一般针对长生命周期的对象，比如用户。
累计快照事实表：用来描述过程开始和结束之间的关键步骤事件，覆盖过程的整个生命周期，通常具有多个日期字段来记录关键时间点，当过程随着生命周期不断变化时，记录也会随着过程的变化而被修改。一般针对短生命周期的对象，比如交易过程。
3、事实表设计原则
尽可能包含所有与业务过程相关的事实
只选择与业务过程相关的事实
分解不可加性事实为可加事实
在选择维度和事实之前必须先声明粒度
在同一个事实表中不能有多个不同粒度的事实
事实的单位要保持一致
对事实的null值要处理
使用退化维度提高事实表的易用性
事实完整性（尽可能多的获取业务过程相关的度量）、事实一致性（有一些事实可以提前计算好确保下游使用的一致性）、事实可加性。
4、事务事实表
单事务事实表：针对每个业务过程设计一个事实表。
多事务事实表：多事务事实表在设计时有两种方法进行事实的处理--1、不同业务过程的事实使用不同的事实字段进行存放；2、不同业务过程的事实使用同一个事实字段进行存放，但增加一个业务过程标签。
多事务事实表的选择：当不同业务过程的度量比较相似、差异不大时，可以采用第二种多事务事实表的设计方式，使用同一个字段来表示度量数据，但存在一个问题--在同一个周期内会有多条记录存在。当不同业务过程的度量差异较大时，可以选择第一种多事务事实表的设计方式。
例子：淘宝交易事务事实表如下
5、周期快照事实表的注意事项
事务事实表与周期快照事实表往往是成对设计的，互相补充，以满足更多的下游统计分析需求。
附加事实：一般在设计周期快照事实表时会附加一些上一个采样周期的状态度量。
6、累计快照事实表的物理实现
第一种方式是全量表，一般按日期分区，每天分区存储昨天的全量+当天的增量合并的结果。适用于全量数据比较少的情况。
第二种方式是全量表的变化形式，针对事实表数据量很大的情况，根据业务实体从产生到消亡的最大时间间隔来测算，比如交易订单以200天计算最大间隔。
第三种方式是以业务实体的结束时间分区，每天的分区存放当天结束的数据，设计一个时间非常大的分区，比如3000-12-31，存放截止当前未结束的数据，每天将当天结束的数据归档至当天分区中。
7、三种事实表的比较