数据仓库简介

一图解千愁

1.概念

1.1.数据仓库概念

数据仓库之父比尔·恩门（Bill Inmon）给出数据仓库的定义如下:

数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策(Decision Making Support)

• 面向主题：面向抽象或者面向业务。比如仓储，速运、财务等业务域
• 集成：数据仓库相当于一个数据中心，其数据来自于其它各个oltp系统、文本格式等异构数据源，按照一定的规则将数据进行组合存储
• 相对稳定：数仓中数据一般按照天的频率从其它异构数据源抽取插入，一般不进行更新或删除操作
• 反映历史变化：数仓数据存储几年甚至几十年，通过数仓数据能够反应历史的数据变化

1.2事实表

事实表用来存放业务上事实发生的数据，如订单表、发货表，一般由维度和度量组成

1.2.1事务事实表

事务事实表和周期快照事实表、累积快照事实表使用相同的一致性维度，主要区别在于描述业务事实方面。事务事实表记录事实层面的事实，保存的是最原子的数据，也称“原子事实表”。事务事实表中的数据在事务事件发生后产生，数据的粒度通常是每个事务一条记录。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。

事务事实表的日期维度记录的是事务发生的日期，它记录的事实是事务活动的内容。用户可以通过事务事实表对事务行为进行特别详细的分析。

通过事务事实表，还可以建立聚集事实表，为用户提供高性能的分析。

1.2.2周期快照事实表

周期快照事实表以具有规律性的、可预见的时间间隔来记录事实，时间间隔如每天、每月、每年等等。典型的例子如销售日快照表、库存日快照表等，实际上就是我们说的聚合表，一般在事务事实表基础上进行汇总

1.2.3累积快照事实表

1.3维表

维度表可以看作是看数据的角度，如时间、地域、产品等均为维度

• 静态维
• 缓慢变化维(slowly changing dimension)

缓慢变化维可以简写为scn，指维度中的值随时间推移缓慢进行变化，如人员的家庭住址，电话号码等信息

根据业务需求不同对scn有三种处理方式：

• TYPE 1：直接更新 业务人员只关注最新维度信息，这种情况下直接进行对维度表中的值进行更新

• TYPE2：添加维度行 当有维度属性发生变化时，生成一条新的维度记录，主键是新分配的代理键，通过自然键可以和原维度记录保持关联。此种情况生成的维表可以成为拉链表

• TYPE3：添加属性列 维度表中新增一列添加上次记录和本次记录信息

• 退化维

  在维度建模的数据仓库中，有一种维度叫Degenerate Dimension，中文一般翻译为“退化维度”。

  这种退化维度一般都是事务的编号，如订单编号、发票编号等。这类编号需要保存到事实表中，但是不需要对应的维度表，所以称为退化维度。

1.4其它基本概念

1.4.1粒度

粒度是指数据仓库的数据单位中保存数据的细化或综合程度的级别。细化程度越高，粒度级就越小；相反，细化程度越低，粒度级就越大。数据的粒度一直是一个设计问题。数据仓库环境中粒度之所以是主要的设计问题，是因为它深深地影响存放在数据仓库中的数据量的大小，同时影响数据仓库所能回答的查询类型。粒度的大小需要数据仓库在设计时在数据量大小与查询的详细程度之间作出权衡。

举例：如时间上按日、周、月汇总销售额，这里的日、周、月指汇总的粒度。

1.4.2度量

在多维数据集中，度量值是一组值，这些值基于多维数据集的事实数据表中的一列，而且通常为数字。此外，度量值是所分析的多维数据集的中心值。即，度量值是最终用户浏览多维数据集时重点查看的数字数据（如销售、毛利、成本）

1.4.3ETL

ETL，Extraction-Transformation-Loading的缩写，即数据抽取（Extract）、转换（Transform）、装载（Load）的过程，它是构建数据仓库的重要环节。

ETL的设计分三部分：数据抽取、数据的清洗转换、数据的加载。在设计ETL的时候我们也是从这三部分出发。数据的抽取是从各个不同的数据源抽取到ODS（OperationalDataStore，操作型数据存储） 中——这个过程也可以做一些数据的清洗和转换），在抽取的过程中需要挑选不同的抽取方法，尽可能的提高ETL的运行效率。ETL三个部分中，花费时间最长的是“T”（Transform，清洗、转换）的部分，一般情况下这部分工作量是整个ETL的2/3。数据的加载一般在数据清洗完了之后直接写入DW （DataWarehousing，数据仓库）中去。

1.4.4数据建模

数据建模分为 业务建模 —>领域概念建模 —>逻辑建模 —>物理建模

➢  业务建模

划分整个单位的业务，一般按照业务部门的划分，进行各个部分之间业务工作的界定，理清各业务部门之间的关系

➢ 领域概念建模

确定领域实体属性关系，使用E-R图表示，E-R图主要是由实体、属性和联系三个要素构成的

➢ 逻辑建模

是将概念模型转化为具体的数据模型的过程，即按照概念结构设计阶段建立的基本E-R图，按选定的管理系统软件支持的数据模型（层次、网状、关系、面向对象），转换成相应的逻辑模型。这种转换要符合关系数据模型的原则。目前最流行就是关系模型（也就是对应的关系数据库）

➢ 物理建模

物理模型就是根据逻辑模型对应到具体的数据模型的机器实现。物理模型是对真实数据库的描述。如关系数据库中的一些对象为表、视图、字段、数据类型、长度、主键、外键、索引、约束、是否可为空、默认值

建模方法论

➢ 范式建模

范式建模法其实是在构建数据模型常用的一个方法，该方法的主要由 Inmon 所提倡，主要解决关系型数据库得数据存储，利用的一种技术层面上的方法。目前，我们在关系型数据库中的建模方法，大部分采用的是三范式建模法

三范式:

每一列都是不可分割的原子数据项
非主属性完全依赖于主键（组合主键），取消非主属性依赖于部分主键
任何非主属性不依赖于其它非主属性（在2NF基础上消除传递依赖）

优点:

结合了业务系统的数据模型，能够比较方便的实现数据仓库的建模

由于对事实属性的细分，可扩展性高。能够直接的体现实体属性间的关系

缺点:

拆分过细使用时候带来极大的不便。

限制了整个数据仓库模型的灵活性，性能等

➢ 维度建模

维度建模法，Kimball 最先提出这一概念。其最简单的描述就是，按照事实表，维表来构建数据仓库，数据集市。这种方法的最被人广泛知晓的名字就是星型模式（Star-schema）

优点：

维度建模非常直观，紧紧围绕着业务模型，可以直观的反映出业务模型中的业务问题。

不需要经过特别的抽象处理，即可以完成维度建模。

能够极大的提升数据仓库的处理能力

缺点:

维度建模法的缺点也是非常明显的，由于在构建星型模式之前需要进行大量的数据预处理，因此会导致大量的数据处理工作。

当业务发生变化，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理。而在这些与处理过程中，往往会导致大量的数据冗余。

如果只是依靠单纯的维度建模，不能保证数据来源的一致性和准确性，而且在数据仓库的底层，不是特别适用于维度建模的方法。

➢ 建模步骤

1. 确定业务主体

2. 定义粒度

3. 选定维度

4. 确定事实

注：本文图片内容参考 <阿里巴巴大数据实践>书籍

数仓规划概述_大数据开发治理平台 DataWorks-阿里云帮助中心

数据模型架构规范介绍_云原生大数据计算服务 MaxCompute-阿里云帮助中心

业务调研的定义维度与构建总线矩阵_云原生大数据计算服务 MaxCompute-阿里云帮助中心

数据仓库研发规范的阶段规划,角色职责和整体流程_大数据开发治理平台 DataWorks-阿里云帮助中心