数据仓库建模的流程(数据仓库建模工具有哪些)

你好，我是dqdpkq。 好久不见~

今天，我们来谈谈几仓常见的建模方法和具体实例的演示。 一起看看吧。

一、为什么需要数据建模？ 在开始今天的故事之前，让我们先想想为什么需要数据建模。

随着IT时代向灾难恢复时代的飞跃，数据开始急剧增长，其中所产生的价值不言而喻。 如何组织和结构分类存储这些数据是所有数据运营商面临的挑战。

把数据当成图书馆的书，我想看看它们分别放在书架上，而不是乱七八糟地堆着。

的数据仓库建模是一种用于更好地组织和存储数据的建模方法，以在性能、成本、效率和数据质量之间取得最佳平衡。 一般来说，从以下四个方面考虑。

性能—快速查询所需数据并降低数据I/O吞吐量。 成本：减少不必要的数据冗馀，实现计算复用，降低大数据系统中的存储和计算成本。 效率：改善数据体验，提高使用效率。 质量：改善数据统计口径不匹配，减少数据计算错误的可能性，提供高质量一致的数据访问平台。 因此，毋庸置疑，大数据系统、数据平台都需要更好地组织和存储数据的数据模型方法。 数据建模工作正围绕这四个指标努力实现最佳平衡。

二、从OLTP系统和OLAP系统的区别来看，模型方法论的选择OLTP系统通常面向的主要数据操作是随机读写，主要是利用3NF的实体关系模型存储数据，从而在事务处理中实现数据的冗馀和完整性

OLAP系统面向的主要数据操作是批量读写，事务中的一致性不是OLAP关注的问题，而是主要关注数据集成和一次性复杂大数据中查询和处理的性能，因此需要采用维度建模等不同的建模方法

如果大家想了解更多关于OLAP系统的事情，请学习这篇文章。 关于OLAP数仓，这大概是史上最全面的总结。

三、典型数据仓库建模方法论数据仓库的本质来自数据库，因此数据仓库建模也在不断派生发展。

从最初借鉴关系数据库理论的范式转换出发，逐渐提出维度建模等，今后建模要求越高，越需要满足3NF、4NF等。 但是，对于数据仓库来说，目前的主流是维度建模，混杂着范式转换。

数据仓库的建模方法学可分为E-R模型、维模型、数据vault模型和Anchor模型。

3.1 E-R模型将事物抽象为“实体”、“属性”、“关系”以表示数据关联和事物说明。 这种数据的抽象建模通常被称为E-R实体关系模型。

数据仓库之父Bill Inmon提出的建模方法是从企业整体高度设计3NF模型，采用实体关系(Entity Relationship )模型描述企业业务，满足3NF。

数据仓库3NF和OLTP系统3NF的区别在于，它是以企业的角度而不是特定的业务流程为导向的主题抽象。

采用E-R模型建设数据仓库模型的出发点是整合数据，将各系统的数据从整个企业的角度按主题进行相似组合和整合，进行一致性处理，为数据分析决策提供服务，但不能直接用于分析决策

作为标准的数据建模方案，实现周期非常长，一致性和可扩展性强，经得起时间的考验。 但是，随着企业数据的高速增长、复杂化，数仓全部采用E-R模型建模，越来越不适合现代化复杂多变的业务组织，因此一般只有数仓底层的ODS、DWD采用E-R关系模型进行设计。

E-R建模过程分为三个阶段。

高级模型：描述主要主题和主题之间关系的高度抽象模型。 用于概述企业的整个业务。 中间层模型：基于高层模型细分主题数据项。 物理模型(基础模型)基于中间层模型，在考虑物理存储的同时，根据性能和平台的特点进行物理属性的设计。 另外，有时也进行几个表的合并、分区的设计等。

E-R模式在实践中最典型的代表是Teradata公司基于金融业务发布的金融服务逻辑数据模型(fs-LDM )，它通过对金融业务的高度抽象和总结，将金融业务划分为10大类

3.2维模型维模型由数据仓库领域的Ralph Kimball大师提出，是数据仓库工程领域最受欢迎的数仓建模经典。

维度建模通过分析决策需求来构建模型，并将构建的数据模型作为分析需求服务，重点是用户如何更快地达到分析需求，同时具有较大、较复杂的查询响应能力。

其代表是使用星形模型和在一些特殊场景中使用的雪花模型。

其设计主要分为以下几个步骤。

选择需要进行分析决策的业务过程业务流程可以是单个业务事件，例如交易支付、退款等； 也可以是某个事件的状态，例如当前账户的余额； 另外，还有一个由一系列相关业务事件组成的业务流程。 具体而言，需要分析特定事件发生的情况、当前状态或事件流程的效率。选择粒度事件分析预先确定所有分析都需要细分的程度，并确定选择的粒度。 粒度是维度的组合。 选择识别维表粒度后，根据该颗粒

度来设计维表，包括维度属性，用于分析时进行分组和筛选。选择事实。确定分析需要衡量的指标。

在 Ralph Kimball 提出对数据仓库维度建模，我们将数据仓库中的表划分为事实表、维度表两种类型。

针对维度建模中事实表和维度表的设计，之前有详细介绍过，感兴趣的同学可以看：维度建模技术实践——深入事实表 、维度建模的灵魂所在——维度表设计。

在这里，我就以常见的电商场景为例：在一次购买的事件中，涉及主体包括客户、商品、商家，产生的可度量值会包括商品数量、金额、件数等。

事实表根据粒度的角色划分不同，可分为事务事实表、周期快照事实表、累积快照事实表等。

事务事实表：用于承载事务数据，任何类型的事件都可以被理解为一种事务，比如商家在交易过程中的常见订单、买家付款，物流过程中的揽货、发货、签收，退款中的申请退款。周期快照事实表：快照事实表以预定的间隔采样状态度量，比如自然年至今或者历史至今的下单金额、支付金额、支付买家数、支付商品件数等等状态度量。累计快照事实表：数据不断更新，选取多业务过程日期。用来记录具有时间跨度的业务处理过程的整个过程的信息，每个生命周期一行，通常这类事实表比较少见。

我们继续就上述的电商场景，聊聊在维表设计时需要关注的一些东西：

缓慢变化维度：例如会员表的手机号、地址、生日等属性。退化维度 ：订货单表的订单编号、物流表的物流编号等。雪花维度：满足第三范式的维度关系结构。非规范化扁平维度：商品维表众中产品、品牌、类目、品类等。多层次维度：地区维度的省、市、区县，商品的类目层级。角色维度：日期维度在物流中扮演发货日期、送货日期、收获日期等不同角色。

接下来就是针对维度建模按照数据的组织类型，可以划分为星型模型、雪花模型、星座模型。

星型模型：星型模型主要是维表和事实表，以事实表为中心，所有维度直接关联在事实表上，呈星型分布。

2. 雪花模型，在星型模型的基础上，维度表上又关联了其他维度表。这种模型维护成本高，性能方面会差一些。

3. 星座模型，是对星型模型的扩展延伸，多张事实表共享维度表。实际上数仓模型建设后期，大部分维度建模都是星座模型。

简单总结下就是：

星型模型和雪花模型主要区别就是对维度表的拆分。对于雪花模型，维度表的涉及更加规范，一般符合3NF，有效降低数据冗余，维度表之间不会相互关联。星型模型，一般采用降维的操作，反规范化，不符合3NF，通过利用冗余来避免模型过于复杂，提高易用性和分析效率，效率相对较高。 3.3 DataVault 模型

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

它强调建立一个可审计的基础数据层，也就是强调数据的历史性、可追溯性和原子性，而不要求对数据进行过度的一致性处理和整合。

同时它基于主题概念将企业数据进行结构化组织，并引入了更进一步的范式处理来优化模型，以应对源系统变更的扩展性。 Data Vault 型由以下几部分组成：

Hub - 中心表：是企业的核心业务实体，由实体 Key、数仓序列代理键、装载时间、数据来源组成，不包含非键值以外的业务数据属性本身。Link - 链接表：代表 Hub 之间的关系。这里与 ER 模型最大的区别是将关系作为一个独立的单元抽象，可以提升模型的扩展性。它可以直接描述 1:1、1:2和n:n的关系，而不需要做任何变更。它由 Hub的代理键、装载时间、数据来源组成。Satellite - 卫星表：数仓中数据的主要载体，包括对链接表、中心表的数据描述、数值度量等信息。

Data Vault 模型比 E-R 模型更容易设计和产出，它的 ETL 加工可实现配置化。我们可以将 Hub 想象成人的骨架，那么 Link 就是连接骨架的韧带，而 SateIIite 就是骨架上面的血肉。

3.4 Anchor 模型

Anchor 对 Data Vault 模型做了进一步的规范化处理，它的核心思想是所有的扩展只是添加而不是修改，因此将模型规范到6NF，基本变成了 k-v 结构化模型。

Anchors ：类似于 Data Vault 的 Hub ，代表业务实体，且只有主键。Attributes ：功能类似于 Data Vault 的 Satellite，但是它更加规范化，将其全部 k-v 结构化， 一个表只有一个 Anchors 的属性描述。Ties ：就是 Anchors 之间的关系，单独用表来描述，类似于 Data Vault 的 Link ，可以提升整体模型关系的扩展能力。Knots ：代表那些可能会在 Anchors 中公用的属性的提炼，比如性别、状态等这种枚举类型且被公用的属性。

由于过度规范化，使用中牵涉到太多的Join操作，这里我们就仅作了解。

四、总结

以上为四种基本的建模方法，目前主流建模方法为： E-R模型、维度模型。

E-R模型通常用于OLTP数据库建模，应用到构建数仓时就更偏向于数据整合，站在企业整体考虑，将各个系统的数据按相似性一致性、合并处理，为数据分析、决策服务，但并不便于直接用来支持分析。

维度建模是面向分析场景而生，针对分析场景构建数仓模型；重点关注快速、灵活的解决分析需求，同时能够提供大规模数据的快速响应性能。针对性强，主要应用于数据仓库构建和OLAP引擎低层数据模型。

数据仓库模型的设计是灵活的，不会局限于某一种模型，需要以实际的需求场景为导向，需要兼顾灵活性、可扩展性以及技术可靠性及实现成本。

我是「dqdpkq」，一枚热爱技术、会写诗的大数据开发猿，欢迎大家关注呀！

Respect ~