hadoop构建数据仓库实践 数据仓库简介和数据仓库设计基础章节 读书笔记

1.数据仓库简介

1.0演变

1.1什么是数据仓库

本质：数据仓库试图提供一种从操作型系统到决策支持环境的数据流架构模型。

要解决的问题：多重数据复制带来的高成本问题（在没有数据仓库的时代，需要大量的冗余数据来支撑多个决策支持环境。在大组织里，多个决策支持环境独立运作是典型的情况。尽管每个环境服务于不同的用户，但这些环境经常需要大量相同的数据。处理过程收集、清洗、整合来自多个数据源的数据，并为每个决策支持环境做部分数据复制。数据源通常是早已存在的操作型系统，很多是遗留系统。此外，当一个新的决策支持环境形成时，操作型系统的数据经常被再次复用。用户访问这些处理后的数据。
）

1.1.1　数据仓库的定义

数据仓库之父Bill Inmon在1991年出版的Building the Data Warehouse
一书中首次提出了被广为认可的数据仓库定义：面向主题（业务相关的数据的类别）、集成（面向主题相关，多个数据源）、非易失（一般并不进行数据更新）,包含历史数据的数据集合，用于决策支持。
除了以上四个特性外，数据仓库还有一个非常重要的概念就是粒度。（粒度是指数据的细节或汇总程度，细节程度越高，粒度级别越低。）

1.1.2　建立数据仓库的原因

• 将多个数据源集成到单一数据存储，因此可以使用单一数据查询引擎展示数据。
• 缓解在事务处理数据库上因执行大查询而产生的资源竞争问题。
• 维护历史数据。
• 通过对多个源系统的数据整合，使得在整个企业的角度存在统一的中心视图。
• 通过提供一致的编码和描述，减少或修正坏数据问题，提高数据质量。
• 一致性地表示组织信息。 提供所有数据的单一通用数据模型，而不用关心数据源。
• 重构数据，使数据对业务用户更有意义。
• 向复杂分析查询交付优秀的查询性能，同时不影响操作型系统。
• 开发决策型查询更简单。

1.1.3传统数据库和数据仓库比较

数据仓库3个层次

作 为 企 业 实 施 决 策 的 支 持 工 具 ， 数 据仓库在理论上并没有固定的，严格的规 定 ， 而 是 随 企 业 规 模 、 决 策 类 型 、 数 据 特 点 的 不 同 而 改 变 。 即 使 是 得 到 了 广 泛 接 受 的数据 仓 库 “ 三 层 结 构 " 理 论 ， 对 三 层 的 具 体 规 定 也 并 不 统 一 ， Jiawei Han 和 Micheline Kam认 为 ， 三 层 的 内 容 是 指 仓 库 数 据 库 服 务 器 层 、 OLAP 服 务 器 层 和 客 户 层 ， 而 Paul Gray H 与 J. Watson 则 认 为 ， 数 据 仓 库 的 三 层 是 指 数 据 与 数 据 管 理 软 件 层 、 数 据 仓 库 层 以 及 支 持 引 擎 客户端层 。 从各部件 的功能来分析 ，数据仓库在逻辑上可以分为三个层次 ，数据获 取 管理层、数据存储 层 与 数 据 分 析 / 应 用 层 。

1.2　操作型系统与分析型系统

操作型系统完成组织的核心业务，例如下订单、更新库存、记录支付信息等。

这些系统是事务型的，核心目标是尽可能快地处理事务，同时维护数据的一致性和完整性。

而分析型系统的主要作用是通过数据分析评估组织的业务经营状况，并进一步辅助决策。

1.2.1　操作型系统

操作型系统是一类专门用于管理面向事务的应用的信息系统。事务保证工作单元的可靠性，提供并发访问数据库的多个程序间的隔离。有ACID特性。

事务简介

定义：事务是工作于数据库管理系统（或类似系统）中的一个逻辑单元，该逻辑单元中的操作被以一种独立于其他事务的可靠方式所处理。事务一般代表着数据改变，它提供“all-or-nothing”操作，就是说事务中的一系列操作要么完全执行，要么完全不执行

作用：
1）保证工作单元的可靠性。
2）提供并发访问数据库的多个程序间的隔离

ACID特性

原子性

指的是事务中的一系列操作或全执行或不执行，这些操作是不可再分的。

一致性

数据库系统中的一致性是指任何数据库事务只能以允许的方式修改数据。任何数据库写操作必须遵循既有的规则，包括约束、级联、触发器以及它们的任意组合。一致性并不保证应用程序逻辑的正确性，但它能够保证不会因为程序错误而使数据库产生违反规则的结果。

隔离性

在数据库系统中，隔离性决定了其他用户所能看到的事务完整性程度。例如，一个用户正在生成一个采购订单，并且已经生成了订单主记录，但还没有生成订单条目明细记录。此时订单主记录能否被其他并发用户看到呢？这就是由隔离级别决定的。数据库系统中，按照由低到高一般有读非提交、读提交、可重复读、串行化等几种隔离级。数据库系统并不一定实现所有的隔离级别，如Oracle数据库只实现了读提交和串行化，而MySQL数据库则提供这全部四种隔离级别。

隔离级越低，多用户同时访问数据的能力越高，但同时也会增加脏读、丢失更新等并发操作的负面影响。相反，高隔离级降低了并发影响，但需要使用更多的系统资源，也增加了事务被阻塞的可能性。

操作型系统通常是高并发、高吞吐量的系统，具有大量检索、插入、更新操作，事务数量大，但每个事务影响的数据量相对较小。这样的系统很适合在线应用，这些应用有成千上万用户在同时使用，并要求能够立即响应用户请求。操作型系统常被整合到面向服务的架构（SOA）和Web服务里。对操作型系统应用的主要要求是高可用、高速度、高并发、可恢复和保证数据一致性

持久性

数据库系统的持久性保证已经提交的事务是永久保存的。

操作型系统总结

操作型系统通常是高并发、高吞吐量的系统，具有大量检索、插入、更新操作，事务数量大，但每个事务影响的数据量相对较小。这样的系统很适合在线应用，这些应用有成千上万用户在同时使用，并要求能够立即响应用户请求。操作型系统常被整合到面向服务的架构（SOA）和Web服务里。对操作型系统应用的主要要求是高可用、高速度、高并发、可恢复和保证数据一致性

操作型系统的数据库操作

在数据库使用上，操作型系统常用的操作是增、改、查，并且通常是插入与更新密集型的，同时会对数据库进行大量并发查询，而删除操作相对较少。操作型系统一般都直接在数据库上修改数据，没有中间过渡区。

操作型系统的数据库设计

操作型系统的特征是大量短的事务，并强调快速处理查询。对于操作型系统每秒事务数是操作型系统的一个有效度量指标。在数据库逻辑设计上，操作型系统的应用数据库大都使用规范化设计方法，通常要满足第三范式。这是因为规范化设计能最大限度地数据冗余，因而提供更快更高效的方式执行数据库写操作。关于规范化设计概念及其相关内容，会在第2章“数据仓库设计”中做详细说明。

在数据库物理设计上，应该依据系统所使用的数据库管理系统的具体特点，做出相应的设计，毕竟每种数据库管理系统在实现细节上还是存在很大差异的。

操作型系统都是以数据库系统为核心，而数据库系统为了保持ACID特性，本质上是单一集中式系统。在当今这个信息爆炸的时代，集中式数据库往往已无法支撑业务的需要（从某订票网站和某电商网站的超大瞬时并发量来看，这已是一个不争的事实）。这就给操作型系统带来新的挑战。分布式事务、去中心化、CAP与最终一致性等一系列新的理论和技术为解决系统扩展问题应运而生。

1.2.2　分析型系统

定义：分析型系统是一种快速回答多维分析查询的实现方式。

应用：销售业务分析报告、市场管理报告、业务过程管理（BPM）、预算和预测、金融分析报告及其类似的应用

分析型系统的数据库操作

在数据库层面，分析型系统操作被定义成少量的事务，复杂的查询，处理归档和历史数据。这些数据很少被修改，从数据库抽取数据是最多的操作，也是识别这种系统的关键特征。分析型数据库基本上都是读操作。

分析型系统的数据库设计

分析型系统的特征是相对少量的事务，但查询通常非常复杂并且会包含聚合计算。对于分析型系统，吞吐量是一个有效的性能度量指标。在数据库逻辑设计上，分析型数据库使用多维数据模型，通常是设计成星型模式或雪花模式。关于多维数据模型的概念及其相关内容，会在第2章“数据仓库设计”中做详细说明。

在数据库物理设计上，可能需要考虑表分区、位图索引、并行化操作等。

1.2.3　操作型系统和分析型系统对比

操作型系统和分析型系统以完全不同的方式使用数据库，分析型系统更加注重数据分析和报表，而操作型系统的目标是一个伴有大量数据改变的事务优化系统。具体区别：

• 侧重点：操作型系统更适合对已有数据的更新，所以是日常处理工作或在线系统的选择。相反，分析型系统提供在大量存储数据上的分析能力，所以这类系统更适合报表类应用
• 目标：操作型系统数据库通常使用规范化设计，为普通查询和数据修改提供更好的性能。另一方面，分析型数据库具有典型的数据仓库组织形式
• 响应速度：操作型系统上的查询更小，而分析型系统上执行的查询要复杂得多。所以操作型系统会比分析型系统快很多。
• 数据更新：操作型系统的数据会持续更新，并且更新会立即生效。而分析型系统的数据更新，是由预定义的处理作业同时装载大量的数据集合，并且在装载前需要做数据转换，因此整个数据更新过程需要很长的执行时间。
• 备份：由于操作型系统要做到绝对的数据安全和可用性，所以需要实施复杂的备份系统。基本的全量备份和增量备份都是必须要做的。而分析型系统只需要偶尔执行数据备份即可，这一方面是因为这类系统一般不需要保持持续运行，另一方面数据还可以从操作型系统重复装载。
  -存储：两种系统的空间需求显然都依赖于它们所存储的数据量。分析型系统要存储大量的历史数据，因此需要更多的存储空间。

图中显示的整个数据仓库环境包括操作型系统和数据仓库系统两大部分。操作型系统的数据由各种形式的业务数据组成，这其中可能有关系数据库、TXT或CSV文件、HTML或XML文档，还可能存在外部系统的数据，比如网络爬虫抓取来的互联网数据等，数据可能是结构化、半结构化、非结构化的。这些数据经过抽取、转换和装载（ETL）过程进入数据仓库系统。

这里把ETL过程分成了抽取和转换装载两个部分。抽取过程负责从操作型系统获取数据，该过程一般不做数据聚合和汇总，但是会按照主题进行集成，物理上是将操作型系统的数据全量或增量复制到数据仓库系统的RDS中。转换装载过程并将数据进行清洗、过滤、汇总、统一格式化等一系列转换操作，使数据转为适合查询的格式，然后装载进数据仓库系统的TDS中。传统数据仓库的基本模式是用一些过程将操作型系统的数据抽取到文件，然后另一些过程将这些文件转化成MySQL或Oracle这样的关系数据库的记录。最后，第三部分过程负责把数据导入进数据仓库。
RDS（RAW DATA STORES）是原始数据存储的意思。将原始数据保存到数据仓库里是个不错的想法。ETL过程的bug或系统中的其他错误是不可避免的，保留原始数据使得追踪并修改这些错误成为可能。有时数据仓库的用户会有查询细节数据的需求，这些细节数据的粒度与操作型系统的相同。有了RDS，这种需求就很容易实现，用户可以查询RDS里的数据而不必影响业务系统的正常运行。这里的RDS实际上是起到了操作型数据存储（ODS）的作用，关于ODS相关内容本小节后面会有详细论述。

TDS（TRANSFORMED DATA STORES）意为转换后的数据存储。这是真正的数据仓库中的数据。大量的用户会在经过转换的数据集上处理他们的日常查询。如果前面的工作做得好，这些数据将被以保证最重要的和最频繁的查询能够快速执行的方式构建。
这里的原始数据存储和转换后的数据存储是逻辑概念，它们可能物理存储在一起，也可能分开。当原始数据存储和转换后的数据存储物理上分开时，它们不必使用同样的软硬件。传统数据仓库中，原始数据存储通常是本地文件系统，原始数据被组织进相应的目录中，这些目录是基于数据从哪里抽取或何时抽取建立（例如以日期作为文件或目录名称的一部分）；转换后的数据存储一般是某种关系数据库。

自动化调度组件的作用是自动定期重复执行ETL过程。不同角色的数据仓库用户对数据的更新频率要求也会有所不同，财务主管需要每月的营收汇总报告，而销售人员想看到每天的产品销售数据。作为通用的需求，所有数据仓库系统都应该能够建立周期性自动执行的工作流作业。传统数据仓库一般利用操作系统自带的调度功能（如Linux的cron或Windows的计划任务）实现作业自动执行。

数据目录有时也被称为元数据存储，它可以提供一份数据仓库中数据的清单。用户通过它应该可以快速解决这些问题：什么类型的数据被存储在哪里，数据集的构建有何区别，数据最后的访问或更新时间等。此外还可以通过数据目录感知数据是如何被操作和转换的。一个好的数据目录是让用户体验到系统易用性的关键。

查询引擎组件负责实际执行用户查询。传统数据仓库中，它可能是存储转换后数据的（Oracle、MySQL等关系数据库系统内置的）查询引擎，还可能是以固定时间间隔向其导入数据的OLAP立方体，如Essbase cube。

用户界面指的是最终用户所使用的接口程序。可能是一个GUI软件，如BI套件的中的客户端软件，也可能就是一个浏览器。

1.3.2　主要数据仓库架构

在数据仓库技术演化过程中，产生了几种主要的架构方法，包括数据集市架构、Inmon企业信息工厂架构、Kimball数据仓库架构和混合型数据仓库架构

数据集市架构

数据集市是按主题域组织的数据集合，用于支持部门级的决策。有两种类型的数据集市：独立数据集市和从属数据集市。

独立数据集市集中于部门所关心的单一主题域，数据以部门为基础部署，无须考虑企业级别的信息共享与集成。独立数据集市从一个主题域或一个部门的多个事务系统获取数据，用以支持特定部门的业务分析需要。一个独立数据集市的设计既可以使用实体关系模型，也可以使用多维模型。数据分析或商业智能工具直接从数据集市查询数据，并将查询结果显示给用户。一个典型的独立数据集市架构如图所示。

因为一个部门的业务相对于整个企业要简单，数据量也小得多，所以部门的**独立数据集市具有周期短、见效快的特点。**如果从企业整体的视角来观察这些数据集市，你会看到每个部门使用不同的技术，建立不同的ETL的过程，处理不同的事务系统，而在多个独立的数据集市之间还会存在数据的交叉与重叠，甚至会有数据不一致的情况。从业务角度看，当部门的分析需求扩展，或者需要分析跨部门或跨主题域的数据时，独立数据市场会显得力不从心。而当数据存在歧义，比如同一个产品，在A部门和B部门的定义不同时，将无法在部门间进行信息比较。

另外一种数据集市是从属数据集市。如Bill Inmon所说，从属数据集市的数据来源于数据仓库。数据仓库里的数据经过整合、重构、汇总后传递给从属数据集市。从属数据集市的架构如图所示。

建立从属数据集市的好处主要有：

• 性能：当数据仓库的查询性能出现问题，可以考虑建立几个从属数据集市，将查询从数据仓库移出到数据集市。
• 安全：每个部门可以完全控制他们自己的数据。
• 数据一致：因为每个数据集市的数据来源都是同一个数据仓库，有效消除了数据不一致的情况。

Inmon企业信息工厂架构

Kimball数据仓库架构

Kimball与Inmon两种架构的主要区别在于核心数据仓库的设计和建立。Kimball的数据仓库包含高粒度的企业数据，使用多维模型设计，这也意味着数据仓库由星型模式的维度表和事实表构成。分析系统或报表工具可以直接访问多维数据仓库里的数据。在此架构中的数据集市也与Inmon中的不同。这里的数据集市是一个逻辑概念，只是多维数据仓库中的主题域划分，并没有自己的物理存储，也可以说是虚拟的数据集市。

3.混合型数据仓库架构

1.3操作系统存储

谓的混合型结构，指的是在一个数据仓库环境中，联合使用Inmon和Kimball两种架构。从架构图可以看到，这种架构将Inmon方法中的数据集市部分替换成了一个多维数据仓库，而数据集市则是多维数据仓库上的逻辑视图。使用这种架构的好处是，既可以利用规范化设计消除数据冗余，保证数据的粒度足够细；又可以利用多维结构更灵活地在企业级实现报表和分析

1.3.3 操作数据存储

操作数据存储又称为ODS，是Operational Data Store的简写，其定义是这样的：一个面向主题的、集成的、可变的、当前的细节数据集合，用于支持企业对于即时性的、操作性的、集成的全体信息的需求。对比1.1节中数据仓库的定义不难看出，操作型数据存储在某些方面具有类似于数据仓库的特点，但在另一些方面又显著不同于数据仓库。

• 像数据仓库一样，是面向主题的。
• 像数据仓库一样，其数据是完全集成的。
• 数据是当前的，这与数据仓库存储历史数据的性质明显不同。ODS具有最少的历史数据（一般是30天到60天），而尽可能接近实时地展示数据的状态。
• 数据是可更新的，这是与静态数据仓库又一个很大的区别。ODS就如同一个事务处理系统，- 当新的数据流进ODS时，受其影响的字段被新信息覆盖。
• 数据几乎完全是细节数据，仅具有少量的动态聚集或汇总数据。通常将ODS设计成包含事务级的数据，即包含该主题域中最低粒度级别的数据。
  在数据仓库中，几乎没有针对其本身的报表，报表均放到数据集市中完成；与此不同，在ODS中，业务用户频繁地直接访问ODS。

在一个数据仓库环境中，ODS具有如下几个作用：

• **充当业务系统与数据仓库之间的过渡区。**数据仓库的数据来源复杂，可能分布在不同的数据库，不同的地理位置，不同的应用系统之中，而且由于数据形式的多样性，数据转换的规则往往极为复杂。如果直接从业务系统抽取数据并做转换，不可避免地会对业务系统造成影响。而ODS中存放的数据从数据结构、数据粒度、数据之间的逻辑关系上都与业务系统基本保持一致，因此抽取过程只需简单的数据复制而基本不再需要做数据转换，大大降低了复杂性，同时最小化对业务系统的侵入。

• 转移部分业务系统细节查询的功能。某些原来由业务系统产生的报表、细节数据的查询能够在ODS中进行，从而降低业务系统的查询压力。

• 完成数据仓库中不能完成的一些功能。用户有时会要求数据仓库查询最低粒度级别的细节数据，而数据仓库中存储的数据一般都是聚合或汇总过的数据，并不存储每笔交易产生的细节数据。这时就需要把细节数据查询的功能转移到ODS来完成，而且ODS的数据模型是按照面向主题的方式组织的，可以方便地支持多维分析。即数据仓库从宏观角度满足企业的决策支持要求，而ODS层则从微观角度反映细节交易数据或者低粒度的数据查询要求。

1.4　抽取-转换-装载

前面已经多次提到了ETL一词，它是Extract、Transform、Load三个英文单词首字母的简写，中文意为抽取、转换、装载。ETL是建立数据仓库最重要的处理过程，也是最体现工作量的环节，一般会占到整个数据仓库项目工作量的一半以上。

• 抽取：从操作型数据源获取数据。
• 转换：转换数据，使之转变为适用于查询和分析的形式和结构。
• 装载：将转换后的数据导入到最终的目标数据仓库。

建立一个数据仓库，就是要把来自于多个异构的源系统的数据集成在一起，放置于一个集中的位置用于数据分析。如果一开始这些源系统数据就是兼容的当然最好，但情况往往不是这样。ETL系统的工作就是要把异构的数据转换成同构的。如果没有ETL，不可能对异构的数据进行程序化的分析。

1.4.1　数据抽取

抽取操作从源系统获取数据给后续的数据仓库环境使用。这是ETL处理的第一步，也是最重要的一步。数据被成功抽取后，才可以进行转换并装载到数据仓库中。能否正确地获取数据直接关系到后面步骤的成败。

通常数据都不是只抽取一次，而是需要以一定的时间间隔反复抽取，通过这样的方式把数据的所有变化提供给数据仓库，并保持数据的及时性。除此之外，源系统一般不允许外部系统对它进行修改，也不允许外部系统对它的性能和可用性产生影响，数据仓库的抽取过程要能适应这样的需求。如果已经明确了需要抽取的数据，下一步就该考虑从源系统抽取数据的方法了。

对抽取方法的选择高度依赖于源系统和目标数据仓库环境的业务需要。一般情况下，不可能因为需要提升数据抽取的性能，而在源系统中添加额外的逻辑，也不能增加这些源系统的工作负载。有时，用户甚至都不允许增加任何“开箱即用”的外部应用系统，这叫做对源系统具有侵入性。下面分别从逻辑和物理两方面介绍数据抽取方法。
1．逻辑抽取
有两种逻辑抽取类型：全量抽取和增量抽取。
2．物理抽取
(1）联机抽取
(2）脱机抽取(数据库备份文件,备用数据库,导出文件。。。）
3．变化数据捕获
常用的变化数据捕获方法有时间戳、快照、触发器和日志四种。

1.4.2　数据转换

如统一数据类型、处理拼写错误、消除数据歧义、解析为标准格式等。最重要的功能是清洗数据

1.4.3　数据装载

重点考虑两个问题，一是数据装载的效率问题，二是一旦装载过程中途失败了，如何再次重复执行装载过程。

加快装载速度，可以从以下几方面入手。

首先保证足够的系统资源。
数据仓库存储的都是海量数据，所以要配置高性能的服务器，并且要独占资源，不要与别的系统共用。在进行数据装载时，要禁用数据库约束（唯一性、非空性，检查约束等）和索引，当装载过程完全结束后，再启用这些约束，重建索引，这种方法会很大的提高装载速度。一般不使用数据库来保证数据的参考完整性，即不使用数据库的外键约束，它应该由ETL工具或程序来维护。

数据装载过程可能由于多种原因而失败，比如装载过程中某些源表和目标表的结构不一致而导致失败，而这时已经有部分表装载成功了。在数据量很大的情况下，如何能在重新执行装载过程时只装载失败的部分是一个不小的挑战。对于这种情况，实现可重复装载的关键是要记录下失败点，并在装载程序中处理相关的逻辑。还有一种情况，就是装载成功后，数据又发生了改变（比如有些滞后的数据在ETL执行完才进入系统，就会带来数据的更新或新增），这时需要重新再执行一遍装载过程，已经正确装载的数据可以被覆盖，但相同数据不能重复新增。简单的实现方式是先删除再插入，或者用replace into、merge into等类似功能的操作

装载到数据仓库里的数据，经过汇总、聚合等处理后交付给多维立方体或数据可视化、仪表盘等报表工具、BI工具做进一步的数据分析。

1.4.4　开发ETL系统的方法

TL系统一般都会从多个应用系统整合数据，典型的情况是这些应用系统运行在不同的软硬件平台上，由不同的厂商所支持，各个系统的开发团队也是彼此独立的，随之而来的数据多样性增加了ETL系统的复杂性。

开发一个ETL系统，常用的方式是使用数据库标准的SQL及其程序化语言，如Oracle的PL/SQL和MySQL的存储过程、用户自定义函数（UDF）等。还可以使用Kettle这样的ETL工具，这些工具都提供多种数据库连接器和多种文件格式的处理能力，并且对ETL处理进行了优化。使用工具的最大好处是减少编程工作量，提高工作效率。如果遇到特殊需求或特别复杂的情况，可能还是需要使用Shell、Java、Python等编程语言开发自己的应用程序。

ETL过程要面对大量的数据，因此需要较长的处理时间。为了提高ETL的效率，通常这三步操作会并行执行。当数据被抽取时，转换进程同时处理已经收到的数据。一旦某些数据被转换过程处理完，装载进程就会将这些数据导入目标数据仓库，而不会等到前一步工作执行完才开始

1.4.5 常见ETL工具

传统大的软件厂商一般都提供ETL工具软件，如Oracle的OWB和ODI、微软的SQL Server Integration Services、SAP的Data Integrator、IBM的InfoSphere DataStage、Informatica等。

1.5　数据仓库需求

本小节从基本需求和数据需求两方面介绍对数据仓库系统的整体要求

1.5.1　基本需求

安全性：
适当的授权机制。增加安全特性会影响到数据仓库的性能，因此必须提早考虑数据仓库的安全需求。
在数据仓库的设计阶段，我们就应该进行如下的安全性考虑：

• 数据仓库中的数据对于最终用户是只读的，任何人都不能修改其中的数据，这是由数据的非易失性所决定的。
• 划分数据的安全等级，如公开的、机密、秘密、绝密等。
• 制定访问控制方案，决定哪些用户可以访问哪些数据。
• 设计授予、回收、变更用户访问权限的方法。
• 添加对数据访问的审计功能。

可访问性：指的是用户访问和检索数据的能力。数据仓库的最终用户通常是业务人员、管理人员或者数据分析师。他们对组织内的相关业务非常熟悉，对数据的理解也很透彻，但是他们大都不是IT技术专家。这就要求我们在设计数据仓库的时候，将用户接口设计得尽量友好和简单，使得没有技术背景的用户同样可以轻易查询到他们需要的数据。

自动化：狭义的自动化指的是数据仓库相关作业的自动执行。比如ETL过程、报表生成、数据传输等处理，都可以周期性定时自动完成。广义的数据仓库自动化指的是在保证数据质量和数据一致性的前提下，加速数据仓库系统开发周期的过程。整个数据仓库生命周期的自动化，从对源系统分析到ETL，再到数据仓库的建立、测试和文档化，可以帮助加快产品化进程，降低开发和管理成本，提高数据质量。

1.5.2　数据需求

通过数据仓库，既可以周期性地回答已知的问题（如报表等），也可以进行即席查询（ad-hoc queries）。报表最基本的需求就是对预定义好的一系列查询条件、查询内容，排序条件等进行组合，查询数据，把结果用表格或图形的形式展现出来。而所谓的即席查询不是预定义好的，而是在执行时才确定的。数据库管理员使用命令行或客户端软件，连接数据库系统执行各种各样的查询语句，是最为常见的一种即席查询方式。而理想的数据仓库系统，允许业务或分析人员也可以通过系统执行这样的自定义查询。为了满足需求，数据仓库中的数据需要确保准确性、时效性和历史可追溯性。

• 准确性 想要数据仓库实施成功，业务用户必须信任其中的数据。这就意味着他们应该能知道数据从哪来，何时抽取，怎么转换的。更重要的是，他们需要访问原始数据来确定如何解决数据差异问题。实际上ETL过程应该总是在数据仓库的某个地方（如ODS）保留一份原始数据的复制。

• 时效性 用户的时效性要求差异很大。有些用户需要数据精确到毫秒级，而有些用户只需要几分钟、几小时甚至几天前的数据就可以了。数据仓库是分析型系统，用于决策支持，所以实践中一般不需要很强的实时性，以一天作为时间粒度是比较常见的

• 历史可追溯性 数据仓库更多的价值体现在它能够辅助随时间变化的趋势分析，并帮助理解业务事件（如特殊节日促销等）与经营绩效之间的关系

1.6 小结

（1）数据仓库是一个面向主题的、集成的、随时间变化的、非易失的数据集合，用于支持管理者的决策过程。
（2）数据仓库中的粒度是指数据的细节或汇总程度，细节程度越高，粒度级别越低。
（3）数据仓库的数据来自各个业务应用系统。
（4）很多因素导致直接访问业务系统无法进行全局数据分析的工作，这也是需要一个数据仓库的原因所在。
（5）操作型系统是一类专门用于管理面向事务的应用信息系统，而分析型系统是一种快速回答多维分析查询的实现方式，两者在很多方面存在差异。
（6）构成数据仓库系统的主要组成部分有数据源、ODS、中心数据仓库、分析查询引擎、ETL、元数据管理和自动化调度。
（7）主要的数据仓库架构有独立数据集市、从属数据集市、Inmon企业信息工厂、Kimball多维数据仓库、混合型数据仓库。
（8）ETL是建立数据仓库最重要的处理过程，也是最体现工作量的环节。
（9）Kettle是常用的开源ETL工具。
（10）数据仓库的基本需求是安全性、可访问性、自动化，对数据的要求是准确性、时效性、历史可追溯性。

2.数据仓库设计基础

2.1　关系数据模型

关系模型是由E.F.Codd在1970年提出的一种通用数据模型。由于关系数据模型简单明了，并且有坚实的数学理论基础，所以一经推出就受到了业界的高度重视。关系模型被广泛应用于数据处理和数据存储，尤其是在数据库领域，现在主流的数据库管理系统几乎都是以关系数据模型为基础实现的。

2.1.1　关系数据模型中的结构

关系（表）、属性（字段/列）、属性域、元组（记录/行）、关系数据库、关系表的属性、关系数据模型中的键（超键、候选键、主键、外键）

2.1.2　关系完整性

1.空值

2.关系完整性规则
关系数据模型有两个重要的完整性规则：实体完整性和参照完整性。
（1）实体完整性
在一个基本表中，主键列的取值不能为空。主键是用于唯一标识记录的最小列集合。也就是说，主键的任何子集都不能提供记录的唯一标识。

（2）参照完整性
如果表中存在外键，则外键值必须与主表中的某些记录的候选键值相同，或者外键的值必须全部为空。

3.业务规则
定义或约束组织的某些方面的规则。业务规则的例子包括属性域和关系完整性规则。属性域用于约束特定列能够取的值。

4.关系数据库语言

关系语言定义了允许对数据进行的操作，包括从数据库中更新或检索数据所用的操作以及改变数据库对象结构的操作。关系数据库的主要语言是SQL语言。

SQL是Structured Query Language的缩写，意为结构化查询语言。SQL已经被国际标准化组织（ISO）进行了标准化，使它成为正式的和事实上的定义和操纵关系数据库的标准语言。SQL语言又可分为DDL、DML、DCL、TCL四类。

DDL是Data Definition Language的缩写，意为数据定义语言，用于定义数据库结构和模式。典型的DDL有create、alter、drop、truncate、comment、rename等。

DML是Data Manipulation Language的缩写，意为数据操纵语言，用于检索、管理和维护数据库对象。典型的DML有select、insert、update、delete、merge、call、explain、lock等。

DCL是Data Control Language的缩写，意为数据控制语言，用于授予和回收数据库对象上的权限。典型的DCL有grant和revoke。

TCL是Transaction Control Language的缩写，意为事务控制语言，用于管理DML对数据的改变。它允许一组DML语句联合成一个逻辑事务。典型的TCL有commit、rollback、savepoint、set transaction等。

2.1.3　规范化

关系数据模型的规范化是一种组织数据的技术。规范化方法对表进行分解，以消除数据冗余，避免异常更新，提高数据完整性。

不规范化带来的问题：
没有规范化，数据的更新处理将变得困难，异常的插入、修改、删除数据的操作会频繁发生。
为了克服这些异常更新，我们需要对表进行规范化设计。

规范化是通过应用范式规则实现的。最常用的范式有第一范式（1NF）、第二范式（2NF）、第三范式（3NF）。

（1）第一范式（1NF）
表中的列只能含有原子性（不可再分）的值。

（2）第二范式（2NF）
第二范式要同时满足下面两个条件：
满足第一范式。
没有部分依赖

（3）第三范式（3NF）
第三范式要同时满足下面两个条件：
满足第二范式。
没有传递依赖。

在关系数据模型设计中，一般需要满足第三范式的要求。如果一个表有良好的主外键设计，就应该是满足3NF的表。规范化带来的好处是通过减少数据冗余提高更新数据的效率，同时保证数据完整性。然而，我们在实际应用中也要防止过度规范化的问题。规范化程度越高，划分的表就越多，在查询数据时越有可能使用表连接操作。而如果连接的表过多，会影响查询的性能。关键的问题是要依据业务需求，仔细权衡数据查询和数据更新的关系，制定最适合的规范化程度。还有一点需要注意的是，不要为了遵循严格的规范化规则而修改业务需求。

2.1.4　关系数据模型与数据仓库

关系数据模型可以提供高性能的数据更新操作，能很好地满足事务型系统的需求，这点毋庸置疑。但是对于查询与分析密集型的数据仓库系统还是否合适呢？对这个问题的争论由来已久，基本可以分为Inmon和Kimball两大阵营，Inmon阵营是应用关系数据模型构建数据仓库的支持者。

Inmon方法是以下面这些假设的成立为前提的：非冗余性、稳定性（组织中最经常变化的是它的处理过程、应用和技术，如果依赖于这三个因素中的任何一个建立数据模型，当它们发生改变时，肯定要对数据模型进行彻底修改）、一致性、灵活性

关系数据模型优点：已被证明是可靠的、简单的数据建模方法。应用其规范化规则，将产生一个稳定的、一致的数据模型。该模型支持由组织制定的政策和约定的规则，同时为数据集市分析数据提供了更多的灵活性，使得数据库存储以及数据装载方面也是最有效的。

关系数据模型的缺点：需要额外建立数据集市的存储区，并增加相应的数据装载过程。另外，对数据仓库的使用强烈依赖于对SQL语言的掌握程度。

2.2　维度数据模型

维度数据模型简称维度模型（Dimensional modeling, DM），是一套技术和概念的集合，用于数据仓库设计。根据数据仓库大师Kimball的观点，维度模型是一种趋向于支持最终用户对数据仓库进行查询的设计技术，是围绕性能和易理解性构建的。

事实和维度是两个维度模型中的核心概念。事实表示对业务数据的度量，而维度是观察数据的角度。事实通常是数字类型的，可以进行聚合和计算，而维度通常是一组层次关系或描述信息，用来定义事实。

2.2.1　维度数据模型建模过程

一般使用下面的过程构建维度模型：

• 选择业务流程：确认哪些业务处理流程是数据仓库应该覆盖的，是维度方法的基础。
• 声明粒度：在一个事实所对应的所有维度设计中强制实行粒度一致性是保证数据仓库应用性能和易用性的关键。从给定的业务流程获取数据时，原始粒度是最低级别的粒度。建议从原始粒度数据开始设计，因为原始记录能够满足无法预期的用户查询。汇总后的数据粒度对优化查询性能很重要，但这样的粒度往往不能满足对细节数据的查询需求。
• 确认维度：维度表是事实表的基础，也说明了事实表的数据是从哪里采集来的。
• 确认事实：大部分事实表的度量都是数字类型的，可累加，可计算，如成本、数量、金额等。

2.2.2　维度规范化

与关系模型类似，维度也可以进行规范化。对维度的规范化（又叫雪花化），可以去除冗余属性，是对非规范化维度做的规范化处理，在下面介绍雪花模型时，会看到维度规范化的例子。一个非规范化维度对应一个维度表，规范化后，一个维度会对应多个维度表，维度被严格地以子维度的形式连接在一起。实际上，在很多情况下，维度规范化后的结构等同于一个低范式级别的关系型结构。

2.2.3　维度数据模型的特点

（1）易理解。相对于规范化的关系模型，维度模型容易理解且更直观。在维度模型中，信息按业务种类或维度进行分组，这会提高信息的可读性，也方便了对于数据含义的解释。简化的模型也让系统以更为高效的方式访问数据库。关系模型中，数据被分布到多个离散的实体中，对于一个简单的业务流程，可能需要很多表联合在一起才能表示。

（2）高性能。维度模型更倾向于非规范化，因为这样可以优化查询的性能。介绍关系模型时多次提到，规范化的实质是减少数据冗余，以优化事务处理或数据更新的性能。

（3）可扩展。维度模型是可扩展的。由于维度模型允许数据冗余，因此当向一个维度表或事实表中添加字段时，不会像关系模型那样产生巨大的影响，带来的结果就是更容易容纳不可预料的新增数据。

2.2.4　星型模式

星型模式由事实表和维度表组成，一个星型模式中可以有一个或多个事实表，每个事实表引用任意数量的维度表。

**星型模式将业务流程分为事实和维度。事实包含业务的度量，是定量的数据，如销售价格、销售数量、距离、速度、重量等是事实。维度是对事实数据属性的描述，如日期、产品、客户、地理位置等是维度。**可以简化对维度表的维护，但查询数据时会有更多的表连接，严重时会使模型难于使用，因此在设计中应该尽量避免。

1．事实表

事实表记录了特定事件的数字化的考量，一般由数字值和指向维度表的外键组成。通常会把事实表的粒度级别设计得比较低，使得事实表可以记录很原始的操作型事件，但这样做的负面影响是累加大量记录可能会更耗时。事实表有以下三种类型：

• 事务事实表。记录特定事件的事实，如销售。
• 快照事实表。记录给定时间点的事实，如月底账户余额。
• 累积事实表。记录给定时间点的聚合事实，如当月的总的销售金额。一般需要给事实表设计一个代理键作为每行记录的唯一标识。代理键是由系统生成的主键，它不是应用数据，没有业务含义，对用户来说是透明的。

2．维度表

维度表的记录数通常比事实表少，但每条记录包含有大量用于描述事实数据的属性字段。维度表可以定义各种各样的特性，以下是几种最长用的维度表：

• 时间维度表。描述星型模式中记录的事件所发生的时间，具有所需的最低级别的时间粒度。数据仓库是随时间变化的数据集合，需要记录数据的历史，因此每个数据仓库都需要一个时间维度表。
• 地理维度表。描述位置信息的数据，如国家、省份、城市、区县、邮编等。
  产品维度表。描述产品及其属性。
• 人员维度表。描述人员相关的信息，如销售人员、市场人员、开发人员等。
• 范围维度表。描述分段数据的信息，如高级、中级、低级等。
  通常给维度表设计一个单列、整型数字类型的代理键，映射业务数据中的主键。业务系统中的主键本身可能是自然键，也可能是代理键。

3．优点

星型模式是非规范化的，在星型模式的设计开发过程中，不受应用于事务型关系数据库的范式规则的约束。星型模式的优点如下：

• 简化查询。查询数据时，星型模式的连接逻辑比较简单，而从高度规范化的事务模型查询数据时，往往需要更多的表连接。
• 简化业务报表逻辑。与高度规范化的模式相比，由于查询更简单，因此星型模式简化了普通的业务报表（如每月报表）逻辑。
• 获得查询性能。星型模式可以提升只读报表类应用的性能。
• 快速聚合。基于星型模式的简单查询能够提高聚合操作的性能。
• 便于向立方体提供数据。星型模式被广泛用于高效地建立OLAP立方体，几乎所有的OLAP系统都提供ROLAP模型（关系型OLAP），它可以直接将星型模式中的数据当作数据源，而不用单独建立立方体结构。

4．缺点
星型模式的主要缺点是不能保证数据完整性。一次性地插入或更新操作可能会造成数据异常，而这种情况在规范化模型中是可以避免的。星型模式的数据装载，一般都是以高度受控的方式，用批处理或准实时过程执行的，以此来抵消数据保护方面的不足。

星型模式的另一个缺点是对于分析需求来说不够灵活。它更偏重于为特定目的建造数据视图，因此实际上很难进行全面的数据分析。星型模式不能自然地支持业务实体的多对多关系，需要在维度表和事实表之间建立额外的桥接表。

2.2.5　雪花模式

所谓的“雪花化”就是将星型模式中的维度表进行规范化处理。当所有的维度表完成规范化后，就形成了以事实表为中心的雪花型结构，即雪花模式。**将维度表进行规范化的具体做法是，把低基数的属性从维度表中移除并形成单独的表。**基数指的是一个字段中不同值的个数，如主键列具有唯一值，所以有最高的基数，而像性别这样的列基数就很低。

在雪花模式中，一个维度被规范化成多个关联的表，而在星型模式中，每个维度由一个单一的维度表所表示。一个规范化的维度对应一组具有层次关系的维度表，而事实表作为雪花模式里的子表，存在具有层次关系的多个父表。

星型模式和雪花模式都是建立维度数据仓库或数据集市的常用方式，适用于加快查询速度比高效维护数据的重要性更高的场景。这些模式中的表没有特别的规范化，一般都被设计成一个低于第三范式的级别。

1．数据规范化与存储

规范化的过程就是将维度表中重复的组分离成一个新表，以减少数据冗余的过程。正因为如此，规范化不可避免地增加了表的数量。但是规范化减少了存储数据的空间需求，而且提高了数据更新的效率。

2．优点

雪花模式是和星型模式类似的逻辑模型。实际上，星型模式是雪花模式的一个特例（维度没有多个层级）。某些条件下，雪花模式更具优势：

• 一些OLAP多维数据库建模工具专为雪花模型进行了优化。
• 规范化的维度属性节省存储空间。

3．缺点

雪花模型的主要缺点是维度属性规范化增加了查询的连接操作和复杂度。相对于平面化的单表维度，多表连接的查询性能会有所下降。但雪花模型的查询性能问题近年来随着数据浏览工具的不断优化而得到缓解。

和具有更高规范化级别的事务型模式相比，雪花模式并不确保数据完整性。向雪花模式的表中装载数据时，一定要有严格的控制和管理，避免数据的异常插入或更新。

2.3　Data Vault模型

2.3.1　Data Vault模型简介
2.3.2　Data Vault模型的组成部分
2.3.3　Data Vault模型的特点
2.3.4　Data Vault模型的构建
2.3.5　Data Vault模型实例

2.4　数据集市

2.4.1　数据集市的概念

数据集市是数据仓库的一种简单形式，通常由组织内的业务部门自己建立和控制。一个数据集市面向单一主题域，如销售、财务、市场等。数据集市的数据源可以是操作型系统（独立数据集市），也可以是企业级数据仓库（从属数据集市）

2.4.2　数据集市与数据仓库的区别

2.4.3　数据集市设计

数据集市主要用于部门级别的分析型应用，数据大都是经过了汇总和聚合操作，粒度级别较高。数据集市一般采用维度模型设计方法，数据结构使用星型模式或雪花模式。

2.5　数据仓库实施步骤

实施一个数据仓库项目的主要步骤是：定义项目范围、收集并确认业务需求和技术需求、逻辑设计、物理设计、从源系统向数据仓库装载数据、使数据可以被访问以辅助决策、管理和维护数据仓库。

2.6　小结

（1）关系模型、多维模型和Data Vault模型是三种常见的数据仓库模型。
（2）数据结构、完整性约束和SQL语言是关系模型的三个要素。
（3）规范化是通过应用范式规则实现的。第一范式（1NF）要求保持数据的原子性、第二范式（2NF）消除了部分依赖、第三范式（3NF）消除了传递依赖。关系模型的数据仓库一般要求满足3NF。
（4）事实、维度、粒度是维度模型的三个核心概念。
（5）维度模型的四步设计法是选择业务流程、声明粒度、确定维度、确定事实。
（6）星型模式和雪花模式是维度模型的两种逻辑表示。对星型模式进一步规范化，就形成了雪花模式。
（7）Data Vault模型有中心表（Hub）、链接表（Link）、附属表（Satellite）三个主要组成部分。中心表记录业务主键，链接表记录业务关系，附属表记录业务描述。
（8）Data Vault不区分数据在业务层面的正确与错误，它保留操作型系统的所有时间的所有数据，装载数据时不做数据验证、清洗等工作。
（9）数据集市是部门级的、面向单一主题域的数据仓库。
（10）数据集市的复杂度和需要处理的数据都小于数据仓库，因此更容易建立与维护。
（11）实施一个数据仓库项目的主要步骤是：定义范围、确认需求、逻辑设计、物理设计、装载数据、访问数据、管理维护。