技术开发 频道

Olap4j:在线分析处理服务器的Java API

  【IT168 评论】经过近五年的工作,商业智能厂商Pentaho发布了olap4j 1.0,olap4j 1.0是一个全新、通用的Java API,适用于所有在线分析处理(OLAP)服务器。当前版本支持以下几款OLAP服务器:

  •  Pentaho分析服务(Mondrian)
  •  Microsoft SQL Server分析服务
  •  Jedox Palo
  •  SAP/BW

  以前业界曾有过提供标准Java OLAP API的尝试。Java Community Process在2000年的时候正式提出要有一个标准的OLAP接口,以便在替换供应商的时候少更改实现。JSR 69——Java OLAP Interface(JOLAP)当初打算要为能创建、维护OLAP数据和元数据的J2EE环境提供厂商无关的纯Java API。但这个规范在2004年获批后并没有完成,导致Java开发社区仍然没有标准的Java OLAP API。

  记者有幸采访了olap4j规范的领导者、Pentaho分析的首席架构师和Mondrian的创始人Julian Hyde,以了解olap4j的更多内容。

  记者:olap4j 1.0版本的主要功能有哪些?

  Olap4j是一个允许你从Java环境里连接OLAP数据库、查询元数据、执行MDX查询的API。它是第一个让Java程序员连接不同厂商OLAP服务器的Java API。

  有两种olap4j驱动。一种用于基于SOAP的标准XMLA(XML for Analysis),这个驱动可以和任何XMLA服务器通讯,包括Microsoft SQL Server分析服务2005和2008版本、Jedox Palo、SAP/BW。用于Mondrian的olap4j驱动可以在同一个JVM内和Mondrian引擎通讯,Mondrian驱动是olap4j的参考实现,而且几年前就已经成为Mondrian的主要API了。

  olap4j API和两种驱动这几年在生产环境里证明都是很稳定的。

  记者:对开发社区来说,有一个用来和OLAP服务器交互的开放标准为什么很重要?

  开放的标准能为开发人员、集成商和最终用户提供一种选择。没有开放标准的话,如果你想使用供应商X的OLAP服务器,你就会受到限制,必须使用供应商X的OLAP客户端。你要是正在构建应用,应用也会受限于供应商X。使用olap4j的话,如果有一款OLAP服务器更好、更便宜、更快,或者只是因为某个特定客户已经有该服务器的站点许可了,那你就可以切换到这个服务器上去。而且OLAP客户端也会有多种选择。

  记者:olap4j和JSR 69有何不同?

  在我看来,JSR 69有很多不足之处。它是一个相当高层次的接口,要求用户理解非常多的元模型(基于公共仓库元模型)和大量的查询模型。查询需要调用API,而不是在SQL或MDX之类的语言里用文本的方式去指定。发起JSR 69的那些厂商都有既有的实现,我觉得他们要在各种查询构建API里找到一种调和的方案,结果却僵持不下。最终,领军OLAP服务器市场的Microsoft并没有成为规范的贡献者。

  大约在同一时间,Microsoft提出了自己的OLAP标准:在C和C++环境下用于OLAP的OLE DB,用于C#和VB等.NET语言的ADO MD,还有用于SaaS的XMLA(一种SOAP方言)。这些标准更加简单,而且由于基于查询语言MDX,它们更像开发人员用来和关系型数据库交互的API(ODBC、JDBC)。这些标准已经在各自的环境里得到了普遍的应用,Microsoft当然没有兴趣去创建一个Java标准。

  olap4j为了让Java开发人员立即上手,采用了Java开发人员所熟悉的JDBC模式。比如说,olap4j里创建连接、准备和执行语句的代码看起来和JDBC里的非常像。所不同的是,查询语言是MDX而非SQL,而且结果是个多维的CellSet,而不是由行和列组成的ResultSet。

  olap4j差不多可以说是JDBC的扩展,实际上这意味着你可以为olap4j连接使用连接池、目录服务等基础设施,就像供JDBC连接使用的一样。

  记者:这些MDX查询是如何生成的?

  在JDBC应用里SQL通常是硬编码的,相反,OLAP的目的是进行交互式的数据探索,所以查询需要动态生成。Olap4j提供了一个查询模型,可以一步一步构建查询,然后转换成MDX。olap4j和以查询模型为中心的API(比如JSR-69和Oracle的OLAP API)相比,最关键的区别在于olap4j里查询模型是可选的。如果你是应用开发人员,你的应用总需要展示同样的图表或数据表格,那你可以手工编写MDX查询;如果你是OLAP工具开发人员,你就可以使用olap4j的查询模型或是构建自己的查询模型。虽然我们已经到了1.0版本,但olap4j的查询模型仍然在继续进行。好消息是它并不是API的核心部分,而且它的演进不会破坏API的其他部分。

  这样做的结果是olap4j要比JSR-69和Oracle的OLAP API更小、更简单。对学习API的应用开发人员,以及试图实现API的服务器和驱动的开发人员来说,这可是个好消息。

0
相关文章