干货 | 数仓建模，推荐收藏！

分享嘉宾：云 祁

编辑整理：柠檬妹

出品平台：数据仓库与Python大数据

正文

导读：这两天又翻出了《大数据之路：阿里巴巴大数据实践》，重新读了数据建模那部分的内容，依旧感觉受益良多，遂整理了笔记分享给大家。

ps：文末阅读原文回复：06，可领取电子书

数据建模

数据建模在这本书占据了三分之一篇幅，可见其重要性！

9.1 典型的数据仓库建模方法论

9.1.1 ER模型

传统关系型数据库的ER模型是基于具体业务实体的，而大数据领域的ER模型是建立于业务主题之上的。更着重描述业务主题之间的关系，将具体业务实体整合到了业务主题之下。

业务主题理论上满足3NF的范式要求。描述业务主题之间关系为高层模型，其下的中层模型细化了主题的数据项，中层模型下的物理模型考虑物理存储（分区、合并等）。

9.1.2 维度模型

度模型从业务需求出发，考虑业务事件（比如交易、还款等不可拆分的行为），再将事件细分为多个粒度，基于粒度再设计多种维度，最后选择需要衡量的事实指标。维度模型重点关注需求分析，典型代表是星型模型和雪花模型。

9.1.3 Data Vault 模型

Data Vault Dan Linstedt 发起创建的一种模型，其设计的出发点也是为了实现数据的整合，但不能直接用于数据分析决策。

它强调建立一个可审计的基础数据层，也就是强调数据的历史性、可追溯性和原子性，而不要求对数据进行过度的一致性处理和整合同时它基于主题概念将企业数据进行结构化组织，并引入了更进一步的范式处理来优化模型，以应对游、系统变更的扩展性。

9.1.4 Anchor 模型

Anchor Data Vault 模型做了进一步规范化处理， Lars. Ri:innback 的初衷是设计 个高度可扩展的模型，其核心思想是所有的扩展只是添加而不是修改，因此将模型规范到 6NF ，基本变成了 k-v 结构化模型。

9.2 阿里巴巴数据模型实践

第一阶段：完全应用驱动的时代，数据完全以满足报表需求为目的，将数据以与源结构相同的方式同步到Oracle，数据完全以满足报表需求为目的，将数据以与源结构相同的方式同步到 Oracle （称作 ODS 层），数据工程师基于 ODS数据进行统计，基本没有系统化的模型方法体系，完全基于对 Oracle数据库特性的利用进行数据存储和加工，部分采用 一些维度建模的缓慢变化维方式进行历史数据处理。这时候的数据架构只有两层，即 ODS+DSS。

第二阶段：随着阿里业务的快速发展，数据量飞速增长，性能成为一个较大问题，需要通过一些模型技术改变烟囱式的开发模型，消除数据冗余，提升数据一致性，来自传统行业的数据仓库工程师开始尝试架构工程领域比较流行的ER模型+维度模型方式应用到阿里巴巴集团，构建出一个四层的模型架构，即ODL（数据操作层）+BDL（基础数据层）+IDL（接口数据层）+ADL（应用数据层）。ODL与源系统一致，BDL希望引入ER模型，加强数据的整合，构建一致的基础数据模型，IDL基于维度模型方法构建集市层，ADL完成应用的个性化和基于展现需求的数据组装，这个对应当前的ODS，DWD，DWA/DWI及ST层，但阿里在构建ER时碰到了较大的挑战，主要是业务快速发展，人员快速变化、业务知识功底的不够全面，导致ER模型产出困难。

阿里得出了一个结论：在不太成熟、快速变化的业务层面，构建ER模型的风险很大，不太适合去构建ER模型，说的有点道理，比如运营商业务相对比较稳定，国际上也有一些最佳实践，从概念-领域-逻辑-物理的全局把控上还能应对，但面对变化，的确有其限制。

第三个阶段：阿里业务和数据飞速发展，迎来了hadoop为代表的分部署存储计算的快速发展，同时阿里自主研发的分布式计算平台MaxCompute也在进行，因此开始建设自己的第三代模型架构，其选择了以Kimball的维度建模为核心理念的模型方法论，同时进行了一定的升级和扩展，构建了阿里巴巴集团的公共层模型数据架构体系。

阿里模型分为三层：操作数据层（ODS）、公共维度模型层（CDM）和应用数据层（ADS），模型层包括明细数据层（DWD）和汇总数据层（DWS）。

ODS：把操作系统数据几乎无处理的存放到数据仓库系统中。

CDM：又细分为DWD和DWS，分别是明细数据层和汇总数据层，采用维度模型方法作为理论基础，更多采用一些维度退化方法，将维度退化至事实表中，减少事实表和维表的关联，提高明细数据表的易用性，同时在汇总数据层，加强指标的维度退化，采取更多的宽表化手段构建公共指标数据层，提升公共指标的复用性。

ADS：存放数据产品个性化的统计指标数据，根据CDM与ODS加工生成。

具体见如下模型架构图：

关于模型的分层每个行业都可以基于自己的实际去划分，没有所谓的最佳实践，比如笔者所在的企业，源端维度一致性非常好，DWD主要做标准化工作，屏蔽ODS变化导致的上层改动，关于维度建模的理念更多体现在DWA/DWI层中。

9.3 模型实施

OneData是阿里的模型设计理论，看完这个过程，基本会搞清楚维度建模的各个步骤，强烈建议结合后面的维度和事实表建模进行精读，主要步骤如下：

数据调研：业务调研需要对业务系统的业务进行了解，需求分析则是收集分析师运营人员对数据或者报表的需求，报表需求实际是最现实的建模需求的基础。

实施工作流图镇楼，大佬说这张图就可以值回书价。

架构设计：分为数据域划分和构建总线矩阵。数据域划分是指面向业务分析，将业务过程或者维度进行抽象的集合，业务过程可以概括为一个个不可拆分的行为事件，如下单、支付等。

构建总线矩阵需要明确每个数据域下游哪些业务过程，业务过程与哪些维度相关，并定义每个数据域下的业务过程和维度。

如表 9.5 所示是根据业务过程进行归纳，抽象出的数据域（部分示例）。

在进行充分的业务调研和需求调研后，就要构建总线矩阵了。需要做两件事情 ：明确每个数据域下有哪些业务过程；业务过程与哪些维度相关，并定义每个数据域下的业务过程和维度。

如表 9.6 所示是供应链管理业务过程示例。

规范定义：规范定义主要定义指标体系，包括原子指标、修饰词、时间周期和派生指标，关于指标的规范定义阿里有单独的一节描述，大家可以好好学习一下，很多时候细节决定成败。

模型设计：模型设计主要包括维度及属性的规范定义、维表、明细事实表和汇总事实表的模型设计。

总结：OneData 的实施过程是一个高度迭代和动态的过程， 般采用螺旋式实施方法。在总体架构设计完成之后，开始根据数据域进行迭代式模型设计和评审。在架构设计、规范定义和模型设计等模型实施过程中，都会引人评审机制，以确保模型实施过程的正确性。

9.4 维度设计

将度量称为事实，将环境描述为维度。维度的作用一般是条件约束、分类查询与排序。

9.4.1 维度的基本设计原则

1. 从主维表与相关维表中提取维度属性或者生成新的维度属性，属性越丰富越好。
2. 属性是编码类型的，要有文字描述。
3. 将需要复杂逻辑计算的属性提前整理并保存下来。
4. 维表以空间换取简明性和查询性能。
5. 维度一致性。保证能够交叉查询。

“

不同数据域共享维表。 一致性上卷。某个维度的维度属性是另一个维度的子集。 交叉属性。两个维度有部分属性相同。

”

9.4.2 维度的整合与拆分

依据高内聚低耦合的原则，保证扩展性、易用性和高效性。

• 水平拆分与整合一般根据维度属性类型和维度之间的关联性来进行整合与拆分。要么提取出公共维度属性，分别保存个性化维度属性；要么整合到相同的维表中。若类型只有较少的重叠，则采取提取公用维度的做法，否则整合到一张维表中，即使类型重叠较多。但维度属于两个关联性较小的业务条线，也要分开在不同的集市。

• 垂直拆分与整合由于维度产出的时间，使用的热度，变化的频率不尽相同，需要使用主从维表来解决。主维表存放稳定、产出时间早、热度高的属性，从表存放变化较快、产出时间晚、热度低的属性。

9.4.3 历史数据归档

有3种归档策略：

1. 数据仓库与前台数据库保持相同的归档算法。但在前台归档算法复杂或者算法经常变化的情况下不适用。
2. 解析前台数据库的日志并归档。当解析到增量日志中的删除标志时归档，但要求前台应用在数仓归档之后才真正删除数据，之前仅做逻辑删除，避免前后台数据状态不一致的情况。（推荐使用）
3. 数据仓库自定义归档策略。但要求比前台应用晚归档、少归档，避免出现前台应用更新已归档数据的情况。

9.4.4 维度变化

维度的变化大多要慢于数据的变化，但根据业务情况不同，有时需要使用某个历史时刻的维度。维度的历史归档策略：

1. 仅保留维度最新的值。无法满足需要使用历史维度的情况。
2. 将新维度作为新的一行数据存储，同时记录维度的生效时间和失效时间。关联查询时要带上时间条件。
3. 将新维度作为新的一列存储，相当于旧值与新值的概念。但变化频繁时不适用。
4. 保存维表快照。根据数仓的数据更新周期，每个周期保存一份快照。根据时间和业务主键进行关联。此方法简单有效，但极浪费存储。
5. 极限存储。使用拉链表的方式存储变化的数据，查询时根据维度的生效时间和结束时间来关联，但与2不同的是做了封装将普通的查询语句转换为带有时间条件的查询语句。而且使用生效时间按月做分区。（推荐）

使用极限存储，仅限于维度变化即不快又不慢的情况，太快会导致维度数据太过庞大，太慢不需要极限存储。而且保存维度历史一般要求维度是枚举值类型，如果类似积分这样的连续值，则可能不适用。

9.4.5 特殊维度

递归层次维度若维度存在层级关系，通过扁平化存储，将上下层关系以不同的列的方式存储在同一张维表中。若层级关系是非均衡的，即枝干的深度不一致，有两种处理方式：

1. 回填：将维度向下虚拟，使其与起他枝干的深度一致。
2. 层次桥接表：使用父层级、子层级、父子层级间隔来描述。

行为维度行为维度是通过对客户行为的计算得到的维度，是否与主维表放在一起取决于维度变化的频率，以及计算逻辑的复杂程度。

多值维度即事实表的记录与维表记录是1对多的关系，比如申请书与卡片的关系。

1. 降低事实表的粒度。比如申请书降低到以卡片为单位。但经常事实不允许。
2. 保留预留字段。比如申请书中预留多个卡片栏位。
3. 使用关联表。但复杂度高不易维护。

9.5  事实表设计

1. 事实表

事实表要尽可能多的包含与业务过程相关的度量。事实表包含的业务流程可以是一个也可以是多个，多个业务流程需要在更高层面的流程上有关联，并且维度存在一定的相似性。

1. 事实表的粒度

可以根据维度组合的细节程度，业务含义两方面来表述。同一个事实表中的不同事实的粒度须一致。

1. 度量

一般为整数或浮点数。尽可能是可加的，避免类似百分比这种经过计算度量。多事实的事实表的度量是冗余的，当某种事实只使用到部分度量时，将其他度量设置为0。也可以使用同一个度量，但需要额外添加一个类型维度。

1. 退化维度

保存在事实表中的维度属性。

1. 事物表的类型

事物事实表，周期快照事实表，累计快照事实表。累计快照事物表更适合处理起止时间明确的短生命周期实体，否则应该使用周期快照事实表。

1. 聚集

聚集中的维度和度量和原事实表中的维度和度量保持一致。比如原事实表包含了买家与卖家，那么聚集中可以同时包含买家与卖家相关的聚集维度。聚集的维度的粒度保持一致，不能出现按日汇总又出现按月汇总的数据，可以按照不同的列来保存；聚集的粒度可以和原事实的粒度不同，按照实际的需求来确定聚集的粒度。

End

Day Day Up . 关注我们提升自己不迷惑，我们下期见啦 ~

欢迎加入大数据|数仓技术交流群。

进群方式：请加微信（微信号：iom1128），回复：数据，通过审核会拉你进群。

下载资料：长按扫码回复 经典点个在看，少个 bug 👇