Olap4j 1.0：用于在线分析处理（OLAP）服务器的Java API

经过近五年的工作，商业智能厂商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。

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

InfoQ：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和两种驱动这几年在生产环境里证明都是很稳定的。

InfoQ：对开发社区来说，有一个用来和OLAP服务器交互的开放标准为什么很重要？

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

InfoQ：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连接使用的一样。

InfoQ：这些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的服务器和驱动的开发人员来说，这可是个好消息。

InfoQ：到目前为止，JOLAP已经成为很多其他工作的基础了。比如Hyperion的XMLA实现就使用了基于JOLAP规范的Java API。但规范本身并没有真正成为这样的标准。你打算去复兴JOLAP规范本身吗？

我们不打算那么做，原因上面已经说过了。不过olap4j采用了XMLA的很多内容，XMLA是目前最重要的OLAP规范。两个API的元数据非常像，查询语言MDX则完全相同。主要区别是，在Java环境里olap4j要比XMLA好用的多。而且olap4j在很多情况下都比XMLA有效率，因为驱动能使用缓存，或是使用比XML over HTTP更有效的协议。

InfoQ：你打算把规范提交给JCP么？还是想让它继续作为独立的规范和流程发展下去？

我们希望olap4j能像JDBC那样被看作是Java运行时库的标准部分。但我们现在还不打算把它提交到JCP。JSR-69的失败有一个教训，就是市场要比JCP的结果更为重要。我们希望越来越多的服务器能添加olap4j驱动，olap4j也能随之成为市场的生力军。服务器厂商看到olap4j的好处之后，希望他们会支持我们在JCP里提议olap4j。

InfoQ：olap4j和其他Java OLAP接口的主要区别有哪些？像Oracle的OLAP Java API。

首先，包括Oracle API在内的其他API都不是基于MDX查询语言的。相反，查询都是通过编程方式创建的，而且构建查询的API往往因厂商的不同而不同。

其次，其他API会让你受限于特定的厂商。

大多数OLAP服务器近来都实现了XMLA。这需要继续做两件重要的事情。首先就是以用于XMLA的开源olap4j驱动为起点，创建用于这些服务器的olap4j驱动。第二，这些服务器实现XMLA实际上意味着他们要实现MDX语言。所以，为这些服务器实现原生的olap4j驱动应该是有可能的，这要比基于XMLA的驱动更有效率。

InfoQ：有计划在olap4j以后的版本里对其他OLAP服务器提供驱动支持么？

我们不能保证支持所有特定的服务器，但作为开源项目，我们希望社区能做出有价值的贡献。在过去的一年里，其他人已经实现了SAP/BW和Palo的驱动；我希望在接下来的几个月里能有Oracle/Essbase的驱动。

InfoQ：关于olap4j，开发社区还有应该知道的信息么？

olap4j 1.0里的核心API是稳定的。我们保证API以后演进的时候能向后兼容。但我们不会止步于olap4j 1.0。我们将以兼容的方式增强核心API，在以后的版本里我们还会添加很多内容。

我们想扩展、改进查询模型。前面已经说过，查询模型是一个生成MDX的客户端库，所以修改起来非常容易，也不会修改API里查询元数据、执行查询的核心部分。

有一个单元格回写的实验工具。它允许“假设”场景和应用的规划。它在olap4j里只是一个可选的功能，但我们希望Palo和Mondrian至少要实现它。

还有一个实验工具，在服务器上的数据发生变化时能立即接收“推”过来的通知。想象一下，Web客户端上单元格的值在你眼前发生变化，还会简单地改变颜色以提醒你有变更。

由于olap4j是按照开放流程进行开发的，贡献者来自不同的项目和公司，所以我们可以期待在规范的后续版本里能出现更多的好点子。

Olap4j是由公司和开源项目联合开发的。它是一个开放的规范，遵循Eclipse公共许可（EPL）。

 查看英文原文：Olap4j 1.0: a Java API for OLAP Servers