数据仓库

数据库与数据仓库的区别

简而言之，数据库是面向事务的设计，数据仓库是面向主题设计的。

数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。

数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有意引入冗余，采用反范式的方式来设计。

数据库是为捕获数据而设计，数据仓库是为分析数据而设计，它的两个基本的元素是维表和事实表。维是看问题的角度，比如时间，部门，维表放的就是这些东西的定义，事实表里放着要查询的数据，同时有维的ID。

单从概念上讲，有些晦涩。任何技术都是为应用服务的，结合应用可以很容易地理解。以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记帐。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存款又多，消费交易又多，那么该地区就有必要设立ATM了。

显然，银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。

数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。那么，数据仓库与传统数据库比较，有哪些不同呢?让我们先看看W.H.Inmon关于数据仓库的定义:面向主题的、集成的、与时间相关且不可修改的数据集合。

“面向主题的”:传统数据库主要是为应用程序进行数据处理，未必按照同一主题存储数据;数据仓库侧重于数据分析工作，是按照主题存储的。这一点，类似于传统农贸市场与超市的区别—市场里面，白菜、萝卜、香菜会在一个摊位上，如果它们是一个小贩卖的;而超市里，白菜、萝卜、香菜则各自一块。也就是说，市场里的菜(数据)是按照小贩(应用程序)归堆(存储)的，超市里面则是按照菜的类型(同主题)归堆的。

“与时间相关”:数据库保存信息的时候，并不强调一定有时间信息。数据仓库则不同，出于决策的需要，数据仓库中的数据都要标明时间属性。决策中，时间属性很重要。同样都是累计购买过九车产品的顾客，一位是最近三个月购买九车，一位是最近一年从未买过，这对于决策者意义是不同的。

“不可修改”:数据仓库中的数据并不是最新的，而是来源于其它数据源。数据仓库反映的是历史信息，并不是很多数据库处理的那种日常事务数据(有的数据库例如电信计费数据库甚至处理实时信息)。因此，数据仓库中的数据是极少或根本不修改的;当然，向数据仓库添加数据是允许的。

数据仓库的出现，并不是要取代数据库。目前，大部分数据仓库还是用关系数据库管理系统来管理的。可以说，数据库、数据仓库相辅相成、各有千秋。

补充一下，数据仓库的方案建设的目的，是为前端查询和分析作为基础，由于有较大的冗余，所以需要的存储也较大。为了更好地为前端应用服务，数据仓库必须有如下几点优点，否则是失败的数据仓库方案。

1.效率足够高。客户要求的分析数据一般分为日、周、月、季、年等，可以看出，日为周期的数据要求的效率最高，要求24小时甚至12小时内，客户能看到昨天的数据分析。由于有的企业每日的数据量很大，设计不好的数据仓库经常会出问题，延迟1-3日才能给出数据，显然不行的。

2.数据质量。客户要看各种信息，肯定要准确的数据，但由于数据仓库流程至少分为3步，2次ETL，复杂的架构会更多层次，那么由于数据源有脏数据或者代码不严谨，都可以导致数据失真，客户看到错误的信息就可能导致分析出错误的决策，造成损失，而不是效益。

3.扩展性。之所以有的大型数据仓库系统架构设计复杂，是因为考虑到了未来3-5年的扩展性，这样的话，客户不用太快花钱去重建数据仓库系统，就能很稳定运行。主要体现在数据建模的合理性，数据仓库方案中多出一些中间层，使海量数据流有足够的缓冲，不至于数据量大很多，就运行不起来了。

数据仓库组成

数据处理平台：接口+工具

ETL是数据抽取（Extract）、清洗（Cleaning）、转换（Transform）、装载（Load）的过程。是构建数据仓库的重要一环，用户从数据源抽取出所需的数据，经过数据清洗,最终按照预先定义好的数据仓库模型，将数据加载到数据仓库中去。

3.5.1 数据源分析
数据源是数据仓库系统所有信息的源头，主要是操作型业务应用系统存放的数据集合。数据源分析是指对业务数据源中的原始数据进行分析，得到数据的范围、格式，以及其更新方式、更新频率、质量等方面的信息。商业智能系统本身就是一个数据分析的系统，对数据源的分析是开启商业智能项目大门的过程，数据仓库系统需要支持多种数据源格式，为了确定抽取方式，需要对数据源进行详细的分析。
在分析的过程中，需要确定业务源数据中哪些数据需要被抽取。为了确定合适的抽取方式，需要在抽取之前对数据源进行分析，分析的范围一般包括数据的格式、数据的范围、更新的方式、数据质量的好坏。在分析的过程中，应该尽可能获取分析的结果，形成数据源分析报告，在仔细研究分析报告后，再选择合适的抽取、加载方式。
在分析时，应该抛弃实际的应用系统，在逻辑上重新确定目标表中需要哪些业务数据，然后再根据业务系统的实现方式，分析业务源数据的存储格式、更新频率、更新方式和数据质量。
可以得出这样的结论：所谓数据源分析，就是对源数据进行分析和总结，得出源数据的范围、格式、更新方式、更新频率和质量好坏的过程。
数据源分析的过程分为范围分析、格式分析、更新方式分析、质量分析4个方面，如图3-13所示。

1）范围分析是指分析数据的范围。用户需要确定数据仓库系统需要数据源中的哪些原始数据。例如，在某电力行业的销售电量分析主题中，所有的数据均来自某管理信息系统，由此可以确定，这个销售电量分析主题的数据源都来自该管理信息系统，可能是与这个管理系统中的客户相关的数据，或者与电量相关的数据。而与财务数据或用户欠费相关的业务数据不相关。
2）格式分析是指对原始数据在数据库中的物理存储方式进行分析。内容包括在数据库中的存储类型、存储长度、数据精度等指标。
3）更新方式分析是指对原始数据在应用系统中的更新方式、更新频率、更新内容进行分析判断。内容包括原始数据何时更新、更新方式、具体更新哪些内容等。例如，在某销售电量主题分析中，需要考虑用户的抄表数据和电量数据，一般都是每月增量更新的，而用户的档案信息也有可能进行更新，用户的欠费信息也随着用户的缴费行为而随时发生相应的变化。
4）质量分析是指分析业务源数据的质量。主要分析数据完整性、数据准确性、数据一致性等内容。一般步骤包括：设计数据质量定义文档，内容包括数据质量验收的依据，数据质量等级的划分，数据质量检查的流程等内容；再根据数据质量定义文档进行数据质量检查，最终形成质量报告；根据数据质量报告进行深入分析，将分析结果提交给相关人员，协助设计人员完成数据清洗规则的制定。通常，质量分析是数据源分析中最重要、工作量最多的部分。
总结：除以上所述的对数据源进行分析外，还需要对各项指标数据的确切含义，统计口径等信息进行明确的界定，以避免产生二义性。例如，在销售电量主题分析中，需要明确销售电量的确切含义，是否包含线损电量、变损电量等。

元数据;
什么是元数据
任何文件系统中的数据分为数据和元数据。数据是指普通文件中的实际数据，而元数据指用来描述一个文件的特征的系统数据，诸如访问权限、文件拥有者以及文件\数据块的分布信息(inode…)等等。在集群文件系统中，分布信息包括文件在磁盘上的位置以及磁盘在集群中的位置。用户需要操作一个文件必须首先得到它的元数据，才能定位到文件的位置并且得到文件的内容或相关属性。

元数据管理方式
元数据管理有两种方式。集中式管理和分布式管理。集中式管理是指在系统中有一个节点专门司职元数据管理，所有元数据都存储在该节点的存储设备上。所有客户端对文件的请求前，都要先对该元数据管理器请求元数据。分布式管理是指将元数据存放在系统的任意节点并且能动态的迁移。对元数据管理的职责也分布到各个不同的节点上。大多数集群文件系统都采用集中式的元数据管理。因为集中式管理实现简单，一致性维护容易，在一定的操作频繁度内可以提供较满意的性能。缺点是单一失效点问题，若该服务器失效，整个系统将无法正常工作。而且，当对元数据的操作过于频繁时，集中的元数据管理成为整个系统的性能瓶颈。
分布式元数据管理的好处是解决了集中式管理的单一失效点问题， 而且性能不会随着操作频繁而出现瓶颈。其缺点是，实现复杂，一致性维护复杂，对性能有一定影响。
一、基本概念

数据仓库一词尚没有一个统一的定义,著名的数据仓库专家W. H. Inmon 在其著作《Buildingthe Data Warehouse》一书中给予如下描述:数据仓库(Data Warehouse) 是一个面向主题的(SubjectOri2ented) 、集成的( Integrate ) 、相对稳定的(Non -Volatile ) 、反映历史变化( TimeVariant) 的数据集合用于支持管理决策。对于数据仓库的概念我们可以从两个层次予以理解,首先,数据仓库用于支持决策,面向分析型数据处理,它不同于企业现有的操作型数据库;其次,数据仓库是对多个异构的数据源有效集成,集成后按照主题进行了重组,并包含历史数据,而且存放在数据仓库中的数据一般不再修改。

为最大限度地实现灵活性，集成的数据仓库的数据应该存储在标准RDBMS 中，并经过规范的数据库设计，以及为了提高性能而增加一些小结性信息和不规范设计。这种类型的数据仓库设计被称为原子数据仓库。原子数据仓库的子集,又称为数据集市。原子仓库存在的主要目的是作为数据集市的工作基础，同时也作为参照性数据仓库。原子仓库的大小、集中存放和数据库设计可能无法满足特殊类型用户的各种需求。其子集,即各个数据集市被拷贝到其它计算机上,可作为它们自己的数据仓库。数据集市可以和产生它们的原子数据仓库一样大,甚至更大。它们可以位于原子数据仓库的附近，或分布到更靠近用户的位置，放置在何处取决于使用和通讯成本。数据集市是用来满足特殊用户的应用需求的数据仓库，它们的规模可能达到数百GB。使其成为数据集市的关键是它的使用目标、范围，而非规模大小。
数据集市可以理解为是一个小型的部门或者工作组级别的数据仓库。有两种类型的数据集市（如下图）：

独立型（直接从操作型环境中获取数据）：这些数据集市是由特定的工作组、部门或业务线进行控制的，完全是为满足其需求而构建的。实际上，它们甚至与其他工作组、部门或业务线中的数据集市没有任何连通性
从属型（从企业级数据仓库中获取数据）：这样的数据集市往往以分布式的方式实现。虽然不同的数据集市是在特定的工作组、部门或生产线中实现的，但它们可以是集成、互连的，以提供更加全局的业务范围的数据视图。实际上，在最高的集成层次上，它们可以成为业务范围的数据仓库。这意味着一个部门中的终端用户可以访问和使用另一部门中数据集市中的数据

二、为什么提出数据集市

虽然 OLTP 和遗留系统拥有宝贵的信息，但是可能难以从这些系统中提取有意义的信息并且速度也较慢。而且这些系统虽然一般可支持预先定义操作的报表，但却经常无法支持一个组织对于历史的、联合的、智能的或易于访问的信息的需求。因为数据分布在许多跨系统和平台的表中，而且通常是“脏的”，包含了不一致的和无效的值，使得难于分析。

数据集市将合并不同系统的数据源来满足业务信息需求。若能有效地得以实现，数据集市将可以快速且方便地访问简单信息以及系统的和历史的视图。一个设计良好的数据集市有如下特点（有些特点数据仓库也具有，有些特点是相对于数据仓库来讲的）：
(1) 特定用户群体所需的信息，通常是一个部门或者一个特定组织的用户，且无需受制于源系统的大量需求和操作性危机（想对于数据仓库）。
(2) 支持访问非易变（nonvolatile）的业务信息。（非易变的信息是以预定的时间间隔进行更新的，并且不受 OLTP 系统进行中的更新的影响。）
(3) 调和来自于组织里多个运行系统的信息，比如账目、销售、库存和客户管理以及组织外部的行业数据。
(4) 通过默认有效值、使各系统的值保持一致以及添加描述以使隐含代码有意义，从而提供净化的（cleansed）数据。
(5) 为即席分析和预定义报表提供合理的查询响应时间（由于数据集市是部门级的，相对于庞大的数据仓库来讲，其查询和分析的响应时间会大大缩短）。

三、数据仓库设计方法论

在数据仓库建立之前，会考虑其实现方法，通常有自顶向下、自底向上和两者综合进行的这样三种实现方案，下面分别对其做简要阐述：

(1)自顶向下的实现
自顶向下的方法就是在单个项目阶段中实现数据仓库。自顶向下的实现需要在项目开始时完成更多计划和设计工作。这就需要涉及参与数据仓库实现的每个工作组、部门或业务线中的人员。要使用的数据源、安全性、数据结构、数据质量、数据标准和整个数据模型的有关决策一般需要在真正的实现开始之前就完成。

(2)自底向上的实现
自底向上的实现包含数据仓库的计划和设计，无需等待安置好更大业务范围的数据仓库设计。这并不意味着不会开发更大业务范围的数据仓库设计；随着初始数据仓库实现的扩展，将逐渐增加对它的构建。现在，该方法得到了比自顶向下方法更广泛的接受，因为数据仓库的直接结果可以实现，并可以用作扩展更大业务范围实现的证明。

(3)一种折中方案
每种实现方法都有利弊。在许多情况下，最好的方法可能是某两种的组合。该方法的关键之一就是确定业务范围的架构需要用于支持集成的计划和设计的程度，因为数据仓库是用自底向上的方法进行构建。在使用自底向上或阶段性数据仓库项目模型来构建业务范围架构中的一系列数据集市时，您可以一个接一个地集成不同业务主题领域中的数据集市，从而形成设计良好的业务数据仓库。这样的方法可以极好地适用于业务。在这种方法中，可以把数据集市理解为整个数据仓库系统的逻辑子集，换句话说数据仓库就是一致化了的数据集市的集合。这种方案的实施步骤通常分如下几步：
(6) 从整个企业的角度定义计划和需求
(7) 构建完整的仓库体系结构
(8) 使数据内容一致而且标准化
(9) 将数据仓库作为一种超级数据集市来实施

关于Inmon 和 Kimball的大辩论：
Ralph Kimball 和 Bill Inmon 一直是商业智能领域中的革新者，开发并测试了新的技术和体系结构。
Bill Inmon 将数据仓库定义为“一个面向主题的、集成的、随时间变化的、非易变的用于支持管理的决策过程的数据集合”；他通过“面向主题”表示应该围绕主题来组织数据仓库中的数据，例如客户、销售、产品等等。每个主题区域仅仅包含该主题相关的信息。数据仓库应该一次增加一个主题，并且当需要容易地访问多个主题时，应该创建以数据仓库为来源的数据集市。换言之，某个特定数据集市中的所有数据都应该来自于面向主题的数据存储。 Inmon 的方法包含了更多上述工作而减少了对于信息的初始访问。但他认为这个集中式的体系结构持续下去将提供更强的一致性和灵活性，并且从长远来看将真正节省资源和工作。下图是他的设计方法图解：

Ralph Kimball 说“数据仓库仅仅是构成它的数据集市的联合”，他认为“可以通过一系列维数相同的数据集市递增地构建数据仓库”。每个数据集市将联合多个数据源来满足特定的业务需求。通过使用“一致的”维，能够共同看到不同数据集市中的信息，这表示它们拥有公共定义的元素。设计方法如下图：

Kimball 的方法将提供集成的数据来回答组织迫切的业务问题并且要快于 Inmon 的方法。Inmon 的方法是只有在构建几个单主题区域之后，集中式的数据仓库才创建数据集市。而 Kimball 认为该方法缺乏灵活性并且在现在的商业环境中所花时间太长。
实际上，方法的选择取决于项目的主要商业驱动。如果该组织正忍受糟糕的数据管理和不一致的数据，或者希望为今后打下良好的基础，那么 Inmon 的方法就更好一些。 如果该组织迫切需要给用户提供信息，那么 Kimball 的方法将满足该需求。而一旦满足了迫切的信息需求后，就应该考虑包含独立数据仓库的数据体系结构的转换计划。数据仓库将使数据集市与遗留系统和 OLTP 系统隔离，并且支持更快地创建将来的数据集市。由于数据仓库在整个发展中一直承担了重任，所以它将支持极力关注数据集市。实际上基于商业驱动的需要，采用上面三种设计方案中的最后一种方法：自顶向下和自底向上综合的方案会很好的适应数据仓库建立过程中的不同需求。

四、数据仓库与数据集市的区别

数据仓库是企业级的，能为整个企业各个部门的运行提供决策支持手段；而数据集市则是一种微型的数据仓库,它通常有更少的数据,更少的主题区域,以及更少的历史数据,因此是部门级的，一般只能为某个局部范围内的管理人员服务，因此也称之为部门级数据仓库。数据仓库和数据集市之间的区别如下图：

数据仓库和数据集市的区别可从如下三个方面进行理解：
（1） 数据仓库向各个数据集市提供数据
（2） 几个部门的数据集市组成一个数据仓库

（3） 下面从其数据内容特征进行分析，数据仓库中数据结构采用规范化模式，数据集市中的数据结构采用星型模式，通常仓库中数据粒度比集市的粒度要细，下图反映了数据结构和数据内容特征的区别

星形模型PK雪花形模型:

一、概述
在多维分析的商业智能解决方案中，根据事实表和维度表的关系，又可将常见的模型分为星型模型和雪花型模型。在设计逻辑型数据的模型的时候，就应考虑数据是按照星型模型还是雪花型模型进行组织。
当所有维表都直接连接到“ 事实表”上时，整个图解就像星星一样，故将该模型称为星型模型，如图 1 。
星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余，如在地域维度表中，存在国家 A 省 B 的城市 C 以及国家 A 省 B 的城市 D 两条记录，那么国家 A 和省 B 的信息分别存储了两次，即存在冗余。
图1. 销售数据仓库中的星型模型
当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 ” 层次 ” 区域，这些被分解的表都连接到主维度表而不是事实表。如图 2，将地域维表又分解为国家，省份，城市等维表。它的优点是 : 通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗余。

星型模型因为数据的冗余所以很多统计查询不需要做外部的连接，因此一般情况下效率比雪花型模型要高。星型结构不用考虑很多正规化的因素，设计与实现都比较简单。雪花型模型由于去除了冗余，有些统计就需要通过表的联接才能产生，所以效率不一定有星型模型高。正规化也是一种比较复杂的过程，相应的数据库结构设计、数据的 ETL、以及后期的维护都要复杂一些。因此在冗余可以接受的前提下，实际运用中星型模型使用更多，也更有效率。
二、使用选择
星形模型(Star Schema)和雪花模型(Snowflake Schema)是数据仓库中常用到的两种方式，而它们之间的对比要从四个角度来进行讨论。
　　1.数据优化
雪花模型使用的是规范化数据，也就是说数据在数据库内部是组织好的，以便消除冗余，因此它能够有效地减少数据量。通过引用完整性，其业务层级和维度都将存储在数据模型之中。

相比较而言，星形模型实用的是反规范化数据。在星形模型中，维度直接指的是事实表，业务层级不会通过维度之间的参照完整性来部署。

　2.业务模型
主键是一个单独的唯一键(数据属性)，为特殊数据所选择。在上面的例子中，Advertiser_ID就将是一个主键。外键(参考属性)仅仅是一个表中的字段，用来匹配其他维度表中的主键。在我们所引用的例子中，Advertiser_ID将是Account_dimension的一个外键。
在雪花模型中，数据模型的业务层级是由一个不同维度表主键-外键的关系来代表的。而在星形模型中，所有必要的维度表在事实表中都只拥有外键。
　　3.性能
第三个区别在于性能的不同。雪花模型在维度表、事实表之间的连接很多，因此性能方面会比较低。举个例子，如果你想要知道Advertiser 的详细信息，雪花模型就会请求许多信息，比如Advertiser Name、ID以及那些广告主和客户表的地址需要连接起来，然后再与事实表连接。
而星形模型的连接就少的多，在这个模型中，如果你需要上述信息，你只要将Advertiser的维度表和事实表连接即可。
　　4.ETL
雪花模型加载数据集市，因此ETL操作在设计上更加复杂，而且由于附属模型的限制，不能并行化。
星形模型加载维度表，不需要再维度之间添加附属模型，因此ETL就相对简单，而且可以实现高度的并行化。
　　总结
雪花模型使得维度分析更加容易，比如“针对特定的广告主，有哪些客户或者公司是在线的?”星形模型用来做指标分析更适合，比如“给定的一个客户他们的收入是多少?”