什么是数据仓库

咱们前面学习过Hive，说Hive其实就是一个数据仓库，可以这样理解，就是把Hive认为是一种技术，通过Hive这种技术可以实现数据仓库的建设。
来看一下针对数据仓库的官方解释：

数据仓库(Data Warehouse)是一个面向主题的、集成的、稳定的且随时间变化的数据集合，用于支持管理人员的决策

注意它里面的这几个特性：

• 面向主题
  主题就是类型的意思。
  传统数据库主要是为应用程序进行数据处理，未必会按照同一主题存储数据；
  数据仓库侧重于数据分析工作，是按照主题存储的。
  这一点，类似于传统农贸市场与超市的区别
  市场里面，针对一个商贩，他卖的萝卜、白菜这些蔬菜以及水果会在一个摊位上；、
  而超市里，蔬菜和水果是分开的，并且在蔬菜里面也会进行分类，不同类型的蔬菜放到不同的地方。
  也就是说，农贸市场里的菜(数据)是按照商贩(应用程序)去归类(存储)的，而超市里面则是按
  照蔬菜、水果的类型(同主题)归类的。
• 集成
  传统数据库通常与某些特定的应用相关，数据库之间相互独立。而数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。
• 稳定
  稳定说的是相对稳定
  传统数据库中的数据通常实时更新，数据根据需要及时发生变化。数据仓库的数据主要供企业决策分析使用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。
• 变化
  这里的变化说的是反映历史变化
  传统数据库主要关心当前某一个时间段内的数据，而数据仓库中的数据通常包含历史信息，它里面记录了企业从过去某一时间点(如开始应用数据仓库的时间)到目前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出分析和预测。

企业数据仓库的建设，是以现有企业业务系统和大量业务数据的积累为基础。数据仓库不是静态的概念，只有把信息及时交给需要这些信息的使用者，供他们做出改善其业务经营的决策，信息才能发挥作用，信息才有意义。而把信息加以整理归纳和重组，并及时提供给相应的管理决策人员，是数据仓库的根本任务。

事实表、维度表

事实表

事实表是指保存了大量业务数据的表，或者说保存了一些真实的行为数据的表
例如：销售商品所产生的订单数据

维度表

首先说一下什么是维度
维度其实指的就是一个对象的属性或者特征，例如：时间维度，地理区域维度，年龄维度这是维度的概念。
维度表里面存放的其实就是刚才我们所说的那些维度相关的信息

数据库三范式

第一范式(1NF)

数据库表的每一列都是不可分割的原子数据项

这里面存储的是学生信息
但是这里面的地址字段显然是不符合第一范式的，因为这里面的地址信息是可以拆分为省份+城市+街道信息的
所以针对这个字段进行拆分，让这个表满足第一范式

第二范式(2NF)

第二范式(2NF)表示在1NF的基础上，数据库表中每一列都和主键相关，不能只和主键的某一部分相关(针
对联合主键而言)
也就是说一个表中只能保存一种类型的数据，不可以把多种类型数据保存在同一张表中

第三范式(3NF)

要求一个数据库表中不包含已在其它表中包含的非主键字段
就是说，表中的某些字段信息，如果能够被推导出来，就不应该单独的设计一个字段来存放(能尽量外键
join就用外键join)。很多时候，我们为了满足第三范式往往会把一张表拆分成多张表

来看下面这个案例
针对刚才满足了第二范式的表，其实还可以进行拆分

可以再拆分为这样：

数据仓库建模方式

数据仓库建模可以使用多种方式
1：ER实体模型，这种模型其实就是满足数据库第三范式的模型，这就是刚才我们为什么要分析数据库中的三范式了。
ER模型是数据库设计的理论基础，当前几乎所有的OLTP系统设计都采用ER模型建模的方式
Bill Inom提出的数仓理论，推荐采用ER关系模型进行建模，不过这种方式在实际工作中不推荐使用。
2：维度建模模型
Ralph Kimball提出的数仓理论中，提出了维度建模，将数据仓库中的表划分为事实表和维度表。
基于事实表和维度表进行维度建模。维度建模通常又分为星型模型和雪花模型型。维度建模是我们在构建数据仓库中常用的方式。
3：Data Vault模型
Data Vault是在ER模型的基础上衍生而来，模型设计的初衷是有效的组织基础数据层，使之易扩展、灵活的应对业务的变化，同时强调历史性、可追溯性和原子性，不要求对数据进行过度的一致性处理；并非针对分析场景所设计。
4：Anchor模型
Anchor是对Data Vault模型做了更近一步的规范化处理，初衷是为了设计高度可扩展的模型，核心思想是所有的扩张只添加而不修改，于是设计出的模型基本变成了k-v结构的模型。
Data Vault模型和Anchor模型，这两种模型大家知道就行了，很少使用，如果大家感兴趣的话可以到网上查阅相关资料了解一下。

维度建模模型

星型模型和雪花模型主要区别就是对维度表的拆分
雪花模型：维度表的设计更加规范，一般符合3NF；
星型模型：一般采用降维的操作，利用冗余来避免模型过于复杂，提高易用性和分析效率

星型模型（冗余，推荐）

这里面的中间的订单表是事实表，外面的四个是维度表。
这几个维度表，其实严格意义上来说，只能满足第二范式，是不满足第三范式的。
但是这样的好处是查询效率比较高，在查询的时候不需要关联很多张表。缺点就是数据有冗余。
使用这个五角星代表星型模型还是比较形象的，因为针对事实表周边的这些维度表，外层就没有其它的表

雪花模型（符合3NF）

这个里面订单表是一个事实表，其余的都是维度表。
针对商品维度表外层又拆分出来了一个商品类目的维度表，这样拆分之后其实就满足第三范式了，但是这
样就变的复杂了，后期在获取商品维度数据的时候，还需要关联这个商品类目维度表。
这里使用这个雪花代表雪花模型也是比较形象的，事实表周边会有一层维度表，这些维度表外层还可能会
有多层维度表

对比

星型模型 VS 雪花模型

• 冗余：雪花模型符合业务逻辑设计，采用3NF设计，有效降低数据冗余；星型模型的维度表设计不符合

3NF，反规范化，维度表之间不会直接相关，牺牲部分存储空间

• 性能：雪花模型由于存在维度间的关联，采用3NF降低冗余，通常在使用过程中，需要连接更多的维度

表，导致性能偏低；星型模型违反三范式，采用降维的操作将维度整合，以存储空间为代价有效降低维度
表连接数，性能比雪花模型高

那我们在实际工作中一般会选择哪种呢？
在实际工作中我们多采用星型模型，因为数据仓库主要是侧重于做数据分析，对数据的查询性能要求比较
高，所以星型模型是比较好的选择，在实际工工作中我们会尽可能的多构建一些宽表，提前把多种有关联
的维度整合到一张表中，后期使用时就不需要多表关联了，比较方便，并且性能也高。

数据仓库分层

为什么要分层

数据仓库在构建过程中通常都需要进行分层处理。业务不同，分层的技术处理手段也不同。对数据进行分
层的一个主要原因就是希望在管理数据的时候，能对数据有一个更加清晰的掌控
详细来讲，主要有下面几个原因：
1、清晰的数据结构：每一个分层的数据都有它的作用域，这样我们在使用表的时候能更方便地定位和理
解。
2、数据血缘追踪：简单来讲可以这样理解，我们最终给业务方呈现的是一个能直接使用的业务表，但是
它的来源有很多，如果有一张来源表出问题了，我们希望能够快速准确地定位到问题，并清楚它的危
害范围，分层之后就很好定位问题，以及可以清晰的知道它的危害范围。
3、减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少重复计算。
4、把复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单
和容易理解。而且便于维护数据的准确性， 当数据出现问题之后，可以不用修复所有的数据，只需
要从有问题的步骤开始修复。

如何分层

数据仓库一般会分为4层

1. ODS（原始数据）

原始数据层，数据源中的数据，采集过来之后，原样保存。

2. DWD（明细数据）

明细数据层：这一层是对ODS层的数据进行清洗，解决一些数据质量问题和数据的完整度问题。

3. DWS（汇总数据）

这一层是对DWD层的数据进行轻度聚合汇总，生成一系列的中间表，提升公共指标的复用性，减少重复加工，并且构建出来一些宽表，用于提供后续的业务查询。

4. APP（应用数据）

根据业务需要，由前面三层的数据统计而出的结果，可以直接提供查询展现，一般会把APP层的数据导出到MySQL中供线上系统使用，提供报表展示、数据监控及其它功能。也有公司把这层称为DM层。虽然名字不一样，但是性质是一样的。

数据清洗原则

1、数据唯一性校验(通过数据采集工具采集的数据会存在重复的可能性)

2、数据完整性校验(采集的数据中可能会出现缺失字段的情况，针对缺失字段的数据建议直接丢掉，如果可以确定是哪一列缺失也可以进行补全，可以用同一列上的前一个数据来填补或者同一列上的后一 个数据来填补)

3、数据合法性校验-1(针对数字列中出现了null、或者-之类的异常值，全部替换为一个特殊值，例如0或 者-1，这个需要根据具体的业务场景而定)

4、数据合法性校验-2(针对部分字段需要校验数据的合法性，例如：用户的年龄，不能是负数) 数据仓库命名规范

数据仓库命名规范

针对数据仓库的每一层都在Hive中创建一个数据库，数据库的命名包含每一层的标识符

例如：针对ODS层可以在Hive中创建数据库 ods_mall，把同一层的表都放到一个数据库里面，方便管理

针对每一层中的表名，在创建的时候可以使用每一层的标识符开头

例如：针对ODS层，创建的表名为：ods_user，这样方便后期使用，只要看到表名就可以知道这个表示哪一层的了。

针对一些临时表，我们可以在对应的分层中创建表名的时候，以_tmp结尾。
针对一些备份的表，可以在表名后面添加_bak。 典型的数据仓库系统架构

典型的数据仓库系统架构

数据源部分负责采集各种日志数据、业务数据，以及一些文档资料，将我们需要的这些数据加载到Hive
中，构建数据仓库数据仓库构建好了以后可以为很多服务提供数据支撑
例如：做数据报表，做OLAP数据分析，以及在做用户画像和数据挖掘的时候都是需要使用到数据仓库中的数据的在实际工作中，数据仓库分为离线数据仓库和实时数据仓库我们这个项目主要分析离线数据仓库，因为到现阶段为止我们主要学习了离线计算相关的技术框架。