OLAP联机分析处理介绍

　　联机分析处理 (olap) 的概念最早是由关系数据库之父e.f.codd于1993年提出的，他同时提出了关于olap的12条准则。olap的提出引起了很大的反响，olap作为一类产品同联机事务处理 (oltp) 明显区分开来。

　　codd提出olap的12条准则来描述olap系统：

　　准则1 olap模型必须提供多维概念视图

　　准则2 透明性准则

　　准则3 存取能力准则

　　准则4 稳定的报表能力

　　准则5 客户/服务器体系结构

　　准则6 维的等同性准则

　　准则7 动态的稀疏矩阵处理准则

　　准则8 多用户支持能力准则

　　准则9 非受限的跨维操作

　　准则10 直观的数据操纵

　　准则11 灵活的报表生成

　　准则12 不受限的维与聚集层次

oltp

olap

用户

操作人员，低层管理人员

决策人员，高级管理人员

功能

日常操作处理

分析决策

db 设计

面向应用

面向主题

数据

当前的， 最新的细节的， 二维的分立的

历史的， 聚集的， 多维的集成的， 统一的

存取

读/写数十条记录

读上百万条记录

工作单位

简单的事务

复杂的查询

db 大小

100mb-gb

100gb-tb

　　在过去的二十年中，大量的企业利用关系型数据库来存储和管理业务数据，并建立相应的应用系统来支持日常业务运作。这种应用以支持业务处理为主要目的，被称为联机事务处理(oltp，on-line transaction processing)应用，它所存储的数据被称为操作数据或者业务数据。

　　随着市场竞争的日趋激烈，企业更加强调决策的及时性和准确性，这使得以支持决策管理分析为主要目的的应用迅速崛起，这类应用被称为联机分析处理，它所存储的数据被称为信息数据。

　　联机分析处理的用户是企业中的专业分析人员及管理决策人员，他们在分析业务经营的数据时，从不同的角度来审视业务的衡量指标是一种很自然的思考模式。例如分析销售数据，可能会综合时间周期、产品类别、分销渠道、地理分布、客户群类等多种因素来考量。这些分析角度虽然可以通过报表来反映，但每一个分析的角度可以生成一张报表，各个分析角度的不同组合又可以生成不同的报表，使得it人员的工作量相当大，而且往往难以跟上管理决策人员思考的步伐。

　　事实上，随着数据仓库理论的发展，数据仓库系统已逐步成为新型的决策管理信息系统的解决方案。数据仓库系统的核心是联机分析处理，但数据仓库包括更为广泛的内容。

　　-概括来说，数据仓库系统是指具有综合企业数据的能力，能够对大量企业数据进行快速和准确分析，辅助做出更好的商业决策的系统。它本身包括三部分内容：

　　1、数据层：实现对企业操作数据的抽取、转换、清洗和汇总，形成信息数据，并存储在企业级的中心信息数据库中。

　　2、应用层：通过联机分析处理，甚至是数据挖掘等应用处理，实现对信息数据的分析。

　　3、表现层：通过前台分析工具，将查询报表、统计分析、多维联机分析和数据发掘的结论展现在用户面前。

　　从应用角度来说，数据仓库系统除了联机分析处理外，还可以采用传统的报表，或者采用数理统计和人工智能等数据挖掘手段，涵盖的范围更广；就应用范围而言，联机分析处理往往根据用户分析的主题进行应用分割，例如：销售分析、市场推广分析、客户利润率分析等等，每一个分析的主题形成一个olap应用，而所有的olap应用实际上只是数据仓库系统的一部分。

　　olap展现在用户面前的是一幅幅多维视图。维（dimension）：是人们观察数据的特定角度，是考虑问题时的一类属性，属性集合构成一个维（时间维、地理维等）。

　　维的层次（level）：人们观察数据的某个特定角度（即某个维）还可以存在细节程度不同的各个描述方面（时间维：日期、月份、季度、年）。

　　维的成员（member）：维的一个取值，是数据项在某维中位置的描述。（“某年某月某日”是在时间维上位置的描述）。

　　度量（measure）：多维数组的取值。（2000年1月，上海，笔记本电脑，0000）。

　　olap的基本多维分析操作有钻取（drill-up和drill-down）、切片（slice）和切块（dice）、以及旋转（pivot）等。

　　切片和切块：是在一部分维上选定值后，关心度量数据在剩余维上的分布。如果剩余的维只有两个，则是切片；如果有三个或以上，则是切块。

　　旋转：是变换维的方向，即在表格中重新安排维的放置（例如行列互换）。

　　数据仓库与olap的关系是互补的，现代olap系统一般以数据仓库作为基础，即从数据仓库中抽取详细数据的一个子集并经过必要的聚集存储到olap存储器中供前端分析工具读取。典型的olap系统体系结构如下图所示：

　　olap系统按照其存储器的数据存储格式可以分为关系olap（relationalolap，简称rolap）、多维olap（multidimensionalolap，简称molap）和混合型olap（hybridolap，简称holap）三种类型。

　　molap将olap分析所用到的多维数据物理上存储为多维数组的形式，形成“立方体”的结构。维的属性值被映射成多维数组的下标值或下标的范围，而总结数据作为多维数组的值存储在数组的单元中。由于molap采用了新的存储结构，从物理层实现起，因此又称为物理olap（physicalolap）；而rolap主要通过一些软件工具或中间软件实现，物理层仍采用关系数据库的存储结构，因此称为虚拟olap（virtualolap）。

　　由于molap和rolap有着各自的优点和缺点（如下表所示）,且它们的结构迥然不同，这给分析人员设计olap结构提出了难题。为此一个新的olap结构——混合型olap（holap）被提出，它能把molap和rolap两种结构的优点结合起来。迄今为止，对holap还没有一个正式的定义。但很明显，holap结构不应该是molap与rolap结构的简单组合，而是这两种结构技术优点的有机结合，能满足用户各种复杂的分析请求。

　　rolap molap

　　沿用现有的关系数据库的技术

　　专为olap所设计

　　响应速度比molap慢；

　　现有关系型数据库已经对olap做了很多优化，包括并行存储、并行查询、并行数据管理、基于成本的查询优化、位图索引、sql 的olap扩展(cube,rollup)等，性能有所提高

　　性能好、响应速度快

　　数据装载速度快

　　数据装载速度慢

　　存储空间耗费小，维数没有限制

　　需要进行预计算,可能导致数据爆炸，维数有限；无法支持维的动态变化

　　借用rdbms存储数据，没有文件大小限制

　　受操作系统平台中文件大小的限制，难以达到tb 级(只能10~20g)

　　可以通过sql实现详细数据与概要数据的存储

　　缺乏数据模型和数据访问的标准

　　–不支持有关预计算的读写操作

　　–sql无法完成部分计算

　　–无法完成多行的计算

　　–无法完成维之间的计算

　　–支持高性能的决策支持计算

　　–复杂的跨维计算

　　–多用户的读写操作

　　–行级的计算

　　维护困难

　　管理简便

　　同样是仿照用户的多角度思考模式，联机分析处理有三种不同的实现方法：

　　· 关系型联机分析处理(rolap,relational olap)

　　· 多维联机分析处理(molap,multi-dimensional olap)

　　· 前端展示联机分析处理(desktop olap)

　　其中，前端展示联机分析需要将所有数据下载到客户机上，然后在客户机上进行数据结构/报表格式重组，使用户能在本机实现动态分析。该方式比较灵活，然而它能够支持的数据量非常有限，严重地影响了使用的范围和效率。因此，随着时间的推移，这种方式已退居次要地位，在此不作讨论。

　　以下就rolap和molap的具体实施方法进行讨论：

　　顾名思义，关系型联机分析处理是以关系型数据库为基础的。唯一特别之处在于联机分析处理中的数据结构组织的方式。

　　让我们考察一个例子，假设我们要进行产品销售的财务分析，分析的角度包括时间、产品类别、市场分布、实际发生与预算四方面内容，分析的财务指标包括：销售额、销售支出、毛利(=销售额-销售支出)、费用、纯利(=毛利-费用)等内容，则我们可以建立如下的数据结构：

　　该数据结构的中心是主表，里面包含了所有分析维度的外键，以及所有的财务指标，可计算推导的财务指标不计在内，我们称之为事实表(fact table)。周围的表分别是对应于各个分析角度的维表(dimension table)，每个维表除了主键以外，还包含了描述和分类信息。无论原来的业务数据的数据结构为何，只要原业务数据能够整理成为以上模式，则无论业务人员据此提出任何问题，都可以用sql语句进行表连接或汇总(table join and group by)实现数据查询和解答。（当然，有一些现成的rolap前端分析工具是可以自动根据以上模型生成sql语句的）。这种模式被称为星型模式(star-schema)，可应用于不同的联机分析处理应用中。

　　以下是另一个采用星型模式的例子，分析的角度和指标截然不同，但数据结构模式一样。我们看到的不是表的数据，而是表的结构。在联机分析处理的数据模型设计中，这种表达方式更为常见：

　　有时候，维表的定义会变得复杂，例如对产品维，既要按产品种类进行划分，对某些特殊商品，又要另外进行品牌划分，商品品牌和产品种类划分方法并不一样。因此，单张维表不是理想的解决方案，可以采用以下方式，这种数据模型实际上是星型结构的拓展，我们称之为雪花型模式(snow-flake schema).

　　无论采用星型模式还是雪花型模式，关系型联机分析处理都具有以下特点：

　　· 数据结构和组织模式需要预先设计和建立；

　　· 数据查询需要进行表连接，在查询性能测试中往往是影响速度的关键；

　　· 数据汇总查询（例如查询某个品牌的所有产品销售额），需要进行group by 操作，虽然实际得出的数据量很少，但查询时间变得更长；

　　· 为了改善数据汇总查询的性能，可以建立汇总表，但汇总表的数量与用户分析的角度数目和每个角度的层次数目密切相关。例如，用户从8个角度进行分析，每个角度有3个汇总层次，则汇总表的数目高达3的8次方。

　　可以采取对常用汇总数据建立汇总表，对不常用的汇总数据进行group by 操作，这样来取得性能和管理复杂度之间的均衡。

　　多维联机分析处理实际上是用多维数组的方式对关系型数据表进行处理。下图是rolap与molap的对比：

　　图中左边是rolap方式，右边是molap方式，两者对应的是同一个三维模型。molap首先对事实表中的所有外键进行排序，并将排序后的具体指标数值一一写进虚拟的多维立方体中。当然，虚拟的多维立方体只是为了便于理解而构想的，molap实际的数据存储放在数据文件(data file)中，其数据放置的顺序与虚拟的多维立方体按x,y,z坐标展开的顺序是一致的(如上图)。同时，为了数据查找的方便，molap需要预先建立维度的索引，这个索引被放置在molap的概要文件(outline)中。

　　一旦概要文件定义好，molap系统可以自动安排数据存储的方式和进行数据查询。从molap的数据文件与rolap的事实表的对比可以看出，molap的数据文件完全不需要纪录维度的外键，在维度比较多的情况下，这种数据存储方式大量地节省了空间。

　　但是，如果数据相当稀疏，虚拟的多维立方体中很多数值为空时，molap的数据文件需要对相关的位置留空，而rolap的事实表却不会存储这些纪录。为了有效地解决这种情况，molap采用了稀疏维和密集维相结合的处理方式，如下图。

　　上图的背景是某些客户只通过某些分销渠道才购买，但是只要该客户存在，他在各个月和各个地区内均有消费(例如，华南ibm只通过熊猫国旅定购南航机票，但在华南四省在每个月均有机票订购)。则时间和地区维是密集维，客户和分销渠道是稀疏维，molap将稀疏维建成索引文件(index file)，密集维所对应的数值仍然保留在数据文件中，索引文件不存储空纪录。这样保持了对空间的合理利用。我们也可以看到，如果所有维都是稀疏维，则molap的索引文件就退化成rolap的事实表， 两者没有区别了。

　　在实际应用中，不可能所有分析的维度都是密集的，也绝少存在所有分析的维度都是稀疏的，因此稀疏维和密集维并用的模式几乎主导了所有的molap应用。而稀疏维和密集维的定义全部集中在概要文件中，因此，只要预先定义好概要文件，所有的数据分布就自动确定了。

　　在这种模式中，密集维的组合组成了的数据块(data block)，每个数据块是i/o读写的基础单位(如上图)，所有的数据块组成了数据文件。稀疏维的组合组成了索引文件，索引文件的每一个数据纪录的末尾都带有一个指针，指向要读写的数据块。因此，进行数据查询时，系统先搜索索引文件纪录，然后直接调用指针指向的数据块进行i/o读写(如果该数据块尚未驻留内存)，将相应数据块调入内存后，根据密集维的数据放置顺序直接计算出要查询的数据距离数据块头的偏移量，直接提取数据下传到客户端。因此，molap 方式基本上是索引搜索与直接寻址的查询方式相结合，比起rolap的表/索引搜索和表连接方式，速度要快得多。

　　特点

　　· 需要预先定义概要文件；

　　· 数据查询采用索引搜索与直接寻址的方式相结合，不需要进行表连接，在查询性能测试中比起rolap有相当大的优势；

　　· 在进行数据汇总查询之前，molap需要预先按概要文件中定义的数据汇总关系进行计算，这个计算通常以批处理方式运行。计算结果回存在数据文件中，当用户查询时，直接调用计算结果，速度非常快。

　　· 无论是数据汇总还是计算衍生数据，预先计算的方式实际上是用空间来换时间。当然，用户也可以选择动态计算的方式，用查询时间来换取存储空间。molap可以灵活调整时空的取舍平衡。

　　· 用户难以使用概要文件中没有定义的数据汇总关系和衍生指标。

　　· 在大数据量环境下，关系型数据库可以达到tb级的数据量，现有的molap应用局限于基于文件系统的处理和查询方式，其性能会在100gb级别开始下降，需要进行数据分区处理，因此扩展性不如rolap。因此，molap多数用于部门级的主题分析应用。

　　联机分析处理其他要素包括假设分析(what-if)，复杂计算，数据评估等等。这些因素对用户的分析效用至关重要，但是与rolap和molap的核心工作原理的不一定有很紧密的关系，事实上，rolap和molap都可以在以上三方面有所建树，只不过实现的方法迥异。因此，这些因素更取决于各个厂商为他们的产品提供的外延功能。对于像ibm的db2 olap server这样一个成熟的产品来说，这三方面均有独特的优势：

　　假设分析提出了类似于以下的问题："如果产品降价5%，而运费增加8%，对不同地区的分销商的进货成本会有什么影响？"这些问题常用于销售预测、费用预算分配、奖金制度确定等等。据此，用户可以分析出哪些角度、哪些因素的变化将对企业产生重要影响；并且，用户可以灵活调节自己手中掌握的资源(例如费用预算等)，将它用到最有效的地方中去。

　　分析人员往往需要分析复杂的衍生数据，诸如：同期对比、期初/期末余额、百分比份额计算、资源分配(按从顶向下的结构图逐级分配)、移动平均、均方差等等。对这些要求，db2 olap server提供丰富的功能函数以便用户使用。因为只有在无需编程的环境下，商业用户才能更好地灵活利用这些功能进行复杂的真实世界模拟。

　　数据评估包括两方面内容，有效性评估和商业意义评估。在有效性评估方面，数据抽取、清洗和转换的规则的定义是至关重要的。而合理的数据模型设计能有效防止无效数据的进入。例如在rolap中，如果维表没有采用范式设计(normalise design)，可能会接受如下的维表：

　　机构代码 机构名称 所属区县 所属城市 所属省份

　　001 越秀支行 越秀区 广州 广东

　　002 祖庙支行 佛山 广州 广东

　　003 翠屏支行 佛山 南海 广东

　　004 。。。 。。。 。。。 。。。

　　显然，002中显示的佛山属于广州市，与003中显示的佛山属于南海市是矛盾的。这显示出数据源有问题，但是如果采用星型模式设计，rolap无法自动发现数据源的问题！

　　在类似情况下，molap的表现稍占优势。因为molap需要预先定义概要文件，而概要文件会详细分析维度的层次关系，因此生成概要文件时会反映数据源的错误。因此，在db2 olap server中，记录003会被拒收，并纪录在出错日志中，供it人员更正。

　　但是，olap对数据源有效性的验证能力毕竟是有限的，因此，数据有效性必须从源数据一级和数据抽取/清洗/转换处理一级来进行保障。

　　对用户而言，数据的商业含义评估更有意义。在商业活动中，指标数值的取值范围是比较稳定的，如果指标数值突然发生变化，或者在同期比较、同类比较中有特殊表现，意味着该指标代表的方方面面具有特别的分析意义。普通的olap往往需要用户自己去观察发现异常指标，而db2 olap server的olap minor(多维数据挖掘功能)能为用户特别地指出哪些条件下的哪些指标偏离常值，从而引起用户的注意和思考。例如：12月份南部的圣诞礼品销售额不到同期类似区域（东部、中部、西部）的50%。