浅谈数仓模型（维度建模）

最新推荐文章于 2024-08-01 00:00:00 发布

catydidd

最新推荐文章于 2024-08-01 00:00:00 发布

阅读量785

点赞数

文章标签：数据仓库 big data 数据挖掘

原文链接：https://zhuanlan.zhihu.com/p/137454121

版权

背景

介绍

案例

背景

数据仓库的核心是展现层和提供优质的服务。ETL 及其规范、分层等所做的一切都是为了一个更清晰易用的展现层。

数仓架构的原则：

1、底层业务的数据驱动为导向同时结合业务需求驱动
2、便于数据分析
屏蔽底层复杂业务
简单、完整、集成的将数据暴露给分析层
3、底层业务变动与上层需求变动对模型冲击最小化
业务系统变化影响削弱在基础数据层（资金订单改造）
结合自上而下的建设方法削弱需求变动对模型的影响
数据水平层次清晰化
3、高内聚松耦合
主题之内或各个完整意义的系统内数据的高内聚
主题之间或各个完整意义的系统间数据的松耦合
4、构建仓库基础数据层
使得底层业务数据整合工作与上层应用开发工作相隔离，为仓库大规模开发奠定基础
仓库层次更加清晰，对外暴露数据更加统一

数仓模型不只是考虑如何设计和实现功能，设计原则应该从访问性能、数据成本、使用成本、数据质量、扩展性来考虑。

如何搭建一个好的数据仓库：

数仓设计的3个维度：

当前主流建模方法为：ER模型、维度模型。

1、ER模型常用于OLTP数据库建模，应用到构建数仓时更偏重数据整合，站在企业整体考虑，将各个系统的数据按相似性一致性、合并处理，为数据分析、决策服务，但并不便于直接用来支持分析。缺陷：需要全面梳理企业所有的业务和数据流，周期长，人员要求高。
2、维度建模是面向分析场景而生，针对分析场景构建数仓模型；重点关注快速、灵活的解决分析需求，同时能够提供大规模数据的快速响应性能。针对性强，主要应用于数据仓库构建和OLAP引擎低层数据模型。优点：不需要完整的梳理企业业务流程和数据，实施周期根据主题边界而定，容易快速实现demo，而且相对来说便于理解、提高查询性能、对称并易扩展。

作为大数据板块，数据来源更加广泛，针对的业务域也更加宽广，所以维度建模相对来说更加灵活并适用。

在讨论维度建模之前，关注数仓和BI的基本目标是非常有意义的，在做日常的数据需求的时候，经常会遇到如下几个痛点：

收集了海量数据，不知道如何去做ETL；
不同来源的数据该如何去聚合；
如何方便业务人员快速方便的获取数据；
如何定义重要的数据指标；
如何确保数据准确性；
数据如何支持决策；

基于上面的痛点，就需要搭建一套DW/BI系统（当然现在市面上有很多类似的产品，例如：如：QuickBI、GrowingIO、神策、猛犸等等），但是对于公司而言，适合自己的才是最好的，大部分公司选择自己搭建或者利用开源的软件（例如MateBase），这个系统必须满足：

DW/BI系统能够方便的存储信息（或者说能跟现在主流的数据库打通）。也就是说系统展现的内容必须是容易理解的，对于业务人员必须直观而且好操作，数据结构和标示必须符合业务思维过程和词汇，用户能够以各种形式切割和分析数据，同时能够快速的将查询结果反馈。
DW/BI系统必须以一致性的形式展现信息（指标的唯一性）。也就是说数据必须是可信的，同一指标定义在不同的数据源中，所含的意义必须相同，既同名同意性。
DW/BI系统能够适应变化（模块的低耦合）。当用户需求、业务维度需要调整的调整的时候，设计的DW模型必须能够兼容这些变化，已经存在数据和指标不应该被破坏或修改，就算一些指标的调整，也要以适当的方式描述变化，并对用户完全透明。
DW/BI系统必须保证数据安全（数据安全）。能展示的数据必须是统计的结果数据，一些详单展现和下载必须和平台的权限系统挂钩，避免数据泄漏。
DW/BI系统成功的标示是业务群体接收并使用，而且必须配套一个展现模块的监控系统，能够让产品方知道各个模块的使用情况，对一些访问量比较少的模块可以适当的调整和优化。

介绍

DW/BI架构：

源事务：业务库或者日志等各个方面的数据源，一般不维护历史信息。

ETL：目的是构建和加载数据到展现区的目标维度模型中，划分维度和事实。

模型：围绕业务过程度量事件进行构建，为满足用户无法预估的需求，必须包含详细的原子数据。

为避免数据的冗余存储造成的浪费和低效，并方便多业务部门查询方便以及同一指标的数据准确性和业务的扩展性，一般采取以下的架构模式：

维度建模：

用于度量的事实表，事实表一般会有两个或者多个外健与维度表的主键进行关联。事实表的主键一般是组合健，表达多对多的关系。

用于描述环境的维度表，单一主键。维度表的属性是所有查询约束和报表标示的来源。维度提供数据的入口点，提供所有DW/BI分析的最终标识和分组。

所以维度建模表示每个业务过程包含的事实表，事实表里面存储事件的数值化度量，围绕事实表的是多个维度表，维度表包含事件发生的实际存在的文本环境。

从图表中能看出来，维度模型（星型模型）比较简单，而且适于变化，各个维度的地位相同。可根据业务情况进行新增或者修改（只要维度的单一值已经存在事实表中）。

雪花模型：

维度建模的主要是4个主要决策：

1、选择业务过程

业务过程是通常表示的是业务执行的活动，与之相关的维度描述和每个业务过程事件关联的描述性环境。
通常由某个操作型系统支持，例如：订单系统。
业务过程建立或获取关键性能度量。
一系列过程产生一系列事实表。

2、声明粒度

粒度传递的是与事实表度量有关的细节级别。
精确定义某个事实表的每一行表示什么。
对事实表的粒度要达成共识。

3、确认维度

健壮的维度集合来粉饰事实表。
维度表示承担每个度量环境中所有可能的单值描述符。

4、确认事实

不同粒度的事实必须放在不同的事实表中。
事实表的设计完全依赖物理活动，不受最终报表的影响。
事实表通过外健关联与之相关的维度。
查询操作主要是基于事实表开展计算和聚合。

其中粒度是非常重要的，粒度用于确定事实表的行表示什么，建议从关注原子级别的粒度数据开始设计，因为原子粒度能够承受无法预估的用户查询，而且原子数据可以以各种可能的方式进行上卷，而一旦选择了高粒度，则无法满足用户下钻细节的需求。

事实是整个维度建模的核心，其中雪花模型或者星型模型都是基于一张事实表通过外健关联维表进行扩展，生成一份能够支撑可预知查询需求的模型宽表，而且最后的查询也是落在事实表中进行。

目前常见的维度模型：
星型模型
每一个维表都与都与事实表相关联。数据冗余量较大
雪花模型
有些维表可能不与事实表直接关联，而是通过其他维表关联到事实表。数据冗余量较小
星座模型
由多个事实表相组合，维表是公共的。企业中一般都是星座模型

注意：

维度表的唯一主键应该是代理健而不是来自系统的标示符，也就是所谓的自然健，因为自然键通常具有一定的业务含义，但日久天长，这些信息是有可能发生变化的，而代理健可以提高关联效率并将关系数据库设计和业务的解耦。
维度表和事实表关联的每个连接应该基于无含义的整数代理健。
固定深度层次在维度表中应该扁平化，规范化的雪花模型不利于多属性浏览，而且大量的表和连接操作会影响性能。
非完全独立的维度应该合并为一个维度，将同一层次的元素标示为事实表中不同维度是错误的，会增加查询和存储负担，最后变成蜈蚣表，例如：日维度、周维度、月维度等可以合并为一个周期维度。