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