目录
大数据时代,维度建模已成为各大厂的主流方式。
维度建模从分析决策的需求出发构建模型,为分析需求服务。重点关注用户如何快速的完成数据分析,可以直观的反应业务模型中的业务问题,需要大量的数据预处理、数据冗余,有较好的大规模复杂查询的响应性能。
系列文章详见「数仓系列文章- 传送门」
维度建模按数据组织类型划分可分为星型模型、雪花模型、星座模型。
Kimball老爷爷维度建模四个步骤:
选择业务处理过程 > 定义粒度 > 选择维度 > 确定事实
星型模型主要是维表和事实表,以事实表为中心,所有维度直接关联在事实表上,呈星型分布。
雪花模型,在星型模型的基础上,维度表上又关联了其他维度表。这种模型维护成本高,性能方面也较差,所以一般不建议使用。尤其是基于hadoop体系构建数仓,减少join就是减少shuffle,性能差距会很大。
星型模型可以理解为,一个事实表关联多个维度表,雪花模型可以理解为一个事实表关联多个维度表,维度表再关联维度表。
星座模型,是对星型模型的扩展延伸,多张事实表共享维度表。
星座模型是很多数据仓库的常态,因为很多数据仓库都是多个事实表的。所以星座模型只反映是否有多个事实表,他们之间是否共享一些维度表。
即实体关系(ER)模型,数据仓库之父Immon提出的,从全企业的高度设计一个3NF模型,用实体加关系描述的数据模型描述企业业务架构,在范式理论上符合3NF。此建模方法,对建模人员的能力要求非常高。
特点:设计思路自上而下,适合上游基础数据存储,同一份数据只存储一份,没有数据冗余,方便解耦,易维护,缺点是开发周期一般比较长,维护成本高。
详见:一篇文章搞懂数据仓库:三范式与反范式_不吃西红柿-CSDN博客_数据仓库三范式
DataVault由Hub(关键核心业务实体)、Link(关系)、Satellite(实体属性) 三部分组成 ,是Dan Linstedt发起创建的一种模型方法论,它是在ER关系模型上的衍生,同时设计的出发点也是为了实现数据的整合,并非为数据决策分析直接使用。
高度可扩展的模型,所有的扩展只是添加而不是修改,因此它将模型规范到6NF,基本变成了K-V结构模型。企业很少使用。
数据模型建设的怎么样,极度依赖规范设计,如果代码风格是“千人千面”,那么恐怕半年下来,业务系统就没法看了。没有什么比“数据系统”更看重“法制”了,规范体系不仅能保障数据建设的一致性,也能够应对业务交接的情况,更能够为自动化奠定基础。
数仓系列传送门:https://blog.csdn.net/weixin_39032019/category_8871528.html