1 事实表、维度表
首先我们来看两个名词：事实表和维度表
1.1 什么是事实表呢？
事实表是指保存了大量业务数据的表，或者说保存了一些真实的行为数据的表
例如：销售商品所产生的订单数据
1.2 什么是维度表呢？
首先说一下什么是维度
维度其实指的就是一个对象的属性或者特征，例如：时间维度，地理区域维度，年龄维度这是维度的概念。
维度表里面存放的其实就是刚才我们所说的那些维度相关的信息
这是事实表和维度表的特点，大家最起码要能区分出来一个表是事实表还是维度表，否则在工作中别人提到这两个概念你还是一脸懵，那就尴尬了。
2 数据库三范式
接下来我们需要复习一下数据库中的三范式的特性，不知道大家还有没有印象，这个属于数据库相关的知识，如果大家系统的学习过类似于MySQL之类的关系型数据库的话，这块应该是有一些印象的。其实严格意义上来说，关系型数据库的范式是有多种的
第一范式(1NF)
第二范式(2NF)
第三范式(3NF)
巴斯-科德范式(BCNF)
第四范式(4NF)
第五范式(5NF)
不过后面那几种不太常见，数据库设计一般满足第三范式就足够了，所以在这我们就分析一下前三种范式
2.1 首先看第一范式(1NF):
它的意思是说数据库表的每一列都是不可分割的原子数据项
来看下面这个案例：
这里面存储的是学生信息
但是这里面的地址字段显然是不符合第一范式的，因为这里面的地址信息是可以拆分为省份+城市+街道
信息的
所以针对这个字段进行拆分，让这个表满足第一范式
2.2 第二范式(2NF)
第二范式(2NF)表示在1NF的基础上，数据库表中每一列都和主键相关，不能只和主键的某一部分相关(针
对联合主键而言)
也就是说一个表中只能保存一种类型的数据，不可以把多种类型数据保存在同一张表中
来看下面这个案例：
最后来看一下第三范式
注意：满足第三范式（3NF）必须先满足第二范式（2NF）。
2.3 第三范式(3NF)
要求一个数据库表中不包含已在其它表中包含的非主键字段
就是说，表中的某些字段信息，如果能够被推导出来，就不应该单独的设计一个字段来存放(能尽量外键
join就用外键join)。很多时候，我们为了满足第三范式往往会把一张表拆分成多张表
来看下面这个案例
针对刚才满足了第二范式的表，其实还可以进行拆分
可以再拆分为这样：
这样就满足数据库的第三范式了。
我们在这分析这三种范式有什么意义吗？不要着急，往下面看
数据仓库建模方式
数据仓库建模可以使用多种方式
1：ER实体模型，这种模型其实就是满足数据库第三范式的模型，这就是刚才我们为什么要分析数据库中的三范式了。
ER模型是数据库设计的理论基础，当前几乎所有的OLTP系统设计都采用ER模型建模的方式
Bill Inom提出的数仓理论，推荐采用ER关系模型进行建模，不过这种方式在实际工作中不推荐使用。
2：维度建模模型
Ralph Kimball提出的数仓理论中，提出了维度建模，将数据仓库中的表划分为事实表和维度表。
基于事实表和维度表进行维度建模。维度建模通常又分为星型模型和雪花模型，一会我们详细分析这两种维度建模模型。维度建模是我们在构建数据仓库中常用的方式。
3：Data Vault模型
Data Vault是在ER模型的基础上衍生而来，模型设计的初衷是有效的组织基础数据层，使之易扩展、灵活的应对业务的变化，同时强调历史性、可追溯性和原子性，不要求对数据进行过度的一致性处理；并非针对分析场景所设计。
3：Anchor模型
Anchor是对Data Vault模型做了更近一步的规范化处理，初衷是为了设计高度可扩展的模型，核心思想
是所有的扩张只添加而不修改，于是设计出的模型基本变成了k-v结构的模型。
Data Vault模型和Anchor模型，这两种模型大家知道就行了，很少使用，如果大家感兴趣的话可以到网
上查阅相关资料了解一下。
3 维度建模模型
下面详细分析一下维度建模模型
3.1 星型模型和雪花模型
星型模型和雪花模型主要区别就是对维度表的拆分，
对于雪花模型，维度表的设计更加规范，一般符合3NF；
而星型模型，一般采用降维的操作，利用冗余来避免模型过于复杂，提高易用性和分析效率
3.1.1 星型模型
这里面的中间的订单表是事实表，外面的四个是维度表。
这几个维度表，其实严格意义上来说，只能满足第二范式，是不满足第三范式的。
但是这样的好处是查询效率比较高，在查询的时候不需要关联很多张表。
缺点就是数据有冗余。
使用这个五角星代表星型模型还是比较形象的，因为针对事实表周边的这些维度表，外层就没有其它的表
了。
3.1.2 雪花模型
这个里面订单表是一个事实表，其余的都是维度表。
针对商品维度表外层又拆分出来了一个商品类目的维度表，这样拆分之后其实就满足第三范式了，但是这
样就变的复杂了，后期在获取商品维度数据的时候，还需要关联这个商品类目维度表。
这里使用这个雪花代表雪花模型也是比较形象的，事实表周边会有一层维度表，这些维度表外层还可能会
有多层维度表
那接下里我们针对这两种模型的优缺点进行一个总结
星型模型 VS 雪花模型 冗余：雪花模型符合业务逻辑设计，采用3NF设计，有效降低数据冗余；星型模型的维度表设计不符合
3NF，反规范化，维度表之间不会直接相关，牺牲部分存储空间
性能：雪花模型由于存在维度间的关联，采用3NF降低冗余，通常在使用过程中，需要连接更多的维度
表，导致性能偏低；星型模型违反三范式，采用降维的操作将维度整合，以存储空间为代价有效降低维度
表连接数，性能比雪花模型高
那我们在实际工作中一般会选择哪种呢？
在实际工作中我们多采用星型模型，因为数据仓库主要是侧重于做数据分析，对数据的查询性能要求比较
高，所以星型模型是比较好的选择，在实际工工作中我们会尽可能的多构建一些宽表，提前把多种有关联
的维度整合到一张表中，后期使用时就不需要多表关联了，比较方便，并且性能也高。
数据仓库分层 为什么要分层
数据仓库在构建过程中通常都需要进行分层处理。业务不同，分层的技术处理手段也不同。对数据进行分
层的一个主要原因就是希望在管理数据的时候，能对数据有一个更加清晰的掌控
详细来讲，主要有下面几个原因：
清晰的数据结构：每一个分层的数据都有它的作用域，这样我们在使用表的时候能更方便地定位和理
解。
数据血缘追踪：简单来讲可以这样理解，我们最终给业务方呈现的是一个能直接使用的业务表，但是
它的来源有很多，如果有一张来源表出问题了，我们希望能够快速准确地定位到问题，并清楚它的危
害范围，分层之后就很好定位问题，以及可以清晰的知道它的危害范围。
减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少重复计算。
把复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单
和容易理解。而且便于维护数据的准确性， 当数据出现问题之后，可以不用修复所有的数据，只需
要从有问题的步骤开始修复。
4 数据仓库分层设计
那针对我们这里的数据仓库该如何分层呢？
数据仓库一般会分为4层 1. ODS层：原始数据层，数据源中的数据，采集过来之后，原样保存。
2. DWD层：明细数据层：这一层是对ODS层的数据进行清洗，解决一些数据质量问题和数据的完整度
问题。
3. DWS层：这一层是对DWD层的数据进行轻度聚合汇总，生成一系列的中间表，提升公共指标的复用
性，减少重复加工，并且构建出来一些宽表，用于提供后续的业务查询。
4. APP层：根据业务需要，由前面三层的数据统计而出的结果，可以直接提供查询展现，一般会把APP
层的数据导出到MySQL中供线上系统使用，提供报表展示、数据监控及其它功能。也有公司把这层
称为DM层。虽然名字不一样，但是性质是一样的。
注意：针对DWD层在对数据进行清洗的时候，一般需要遵循以下原则
数据唯一性校验(通过数据采集工具采集的数据会存在重复的可能性) 2. 数据完整性校验(采集的数据中可能会出现缺失字段的情况，针对缺失字段的数据建议直接丢掉，如
果可以确定是哪一列缺失也可以进行补全，可以用同一列上的前一个数据来填补或者同一列上的后一
个数据来填补) 3. 数据合法性校验-1(针对数字列中出现了null、或者-之类的异常值，全部替换为一个特殊值，例如0或 者-1，这个需要根据具体的业务场景而定) 4. 数据合法性校验-2(针对部分字段需要校验数据的合法性，例如：用户的年龄，不能是负数) 数据仓库命名规范
我们在使用Hive实现数据仓库的时候该如何体现这些层次？
针对数据仓库的每一层都在Hive中创建一个数据库，数据库的命名包含每一层的标识符
例如：针对ODS层可以在Hive中创建数据库 ods_mall，把同一层的表都放到一个数据库里面，方便
管理
针对每一层中的表名，在创建的时候可以使用每一层的标识符开头
例如：针对ODS层，创建的表名为：ods_user，这样方便后期使用，只要看到表名就可以知道这个
表示哪一层的了。
针对一些临时表，我们可以在对应的分层中创建表名的时候，以_tmp结尾。
针对一些备份的表，可以在表名后面添加_bak。 典型的数据仓库系统架构
下图是一个典型的企业数据仓库系统，通常包含数据源、数据存储与管理、数据的访问三个部分
数据源部分负责采集各种日志数据、业务数据，以及一些文档资料，将我们需要的这些数据加载到Hive
中，构建数据仓库
数据仓库构建好了以后可以为很多服务提供数据支撑
例如：做数据报表，做OLAP数据分析，以及在做用户画像和数据挖掘的时候都是需要使用到数据仓库中的数据的在实际工作中，数据仓库分为离线数据仓库和实时数据仓库我们这个项目主要分析离线数据仓库，因为到现阶段为止我们主要学习了离线计算相关的技术框架。
