四大OLAP工具选型浅析

     OLAP(在线分析处理)这个名词是在1993年由E.F.Codd提出来的,只是,眼下市场上的主流产品差点儿都是在1993年之前就已出来,有的甚至已有三十多年的历史了。OLAP产品不少,本文将主要涉及Cognos(Powerplay)、Hyperion (Essbase)、微软(Analysis Service)以及MicroStrategy几大厂商的产品。
  
  快枪手  VS  多面手
  单纯从成本角度考虑,微软的产品算是最能节省成本的,Cognos和MicroStrategy则在同一水平线,都比微软贵一些。而Hyperion (Essbase)产品比較独立,也曾占有美国OLAP市场最大的份额,其产品价格又要更高一些。
  从市场份额来看,就国外的市场报告分析,微软、Cognos、Hyerion三家占领主流。在国内,眼下还没有权威的市场报告,假设仅从所接触到的项目来看的话,用Cognos的非常多,买Essbase的也不少。这些年都是一些大企业建设BI项目,有足够的预算,多选用Cognos、Essbase;而Microstrategy,进入中国不算早,这几年在政府、金融行业也颇有建树。
  若论开发应用,微软的产品向来以友好的用户界面著称,上手迅速。在OLAP产品上,微软依旧发扬了这一优良传统,并有进一步标准化的趋势,开发了OLE DB for OLAP以及MDX(Multi-Dimensional Express多维表达式);參与XMLA(XML for Analysis)规范制定,也是想作为OLAPserver和前端分析应用的传输数据标准。
  而Cognos以桌面OLAP開始,一直以轻便、快捷的操作闻名。所谓桌面OLAP,是能够用client将cube下载到本地进行訪问。尽管Poweplay早已演变成C/S结构的OLAPserver,但其轻便的特点还是延续下来,并且提供能够简洁部署且具有交互性的PowerPlay Web Explorer界面。从互联网上,我们能够非常快搜索出很多基于PowerPlay Web的分析应用。
  Essbase作为老牌的OLAPserver,是一个比較复杂的产品。所谓复杂,有两层意思,一是提供了丰富的API,让你能够充分定制开发;二是开发的难度较大,部署起来不easy。这也是国内非常多用户难以将这个产品用好的一大原因。
  比較Essbase和Powerplay,会发现截然相反的两个特点:Essbase的复杂和Powerplay的简洁。对于这两者,单独说哪一种更好都不够客观,由于当你抱怨Essbase繁杂的接口时,也有人在抱怨Powerplay的定制功能怎么如此之少。这种情形事实上跟这两种产品的定位有关,Essbase比較专注于高性能的多维存储服务,而Powerplay则更专注于快捷的多维訪问。换句话讲,Essbase之于Powerplay正像专业相机之于傻瓜相机,在选哪一个更好的问题上,不同的人肯定有不一样的答案。
  当然,假设你想在找复杂和简洁之间找一个中间者,我想微软的 Analysis Service就是这种产品。只是要注意的是,这个产品和SQL Server绑定得比較紧,这是微软的一贯策略。

 

  百花争艳 VS  一支独秀
  依据多维数据存储的位置,OLAP一般分为MOLAP(Multi-Dimensional OLAP)和ROLAP(Relational OLAP)两种,此外,还有混合的HOLAP(Hybrid OLAP)。
  当中, Cognos的Powerplay、Hyperion 的Essbase和微软的Analysis Service这些产品都是MOLAP产品。.这类产品将数据从关系数据库(甚至是文本文件、Excel文件)中抽取出来,存储在自己的数据库中。这种数据库跟寻常我们所见的Oracle、DB2这类关系数据库不同之处在于,它是专有格式的,且没有标准的訪问接口。因此,这些产品怎样实现多维存储也都不尽同样,大致的原理是以编程语言中多维数组的方式存放数据。度量值存放在数组的单元格中,而数组每一个维就相应一个维度,当中,维元素就维的坐标。
  能够想象,多维数据库的单元格跟维度、维元素的多少有莫大关系,而随着维度添加,数据库也迅速膨胀。因此,对于MLOAP产品,多维存储的存储空间、性能自然是比較关键的。Essbase在这方面提供许多优化工作,但有时候也会显得过于复杂。Powerplay也提供某些选项,诸如cube分区等,这是比較简单的优化方法。
  OLAP产品的核心功能是提供多维存储,另外就是能够将OLAP訪问操作转换为对数据的请求并返回,这些OLAP訪问操作大多是用户通过前端发出的,因此要考虑OLAP产品能够和哪些前端工具对接。
  Cognos Powerplay是个相对封闭的产品,它有自己的client和Web Explorer,你也甭想着用其它前端来訪问它。Hyperion和微软都採用开放式接口,提供丰富的訪问API,第三方能够用这些API訪问其数据库。上文曾提到微软开发的MDX和參与的XMLA(XML for Analysis)规范,其实,一些第三方的前端工具正是基于这种标准和OLAP产品对接,比方能够用BO WebI连接Essbase。更有甚者,微软的server还提供用MDX来查询多维数据,就像用SQL来訪问关系数据库一样。
  诚然,这看起来的确比較酷,但有一点也要明白:眼下尽管有XMLA、MDX这种标准,但还不是很成熟,且并不是唯一标准。所以即使有第三方前端工具訪问这些OLAPserver,但仅仅能说是多了一些选择,真正在前端功能上,并不能保证比封闭结构更丰富。
  假设说OLAP产品市场差点儿都被MOLAP占领,那么,有一家公司肯定不允许,那就是MicroStrategy,它差点儿是眼下唯一一家还占领一定市场份额的ROLAP产品。这是一件很奇怪的事情,从第一个ROLAP产品Metaphor到Metacube、WhiteLight、MicroStrategy,这些独立的ROLAP厂商似乎都是难以生存下去,仅仅有MicroStrategy坚挺到如今。到底是它的产品厉害,还是市场做得到位?眼下还不得而知。
  从原理上讲,ROLAP将数据存放在关系数据库中,当然要求关系模型要很严格,比方要遵循星型模式或雪花模式,才干定义出维度、度量、事实表、聚集表等元数据。但这样就添加了部署的难度,而且假设聚集表构建得不好,最后的訪问性能就难以保证。恐怕这也是ROLAP难以生存下去的原因吧。
  眼下,许多OLAP产品都会混合MOLAP和ROLAP,特别是那些本身就做关系数据库的厂商,在现有数据库上面添加一些ROLAP的特性并不困难。IBM在与Essbase终止OEM合同之后,推出一个名为CubeViews的产品,就能够说是一个ROLAP产品。
  尽管国内市场上已经涌现出这么多产品,但实际上,OLAP并没有被广泛接受,即使在已经建设BI系统好几年的电信行业也是如此。OLAP提供了一套系统的方法,将维度、度量、层次、切片、钻取概念化,但在前几年,原始的cube被直接推送给市场人员、领导,复杂的界面(对于领导来说,那已经够复杂了)让这种应用难以得到推广。为此,OLAP产品的定位无疑还须要进一步明白。