数据库, 数据仓库, 数据集市

转载声明

本文大量内容系转载自以下文章，有删改，并参考其他文档资料加入了一些内容：

• 数据仓库和数据集市的区别
  作者：修鹏李
  出处：CSDN

• 大数据：数据仓库和数据库的区别
  作者：南宫蓉
  出处：简书

• 第一篇：数据仓库概述

• 第二篇：数据库关系建模
  作者：穆晨
  出处：CNBLOS

摘要

本文简要介绍数据库 数据仓库和数据集市概念，并做简要对比。

0x01 数据仓库和数据库

1.1 数据库

关系数据库本质上是一个二元关系，说的简单一些，就是一个二维表格，对普通人来说，最简单的理解就是一个Excel表格。这种数据库类型，具有结构化程度高，独立性强，冗余度低等等优点，一下子就促进了计算机的发展。

1.2 操作型数据库和分析型数据库

随着关系数据库理论的提出，诞生了一系列经典的RDBMS，如Oracle，MySQL，SQL Server等。这些RDBMS被成功推向市场，并为社会信息化的发展做出的重大贡献。然而随着数据库使用范围的不断扩大，它被逐步划分为两大基本类型：

1. 操作型数据库
   主要用于业务支撑。一个公司往往会使用并维护若干个操作型数据库，这些数据库保存着公司的日常操作数据，比如商品购买、酒店预订、学生成绩录入等；
2. 分析型数据库
   主要用于历史数据分析。这类数据库作为公司的单独数据存储，负责利用历史数据对公司各主题域进行统计分析；

那么为什么要"分家"？在一起不合适吗？能不能构建一个同样适用于操作和分析的统一数据库？答案是NO。一个显然的原因是它们会"打架"…如果操作型任务和分析型任务抢资源怎么办呢？再者，它们有太多不同，以致于早已"貌合神离"。接下来看看它们到底有哪些不同吧。

1.3 操作型数据库 VS 分析型数据库

因为主导功能的不同(面向操作/面向分析)，两类数据库就产生了很多细节上的差异。这就好像同样是人，但一个和尚和一个穆斯林肯定有很多行为/观念上的不同。

接下来本文将详细分析两类数据库的不同点：

1. 数据组成差别 - 数据时间范围差别
   一般来讲，操作型数据库只会存放90天以内的数据，而分析型数据库存放的则是数年内的数据。这点也是将操作型数据和分析型数据进行物理分离的主要原因。

2. 数据组成差别 - 数据细节层次差别
   操作型数据库存放的主要是细节数据，而分析型数据库中虽然既有细节数据，又有汇总数据，但对于用户来说，重点关注的是汇总数据部分。

   操作型数据库中自然也有汇总需求，但汇总数据本身不存储而只存储其生成公式。这是因为操作型数据是动态变化的，因此汇总数据会在每次查询时动态生成。

   而对于分析型数据库来说，因为汇总数据比较稳定不会发生改变，而且其计算量也比较大(因为时间跨度大)，因此它的汇总数据可考虑事先计算好，以避免重复计算。

3. 数据组成差别 - 数据时间表示差别
   操作型数据通常反映的是现实世界的当前状态；而分析型数据库既有当前状态，还有过去各时刻的快照，分析型数据库的使用者可以综合所有快照对各个历史阶段进行统计分析。

4. 技术差别 - 查询数据总量和查询频度差别
   操作型查询的数据量少而频率多，分析型查询则反过来，数据量大而频率少。要想同时实现这两种情况的配置优化是不可能的，这也是将两类数据库物理分隔的原因之一。

5. 技术差别 - 数据更新差别
   操作型数据库允许用户进行增，删，改，查；分析型数据库用户则只能进行查询。

6. 技术差别 - 数据冗余差别
   数据的意义是什么？就是减少数据冗余，避免更新异常。而如5所述，分析型数据库中没有更新操作。因此，减少数据冗余也就没那么重要了。

   现在回到开篇是提到的第二个问题"某大公司Hadoop Hive里的关系表不完全满足完整/参照性约束，也不完全满足范式要求，甚至第一范式都不满足。这种情况正常吗？"，答曰是正常的。因为Hive是一种数据仓库，而数据仓库和分析型数据库的关系非常紧密(后文会讲到)。它只提供查询接口，不提供更新接口，这就使得消除冗余的诸多措施不需要被特别严格地执行了。

7. 功能差别 - 数据读者差别
   操作型数据库的使用者是业务环境内的各个角色，如用户，商家，进货商等；分析型数据库则只被少量用户用来做综合性决策。

8. 功能差别 - 数据定位差别
   这里说的定位，主要是指以何种目的组织起来。操作型数据库是为了支撑具体业务的，因此也被称为"面向应用型数据库"；分析型数据库则是针对各特定业务主题域的分析任务创建的，因此也被称为"面向主题型数据库"。

0x02 数据仓库

2.1 概述

数据仓库就是为了解决数据库不能解决的问题而提出的。那么数据库无法解决什么样的问题呢？这个我们得先说说什么是OLAP和OLTP。

2.2 OLTP和OLTP

2.2.1 OLTP

OLTP（OnLine Transaction Processing 联机事务处理） 。简单一些，就是数据库的增删查改。举个例子，你到银行，去取一笔钱出来，或者转账，或者只是想查一下你还有多少存款，这些都是面向“事务”类型的操作。这样的操作有几个显著的特点:

• 首先要求速度很快，
• 基本上都是高可靠的在线操作（比如银行），
• 还有这些操作涉及的数据内容不会特别大（否则速度也就相应的降低），
• 最后，“事务”型的操作往往都要求是精准操作，比如你去银行取款，必须要求一个具体的数字，你是不可能对着柜台员工说我大概想取400到500快之间吧，那样人家会一脸懵逼。

2.2.2 OLAP

这个东西又是上面发明关系型数据库的科德发明的。OLAP略有复杂，但这里我举一个简单的例子，大家就很容易理解了。

比如说，沃尔玛超市的数据库里有很多张表格，记录着各个商品的交易记录。超市里销售一种运动饮料，我们不妨称之为红牛。数据库中有一张表A，记录了红牛在一年的各个月份的销售额；还有一张表B，记录了红牛每个月在美国各个州的销售额：；甚至还有一张表C，记录了这家饮料公司在每个州对红牛饮料的宣传资金投入；甚至后来沃尔玛又从国家气象局拿到了美国各个州的一年365天每天的天气表。好，最后问题来了，请根据以上数据分析红牛在宣传资金不超过三百万的情况下，什么季节，什么天气，美国哪个州最好卖？凭借我们的经验，可能会得出，夏季的晴天，在美国的佛罗里达，最好卖，而且宣传资金投入越高销售额应该也会高。可能这样的结论是正确的，但决策者想要看到的是确凿的数据结论，而不是“可能”这样的字眼。

科学是不相信直觉的，如果我们人工进行手动分析，会发现这个要考虑的维度实在太多了，根本无法下手，何况这才四五个维度，要是更多了怎么办？OLAP就是为了解决这样的问题诞生的，但糟糕的是，传统数据库是无法满足OLAP所需要的数据信息的。

2.3 数据仓库概念

2.3.1 概述

数据库的大规模应用，使得信息行业的数据爆炸式的增长，为了研究数据之间的关系，挖掘数据隐藏的价值，人们越来越多的需要使用OLAP来为决策者进行分析，探究一些深层次的关系和信息。但很显然，不同的数据库之间根本做不到数据共享，就算同一家数据库公司，数据库之间的集成也存在非常大的挑战（最主要的问题是庞大的数据如何有效合并、存储）。

1988年，为解决企业的数据集成问题，IBM（卧槽，又是IBM）的两位研究员（Barry Devlin和Paul Murphy）创造性地提出了一个新的术语：数据仓库（Data Warehouse）。看到这里读者朋友们可能要问了，然后呢？然后…然后就没然后了。就在这个创世纪的术语诞生了之后，IBM就哑火了，只是将这个名词作为市场宣传的花哨概念，并没有在技术领域有什么实质性的研究和突破（可悲我大IBM=。=）。

然而，尽管IBM不为所动，其他企业却在加紧对数据仓库的研究和开发，大家都想在这个领域寻找到第一桶金。终于，到了1992年，后来被誉为“数据仓库之父”的比尔 恩门（Bill Inmon）给出了数据仓库的定义，二十多年后的今天他的定义依然没有被时代淘汰。我们来看看他是怎么定义的：数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理中的决策制定。

对于数据仓库的概念我们可以从两个层次予以理解：

• 首先,数据仓库用于支持决策,面向分析型数据处理,它不同于企业现有的操作型数据库;
• 其次,数据仓库是对多个异构的数据源有效集成,集成后按照主题进行了重组,并包含历史数据,而且存放在数据仓库中的数据一般不再修改。

我们可以不用管这个定义，简单的理解，其实就是我们为了进行OLAP，把分布在各个散落独立的数据库孤岛整合在了一个数据结构里面，称之为数据仓库。

这个数据仓库在技术上是怎么建立的读者朋友们并不需要关心，但是我们要知道，原来各个数据孤岛中的数据，可能会在物理位置（比如沃尔玛在各个州可能都有自己的数据中心）、存储格式（比如月份是数值类型，但但天气可能是字符类型）、商业平台（不同数据库可能用的是Oracle数据库，有的是微软SQL Server数据库）、编写的语言（Java或者Scale等）等等各个方面完全不同，数据仓库要做的工作就是将他们按照所需要的格式提取出来，再进行必要的转换（统一数据格式）、清洗（去掉无效或者不需要的数据）等，最后装载进数据仓库（我们所说的ETL工具就是用来干这个的）。这样，拿我们上面红牛的例子来说，所有的信息就统一放在了数据仓库中了。

自从数据仓库出现之后，信息产业就开始从以关系型数据库为基础的运营式系统慢慢向决策支持系统发展。这个决策支持系统，其实就是我们现在说的商务智能（Business Intelligence）即BI。

可以这么说，数据仓库为OLAP解决了数据来源问题，数据仓库和OLAP互相促进发展，进一步驱动了商务智能的成熟，但真正将商务智能赋予“智能”的，正是我们现在热谈的下一代技术：数据挖掘。

2.3.2 数据仓库特点

1. 面向主题
   面向主题特性是数据仓库和操作型数据库的根本区别。

   操作型数据库是为了支撑各种业务而建立，

   而分析型数据库则是为了对从各种繁杂业务中抽象出来的分析主题(如用户、成本、商品等)进行分析而建立；

2. 集成性
   集成性是指数据仓库会将不同源数据库中的数据汇总到一起；

3. 企业范围
   数据仓库内的数据是面向公司全局的。比如某个主题域为成本，则全公司和成本有关的信息都会被汇集进来；

4. 历史性
   较之操作型数据库，数据仓库的时间跨度通常比较长。前者通常保存几个月，后者可能几年甚至几十年；

5. 时变性
   时变性是指数据仓库包含来自其时间范围不同时间段的数据快照。有了这些数据快照以后，用户便可将其汇总，生成各历史阶段的数据分析报告；

2.4 数据仓库组件

数据仓库的核心组件有四个：业务系统各源数据库，ETL，数据仓库，前端应用。如下图所示：

1. 业务系统
   业务系统包含各种源数据库，这些源数据库既为业务系统提供数据支撑，同时也作为数据仓库的数据源(注：除了业务系统，数据仓库也可从其他外部数据源获取数据)；

2. ETL
   数据仓库会周期不断地从源数据库提取清洗好了的数据，因此也被称为"目标系统"。ETL分别代表：

   • 提取extraction
     表示从操作型数据库搜集指定数据
   • 转换transformation
     表示将数据转化为指定格式，并进行数据清洗保证数据质量
   • 加载load
     加载过程表示将转换过后满足指定格式的数据加载进数据仓库。

3. 前端应用
   和操作型数据库一样，数据仓库通常提供具有直接访问数据仓库功能的前端应用，这些应用也被称为BI(商务智能)应用。

2.5 数据仓库开发流程

2.5.1 概述

数据仓库的开发流程和数据库的比较相似，因此本文仅就其中区别进行分析。

下图为数据仓库的开发流程：

2.5.2 数据仓库需求

需求搜集是所有环节中最重要的一步，吃透了用户需求，往往就成功了大半。这些需求将指导后面如需求建模、实现、以及前端应用程序开发等。通常来说，需求都会通过ER图来表示(参考数据库需求与ER建模)，并和各业务方讨论搜集得到，最终整理成文档。

要特别强调的一点是数据仓库系统开发需求阶段过程是循环迭代式的，一开始的需求集并不大，但随着项目的进展，需求会越来越多。而且不论是以上哪个阶段发生了需求变动，整个流程都需要重新走一遍，决不允许隐式变更需求。

比如为一个学生选课系统进行ER建模，得到如下结果：

2.5.3 数据仓库建模

也就是逻辑模型建模，可参考第二篇：数据库关系建模

ER建模环节完成后，需求就被描述成了ER图。之后，便可根据这个ER图设计相应的关系表了。

但从ER图到具体关系表的建立还需要经过两个步骤：1. 逻辑模型设计 2. 物理模型设计。其中前者将ER图映射为逻辑意义上的关系表，后者则映射为物理意义上的关系表。

逻辑意义上的关系表可以理解为单纯意义上的关系表，它不涉及到表中字段数据类型，索引信息，触发器等等细节信息。

• 概念模型 VS 逻辑模型
  我们首先可以认为【概念模型建模和ER建模，需求可视化】表达的是一个意思。在这个环节中，数据开发人员绘制ER图，并和项目各方人员协同需求，达成一致。由于这部分的工作涉及到的人员开发能力比较薄弱，甚至不懂开发，因此ER图必须清晰明了，不能涉及到过多的技术细节，比如：要给多对多联系/多值属性等多建一张表，要设置外码，各种复合主码等，它们应当对非开发人员透明。而且ER图中每个属性只会出现一次，减少了蕴含的信息量，是更好的交流和文档化工具。在ER图绘制完毕之后，才开始将它映射为关系表。这个映射的过程，就叫做逻辑模型建模或者关系建模。

  还有，ER模型所蕴含的信息，也没有全部被逻辑模型包含。比如联系的自定义基数约束，比如实体的复合属性，派生属性，用户的自定义约束等等。因此ER模型在整个开发流程(如物理模型建模，甚至前端开发)中是都会用到的，不能认为ER模型转换到逻辑模型后就可以扔一边了。

• 逻辑模型 物理模型
  逻辑模型设计好后，就可以开始着手数据仓库的物理实现了，他也被称为物理模型建模，这个阶段不但需要参照逻辑模型，还应当参照ER图。

2.5.4 数据仓库实现

这一步的本质就是在空的数据仓库里实现2种前面创建的关系模型，一般通过使用SQL或者提供的前端工具实现。

2.5.5 开发前端应用程序

前端应用开发在需求搜集好了之后就开始进行，主要有网站、APP等前端形式。另外前端程序的实际实现涉及到和数据仓库之间交互，因此这一步的最终完成在数据库建模之后。

2.5.6 ETL工程

较之数据库系统开发流程，数据仓库开发只多出ETL工程部分。然而这一部分极有可能是整个数据仓库开发流程中最为耗时耗资源的一个环节。因为该环节要整理各大业务系统中杂乱无章的数据并协调元数据上的差别，所以工作量很大。在很多公司都专门设有ETL工程师这样的岗位，大的公司甚至专门聘请ETL专家。

2.5.7 数据仓库部署

顾名思义，这一步就是部署数据库系统的软硬件环境。数据库部署往往还包含将初始数据填入数据库中的意思。对于云数据仓库，这一步就叫"数据上云"。

2.5.8 数据仓库使用

这一步没啥多讲的，就再讲一个有关的故事吧。同样是在A公司，有一次某政企私有云项目完成后，我们有人被派去给他们培训如何使用。结果去的人回来后说政企意见很大，认为让他们学习SQL以外的东西都不行。拒绝用Python写UDF，更拒绝MR编程接口，只要SQL和图形界面操作方式。一开始我对政企的这种行为有点看不起，但后来我想，就是因为有这群挑剔的用户，才使得A公司云产品的易用性如此强大，从而占领国内云计算的大部分市场。用户的需求才是技术的唯一试金石。

2.5.9 数据库管理和维护

严格来讲，这部分不算开发流程，属于数据库系统开发完成后的工作。

2.6 数据仓库系统管理

数据仓库系统发行后，控制权便从数据仓库设计、实现、部署的团队移交给了数据仓库管理员，并由他们来对系统进行管理，涵盖了确保一个已经部署的数据仓库系统正确运行的各种行为。为了实现这一目标，具体包含以下范畴：

2.7 数据质量体系

数据仓库系统需要重视数据质量问题。用一句话概括，数据质量就是衡量数据能否真实、及时反映客观世界的指标。具体来说，数据质量包含以下几大指标：

1. 准确性
   准确性要求数据能够正确描述客观世界。比如某用户姓名拼音mu chen错误的录入成了muc hen，就应该弹出警告语；

2. 唯一性（视情况而定）
   唯一性要求数据不能被重复录入，或者不能有两个几乎相同的关系。比如张三李四在不同业务环境下分别建立了近乎相同的关系，这时应将这两个关系合并；

3. 完整性
   完整性要求进行数据搜集时，需求数据的被描述程度要高。比如一个用户的购买记录中，必然要有支付金额这个属性；规则验证。

4. 一致性
   一致性要求不同关系、或者同一关系不同字段的数据意义不发生冲突。

   比如某关系中昨天存货量字段+当天进货量字段-当天销售量字段等于当天存货量就可能是数据质量有问题；

5. 及时性
   及时性要求数据库系统中的数据"保鲜"。比如当天的购买记录当天就要入库；

6. 统一性
   统一性要求数据格式统一。比如nike这个品牌，不能有的字段描述为"耐克"，而有的字段又是"奈克"；

• 小结
  数据质量和数据具体意义有很大相关性，因此无法单凭理论来保证。且由于具体业务及真实世界的复杂性，数据质量问题必然会存在，不可能完全预防得了。因此很多公司都提供了数据质量工程服务/软件，用来识别和校正数据库系统中的各种数据质量问题。

0x03 数据集市

Bill Inmon说过一句话叫“IT经理们面对最重要的问题就是到底先建立数据仓库还是先建立数据集市”，足以说明搞清楚这两者之间的关系是十分重要而迫切的！通常在考虑建立数据仓库之前，会涉及到如下一些问题：

• 采取自上而下还是自下而上的设计方法
• 企业范围还是部门范围
• 先建立数据仓库还是数据集市
• 建立领航系统还是直接实施
• 数据集市是否相互独立

数据集市可以理解为是一种"小型数据仓库"，它只包含单个主题，且关注范围也非全局。

数据集市可以分为两种:

• 一种是独立数据集市(independent data mart)，这类数据集市有自己的源数据库和ETL架构；
• 另一种是非独立数据集市(dependent data mart)，这种数据集市没有自己的源系统，它的数据来自数据仓库。当用户或者应用程序不需要/不必要/不允许用到整个数据仓库的数据时，非独立数据集市就可以简单为用户提供一个数据仓库的子集。