一、什么是数据仓库
咱们前面说了要构建一个数据仓库，那严格意义上来说，到底什么是数据仓库呢？ 咱们前面学习过Hive，说Hive其实就是一个数据仓库，可以这样理解，就是把Hive认为是一种技术，通过Hive这种技术可以实现数据仓库的建设。 咱们这个项目中的数据仓库就是使用Hive构建的。
来看一下针对数据仓库的官方解释：
数据仓库(Data Warehouse)是一个面向主题的、集成的、稳定的且随时间变化的数据集合，用于支持管理人员的决策。
二、数据仓库的特性 1、面向主题主题就是类型的意思。 传统数据库主要是为应用程序进行数据处理，未必会按照同一主题存储数据； 数据仓库侧重于数据分析工作，是按照主题存储的。 这一点，类似于传统农贸市场与超市的区别 市场里面，针对一个商贩，他卖的萝卜、白菜这些蔬菜以及水果会在一个摊位上；、 而超市里，蔬菜和水果是分开的，并且在蔬菜里面也会进行分类，不同类型的蔬菜放到不同的地方。 也就是说，农贸市场里的菜(数据)是按照商贩(应用程序)去归类(存储)的，而超市里面则是按 照蔬菜、水果的类型(同主题)归类的。
2、集成传统数据库通常与某些特定的应用相关，数据库之间相互独立。而数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。
3、稳定稳定说的是相对稳定 传统数据库中的数据通常实时更新，数据根据需要及时发生变化。数据仓库的数据主要供企业决策分析使用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。
4、变化这里的变化说的是反映历史变化 传统数据库主要关心当前某一个时间段内的数据，而数据仓库中的数据通常包含历史信息，它里面记录了企业从过去某一时间点(如开始应用数据仓库的时间)到目前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出分析和预测。
企业数据仓库的建设，是以现有企业业务系统和大量业务数据的积累为基础。数据仓库不是静态的概念，只有把信息及时交给需要这些信息的使用者，供他们做出改善其业务经营的决策，信息才能发挥作用，信息才有意义。而把信息加以整理归纳和重组，并及时提供给相应的管理决策人员，是数据仓库的根本任务。
三、数据仓库基础知识在学习数据仓库之前我们先来看一些数据仓库的基础知识 1：事实表、维度表 2：数据库三范式 3：维度建模模型：雪花模型、星型模型
1、事实表、维度表首先我们来看两个名词：事实表和维度表
什么是事实表呢？ 事实表是指保存了大量业务数据的表，或者说保存了一些真实的行为数据的表 例如：销售商品所产生的订单数据 什么是维度表呢？ 首先说一下什么是维度 维度其实指的就是一个对象的属性或者特征，例如：时间维度，地理区域维度，年龄维度 这是维度的概念。
维度表里面存放的其实就是刚才我们所说的那些维度相关的信息。
这是事实表和维度表的特点，大家最起码要能区分出来一个表是事实表还是维度表，否则在工作中别人提到这两个概念你还是一脸懵，那就尴尬了。
2、数据库三范式接下来我们需要复习一下数据库中的三范式的特性，不知道大家还有没有印象，这个属于数据库相关的知识，如果大家系统的学习过类似于MySQL之类的关系型数据库的话，这块应该是有一些印象的。
其实严格意义上来说，关系型数据库的范式是有多种的 第一范式(1NF) 第二范式(2NF) 第三范式(3NF) 巴斯-科德范式(BCNF) 第四范式(4NF) 第五范式(5NF) 不过后面那几种不太常见，数据库设计一般满足第三范式就足够了，所以在这我们就分析一下前三种范式
首先看第一范式(1NF): 它的意思是说数据库表的每一列都是不可分割的原子数据项 来看下面这个案例：
这里面存储的是学生信息 但是这里面的地址字段显然是不符合第一范式的，因为这里面的地址信息是可以拆分为省份+城市+街道信息的
所以针对这个字段进行拆分，让这个表满足第一范式
接下来看一下第二范式 第二范式(2NF)表示在1NF的基础上，数据库表中每一列都和主键相关，不能只和主键的某一部分相关(针对联合主键而言)
也就是说一个表中只能保存一种类型的数据，不可以把多种类型数据保存在同一张表中
来看下面这个案例：
这个表里面除了存储的有学生的班级信息，还有学生的考试成绩信息 根据我们刚才的分析，它是满足第一范式的，但是违背了第二范式，数据库表中的每一列并不是都和主键相关
所以我们为了让这个表满足第二范式，可以这样拆分： 拆成两个表，一个表里面保存学生的班级信息，一个表里面保存学生的考试成绩信息
最后来看一下第三范式
注意：满足第三范式（3NF）必须先满足第二范式（2NF）。第三范式(3NF): 要求一个数据库表中不包含已在其它表中包含的非主键字段
就是说，表中的某些字段信息，如果能够被推导出来，就不应该单独的设计一个字段来存放(能尽量外键join就用外键join)。 很多时候，我们为了满足第三范式往往会把一张表拆分成多张表
来看下面这个案例 针对刚才满足了第二范式的表，其实还可以进行拆分 可以再拆分为这样： 这样就满足数据库的第三范式了。
我们在这分析这三种范式有什么意义吗？不要着急，往下面看
3、数据仓库建模方式数据仓库建模可以使用多种方式
（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模型，这两种模型大家知道就行了，很少使用，如果大家感兴趣的话可以到网上查阅相关资料了解一下。
4、维度建模模型下面详细分析一下维度建模模型
星型模型和雪花模型
星型模型和雪花模型主要区别就是对维度表的拆分， 对于雪花模型，维度表的设计更加规范，一般符合3NF； 而星型模型，一般采用降维的操作，利用冗余来避免模型过于复杂，提高易用性和分析效率
（1）星型模型这里面的中间的订单表是事实表，外面的四个是维度表。 这几个维度表，其实严格意义上来说，只能满足第二范式，是不满足第三范式的。 但是这样的好处是查询效率比较高，在查询的时候不需要关联很多张表。 缺点就是数据有冗余。
使用这个五角星代表星型模型还是比较形象的，因为针对事实表周边的这些维度表，外层就没有其它的表了。
（2）雪花模型这个里面订单表是一个事实表，其余的都是维度表。 针对商品维度表外层又拆分出来了一个商品类目的维度表，这样拆分之后其实就满足第三范式了，但是这样就变的复杂了，后期在获取商品维度数据的时候，还需要关联这个商品类目维度表。
这里使用这个雪花代表雪花模型也是比较形象的，事实表周边会有一层维度表，这些维度表外层还可能会有多层维度表
那接下里我们针对这两种模型的优缺点进行一个总结
（3）星型模型 VS 雪花模型冗余：雪花模型符合业务逻辑设计，采用3NF设计，有效降低数据冗余；星型模型的维度表设计不符合3NF，反规范化，维度表之间不会直接相关，牺牲部分存储空间
性能：雪花模型由于存在维度间的关联，采用3NF降低冗余，通常在使用过程中，需要连接更多的维度表，导致性能偏低；星型模型违反三范式，采用降维的操作将维度整合，以存储空间为代价有效降低维度表连接数，性能比雪花模型高
那我们在实际工作中一般会选择哪种呢？
在实际工作中我们多采用星型模型，因为数据仓库主要是侧重于做数据分析，对数据的查询性能要求比较高，所以星型模型是比较好的选择，在实际工工作中我们会尽可能的多构建一些宽表，提前把多种有关联的维度整合到一张表中，后期使用时就不需要多表关联了，比较方便，并且性能也高。
四、数据仓库分层 1、为什么要分层数据仓库在构建过程中通常都需要进行分层处理。业务不同，分层的技术处理手段也不同。对数据进行分层的一个主要原因就是希望在管理数据的时候，能对数据有一个更加清晰的掌控 详细来讲，主要有下面几个原因：
（1）清晰的数据结构每一个分层的数据都有它的作用域，这样我们在使用表的时候能更方便地定位和理解。
（2）数据血缘追踪简单来讲可以这样理解，我们最终给业务方呈现的是一个能直接使用的业务表，但是它的来源有很多，如果有一张来源表出问题了，我们希望能够快速准确地定位到问题，并清楚它的危害范围，分层之后就很好定位问题，以及可以清晰的知道它的危害范围。
（3）减少重复开发规范数据分层，开发一些通用的中间层数据，能够减少重复计算。
（4）把复杂问题简单化将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。
而且便于维护数据的准确性， 当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。
（5）屏蔽业务的影响不必改一次业务就重新接入数据。
2、数据仓库分层设计那针对我们这里的数据仓库该如何分层呢？
数据仓库一般会分为4层
（1）ODS层原始数据层[operational data store]，数据源中的数据，采集过来之后，原样保存。
（2）DWD层明细数据层[data warehouse detail]，这一层是对ODS层的数据进行清洗，解决一些数据质量问题和数据的完整度问题。
（3）DWS层data warehouse service，这一层是对DWD层的数据进行轻度聚合汇总，生成一系列的中间表，提升公共指标的复用性，减少重复加工，并且构建出来一些宽表，用于提供后续的业务查询。
（4）APP层根据业务需要，由前面三层的数据统计而出的结果，可以直接提供查询展现，一般会把APP层的数据导出到MySQL中供线上系统使用，提供报表展示、数据监控及其它功能。 也有公司把这层称为DM层。 虽然名字不一样，但是性质是一样的。
注意：针对DWD层在对数据进行清洗的时候，一般需要遵循以下原则
数据唯一性校验(通过数据采集工具采集的数据会存在重复的可能性) 数据完整性校验(采集的数据中可能会出现缺失字段的情况，针对缺失字段的数据建议直接丢掉，如果可以确定是哪一列缺失也可以进行补全，可以用同一列上的前一个数据来填补或者同一列上的后一个数据来填补) 数据合法性校验-1(针对数字列中出现了null、或者-之类的异常值，全部替换为一个特殊值，例如0或者-1，这个需要根据具体的业务场景而定) 数据合法性校验-2(针对部分字段需要校验数据的合法性，例如：用户的年龄，不能是负数) 3、数据仓库命名规范我们在使用Hive实现数据仓库的时候该如何体现这些层次？
1、针对数据仓库的每一层都在Hive中创建一个数据库，数据库的命名包含每一层的标识符 例如：针对ODS层可以在Hive中创建数据库 ods_mall，把同一层的表都放到一个数据库里面，方便管理 2、针对每一层中的表名，在创建的时候可以使用每一层的标识符开头 例如：针对ODS层，创建的表名为：ods_user，这样方便后期使用，只要看到表名就可以知道这个表示哪一层的了。针对一些临时表，我们可以在对应的分层中创建表名的时候，以_tmp结尾。 针对一些备份的表，可以在表名后面添加_bak。
五、典型的数据仓库系统架构下图是一个典型的企业数据仓库系统，通常包含数据源、数据存储与管理、数据的 访问三个部分
数据源部分负责采集各种日志数据、业务数据，以及一些文档资料，将我们需要的这些数据加载到Hive中，构建数据仓库，
数据仓库构建好了以后可以为很多服务提供数据支撑
例如：做数据报表，做OLAP数据分析，以及在做用户画像和数据挖掘的时候都是需要使用到数据仓库中的数据的
在实际工作中，数据仓库分为离线数据仓库和实时数据仓库 我们这个项目主要分析离线数据仓库，因为到现阶段为止我们主要学习了离线计算相关的技术框架。
六、项目需求分析通过刚才对一个典型的企业数据仓库系统架构进行分析，我们发现，想要开发一个完整的数据仓库系统，至少需要以下这几个功能模块。
1：数据采集平台，这个模块主要负责采集各种数据源的数据 2：数据仓库，这个模块负责数据存储和管理 3：数据报表，这个模块其实就是数据可视化展示了
通过这三个模块可以实现数据采集，构建数据仓库，最后基于数据仓库中的数据实现上层应用，体现数据仓库的价值。
 1.本站遵循行业规范，任何转载的稿件都会明确标注作者和来源；2.本站的原创文章，会注明原创字样,如未注明都非原创，如有侵权请联系删除！；3.作者投稿可能会经我们编辑修改或补充；4.本站不提供任何储存功能只提供收集或者投稿人的网盘链接。 |
