星型模型、雪花模型、星座模型及数仓建模方法

待我称王封你为后i 2022-05-16 12:58 348阅读 0赞

整体流程概览

![这里写图片描述][70]

（1）数据仓库（Data WareHouse，简称DW）：

数据仓库是一种资讯系统的资料储存理论，主要功能乃是将组织透过资讯系统之联机交易处理（OLAP）经年累月所累积的大量资料，透过数据仓库理论所特有的资料储存架构，作一有系统的分析整理，以利各种分析方法，例如线上分析处理及数据挖掘之进行，并且进而支持例如决策支持系统及主管资讯系统之创建，帮助决策者能快速有效的自大量资料中，分析出有价值的资讯，以利决策拟定及快速回应外在环境变动，帮助建构商业智慧。

（2）数据模型：

数据模型是抽象描述现实世界的一种工具和方法，是通过抽象的实体及实体之间联系的形式，来表示现实世界中事务的相互关系的一种映射

有别于一般联机交易处理(OLTP)系统，数据模型设计是一个数据仓库设计的地基，当前两大主流理论分别为采用正规方式(normalized approach)或多维方式(dimensional approach)进行数据模型设计。 数据模型可以分为逻辑与实体数据模型。逻辑数据模型陈述业务相关数据的关系，基本上是一种与数据库无关的结构设计，通常均会采用正规方式设计。实体数据模型则与数据库管理系统有关，是建置在该系统上的数据架构，故设计时需考虑数据类型(data type)、空间及性能相关的议题。

整个数据仓库得建模过程中，我们需要经历一般四个过程：

业务建模，生成业务模型，主要解决业务层面的分解和程序化。

领域建模，生成领域模型，主要是对业务模型进行抽象处理，生成领域概念模型。

逻辑建模，生成逻辑模型，主要是将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化。

物理建模，生成物理模型，主要解决，逻辑模型针对不同关系型数据库的物理化以及性能等一些具体的技术问题。

实现方式：

数据仓库是一个过程而不是一个项目。

数据仓库系统是一个信息提供平台，他从业务处理系统获得数据，主要以星型模型和雪花模型进行数据组织，并为用户提供各种手段从数据中获取信息和知识。

从功能结构划分，数据仓库系统至少应该包含数据获取（Data Acquisition）、数据存储（Data Storage）、数据访问（Data Access）三个关键部分。

（3）元数据

描述数据仓库内数据的结构和建立方法的数据。可将其按用途的不同分为两类，技术元数据和商业元数据。

技术元数据：

是数据仓库的设计和管理人员用于开发和日常管理数据仓库使用的数据。包括：数据源信息；数据转换的描述；数据仓库内对象和数据结构的定义；数据清理和数据更新时用的规则；源数据到目的数据的映射；用户访问权限，数据备份历史记录，数据导入历史记录，信息发布历史记录等。

商业元数据：

从商业业务的角度描述了数据仓库中的数据。包括：业务主题的描述，包含的数据、查询、报表；

元数据为访问数据仓库提供了一个信息目录（informationdirectory），这个目录全面描述了数据仓库中都有什么数据、这些数据怎么得到的、和怎么访问这些数据。是数据仓库运行和维护的中心，数据仓库服务器利用他来存贮和更新数据，用户通过他来了解和访问数据。

（4）数据集市

为了特定的应用目的或应用范围，而从数据仓库中独立出来的一部分数据，也可称为部门数据或主题数据（subjectarea）。在数据仓库的实施过程中往往可以从一个部门的数据集市着手，以后再用几个数据集市组成一个完整的数据仓库。需要注意的就是在实施不同的数据集市时，同一含义的字段定义一定要相容，这样在以后实施数据仓库时才不会造成大麻烦。

（5）数据仓库建模

目前业界较为流行的数据仓库的建模方法非常多，这里主要介绍范式建模法，维度建模法，实体建模法等几种方法，每种方法其实从本质上讲就是从不同的角度看我们业务中的问题。

范式建模法：

范式建模法其实是我们在构建数据模型常用的一个方法，是Inmon提出的集线器的自上而下（EDW-DM）的数据仓库架构。操作型或事务型系统的数据源，通过ETL抽取转换和加载到数据仓库的ODS层，然后通过ODS的数据建设原子数据的数据仓库EDW，EDW不是多维格式的，不方便上层应用做数据分析，所以需要通过汇总建设成多维格式的数据集市层。优势：易于维护，高度集成；劣势：结构死板，部署周期较长。主要解决关系型数据库得数据存储，利用的一种技术层面上的方法。目前，我们在关系型数据库中的建模方法，大部分采用的是第三范式（Third Normal Form）建模法。

![这里写图片描述][70 1]

ODS和EDW？

ODS简单的理解为 Operational Data Store, 可操作的数据仓库。ODS在数据仓库中是可选择的一部分，但不是必须的。隔离仓库环境和业务环境；ODS作为数据缓冲层，保留的是所有的数据，理论上粒度和源系统保持一致，同时不丢数据，业务DB基本上是直接同步过来，LOG主要是做结构化。

EDW简单理解为 Enterprise Data Warehouse, 企业级数据仓库。属于分析型数据。随着数据爆炸，数据量呈爆发式增长，机器学习与数据挖掘方法的不断改进，EDW在企业中处于越来越重要的位置。ODS的数据经过规范化、解析、整合和筛选之后，进入EDW。EDW中的数据是全公司的数据，根据业务做主题梳理建设之后，需要能方便地满足对于全公司数据的分析，同时又能满足各业务部门数据集市的需求，它需要作为各个部门分析数据的来源，保证数据一致性。这里应该放的比较稳定和公司层面比较通用的数据。

ODS是数据仓库的一个扩展，它也是一个企业级的数据存储模式，它的构造也是面向主题的。ODS是企业中运行系统发布信息的地方，这些信息是实时或接近实时的，这些信息可以被企业中的其它系统使用，包括数据仓库。但ODS与数据仓库不完全一样，主要区别有四点：

1.ODS存放的数据是实时的、可动态刷新的，而数据仓库存储的数据是非实时的、静态的；

2.ODS主要保存当前运行系统的数据，而数据仓库除了保存当前数据，还需要保存大量的历史数据；

3.ODS主要保存明细数据，而数据仓库需要同时保存明细和汇总数据；

4.ODS中的数据可以用于日常分析，而数据仓库中的数据主要用于战略分析。

一般对于ODS设计有如下几个作用：

1.在业务系统和数据仓库之间形成一个隔离层。

2.转移一部分业务系统细节查询的功能。

3.完成数据仓库中不能完成的一些功能。

如图展示数据库，ODS和EDW之间的关系：

![这里写图片描述][70 2]

其中，ADB为传统的关系型数据库，A,B,C表示不同类型的数据流转。A环节表示生产环境中不同数据库之间直接交换数据，例如mysql,sqlserver,oracle等DB直接通过Informatic等工具交换数据。B表示生产环境中的应用数据通过ODS进行数据交换。C表示数据进行到EDW中。具体可以参见https://blog.csdn.net/bitcarmanlee/article/details/51013474这篇博客的说明。

什么是第三范式？

设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。

第一范式（1NF）：指在关系模型中，对域添加的一个规范要求，所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。即实体中的某个属性有多个值时，必须拆分为不同的属性。在符合第一范式（1NF）表中的每个域值只能是实体的一个属性或一个属性的一部分。简而言之，第一范式就是无重复的域。

第二范式（2NF）：在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或记录必须可以被唯一地区分。选取一个能区分每个实体的属性或属性组，作为实体的唯一标识。例如在员工表中的身份证号码即可实现每个一员工的区分，该身份证号码即为候选键，任何一个候选键都可以被选作主键。在找不到候选键时，可额外增加属性以实现区分，如果在员工关系中，没有对其身份证号进行存储，而姓名可能会在数据库运行的某个时间重复，无法区分出实体时，设计辟如ID等不重复的编号以实现区分，被添加的编号或ID选作主键。（该主键的添加是在ER（Entity Relationship Diagram，实体-联系图)设计时添加，不是建库时随意添加）。简而言之，第二范式就是在第一范式的基础上属性完全依赖于主键。

第三范式（3NF）：在2NF基础上，任何非主属性不依赖于其它非主属性（在2NF基础上消除传递依赖）。简而言之，第三范式（3NF）要求一个关系中不包含已在其它关系已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept\_id）、部门名称、部门简介等信息。那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。

因此，范式建模法需要满足

每个属性值唯一，不具有多义性 ;

每个非主属性必须完全依赖于整个主键，而非主键的一部分 ;

每个非主属性不能依赖于其他关系中的属性，因为这样的话，这种属性应该归到其他关系中去。

范式建模法的最大优点就是从关系型数据库的角度出发，结合了业务系统的数据模型，能够比较方便的实现数据仓库的建模。但其缺点也是明显的，由于建模方法限定在关系型数据库之上，在某些时候反而限制了整个数据仓库模型的灵活性，性能等，特别是考虑到数据仓库的底层数据向数据集市的数据进行汇总时，需要进行一定的变通才能满足相应的需求。

维度建模法：

Kimball提出的总线式的自下而上（DM-DW）的数据仓库架构。同样的，操作型或事务型系统的数据源，通过ETL抽取转换和加载到数据仓库的ODS层，然后通过ODS的数据，利用维度建模方法建设一致维度的数据集市。通过一致性维度可以将数据集市联系在一起，由所有的数据集市组成数据仓库。优势：构建迅速，最快的看到投资回报率，敏捷灵活；劣势：作为企业资源不太好维护，结构复杂，数据集市集成困难。常见的模型：星型模型和雪花模型

星型模型：

![这里写图片描述][70 3]

星型模是一种多维的数据关系，它由一个事实表和一组维表组成。每个维表都有一个维作为主键，所有这些维的主键组合成事实表的主键。强调的是对维度进行预处理，将多个维度集合到一个事实表，形成一个宽表。这也是我们在使用hive时，经常会看到一些大宽表的原因，大宽表一般都是事实表，包含了维度关联的主键和一些度量信息，而维度表则是事实表里面维度的具体信息，使用时候一般通过join来组合数据，相对来说对OLAP的分析比较方便。

雪花模型：

![这里写图片描述][70 4]

当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 "层次 " 区域，这些被分解的表都连接到主维度表而不是事实表。雪花模型更加符合数据库范式，减少数据冗余，但是在分析数据的时候，操作比较复杂，需要join的表比较多所以其性能并不一定比星型模型高。（雪花模型可以理解为，为了获取更“深”或更“细”一级的信息）

优缺点：

雪花模型可以精确表示层次化的数据，但还是应该避免使用雪花模式，因为对商业用户来说，理解雪花模式并在其中查询是非常困难的，雪花模式还会影响查询性能

从查询性能角度来看，在OLTP-DW环节，由于雪花型要做多个表联接，性能会低于星型架构；但从DW-OLAP环节，由于雪花型架构更有利于度量值的聚合，因此性能要高于星型架构。

从模型复杂度来看，星型架构更简单。

从层次概念来看，雪花型架构更加贴近OLTP系统的结构，比较符合业务逻辑，层次比较清晰。

从存储空间角度来看，雪花型架构具有关系数据模型的所有优点，不会产生冗余数据，而相比之下星型架构会产生数据冗余。

根据我们的项目经验，一般建议使用星型架构。因为我们在实际项目中，往往最关注的是查询性能问题，至于磁盘空间一般都不是问题。 当然，在维度表数据量极大，需要节省存储空间的情况下，或者是业务逻辑比较复杂、必须要体现清晰的层次概念情况下，可以使用雪花型维度。

在复合式的数据仓库架构中，操作型或事务型系统的数据源，通过ETL抽取转换和加载到数据仓库的ODS层，然后通过ODS的数据，利用范式建模方法，建设原子数据的数据仓库EDW，然后基于EDW，利用维度建模方法建设数据集市。

应用场景：

星型模型的设计方式主要带来的好处是能够提升查询效率，因为生成的事实表已经经过预处理，主要的数据都在事实表里面，所以只要扫描事实表就能够进行大量的查询，而不必进行大量的join，其次维表数据一般比较少，在join可直接放入内存进行join以提升效率，除此之外，星型模型的事实表可读性比较好，不用关联多个表就能获取大部分核心信息，设计维护相对比较简答。

雪花模型的设计方式是比较符合数据库范式的理念，设计方式比较正规，数据冗余少，但在查询的时候可能需要join多张表从而导致查询效率下降，此外规范化操作在后期维护比较复杂。

星座模型：

由多个事实表组合，维表是公共的，可以被多个事实表共享。星座模型是数据仓库最常使用的模型。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L01lZ3VzdGFzX0pKQw_size_16_color_FFFFFF_t_70]

总结：

数据仓库大多数时候是比较适合使用星型模型构建底层数据Hive表，通过大量的冗余来提升查询效率，星型模型对OLAP的分析引擎支持比较友好，这一点在Kylin中比较能体现。而雪花模型在关系型数据库中如MySQL，Oracle中非常常见，尤其像电商的数据库表。在数据仓库中雪花模型的应用场景比较少，但也不是没有，所以在具体设计的时候，可以考虑是不是能结合两者的优点参与设计，以此达到设计的最优化目的。

实体建模法：

实体建模法并不是数据仓库建模中常见的一个方法，它来源于哲学的一个流派。从哲学的意义上说，客观世界应该是可以细分的，客观世界应该可以分成由一个个实体，以及实体与实体之间的关系组成。那么我们在数据仓库的建模过程中完全可以引入这个抽象的方法，将整个业务也可以划分成一个个的实体，而每个实体之间的关系，以及针对这些关系的说明就是我们数据建模需要做的工作。

虽然实体法粗看起来好像有一些抽象，其实理解起来很容易。即我们可以将任何一个业务过程划分成 3 个部分，实体，事件和说明，如下图所示：

![这里写图片描述][70 5]

上图表述的是一个抽象的含义，如果我们描述一个简单的事实：“小明开车去学校上学”。以这个业务事实为例，我们可以把“小明”，“学校”看成是一个实体，“上学”描述的是一个业务过程，我们在这里可以抽象为一个具体“事件”，而“开车去”则可以看成是事件“上学”的一个说明。

从上面的举例我们可以了解，我们使用的抽象归纳方法其实很简单，任何业务可以看成 3个部分：

实体，主要指领域模型中特定的概念主体，指发生业务关系的对象。

事件，主要指概念主体之间完成一次业务流程的过程，特指特定的业务过程。

说明，主要是针对实体和事件的特殊说明。

由于实体建模法，能够很轻松的实现业务模型的划分，因此，在业务建模阶段和领域概念建模阶段，实体建模法有着广泛的应用。从笔者的经验来看，再没有现成的行业模型的情况下，我们可以采用实体建模的方法，和客户一起理清整个业务的模型，进行领域概念模型的划分，抽象出具体的业务概念，结合客户的使用特点，完全可以创建出一个符合自己需要的数据仓库模型来。

但是，实体建模法也有着自己先天的缺陷，由于实体说明法只是一种抽象客观世界的方法，因此，注定了该建模方法只能局限在业务建模和领域概念建模阶段。因此，到了逻辑建模阶段和物理建模阶段，则是范式建模和维度建模发挥长处的阶段。

[70]: /images/20220516/2e30d057569040faa49a9d18dd424c4e.png
[70 1]: /images/20220516/f8044ab9256d4800be9e776e2335a0a1.png
[70 2]: /images/20220516/06d41e13e0144393af824564b793cbe0.png
[70 3]: /images/20220516/517d7f58ff0f41d19fcf45e3a708146f.png
[70 4]: /images/20220516/a65016008ac9471bbf36db98afd5e481.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L01lZ3VzdGFzX0pKQw_size_16_color_FFFFFF_t_70]: /images/20220516/d847936bb9124c6d8ba306eed38329c2.png
[70 5]: /images/20220516/86d88fe6552f410ab8d632a018ef92e6.png