【声明】本文章来自穆晨 - 博客园，记录于此方便后期的学习和查阅
一、前言
阅读本文前，请先回答下面两个问题：
- 数据库和数据仓库有什么区别？
- 某公司Hadoop Hive里的关系表，不完全满足完整/参照性约束，也不完全满足范式要求，甚至第一范式都不满足。这种情况正常吗？
如果不能在五秒内给出答案，那么本文应该是对您有帮助的。
二、数据库"分家"
随着关系数据库理论的提出，诞生了一系列经典的RDBMS，如Oracle、MySQL、SQL Server等。这些RDBMS被成功推向市场，并为社会信息化的发展做出了重大贡献。
随着数据库使用范围的不断扩大，目前已逐步划分为两个基本类型：
1. 操作型数据库
主要用于业务支撑。一个公司往往会使用并维护若干个数据库，这些数据库保存着公司的日常操作数据，比如商品购买、酒店预订、学生成绩录入等。
2. 分析型数据库
主要用于离线(历史)数据分析。基于历史业务数据，进行单独的数据库存储，用于对公司各主题域，进行数据统计和分析；
数据库"分家"是必然趋势。随着数据库使用范围的不断扩大、数据量级的激增，如果基于同一套数据库系统，很容易造成操作型任务和分析型任务的资源冲突，另外在功能、技术、组成等层面也有很多不同。
三、操作型数据库 VS 分析型数据库
![]()
1. 数据组成差别
数据时间范围差别
通常，操作型数据库只会存放90天以内的数据，而分析型数据库存放的则是数年内的数据。这点也是将操作型数据和分析型数据进行物理分离的主要原因。数据细节层次差别
1）操作型数据库存放的主要是细节数据，而分析型数据库中虽然既有细节数据，又有汇总数据，但对于用户来说，重点关注的是汇总数据部分。
2）实际上，操作型数据库中也有汇总需求，但汇总数据本身不存储而只存储其生成公式。这是因为操作型数据是动态变化的，因此汇总数据会在每次查询时动态生成。
3）对于分析型数据库来说，因为汇总数据比较稳定不会发生改变，而且其计算量也比较大(因为时间跨度大)，因此它的汇总数据可考虑事先计算好，以避免重复计算。数据时间表示差别
操作型数据通常反映的是现实世界的当前状态；而分析型数据库既有当前状态，还有过去各时间的快照。分析型数据库的使用者可以综合所有快照对各个历史阶段进行统计分析。
2. 技术差别
- 查询数据总量和查询频度差别
操作型查询的数据量少而频率多，分析型查询则反过来，数据量大而频率少。要想同时实现这两种情况的配置优化是不可能的，这也是将两类数据库物理分隔的原因之一。 - 数据更新差别
操作型数据库允许用户进行增、删、改、查；分析型数据库用户则只能进行查询。 - 数据冗余差别
1）分析型数据库中没有更新操作。因此，减少数据冗余也就没那么重要了。
2）现在回答开篇提到的第二个问题：Hive里的关系表不完全满足完整/参照性约束，也不完全满足范式要求，甚至第一范式都不满足。这种情况正常吗？，答案是正常的。
3）因为Hive是一种数据仓库，而数据仓库和分析型数据库的关系非常紧密(后文会讲到)。它只提供查询接口，不提供更新接口，这就使得消除冗余的诸多措施，不需要被特别严格地执行。
3. 功能差别
- 数据用户差别
操作型数据库的使用者是业务环境内的各个角色，如用户，商家，进货商等；分析型数据库则只被少量用户用来做综合性决策。 - 数据定位差别
操作型数据库是为了支撑具体业务的，因此也被称为"面向应用型数据库"；分析型数据库则是针对各特定业务主题域的分析任务创建的，因此也被称为"面向主题型数据库"。
四、数据仓库(data warehouse)定义
分析型数据库中的操作都是查询，因此可以不需要严格满足完整性/参照性约束以及范式设计要求，而这些却正是关系数据库的精华所在。在这样的情况下，再将它称为数据库，很容易引起大家混淆，毕竟在绝大多数人心中，数据库是可以与关系型数据库画等号的。
数据仓库，最简洁的定义就是：面向分析的存储系统
数据仓库不依赖传统关系数据库来实现，因为关系数据库最少也要求满足第1范式，而数据仓库里的关系表，可以不满足第1范式，即同样的记录在一个关系表里可以出现N次。
由于大多数的数据仓库，其表的统计分析还是用SQL语言来实现，因此很容易让人把它和关系数据库搞混。
分析型数据库的特点：
面向主题：数据仓库和操作型数据库的根本区别。操作型数据库是为了支撑各种业务而建立，而分析型数据库则是为了对从各种繁杂业务中抽象出来的分析主题(如用户、成本、商品等)进行分析而建立；
集成性：数据仓库会将不同源数据库中的数据汇总到一起；
企业范围：数据仓库内的数据是面向公司全局的。比如某个主题域为成本，则全公司和成本有关的信息都会被汇集进来；
历史性：较之操作型数据库，数据仓库的时间跨度通常比较长。前者通常保存几个月，后者可能几年甚至几十年；
时变性：数据仓库包含各历史时间段的数据快照。有了这些数据快照，用户便可将其汇总，生成各历史阶段的数据分析报告。
五、数据仓库组件
数据仓库的核心组件有四个：各源数据库，ETL，数据仓库，前端应用。如下图所示：
- 业务系统：包含各种源数据库，这些源数据库既为业务系统提供数据支撑，同时也作为数据仓库的数据源(注：除了业务系统，数据仓库也可从其他外部数据源获取数据)；
- ETL：也叫目标系统，包括：提取extraction、转换transformation、加载load
提取过程：操作型数据库搜集指定数据；
转换过程：将数据转化为指定格式并进行数据清洗保证数据质量；
加载过程：将转换过后满足指定格式的数据加载进数据仓库。 - 前端应用：和操作型数据库一样，数据仓库通常也提供具有直接访问数据仓库功能的前端应用，这些应用也被称为BI(商务智能)应用。
六、数据集市(data mart)
数据集市可以理解为是一种"小型数据仓库"，它只包含单个主题，且关注范围也非全局。
数据集市可以分为两种：
- 独立数据集市(independent data mart)，这类数据集市有自己的源数据库和ETL架构；
- 非独立数据集市(dependent data mart)，这种数据集市没有自己的源系统，它的数据来自数据仓库。
当用户或者应用程序不需要、不必要、不允许用到整个数据仓库的数据时，非独立数据集市就可以简单为用户提供一个数据仓库的"子集"。
七、数据仓库开发流程
![]()
较之数据库系统开发，数据仓库开发只多出ETL工程部分。通常，该部分可能是整个数据仓库开发流程中最为耗时、耗资源的一个环节。
因为该环节要整理各大业务系统中杂乱无章的数据，并协调元数据上的差别，所以工作量很大。在很多公司都专门设有ETL工程师这样的岗位，大的公司甚至专门聘请ETL专家。
在大数据时代，数据仓库的重要性更胜以往。Hadoop平台下的Hive，Spark平台下的Spark SQL都是各自生态圈内应用最热门的配套工具，而它们的本质就是开源分布式数据仓库。
