MOLAP与ROLAP之争.doc

MOLAP与ROLAP之争MOLAP与ROLAP之争OLAP技术是数据仓库系统中重要的一项应用技术，在OLAP技术发展过程中，由Codd提出的十二条OLAP准则派生了两种的主要OLAP流派，就是以关系型数据库为基础的ROLAP技术和以多维数据库为基础的MOLAP技术。本来，这两种技术都能够实现OLAP功能，也不存在孰优孰劣的问题，在早几年，由于关系数据库技术成熟，ROLAP技术在市场上还略强一些，产品也很多（比如Informix Metacube，Oracle Discoverer等），但近几年MOLAP大行其道，ROLAP几近消亡，目前市场上看到的硕果仅存的ROLAP产品只剩下MicroStrategy和CA解决方案中的产品了，真是遗憾。另外，BO和Brio其实都能够通过语义层定义（Brio中叫Data Model），实现数据结构与业务术语的对应，并实现准OLAP分析功能，但大多数解决方案中，都把BO和Brio当作前端展现工具和报表工具来使用，工具本身建立在关系数据库基础上的分析功能少有人用（连Cognos的Impromptu似乎也少有人用，尽管一般的方案中都购买这个组件），另一个遗憾。大多数系统分析员和方案设计师都知道ROLAP和MOLAP的区别，也会说ROLAP更加灵活，适用海量数据场合，性能优化依赖数据库；MOLAP因进行了全面的预先汇总，查询性能优异，只是浪费存储空间。话当然有理，但对于电信经营分析系统来说，到底哪种技术更加适合？大多数人也没有真正回答这个问题，而是巧妙的互相结合利用，买了MOLAP引擎，也买了报表工具（类似BO之类的），而在开发过程中实际上则只进行Cube设计和构建，ROLAP部分则弃之不用。真的是MOLAP技术更加适用于电信经营分析系统吗？本人观点这是技术方案设计中的最大骗局，理由如下：1） 对于系统性能来讲，以空间换时间是一种基本的优化原理，这对于MOLAP和ROLAP来说都是一样的，只不过MOLAP独立创建Cube文件，而ROLAP则是使用数据库中的汇总表而已。一个Cube完全可以对应一组数据库中的汇总表来实现同等程度的优化，再则，从早期的RedBrick数据仓库、到Oracle8以上的版本，或者IBM DB2的版本，都提供了专为ROLAP优化的自动聚集（Oracle中叫做物化试图，Materilized View）技术，从一个数据量庞大的基础表按照定义的规则自动聚集一组汇总表；前端工具也提供类似的功能，比如Brio就可以根据Data Model的维度和度量自动在数据库中插入相应的汇总表数据，供汇总分析使用。如果开发商愿意在这上面花点经历，还完全可以记录并统计一下用户对数据模型访问时最常用的维度组合，再根据这些维度组合智能地生成汇总，性能必然会大大提升。所以，以性能为理由强推MOLAP是站不住脚的，唯一可能的原因倒是建一个Cube比建一组汇总表要方便省事得多。2） 从灵活性来讲，ROLAP的多维模型可以建立在存放细节数据的表上，也可以建立在汇总表上，维度数量不受限制，还可以比较自由地添加从现有度量派生的运算型度量值（比如百分比、和、差等），而MOLAP技术自身原理所限，维度必然不能过多。而电信的业务数据，随便一个用户资料表，帐单表或者详单表，所涉及的维度都以几十计，而从分析的需求看，任何维度均有组合的可能。但从这一点来看，就可以判断ROLAP在电信经营分析系统中更加有用。3） 从存储效率讲，DW层是要沉淀数据的，否则还叫什么数据仓库？而DW层沉淀数据的基本原理就是提高数据粒度（在时间、地理等维度层次上做文章），建立一系列的汇总表，理论上和实践上都这种汇总都需要分层分级，逐步提高粒度，直至某个粒度的数据可以长期在线存储在系统中为止。事实上，建立了这样的汇总之后，ROLAP的优化已经做得差不多了，不再需要很多额外的只适用于OLAP的数据存储；而对于MOLAP来讲，要在Cube中进行数据的重新汇总，而Cube也是有数据存储期限问题的（Cube文件也不可能无限大），这样Cube中的数据沉淀功能必然与数据库中的数据沉淀相重复，为此开销的数据存储空间在方案中可也是一笔不小的预算。4） 再谈MOLAP自身的特点，对于变化周期不是很快的数据来说，如果访问非常频繁，或者有大量用户使用，建立Cube的确可以使访问性能提升很多，问题是，电信经营分析系统中有非常多的日分析主题，建成Cube，则每天需要刷新更新Cube数据，搞不好还要对Cube数据进行重构（比如数据装载过程出了点什么问题），对系统计算能力和时间的消耗也是系统的一个庞大负担。而ROLAP没有这个问题，即便数据错了，在数据表中更正之后，从前端访问的结果就会随之更正。3、 数据质量，无解的难题数据质量和准确性似乎一直都是个沉重的话题，听说中国移动现在正在进行经营分析系统的数据质量全国性审核，这个问题可见一斑。（对于数据准确性的控制方法，很多人做过研究，本人另外一篇文章中也做过一些讨论， 参见：数据仓库中的数据稽核方法）老调重谈，希望不会招人厌烦，数据准确性的比较基准问题到目前还没有解决，经营分析系统出的报表和统计数据，业务系统也同时在出，如果统计规则相同，看似统计结果应该相同，但实际并不完全如此：业务系统数据在不断变化，而经营分析系统的数据充其量只是业务系统数据在某个时刻的快照，如果统计的时点不同，统计结果自然不会一样；再则经营分析系统对来自业务系统中的数据进行了一系列的处理，清洗、过滤、参照等等，在这个过程中也难保数据没有被丢弃或过滤，这样的统计结果当然也不会一样，但如果要一步步追查起来，恐怕也很难做到。另外一个问题，也许有的客户说移动电话用户在营业厅登记的资料失真，或者由于业务系统对数据核查的规则不严谨（比如出现2010年入网的用户等），导致对客户构成和发展的分析不可信，这诚然存在，但对于经营分析系统来说，有部分这类脏数据可以通过预设规则挑出来，更大部分则会成为漏网之鱼。这个问题的解决已经超离了经营分析系统的范畴，如果把这类问题归结于经营分析系统本身的问题未免有失公允，建议还是通过规范业务管理来解决。返回来再看数据准确性基准问题，我们也不要忘了建设数据仓库的一个主要目的，就是要统一企业内部对各种指标的定义和统计方法，确立指标体系在企业范围的唯一性和通用性，那么为什么经营分析系统在统计的指标业务系统还要继续出呢？甚至经营分析系统为了解决实时（准实时）数据查询的需求，已经规划了ODS层？从系统整体规划来看，经