从0开始学大数据-数据仓库建模
为什么要数据仓库建模
数据模型是数据组织和存储方法，它强调从业务、数据存取和使用角度合理存储数据。有了适合业务和基础数据存储环境的模型，那么大数据就能获得以下好处：
-
性能：良好的数据模型能帮助我们快速查询所需要的数据，减少数据的 I/O 吞吐。
-
成本：良好的数据模型能极大地减少不必要的数据冗余，也能实现计算结果复用，极大的降低大数据系统中的存储和计算成本。
-
效率：良好的数据模型能极大地改善用户使用数据的体验，提高使用数据的效率。
-
质量：良好的数据模型能改善数据统计口径的不一致性，减少数据计算错误的可能性。
范式建模
范式建模（Third Normal Form，3NF）是在构建数据模型常用的一个方法，该方法主要由 Inmon 所提倡，主要解决关系型数据库的数据存储，利用的一种技术层面上的方法。目前在关系型数据库中的建模方法，大部分采用的是三范式建模，即通过实体关系（Entity Relationship，ER）模型描述企业业务。
范式是数据库逻辑模型设计的基本理论，一个关系模型可以从第一范式到第五范式进行无损分解，这个过程称为 规范化。在数据仓库的模型中目前一般采用第三范式，它有着严格的数学定义。从其表达的含义来看，一个符合三范式的关系必须具有以下三个条件：
-
每个属性值唯一，不具有多义性；
-
每个非主属性必须完全依赖于整个主键，而非主键的一部分；
-
每个非主属性不能依赖于其他关系中的属性，因为这样的话，这种属性应该归到其他关系中。
Inmon 提出的集线器的自上而下（EDW-DM）的数据仓库架构。操作型或事务型系统的数据源，通过 ETL 抽取转换和加载到数据仓库的 ODS 层，然后通过 ODS 的数据建设原子数据的数据仓库 EDW，EDW 不是多维格式的，不方便上层应用做数据分析，所以需要通过汇总建设成多维格式的数据集市层。
3NF 模型基本组成
-
实体：相同特征和性质的属性抽象，用抽象的实体名和属性名共同刻画的逻辑实体；
-
关系：实体之间的关系；
-
属性：实体的某种特性，一般实体具有多个属性。
范式建模的特点
-
需要全面了解企业业务和数据
-
实施周期非常长
-
对建模人员的能力要求非常高
ER 模型
ER 模型是数据库设计的理论基础，当前几乎所有的 OLTP 系统设计都采用 ER 模型建模方式。
采用 ER 模型建设数据仓库模型的出发点是整合数据，将各个系统中的数据以整个企业角度按主题进行相似性组合和合并，并进行一致性处理，为数据分析决策服务，但是并不能直接用于分析决策。
建模步骤
建模步骤分为三个阶段：
-
高层阶段：一个高度抽象的模型，描述主要的主题以及主题间的关系，用于描述企业的业务总体概况。
-
中层模型：在高层模型的基础上，细化主题的数据项。
-
物理模型：也叫做底层模型，在中层模型的基础上，考虑物理存储，同时基于性能和平台特点进行物理属性的设计，也可能做一些表的合并、分区的设计等。
维度建模
维度建模是数据仓库领域另一位大师 Ralph Kimball 所倡导，是数据仓库工程领域最流行的数仓建模经典。维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。维度建模是专门用于分析型数据库、数据仓库、数据集市建模的方法。
-
维度模型是一个规范化的事实表和反规范化的一些维度表组成的
-
一种非规范化的关系模型
-
表跟表之间的关系通过关键字和外键来定义
-
-
以良好的可理解性和方便的产生报表来进行数据组织，很少考虑修改的性能
-
通过SQL或者相关的工具实现数据查询和维护
维度表
每一张维表对应现实世界中的一个对象或者概念。如：客户、产品、日期、地区、商场。
维表的特征：
-
包含了众多描述性的列：维表的范围很宽（具有多个属性）
-
通常情况下，跟事实表相比，行数相对较小，通常小于 10 万条
-
内容相对固定，几乎就是一类查找表，或编码表
事实表
每一个事实表通常包含了处理所关系的度量值
每一个事实表的行包括：
-
具有可加性的数值型的度量值
-
与维表相连接的外键
-
通常具有两个和两个以上的外键
-
外键之间表示维表之间多对多的关系
-
事实表的特征：
-
数据量大
-
列数较少
-
经常发生变化
建模流程
-
选择业务过程
该步骤需要建模人员深入到实际业务流程当中，从中建立性能度量，并转化为事实表中的事实。一旦事实表被建立，则对应的粒度即维度也会相对定义。所以这一步还是比较重要的。
-
声明粒度
粒度声明是维度设计的重要步骤，通常选用最低级别的原子粒度，因为原子粒度能够承受无法预期的用户查询。 -
确定维度
因为维度表可以描述事实的属性，维度表有时会被称为数据仓库的灵魂。它是数据仓库系统能够被用作业务分析的入口和描述性标识。 -
确定事实
事实表为实际业务过程中的度量，大部分以数值表示。一个事实表对应一个现实中的某项事务。
维度建模的三种模式
星型模型
星型模式（Star Schema）是面向主题的常用模式，主要由一个事实表及多个维表构成，不存在二级维表。
可以看出，星型模型的维度建模由一个事实表和一组维表组成，且具有以下特点：
-
维表只和事实表关联，维表之间没有关联；
-
每个维表的主码为单列，且该主码放置在事实表中，作为两边连接的外码；
-
以事实表为核心，维表围绕很呈星型分布。
雪花模型
雪花模型（Snowflake Schema）是在星型模型基础上将维表再次扩展，每个维表可以继续向外连接多个子维表。
雪花模型优缺点：
-
优点：耦合性低、冗余小；
-
缺点：跨多表查询时性能低。
星型模型中的维表相对雪花模型来说要大，而且不满足规范化设计。雪花模型相当于将星型模型的大维表拆分成小维表，满足了规范化设计。然而这种模式在实际应用中很少见，因为这样做会导致开发难度增大，而数据冗余问题在数据仓库中并不严重。
星座模型
星座模型（Fact Constellations Schema）也是星型模型的扩展，存在多个事实表且可共用同一个维表。
前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表可能被多个事实表用到。在业务发展的后期，绝大部分维度建模都采用的是星座模型。
三种模式对比
雪花模型是将星型模型的维表进一步划分，使各维表均满足服繁华设计。星座模型则是允许星型模型中出现多个事实表。
一般在面向数据集市主题建模的时候会采用星型模型，如果是企业级数据仓库的建立则采用星座模式较多。数据建模的根本目的是 避免冗余，尽可能提升查询性能，建模方式没有最好只有最优。
Data Vault 模型
Data Vault模型是 Dan Linstedt 在20世纪90年代提出的，主要在对自然界中发现的复杂网络建模。
Data Vault 是面向细节的，可追踪历史的，一组有连接关系的规范化的表的集合。这些表可以支持一个或多个业务功能。从建模风格上看，它采用了一种由第三范式方法（3NF）与维度建模方法混合而成的方式，以二者的独特组合来满足企业需求。
设计理念：满足企业对灵活性、可扩展性、一致性和对需求的适应性要求，是一种专门为企业级数据仓库量身定制的建模方式。
“Hub 可以想象成人的骨架，Link 就是连接骨架的韧带，Satellite 就是骨架上面的须肉
基本结构
1. 中心表（Hub）
中心表用来保存一个组织内的每个实体的业务主键，业务主键唯一标识某个业务实体。
中心表和源系统表相互独立。当一个业务主键用在多个系统时，它在 Data Vault 中只保留一份，其他的组件都链接到这一个业务主键上。
**2. 链接表（Link） **
链接表是中心表之间的链接。一个链接表意味着两个或多个中心表之间有关联。一个链接表通常是一个外键，它代表着一种业务关系。
3. 附属表（Satellite）
附属表用来保存中心表和链接表的属性，包括所有的历史变化数据。一个附属表总有一个且唯一一个外键引用到中心表或链接表。
Data Vault 模型特点
-
所有数据都基于时间来存储，即时数据是低质量的，也不能在 ETL 过程中处理掉；
-
依赖越少越好
-
和源系统越独立越好
-
设计上适合变化，源系统中数据的变化，在不改变模型的情况下可扩展。
-
ETL 作业可以重复执行
-
数据完全可以追踪。
Anchor 模型
Anchor 对 Data Vault 模型做了进一步规范化处理，是一个高度可扩展的模型，其核心思想是所有的扩展只是添加而不是修改，因此将模型规范到 6NF，基本变成了 k-v 结构化模型。
Anchor 模型组成：
-
Anchors：类似于 Data Vault 的 Hub，代表业务实体，且只有主键。
-
Attributes：功能类似于 Data Vault 的 Satellite，但是它更加规范化，将其全部 k-v 结构化，一个表只有一个 Anchors 的属性描述。
-
Ties：就是 Anchors 之间的关系，单独用用来描述，类似于 Data Vault 的 Link，可以提升整体模型关系的罗占能力。
-
Knots：代表那些可能会在多个 Anchors 中公用的属性的提炼，比如性别、状态等这种枚举类型且被共用的属性。
数据仓库中的分析查询只是基于一小部分字段进行的，类似于列存储结构，使用 Anchor 模型可以大大减少扫描的数据量，从而提升查询性能。
总结
数据仓库建模是一个综合性技术，需要使用到ER建模、关系建模、维度建模等技术。而且当企业业务复杂的时候，这部分工作更是需要专门团队与业务方共同合作来完成。因此一个优秀的数据仓库建模团队既要有坚实的数据仓库建模技术，还要有对现实业务清晰、透彻的理解。
-- END --