总览

维度建模基础

建模综述

好的模型带来的好处：
性能：良好的数据模型能帮助我们快速查询所需要的数据，减少 IO 吞吐
成本：极大减少数据冗余，实现计算结果复用，降低存储和计算成本
效率：改善用户使用数据的体验，提高使用效率
质量：减少数据计算出错的可能性

大量的数据仓库也是基于关系型数据库建立。不管是 Hadoop，spark 还是 maxcompute，依然是 sql。只是在大数据领域，选择的关系数据模型的范式不同而已。

OLTP(联机事务处理系统)系统通常面对数据的随机读写，主要采用满足 3NF 实体关系模型存储数据，从而在事务处理中解决数据冗余和一致性问题。

如果不是雪花模型，更新一个数据可能要处理多张表。

OLAP(联机分析处理系统)面向的是批量读写，事务处理的一致性不是 OLAP 关注的，其主要关注数据的整合以及一次性的复杂大数据查询和处理中的性能，因此他需要采用一些不同的数据建模方法。

OLAP 中，数据是稳定的，不存在 OLTP 的问题。

典型数据建模方法论

ER 模型
数据之父 Bill Inmon 是 3NF 模型。数仓中的 3NF 与 OLTP 中的 3NF 在于，他是站在企业角度面向主题的抽象，而不是针对某个具体业务流程的实体对象关系的抽象。
出发点是整合数据。一般是 3 个阶段，高层模型，中层模型，物理模型。

维度模型
是 Kimball 提出的从分析决策的需求触发构建模型，为分析需求服务。重点关注用户如何更快完成需求分析，同时大规模复杂查询下的响应性能。典型代表是星型模型，以及一些特殊场景下的雪花模型。
一般步骤是：选择业务过程，选择粒度，识别维表，选择事实。

Data Vault 模型
ER 模型的衍生，出发点是数据的整合。由以下几部分：Hub，Link，Satallite。

Anchor 模型
Data Vault 进一步规范化处理，模型规范到了 6NF。

维度设计

维度是维度建模的基础。度量称为事实，将环境描述为维度。维度用于分析事实所需要的多样环境。
交易过程，可以通过买家，卖家，商品和时间维度来描述交易发生的环境。

维度包含的维度的列是为维度属性。维度的作用一般是查询约束，分类汇总以及排序。

用主键标识唯一性。主键有两种：代理键和自然键。代理键是不具有业务含义的键，一般用户处理缓慢变化维。自然键可能就是商品 ID。

维度的设计过程就是确定维度属性的过程。数仓的能力直接与维度属性的质量和深度成正比。

将维度的属性层次合并到单个维度中的操作称为反规范化。分析系统的主要目的是用户数据分析和统计。更方便地用户进行统计分析决定了分析系统的优劣。采用雪花模型，统计分析的时候就需要大量的关联操作，复杂度高，查询性能差，因此反规范化处理，方便，易用且性能好。

在实际应用中，总是使用维度的空间来换取简明性和查询性能。

企业级数仓中，一致性维度非常重要，而且不可能一蹴而就，通常采用迭代式的构建过程。

因此我们的维度建模设计是按照 git 方式设计的。

一致性维度适合做交叉探查。比如日志数据域，统计了商品维度最近一天的 PV 和 UV，然后交易数据域统计了商品维度最近一天的下单 GMV，那就可以计算转化率了。

DI 做探索分析，消费的数据是什么样的呢？

数仓的 4 大特性：集成。

不同的应用在设计的时候，主要是为了满足本应用的需求，很少会考虑和其他系统进行数据集成。
所以：

• 编码，命名习惯，度量单位存在很大差异
• 处于性能和扩展性考虑，采用不同物理实现，比如部分数据采用关系型，部分数据采用 NoSql。比如根据查询频率分库分表。

所以需要集成，命名规范统一，字段类型统一。

维度是会缓慢变化的。通常用代理键来处理缓慢变化维。但是阿里的实践过程，并没有使用代理键。阿里采用的是快照方式。

事实设计

维度建模的核心，围绕业务过程设计，通过描述业务过程的度量来表达业务过程。包含了引用的维度和与业务过程有关的度量。

一条记录表达的业务细节程度被称为粒度。有可加性，半可加性和不可加性三种类型。半可加性比如库存可以根据地点和商品进行汇总，但是把每个与的库存累加就没有意义。不可加性比如比例类的(通常需要分解)。

维度属性也可以存到事实表中，这种维度列被称为退化维。就是没有其他属性了。比如单号。

事实表设计原则：

• 尽可能包含所有业务过程相关事实：即使冗余，开销也不大
• 只选择与业务过程相关事实：比如订单下单就不该有支付金额这个事实
• 分解不可加事实为可加的：比如订单优惠率可分解为订单原价金额和订单优惠金额两个事实
• 在选择维度和事实之前必须先申明粒度：越细越好
• …..

维度模型设计就 4 步：

• 选择业务过程
• 声明粒度
• 确定维度
• 确定事实

书中介绍的流程其实是为了使用考虑，目标降低数据获取的复杂性。但是我们这次的话其实期望的是星型模型。因为我们的 sql 是自动生成的。我们可以选择雪花或者星型，只为业务的使用者考虑。
阿里那边实际的事实表还会为了查询考虑，混入一些维度属性，但是我们这边由于把这层自由度都交给了引擎，就完全不要考虑物理实现的情况。

---

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 981909093@qq.com