基于Hadoop生态圈的数据仓库实践 —— 概述（一）

     一种被广泛接受的数据仓库定义是Bill Inmon在1991年出版的《Building the Data Warehouse》一书中所提出的 —— 数据仓库是一个面向主题的、集成的、随时间变化的、非易失的数据集合，用于支持决策。它主要的目标是分析和处理数据，和传统的操作型事务处理有很大区别。

     操作型系统完成组织的核心业务，例如下订单、更新库存、记录支付信息等等。这些系统是事务型的，核心目标是尽可能快地处理事务，同时维护数据的准确性。而象数据仓库这样的分析型系统，是通过数据分析来评估企业的经营效益。操作型系统和分析型系统的差异比较如下表所示：

     数据仓库的数据源一般来自操作型系统，也就是说，必须在某个时点从操作型系统获取数据并将其导入数据仓库，这个过程就是通常所说的抽取（extract）、转换（transform）和装载（load）过程，简称ETL过程。

     之所以不直接在操作型系统上执行分析查询，而是从操作型系统抽取数据，最主要有以下两个原因：（1）在操作型系统上直接执行分析查询会使业务系统受到影响，很可能使其变慢甚至宕机。（2）在操作型系统中很可能查不到分析所需要的数据。出于性能的考虑，操作型系统一般都不会保留很长的历史记录，而只是保留近期活跃的数据，但数据仓库中理论上应该保留所有决策需要的数据，即除了活跃数据外，还应该包含大量的历史归档数据。

     转换是保证数据仓库数据一致和性能优良的关键步骤。操作型数据大多是分散在多个业务系统之中，彼此间缺乏联系，同一数据在系统间还可能存在二义性，很难成为对于整个企业一致的数据视图。对数据仓库的操作具有典型的大数据量、低并发、绝大多数是读操作特点。基于以上两个原因，从操作型系统抽取来的原始数据要经过一些列的数据清洗、加工和转换，使其成为一致的便于查询和使用的格式。这些转换包括数据类型转换、日期时间标准化、把规范化模式逆规范化为星型模式等等。

     装载操作实际上就是把转换后的数据导入到数据仓库的表中，给下游的数据集市、OLAP系统或BI系统准备好可供查询的数据。

     通过数据仓库，既可以周期性地回答已知的问题（如报表等），也可以进行即席查询（ad-hoc queries）。报表最基本的需求就是对预定义好的一系列查询条件、查询内容，排序条件等进行组合，查询数据，把结果用表格或图形的形式展现出来。而所谓的即席查询不是预定义好的，而是在执行时才确定的。换句话说，即席查询是指那些用户在使用系统时，根据自己当时的需求定义的查询。为了满足这些查询需求，需要数据仓库中的数据确保准确性、时效性和历史可追溯性。

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

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

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

     数据仓库主要有规范化数据模型、多维数据模型、Data Vault数据模型等建模方法，其中前两种使用最为广泛。规范化模型用于企业级数据仓库（EDW）建模，而多维模型多用于数据集市建模。规范化模型对于数据库设计者来说非常熟悉，其核心思想就是消除数据冗余以保证数据一致性和事务处理的性能。通常业务数据库、OLTP系统都采用规范化模型，其中常见的有1NF、2NF和3NF。简单地说，1NF就是消除重复元组，并保持列的原子性，具体到数据库设计上就是每个表都要有一个主键来唯一标识一行记录。2NF就是在1NF的基础上消除了部分依赖，即非键属性必须完全依赖于主键。3NF在2NF基础上消除了传递依赖，即非键属性只能完全依赖于主键。一般数据库设计需要满足3NF。而对于多维模型最简单的描述是，按照事实表、维度表来构建数据仓库或数据集市，这种模型被人们熟知的有星型和雪花型。

     星型模型是部署在关系数据库管理系统之上的多维结构，主要包含事实表，以及通过主键/外键关系与之关联的维度表。在星型模型实施中，所有维度级别的数据存储在单个表或视图中。雪花模型就是将维度层次进一步规范化为子维度。在雪花模型实施中，使用多个表或视图来存储维度级别数据。单独的数据库表或视图存储与维中每个级别相关的数据。

     看一下星型模型的定义，那么问题来了：既然事实表与维度表也是以主键/外键的方式相互关联，换句话说，3NF和维度模型都能用实体/关系图（ERD）表示，那么两者的根本区别是什么呢？答案就是：3NF的本质是消除数据冗余，那么维度模型与其根本区别就是数据冗余程度不同。随着规范化程度的提高，必然会使得表和表之间的关系越来越多。而维度模型虽然常应用在关系数据库管理系统之上，但是并不要求必须满足3NF，也就是说维度模型允许可控的数据冗余。这样做简少了表和表间关系的数量，从而提高了查询速度。下面引用《数据仓库设计》书中的一个例子，进一步说明3NF与多维模型的差异。

    如上图所示，左边是一个销售订单的典型的规范化表示。订单（Order）实体描述有关订单整体的信息，订单明细（Order Line）实体描述有关订单项的信息，两个实体都包含描述其订单状态的信息。右边是一个订单状态维（Order Status Dimension），该维描述订单和订单明细中对应的状态编码值的唯一组合。它包括在规范化设计的订单和订单明细实体中都出现的属性。当销售订单事实行被装载时，参照在订单状态维中的适合的状态编码的组合设置它的外键。