聚合策略中选择OLAP还是聚合表

摘要：为了实现对出于做报表和分析的需要所作的查询做出最快的回应，数据库系统面临着艰巨的挑战。这个挑战突出了数据库设计中的一对根本矛盾：即最快还是最好。

聚合策略中选择OLAP还是聚合表

为了实现对出于做报表和分析的需要所作的查询做出最快的回应，数据库系统面临着艰巨的挑战。这个挑战突出了数据库设计中的一对根本矛盾：即最快还是最好。数据库可以存储最小单位的数据量以保持运行速度最快；但是使用者在这种低级的存储水平是很难完成报表或分析的。用户是在总结这样高层次的标准上使用这些数据。而且他们要求完美的查询结果。

面对这种挑战，我们开发了一种策略，使用数据聚合，或者是预先摘要数据。这种聚合策略能够完全评价整个数据库的成就。底线是可获得完美（或至少可接受）的查询结果，除非人们不愿意使用数据库。

聚合策略一般依靠两个技术：OLAP和相关聚合表（和有关聚合意识相关技术，如Oracle 8i 和 DB2 UDB V8）。当一些DBAs依靠相关聚合表开发策略，并不认为同样要使用OLAP。相反的，我看到很多报表和分析的基础是过多的依靠OLAP而没有考虑聚合表技术。这正是我今天在这里想说的，如何选择，以及使用何种技术处理各种聚合。

也许最流行的聚合方法是使用聚合表。有时这种方法可以采用新的表计划形式以支持不同的数据结果，但比数据库粗糙，而有时，可以采取物化的形式，即依靠聚合表优化查询，但是这些查询常常隐藏在直接查询的背后。有时候两种方式同时使用。不管在什么情况下，这些表能够大大提高查询的执行情况。当培训工人使用这种技术时，有大量的相关查询工具和书写报表工具。所有这些聚合表的采用以提高查询的执行是一个具有实践性，高效的方法，但是使用OLAP也可能是一个更好的方法。

一些DBAs不愿意考虑使用OLAP是因为他们还没有用过它，或者是因为与他们所用的查询工具不兼容。但是兼容性问题已经变得越来越不重要了，特别是在两个OLAP DBMSs Essbase和Microsoft Analysis Services的领导下。现在所有最新的工具都支持Essbase，意味着使用相关的工具查询相关数据同样也可以用来查询OLAP数据。Analysis Services使用一个OLAP数据存取层（面向OLAP的OLE DB）即它与相关数据存储层（OLE DB）是兼容的。它容许将查询分解成OLAP数据并将该数据提交给相关装置。甚至具有更强的通用性也不再是遥远的梦想。正如九月，George Spofford在一个智能企业的议题中说：“随着以计算机为模式的网络服务的大量出现，该模式为不同的系统连接创造了新的，更好的方法，整个情形都变了：现在，分析更容易与其他计算相互作用交织在一起。”我想说的是OLAP数据变得越来越能与相关数据兼容了，我们在这一点基础上可以考虑现有技术是否可以提交所需的整个聚合数据。

一旦编报表的人发现OLAP，他或她会发现使用OLAP的优点。在多数情况下，OLAP通常要比其他查询完成的更快（尽管有时不如聚合表快）。但是另一个显著的优点是对查询的适应性强。轻松的以任何维度、级别或数量就能回应出以列或行显示的一套结果是特别具有吸引力的。Analysis Services使用MDX（多维表达）语言，而不是（SQL），来提取OLAP数据。这种查询语言（和多维的OLAP索引）能大大加强其适应性。Essbase还提供可自由使用他们的API或添加电子数据表。从任何维度，级别和数量上呈行或列的显示，SQL通常会要求查询一个CASE的综述具有SUM或其他合计功能。或者它要求从柱型列表资源转换成以行显示的结果中查询专门表以获取想要的数据。不论使用何种方式，如果被查询的表不是行或列的形式，使用SQL查询都会很复杂且执行的处理密度大。另外，OLAP提供大量的分析函数以完成整个运算中的各个部分运算，配置和计算在聚合级别的数据，虽然很复杂，但是很有用。总而言之，OLAP的速度和适应性使其在聚合策略下的数据存储系统中成为一个有吸引力的选择。从另一方面看，依赖OLAP过多也不是一件好事。将过多的查询加在OLAP上的结果就像一个厨房水槽的管道，是一个有着多维和过多数据的立方体，立方体将会出现堵塞，或者对它在作任何改变就会出现这种结局。所以坚持使用这样一种立方体就像一个初级的报表或分析表回应任何查询的变化，实际上这是不可能实现的。

不难想象你怎么处理厨房水槽的管道。在起初有关报表和分析的查询时用一个立方体就可以满足，所以对二者都可以使用OLAP。这样做是高效的，且能确保你的报表与分析表轻松衔接（既然他们有相同的即时数据资源）。然而，逐渐的，新的要求增加了，商业规则也变了。新的维度，数量，计算和新数据要求被加入这个立方体。虽然一段时间，立方体赶上了变化，但是从另外的角度而言，一种变化的出现导致数量的增加，进而引起查询过程处理时间的延长。OLAP的开发者知道维度和数量的增加会在数据库容量和处理时间上发生数据爆炸，或者说是指数型增长。这是由于交错空间的矩阵聚合是一定被计算的。当承受过多的数据或者过多的空间时，数据爆炸导致的过多需求也会使最好的OLAP深陷泥潭。从这一点而言，应该意识到对OLAP立方体的要求太多了。

当你将报表查询从分析查询中分离出来通常会发生什么呢，你会使用OLAP仅作为分析查询，而用聚合表做报表查询（可以实现但不一定产生最好的结果）。这种重新的设计，可能是又费时又费力。如果你在深陷泥潭前，一开始就将分析查询和报表查询分开，并考虑你的支持系统需要多少变化，那就会轻松的多了。我曾经不止一次有过这样的经历，我愿意将我的一些心得与所需之士共享。

首先要采取以下行动：

1、发展和明确哪种聚合是最经常被查询的。如果你还没有建立数据库，你需要询问用户，查阅现存的报表和预测分析。如果你已经建立了一个数据库，审视你的系统，找出哪种聚合是最经常被查询的。Oracle,DB2和Analysis Service都有收集这种信息的方法。对较为频繁的查询，要建立优先查询的概念。比如，这种查询是紧急的，还是不是？

2、要理解对聚合需求的延迟性。对某些人而言，花很多时间处理和计算，从而出现延迟是一个问题。延迟更新选择的具体观点向数据不一致打开大门取决于查询是取具体的数据还是取基础表中的数据。对有些用户这不是问题，但对其他人则是一个问题。较低的延迟聚合OLAP一般而言没有什么问题，尽管依赖于数据的分配，涉及的数据量以及你所用的OLAP数据库的独特之处。

3、确定什么是文本数据，比如地址，超链接等等，需要在聚合数据旁予以提示。直到在出现采用OLAP标准的XML前，用OLAP聚合数据系统整合文本数据是极度困难的。

4、前端工具的选择是一个要着重考虑的问题。有时它会促使后端数据的决定。合理的数据库和OLAP各自有自己的作用；对于以组织为单位，或者以产品分类的长篇累牍的报表的查询，足以显示相关技术实力。而轻松使用以图形表示的查询方式则是OLAP的实力之所在。介于这两个极端间的各种技术都应该被考虑。

5、确定哪种聚合是报表服务器计算的，哪种聚合是数据库或OLAP服务器计算的。在报表服务器中重新聚合是浪费时间，除非他们是一些特定查询模式。

6、 如果OLAP和相关技术显示都可以处理聚合数据，则都可以使用。如果可能，多试用几个OLAP数据库，或者至少要向已使用过不止一个OLAP数据库的人士咨询。主要的困难在于对各个OLAP数据库在泛函性，可测性，可支持的操作平台，以及能否轻松使用和其他方面的比较。

7、对于支持聚合策略的聚合表和OLAP要保持开放的思想。有可能你两种都需要使用。但是不要假定你应该只使用其中一个，而在特定时刻使用另一个。最佳方式是保持开放的思想，而不是完全依赖卖方的建议，并且让你的系统工程师对相关技术和OLAP技术都接受培训。

8、在你知道你需要的聚合数据不能存储是由于OLAP存在设计限制时，你可以使用聚合表。（比如，在Analysis Services下，你不得不在一维限制适用地查询聚合数据中使用父子型的方式。或在Essbase，你不得不频繁使用以元为单位的"动态计算"来减少处理时间。

如果你已经有了一个报表系统，给你介绍一些警告标志，表明你没有充分使用OLAP聚合技术；

1、在更广泛定义的分析需求下，为了集中新的聚合数据，你要不断地添加新的聚合表（比如，实际支出对预算不一致的分析，或提升效率性分析）。

2、你的查询会越来越复杂，因为他们执行了分配，以行列为形式的混合单位的计算。尽管相关管理人士DBMSs在这个领域增加了多个函数，但是这些分析聚合运算就OLAP数据库而言太长了。你也许会发现有更好的函数和更简单轻松使用这些计算的方法。

3、你的报表会变得非常复杂，要花很多时间制成，因为你的报表服务器在执行以上的运算。

4、你有如此多的聚合表，那么数据存储，处理时间和保存都成为问题。在这一点上可以考虑使用ETL工具，但是OLAP也应该被考虑在内。

5、当具体观点更新，或变成一个议题时，要锁定争论的焦点。

6、要考虑购买新的硬件以提高查询的执行情况。

7、你的DBA不熟悉OLAP。

如果你已经装了报表系统，这儿有些警告标志，当你使用OLAP过度时，那么聚合表也许更有效。

1、报表服务器再次聚合低级别的OLAP数据而不使用OLAP聚合。大多数人没有意识到他们的报表服务器也许做了远超过用户需要的数据聚合。

2、立方体要花费很长时间处理添加的新维度或其他变化，添加更多的数据使他通过你的处理窗口。

3、多个维度（10维以上）来自同样的资源表。比如，有个产品维度，以及产品类型，产品尺寸，产品颜色等。在这个例子里，四个都是来自相同表的维度。即使Essbase有特质维度，Analysis Services有实质维度用来处理这些一对多关系的数据（效率更高的是多对多），处理这些关系数据使用相关技术会更有效。使用相关技术，产品、产品类型、产品尺寸、产品颜色将都会在一个数据表中。如果新查询迫使我们添加20个这样的维度，使用聚合表更容易实现。比使用相关技术执行的更完美。

4、OLAP立方体具有维度间的不相关性（潜在的数据交集是不存在的），仅支持来自一个立方体的报表查询。

5、OLAP聚合数据的补时会淹没服务器。

6、你在考虑购买新硬件以提高查询的完成质量。

相关技术和OLAP技术仍然很难创建明确的规则，什么时候使用OLAP，什么时候使用聚合表仍旧是个难题。但是认真考虑支持你的聚合策略的两种技术将会是非常值得的。