加载中…
个人资料
yfx416
yfx416
  • 博客等级:
  • 博客积分:0
  • 博客访问:103,799
  • 关注人气:75
  • 获赠金笔:0支
  • 赠出金笔:0支
  • 荣誉徽章:
相关博文
推荐博文
谁看过这篇博文
加载中…
正文 字体大小:

数据仓库基本概念

(2011-11-14 00:01:39)
标签:

数据挖掘

数据仓库

olap

分类: 数据挖掘

前言:以下是以前读《Data Mining: Concepts and Techniques 2nd edition》时,当时对第二章边看边写了一个笔记索引。今天有空整理了一下,可能有助于建立一些数据仓库的正确概念,其实本篇博文没什么价值,英文不太差的直接读原版好了,这个只是便于自己查阅。韩老师的这本书写得非常好,第一版好像有一个中文版本,但第二版国内好像没有中文翻译。从韩老师的个人主页上来看,第三版今年好像也出版了。也许我可以考虑翻译一下这本书?(呵呵,玩笑)

什么是数据仓库

数据仓库为商业决策提供了架构和工具。泛泛而言,数据仓库的核心实际上就是一个数据库,这个数据库是和日常的操作数据库分离的。数据仓库集成了各种各样的应用系统,能够对历史数据进行分析。

数据仓库的严格定义如下:

数据仓库是一个面向主题的,集成的,时变的,持久化的数据集合,能够支持管理决策。

其中有4个关键字:面向主题,集成的,时变的,持久的。我们进一步来看看这4个特性具体指的是什么:

面向主题:数据仓库是围绕组织机构的主要主题来组织的,比如客户啊,供应商啊,产品啊

,销售啊等等。数据仓库并不关注组织机构每天的日常操作和事务处理,而是只关注在对那些对决策者有意义的数据的建模和分析上。因此,数据仓库是面向特定主题的,这些主题是有意义的,而并非对所有的主题都关注。

集成:一个数据仓库集成了很多异构的数据源,这些异构的数据源包括关系数据库,文件,在线的事务记录等等。通过应用数据清理和数据集成技术确保了数据仓库在命名约定,编码结构和属性测量等方面的一致性。

时变的:数据仓库是从历史的角度来看待数据,因此数据仓库中的数据都或显式或隐式得包含了时间的要素。

持久的:数据仓库里的数据在物理上是和组织机构的日常操作数据分开的,但它是从其中转化而来的。由于这种分离,数据仓库不需要事务处理,故障恢复,并发控制等机制。它只需要两类操作:数据仓库初始化装载和数据访问。

从数据源集成的角度来看,数据仓库的数据源集成方式分为两类:查询驱动的方法和更新驱动的方法。查询驱动的方法是比较传统的方法,它为这些异构的数据源进行了一个封装,建立了一个协调员,当用户的查询到达数据仓库时,先被送到这个协调员,协调员把用户的查询转换成对应的合适的数据库相应的查询,然后这些查询被映射到合适的数据源中去然后进行处理。

另一类的方法就是更新驱动的方法,就是把这些异构数据源的数据预先装载提取到数据仓库中去,然后用户的查询直接就可以在数据仓库中进行查询了。更新驱动的方法是主流。

日常的操作数据库系统和数据仓库是完全不同的,日常的操作数据库系统被称之为在线事务处理系统(OLTP),用来处理日常的操作事务。而数据仓库被称之为在线分析处理系统(OLAP)。他们的区别主要在这么几个方面:

用户:OLTP的用户是终端客户,机构的职员等等。而OLAP的目标用户是知识工人,包括管理者,分析员等等。

数据内容:OLTP管理的是当前的数据,非常得详细。OLAP管理的是大量的历史数据,在各种粒度上对他们进行归纳,综合,聚合等等。

视角:OLTP专注在企业或部门内的当前数据,不涉及横跨不同组织机构的历史数据。相反,OLAP则涉及横跨多个组织机构的不同的数据源,也涉及了组织机构的历史数据,它的尺寸比较大。

访问模式:OLTP的访问模式主要是原子事务操作,要考虑并发控制和数据恢复等等。而OLAP的访问主要是简单的只读操作。

OLAP一般采用的是更新驱动的方法,是和日常OLTP分离的,这样松耦合的架构能够提高各自系统的性能,并且 两者考虑的重点各有不同,一个要考虑并发,恢复,一个则不需要考虑这些,两者的结构,内容也是不同的,一起考虑难以兼顾。

然而现在,OLTP和OLAP有融合的趋势,有的OLTP也提供了OLAP查询方面的支持和优化。

多维数据模型

数据仓库的核心就是多维数据模型,它将数据视为一个数据立方体,它有一些维度。所谓维度,指的是就是一个组织机构想要记录的方面。比如说一个电子产品卖场的数据库,它记录了交易细节,这些记录对应着时间,商品类,机构分支和位置等维度。数据立方体的维度不只是3维的,有可能是多维的。数据立方体模型中包含两类表,一类表是事实表,事实表的主要属性就是一些统计量,比如电子商品卖场的例子中(本文中所有的例子都是针对这个例子的),交易金额,交易量等就是事实表中的主要属性,同时还通过外键链接了一些维度表。这些维度表就是另外一类表,维度表用来进一步描述维度的,比如位置维度表,包含名称,街道,省,国家,邮编等等进一步描述地址的属性。

画两个图,有助于建立数据立方体的直观映像,如下:

clip_image002

图3.1就是一个三维数据立方体的模型。

clip_image004

图3.2是一个4维的数据立方体模型。由上述两个图可以看出,一个n维的数据立方体可以视作一系列的n-1维数据立方体。另外还有一个概念称之为立方体格:给定一些维度,这些维度通过排列组合可以形成一系列可能的维度组合子集,该子集中的每一个元素就对应一个n维立方体,对应着对于给定维度的数据不同程度级别的归纳(好拗口)。画个图如下,一目了然。

clip_image006

多维数据模型在数据库中有3种存在形式:星形表(Star Schema),雪花表(Snowflake Schema),事实星座表(Fact Constellation Schema)。对应电子卖场的例子,三种形式如下:

Star Schema:

clip_image008

该形式包含两种表,一个大的事实表,每个维度对应着一个小的维度表。两种表通过外键连接起来。

Snowflake Schema:

clip_image010

一眼看过去,Star Schema和Snowflake Schema差不多,都是一个事实表,加一堆维度表。但区别在于Star Schema中的维度表是非范式化的,也就是维度表的数据有可能有冗余,比如location维度表,其中city,province_or_state,country三个属性就是非范式化的。怎么理解呢,知春路,中关村南路是两个位置,但他们都是在北京,在中国,因此在location表中知春路,中关村南路两条记录都会存放北京,中国这两个字段,这两者就冗余了,这就是非范式化。通过进一步对Star Schema中的维度表进行了范式化处理,就形成了Snowflake Schema。

Fact constellation Schema:

clip_image012

Fact constellation schema是基于star schema的,它与star schema的不同之处在于,它有多个事实表,这些事实表可以共享这些维度表,其它都和star schema是一样的。

OLAP中还有一个数据拍卖场的概念,数据拍卖场和数据仓库本身差不多,区别在于数据仓库是整个机构范围内的,它可以涉及整个机构范围内所有值得关心的主题。而数据拍卖场(data mart)是部分范围内的,设计的主题也只是经过选择的有限的主题。可以说,数据拍卖场是一个缩小版的数据仓库。

事实表中除了维度的外键之外,最核心的属性就是各种各样的针对数据立方体的统计方法产生的统计量。统计量分为3类:

分布式:所谓分布式的统计量,指的是如果我们能够将计算的对象-数据立方体分解成若干个子立方体,每个子立方体应用该统计方法得到一些子统计量,然后再对这些子统计量再应用该统计方法就能得到一个最终的统计量。这样的一种能够用分布式的方法来并行分解统计工作的统计量就称之为分布式统计量。比如count(),sum(),min(),max()等统计量就是分布式统计量。

代数式:这类统计量可以通过代数公式计算出来,代数公式中的变量可以通过分布式聚合函数获得。代数式的统计量的例子比如均值avg()=sum()/count(),比如方差。

整体性:这类统计量无法利用代数公式和分布式进行统计,反映的数据固有的属性,必须通过遍历所有数据才能获得,比如median(),mode()和rank()等。

维度具有一个概念层次,层次越高越抽象。如下图:

clip_image014

上图表示了两种不同的概念层级结构,a是一种直线的层级结构,而b是一个网格状的层级结构。概念层级可以为我们提供不同的抽象层次。

OLAP或数据仓库具有的操作有这么几种:

向上钻取:对数据立方体沿着某一个维度或多个维度的概念层次向高层次方向进行聚合。

向下钻取:和向上钻取的思路差不多,区别在于向下钻取是沿着维度的概念层次向低层次方向进行聚合,向上钻取和向下钻取改变分析的粒度。

切片:对数据立方体,在某个维度上选择一个值,得到数据立方体的一部分,这就是切片。

切块:对数据立方体,在多个维度上选择一个或多个值,得到数据立方体的一部分,这就是切块,切片和切块是选择需要重点考察的数据子集。

旋转:旋转是一种视觉化的操作,它把数据维度的坐标转换一下,使视图的呈现方式发生变化,给用户一个不一样的角度。

其它的OLAP操作:一种操作是跨越钻取,这种钻取的聚合涉及了多个事实表。另一种操作是穿越钻取,这种钻取可以从数据立方体的最低层级进一步钻取到系统的后端数据表中去。这两种操作好像比较晦涩,难于理解,不过没关系,反正这两种操作也比较少见。

这几种操作的例子如下图:

clip_image016

看了上面这个图,是不是觉得切块,切片这些个操作的名字很贴切?图中中间的立方体就是三维的数据立方体,数据立方体中的一个一个小块被称之为cuboid。

还有一类数据库系统称之为统计数据库SDB,SDB主要用于社会经济学统计,主要给用户提供底层数据,而OLAP主要是为了让用户更有效得处理大量数据,从中发现知识或者提供决策支持。

查询多维数据库的Starnet查询模型是一种查询模型,它由多个维度构成,每个维度是一条从中心点发射的概念层次射线,概念层次射线上的每个抽象层级被称之为脚印。该模型如下图:

clip_image018

数据立方体可以沿着starnet模型的各个维度进行钻取,获得各个层次上数据的抽象。

数据仓库架构

数据仓库的设计要从4个视角来看:

Top-down View:为数据仓库选择必须的相关信息,该信息必须符合当前或将来的商业需求,数据仓库的目的是为了获得哪些信息。

Data source View:考虑数据来源,数据来源多种多样,有的是日常事务数据库,有的是文档,我们需要借助CASE(computer aid software engineer)工具来集成这些数据源。

Data warehouse view:考虑事实表和维度表,选择合适的统计量和恰当的维度。

Business query view:从最终使用者的角度我们需要考虑如何设计系统。

设计一个数据仓库涉及很多技术,要设计一个提取器来提取来自各个数据源的数据,要由仓库软件刷新来更新数据仓库,需要能够从数据中发现模式,趋势,预测,发现异常等等。设计一个好的接口给数据的各个使用者,包括承包商,分析师,终端用户都需要一个好的接口。

数据仓库的设计有两种方法:从上到下和从下到上,以及综合方式。从上到下的设计方式是从整体设计和计划开始。从下到上的设计方式是从一些实验和一些小的原型开始。综合方式是结合前面两种方式。

数据仓库的设计构造有这么几步:计划,需求学习,问题分析,仓库设计,数据集成和测试,数据仓库安装。大型软件开发有两种方式:瀑布流开发和敏捷迭代开发,可根据情况自由选择。

数据仓库的3层架构:

clip_image020

1. 底层是数据库服务器,一般是传统关系数据库。后端的工具用来把数据从日常事务数据库或外部数据源将数据导入数据仓库服务器。

2. 中间是OLAP服务器,一般有两种模型:(1)关系OLAP(ROLAP)模型,这种模型把对多维数据的操作映射成标准的关系操作。(2)多维OLAP模型(MOLAP)模型,这种模型的服务器直接存储多维数据实施多维操作。

3. 顶层是前段客户层,主要包括查询工具,分析工具,数据挖掘工具。

从架构的角度来看,有三种数据仓库模型:企业仓库,数据超市和虚拟仓库。

企业仓库:包含了整个机构范围内所有主题的信息。数据量大,涉及并行计算,构造起来比较复杂。

数据超市:包含了特定主题的数据仓库,一般是部门级别的数据仓库。

虚拟仓库:是日常事务数据库的扩展,通过高效的查询处理,提供了日常数据库的一些视角。

clip_image022

由于直接设计企业数据仓库周期比较长,所以可以采用迭代方法来开发数据仓库。首先定义出系统的高层数据模型,在此基础上,并行得先进行若干数据超市的开发,然后不断得迭代优化这些超市。同时也开始进行整个组织内的大的企业数据仓库开发,最后把数据超市和企业数据仓库结合起来,形成最终的多层数据仓库。

数据仓库的后端工具主要实现了这么几个功能:数据提取,数据清理,数据转化,装载,刷新。

数据仓库中包含一些metadata,所谓metadata就是关于数据的数据,主要包括这么几块:

数据仓库结构的描述:主要包括表,视图,维度,层级等等。

操作性的metadata:包括数据的历史状态,数据被处理的状态等等。

算法:统计量的定义,粒度,主题区域,预先定义的查询等等。

操作环境到数据仓库的映射:包括源数据库,数据分区,数据抽取信息等等。

关于系统性能的数据:读取性能,备份数量等等。

商业metadata:数据所有人信息,policy等等。

OLAP服务器有这么几类:ROLAP,MOLAP,HOLAP和其他。

ROLAP服务器:关系性的DBMS,用来存储仓库数据。

MOLAP服务器:基于数组的多维数据库引擎,可以直接将多维视图直接映射成数据立方体的数组结构,因此OLAP的操作效率很高。

HOLAP(Hybrid OLAP)服务器:将ROLAP和MOLAP结合起来,比如用ROLAP存储大尺寸的细节数据,利用它的大尺寸扩展性。将聚合数据存放在MOLAP,便于OLAP操作快速执行。

专用SQL服务器:一些关系数据库提供了一些高级语言和查询程序来支持只读环境下的SQL查询,可用于OLAP分析。

数据仓库实施

数据仓库包含了大量的数据,因此执行效率非常重要。对于一个n维的数据仓库,那么数据仓库中的排练组合形成的可能的数据立方体的个数为clip_image024个。对于关系数据库而言,数据立方体中的cuboid是通过SQL的group by聚合来实现的。下图就是数据仓库中所有可能数据立方体:

clip_image026

由于每个维度又有多个层次,那么形成的cuboid数量就很惊人了。下面就是数据仓库的cuboid的计算公式:

clip_image028

Li为维度的概念层级的层数。由此可见,cuboid的个数是惊人的。即使通过预先计算的方法来实现获得这些cuboid的视图的开销也是惊人的。这种预先计算的cuboid的做法被称之为实物化。实物化的方法有三种选择:

1. 根本不实物化。不事先做任何计算,等到用户查询的时候才开始计算。这种方法对查询而言,速度会横蛮。

2. 全实物化,把所有的cuboid都事先计算好,但这需要占用很大的空间来存储这些计算出来的cuboid。

3. 部分实物化。有选择性的预先计算出部分cuboid,比如我们只事先计算那些满足用户特定要求的cuboid,比如只计算那些count大于某个阈值的cuboid等等。

部分实物化体现了响应时间和空间的权衡,需要考虑这么几个问题:(1)确定实物化那些cuboid的子集(2)在查询计算的过程当中如何使用这些cuboid(3)在装载和刷新的时候如何有效得更新那些实物化的cuboid。

如何选择实物化的cuboid,要考虑很多,比如查询的特点,查询的频率,cuboid的访问代价,存储要求等等。比如计算cuboid中cell的count值大于某一阈值的cuboid,比如选择计算小维度的cuboid,剩下的cuboid在查询时通过这几个小维度的cuboid组合而成。

为了便于有效得访问数据,大多数的仓库系统都支持索引和cuboid视图。OLAP索引有两种方法:维度索引和联合索引。对于维度索引,对每个给定属性设置一个位向量,位向量中的某一位对应属性中可能的某一个值,属性值对应的向量位为1,其余为0.举例如下:

clip_image030

通过位图索引,能够把一些查询操作转变为位图的代数计算,大大降低计算开销。

另外一种索引方法是联合索引。比如,两个关系R(RID,A),S(B,SID)通过属性A,B联合,那么就建立一个(RID,SID)的索引,这样就不必通过遍历R,S来找出(RID,SID)的关系,通过索引就可以直接找出这种关系。下面就是联合所索引的例子:

clip_image032

根据图3.16,可以得到图3.17这三个索引。通过这三个索引可以大大加快join操作,实际上就是把join操作事先计算出来,这样join查询就无需吸现场扫描计算联合索引。

对于如何高效得处理OLAP查询,有这么两步:

1) 决定要在有效的cuboid执行哪些操作

2) 决定要把这些操作应用在哪些相关的cuboid。

MOLAP的存储模型是一个n维的数组,它有很好的索引性能,但存储空间利用很低,尤其是对稀疏矩阵而言。可以对MOLAP的查询使用一个二层架构,一层是针对密集数组用数组结构,二层针对稀疏数组使用稀疏矩阵结构。对于查询,必须要能迅速定位到合适的密集数组结构,然后再在其基础上建立索引。

如果查询的速度是恒定的,处理查询时还可以考虑一些策略,比如对于用户的查询,我们不是直接给出最终结果,而是给出目前的最优结果,随着时间的推移,结果越来越好,这样使得用户不必傻等最后的结果而浪费时间。另外比如用户查询卖场中几百万商品中销量最好的商品,如果对所有的商品进行排序,找出销量最大的商品,这样的步骤开销很大。通过一定的算法,求top N的商品开销要小的多,速度也快得多。因此,用top N代替the toppest。

从数据仓库到数据挖掘

在数据仓库上,可以做三类应用:信息处理,分析处理和数据挖据。

信息处理:查询,基本的数理统计,一些统计报告,报表等等,一般用网页的形式来呈现。

分析处理:主要是OLAP操作,比如钻取,旋转等等。

数据挖掘:发现隐藏模式和关联模式,分类,预测等等,用合适的视觉化工具将结果呈现出来。

OLAM(Online analytical mining or OLAP mining)在OLAP的基础上集成了多维数据库的数据挖掘和知识发现,它复用了OLAP的结构,同时提供了data mining的功能。一个OLAM的架构如下:

clip_image034

需要注意的是数据挖掘是一个以人为中心的处理过程,也就是说数据挖掘的过程离不开人的干预和互动,数据挖掘不可能是一个自动发掘的过程。OLAP为数据挖掘提供了良好的平台。

0

阅读 评论 收藏 转载 喜欢 打印举报/Report
  • 评论加载中,请稍候...
发评论

    发评论

    以上网友发言只代表其个人观点,不代表新浪网的观点或立场。

      

    新浪BLOG意见反馈留言板 电话:4000520066 提示音后按1键(按当地市话标准计费) 欢迎批评指正

    新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

    新浪公司 版权所有