DB2 OLAP SERVER理论知识.docx

DB2 OLAP SERVER理论知识.docx

《DB2 OLAP SERVER理论知识.docx》由会员分享，可在线阅读，更多相关《DB2 OLAP SERVER理论知识.docx（10页珍藏版）》请在冰豆网上搜索。

DB2OLAPSERVER理论知识

DB2OLAPServer理论知识

1前言

本文将讨论DB2OLAP服务器和Essbase方面的重要理论，涵盖OLAP的数据立方体存贮原理，设计要点到OLAP。

本文中的OLAP服务器是指IBMDB2OLAPServer版本7（包含多维存储选项）和HyperionEssbaseOLAPServer版本6.0。

下表1列出IBMDB2OLAPServer和HyperionEssbaseOLAPServer的版本。

Hyperion

IBM

EssbaseServer5.0

DB2OLAPServer1.0

EssbaseServer5.0.2

DB2OLAPServer1.1

EssbaseServer6.0

DB2OLAPServer7.1

2DB2OLAP简介

2.1多维数据库

多维数据库（Multi-DimensionalDatabase）可以简单地理解为：

将数据存放在一个n维数组中，而不是像关系数据库那样以记录的形式存放。

因此它存在大量稀疏矩阵，人们可以通过多维视图来观察数据。

多维数据库增加了一个时间维，与关系数据库相比，它的优势在于可以提高数据处理速度，加快反应时间，提高查询效率。

目前有两种MDD的OLAP产品：

基于多维数据库管理系统的MOLAP和基于关系数据库管理系统的ROLAP。

DB2OLAPServer（HyperionEssbaseOLAPServer）是一种典型的MOLAP。

2.2DB2OLAPServer结构

DB2OLAPServer客户－服务结构支持企业分析应用。

服务器端：

所有的OLAP应用组件，包括多维数据库大纲，计算脚本，规则文件和数据库信息都存在服务器端。

OLAPServer通常运行在UNIX服务器上。

客户端：

DB2OLAP客户端从服务器上分析和返回数据主要是通过几种方式来实现的：

Lotus1-2-3，MicrosoftExcel，客户应用程序接口和各种专业的前端展现工具如HyperionAnalyzer、BO、Brio、CognosPowerplay等。

DB2OLAP提供丰富的API，开发人员可以用VB，VC和C等语言访问OLAP的API实现用户的各种需求，如自动调度，用户权限等任务。

2.3DB2OLAP多维数据库的存贮原理

DB2OLAP存储结构作为矩阵实施数据存储的概念也许是DB2OLAP开发人员应该学习的最为重要的概念。

对矩阵管理的完全了解包括理解稀疏性的推论概念。

也就是说，添加到矩阵中的维越多，矩阵中实际包含值的单元所占比例就越小。

将二维数组的商业示例看作是含有“度量”维的三个成员，分别称为销售额、销售成本及利润（销售额减销售成本），按照“时间”（第二个维）每天进行记录，持续一年。

随着时间的推移（日复一日），我们通常能够直观地测量销售额和销售成本，并生成利润。

此模型会有1,095个交点（365天乘以3个度量）。

“日”和“度量”紧凑迁移的描述十分容易理解。

对于给定日期，如果有一个销售额数字，您可能也有销售成本信息，并可因此计算出利润度量。

除非有销售信息季节波动剧烈，否则多数时间里都会有销售信息。

因此，可能在所有时间内矩阵被“紧凑”填充以进行“度量”。

图1.交点数量——示例

当我们添加更多维时，就会涉及到稀疏性这一概念。

例如，试图将“客户”（数量为100,000）和“产品”（数量为50）的维添加到该模型。

通常很容易想到，这些维中将存在许多不包含数据的交点。

并非所有客户都会在一年中的每一天购买所有产品。

随着每个维所有成员的笛卡尔乘积般的增加，交点的数目也随之增加。

我们的模型就从1095个单元增加到5,475,000,000（365*3*50*100,000）个单元。

仅通过将数据存储为销售事件结果，关系数据库便可处理数据稀疏性。

这些数据库将记录实际销售额。

然后，可以使用结构化查询语言（SQL）询问和分析数据以回答类似的以下问题：

哪些产品在规定时间内销售额最少？

此答案是由程序派生的。

关系数据库一般不存储（许多）客户没有购买（许多）产品这一事实的表。

但矩阵则会。

矩阵会为每个产品和每个客户保存所有时间内销售额和销售成本的各种可能组合。

其中许多单元不包含数据。

关系数据库中包含哪些产品在所有时间内均具有最少销售额的答案，并且只在检索相关交点以及检查其内容时，才显示此答案。

数据块和索引的两种存储结构实际上是由Essbase的设计人员开发而来的，目的是为了处理稀疏性这一现实问题。

2.4数据块和索引说明

请看以下包含21,370,660,375,680个交点的数组说明：

DIM（172,21,27,32,209,32765）。

ArborEssbase的创建者将维标为紧凑或稀疏。

当一个维标为紧凑时，就成为称作数据块的存储结构的组成部分（参见图2）。

图2.紧凑维形成的块

数据库中创建的每个数据块都具有一个相同的结构，所有数据块都存储在磁盘上的ESS*.PAG文件内，在本例中，精确地说，数据块包含172*21*27=97,524个单元或交点。

数据块寻址或定位是通过组合稀疏成员进行的。

这些组合成为称作索引的存储结构的组成部分，并存储在含有ESS*.IND文件的磁盘上。

通过实现数组维的这两个定义，ArborEssbase创建者实现了模块化矩阵。

数据块是一种固定格式的数据结构，其存在方式取决于索引中与数据相关的稀疏成员组合，与数据相关是指只有在稀疏成员组合之间实际存在商业数据的地方才生成数据块。

因此，如果我们一月份在北极没有销售任何Sun褐色石油，那么在数组中就不为那些交叉坐标保留任何空间。

DB2OLAP存储结构与关系结构的区别之一为关系索引是否可选。

在DB2OLAP中，该索引是不可选的。

删除关系结构中的关系表索引不会对表数据产生任何影响。

删除DB2OLAP数据库中的索引则会破坏该数据库。

数组的小型子组件（数据块及其索引地址）在磁盘和工作内存之间移动起来十分容易。

这些结构非常符合一般用户需求：

仅对任何时间点数组中的信息子集感兴趣。

通过刚才的介绍，我们容易得到DB2OLAP数组的三个限定特征是：

维数目、维内的成员数目、维内成员的层次关系。

OLAP建模中第一条设计规则是使数据库设计中的维数目最小化。

这样就要求我们在实施OLAP项目时，反复和用户讨论需求，以确认哪些维是报表或者多维分析需要的，当然这里首先还是要满足实际应用需要。

OLAP建模中第二条设计规则是使数据库设计中的维层次尽可能少。

在牢记其他稀疏维的情况下，让我们假定该维是全平的，而且，除所有成员的上层之外，成员之间不包含任何层次关系。

从图形上看，该维类似于图4。

图4.无层次结构的维

该维总共有449个成员，全部聚集到一个上层，因而总共有450个成员。

请参考图4与图5中维之间的数据点创建的含意。

图5.具有嵌入式层次结构的维

在此声明中，我们拥有组织各组成员的层次结构，而且这对于我们的数据库有着重要的存储含意。

如果我们有成员EP_11的商业交易，但却没有平面稀疏维图4中的EP_12的商业交易，那么就不会创建任何EP_12块。

设计中，已有效地处理（消除）了数据稀疏性的影响。

但是，当我们将层次结构引入维，并且只存在一个子代的数据时，我们就是在声明存在上层数据点。

在SparseDim#4的层次版本中，EP_11处的事务将在SparseDim#4上层成员的Category1的SubCat1处生成数据，而且数据块创建会在有数据的所有其他稀疏维的每个成员之间产生一个笛卡尔乘积！

这一结果具有极大的交叉维含意。

这里的问题不是平面维好，层次维不好的问题。

相反，层次结构准确地反映出许多商业机构的真实情况，而且在建立这些关系的模型时，矩阵极为有效。

真正的问题是层次结构给数组增添了复杂性，而且是导致多维数据库中发生数据爆炸的因素之一。

我们必须充分理解其影响。

2.5深入理解Dense和Sparse维

在多维数据库里，维可以设置成Dense或者Sparse属性。

Sparse维之间的有数据的组合将生成一个数据块（Block）,而在块内是所有Dense维的数据组合。

Block存放在Ess*.pag文件中，Block块间的信息组成index，index存放在Ess*.ind文件中。

下面假设有一个多维数据库并设置它们如下：

TimeD

AccountsD

ScenerioD

MarketS

ProductS

下图很清楚的解释了DB2OLAP生成一个数据块的过程。

假如在德州（Taxas）没有分销RootBeer，因为并不是每一种产品在所有地区都会销售，那么会怎样呢？

DB2OLAP将不会为（Taxas，RootBeer）创建一个数据块。

给定上面的Block，我们可以计算出Block的大小。

假如Time维有10个成员，Accounts有5个，Scenerio有2个（注：

这里的数字都是指通过计算存储数据的实际个数，通常可以将一些成员设置为Dynamic，从而减少存贮），于是我们可以得到一个块中有10×5×2＝100Cells，如果每个Cell需要8Bytes，可以得出一个块需要800Bytes。

一般建议（IBM和Hyperion），多维数据库中的Block的大小在1K～200K，当然也有许多成功的案例在这个范围之外，笔者做的项目中的Block就大于这个数字。

在最初导入数据后，DB2OLAP通过组合Sparse维形成的Block，它们叫InputBlock，如（NewYork，Cola），（California，Beer）等。

在实际应用中，通常我们会访问诸如东部地区Cola的销售情况，DB2OLAP会通过上卷东部所有城市的销售情况得到。

于是就有（East，Cola）这样类似的块，它们是通过计算所有子块得到，这种数据块叫UpperBlock，这是在导入数据后的计算完成。

多维数据库中的Block是怎样遍历顺序的？

下图可以更加清楚的帮助大家理解数据块是如何访问或者生成的？

2.6怎样设置Dense和Sparse维

正确设置Dense和Sparse维对于多维数据库有非常重要的意思，对于物理存贮，访问速度都有重要影响。

数据库设计员的双重目标（创建数量尽可能少、密度尽可能大的数据块）提示我们，数据块的密度与生成块的数量之间存在某种关系。

事实上，在任何DB2OLAP数据库内，数据块密度与创建的块数之间的关系可以用数学公式表示为：

数据集密度=块密度／块数

开发人员的双重目的不是创建最少的块数，也不是创建最紧凑的块，而是创建块数最少、密度最大的块。

利用反映此关系的数据集密度比率，我们可以简化确定最佳稀疏／紧凑设置的任务，以寻找最高比率。

很明显，比率本身是很普通的数字。

通常可以通过下面的一些方法来设置Dense或者Sparse维。

可以通过与业务人员交谈，初步了解数据的特点。

以上面的多维数据库为例，很明显，并不是所有商品在所有地区都有销售记录，通过发现它们的实际交叉比较少，这样我们可以初步确定这两个为Sparse维。

当然这只是通过对数据的一个简单的认识，是最初的设计，在很多情况下，许多维不能正确的设置。

想要真正准确的对各个维设置Dense或者Sparse，必须通过仔细分析数据的特点。

因此，最好的办法是做以系列试验，验证各种维的Dense和Sparse的组合情况，可以在每次试验后记录块密度和（块数，得到（块密度）／（块数）,比较后取出比值最大的组合。

当然多维数据库的数据量很大，我们不能取所有的数据来试验，我们可以从中拿出一些样本数据，这样有几个好处。

数据量小，完成一次试验所需要的时间小，有利于节约开发时间。

这里需要注意的问题有，样本数据不是随便取的，而是有一定的原则。

通过分析业务，我们知道，数据在每一个时间段基本相似，或者在一个地区里基本相似，这样我们可以用一个时间段的数据来作为样本数据。

下表说明了这种试验记录情况：

3DB2OLAP多维数据库的性能优化

如何让多维数据库获得更快的访问速度，需要更少的存贮空间？

这就需要我们对设计的多维数据库做出优化。

前面提到的正确设置维的Dense或者Sparse，可以说是多维数据库优化的一个很重要的方面。

在实际项目中，我们应该认真把握。

3.1将包含子女或公式的紧凑成员设置为“动态计算（Dynamic）”

将包含子女或公式的紧凑成员设置为“动态计算”，这样在Block中将不存放它的数据，从而有利于减少数据存贮，而需要访问时，客户端临时计算，得到汇总的数据，展现给用户。

下图是没有做动态计算前数据块的大小：

假如我们将Qtr1设置成Dynamic，将另外三个衡量指标设置成Dynamic，则数据块变成如下图所示：

3.2最佳地配置DB2OLAP缓冲器

数据高速缓存是RAM中的一个扩展的物理块数据页存储库，而物理（文件系统）高速缓存则是RAM中的一个压缩物理数据块页存储库。

索引高速缓存是RAM中的一个索引地址页存储库。

DB2OLAP存储管理器（或内核）通过为诸如计算机和报表模块这样的服务器功能层提供数据高速缓存寻址，管理索引和数据高速缓存。

通过点击Database－>Settings,点击Storage，可以查看数据库的缓冲器设置情况。

如下图：

DB2OLAP数据高速缓存中的数据块没有压缩，而物理数据高速缓存（或OS文件系统高速缓存）中的数据块则是经过压缩的。

由于数据高速缓存中没有进行数据块压缩，增加数据高速缓冲存储器最终会增加解析从磁盘抽取数据的可能性，因为这会减少内存中可以保存的块总数。

有一点需要提醒，如果服务器上运行了很多多维数据库，应该注意所有数据库设置的缓存数的总和不要超过服务器的内存总数（看服务器还是否需要运行其他服务）。

3.3必要的时候做数据分区（Partition）

可能会在一些应用中，数据量很大，这是可以考虑使用分区的办法。

这样做有几个好处，通过将一个多维数据库分成几个数据库，从而每一个数据库中的数据量减少，而DB2OLAP总是一个CPU对应一个应用（Application），也就是说，以前用一个CPU处理的多维数据库，现在用多个CPU来处理，性能上会有很大的提高。

这一切对于用户来说都是透明的。

3.4选择合适的数据压缩算法

数据压缩类型可提高系统的总体性能。

压缩数据块越小，在磁盘和内存之间的移动速度越快。

选择使用哪种压缩算法与块密度有关。

DB2OLAP文档建议，当平均块密度大约或低于2-3%时，行程长度编码（RLE）压缩比默认位图压缩（Bit－Map）更有效。

磁盘上的块越小，每次磁盘所读取的块就越多，并且可以在RAM中保留的压缩块也就越多。

3.5数据加载优化

只有一种提高数据加载性能的方法，即按稀疏维对输入数据进行排序。

这种方法之所以有效，是因为通过在稀疏维之间对数据进行排序，可确保由于加载数据而创建的每个数据块仅被访问一次。