我要投搞

标签云

收藏小站

爱尚经典语录、名言、句子、散文、日志、唯美图片

当前位置:大丰收高手论坛 > 动态分析器 >

Olap4j 10:用于在线分析处理(OLAP)服务器的 Java API

归档日期:05-29       文本归类:动态分析器      文章编辑:爱尚语录

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

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

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

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

  大约在同一时间,Microsoft 提出了自己的 OLAP 标准:在 C 和 C++ 环境下用于 OLAP 的 OLE DB,用于 C# 和 VB 等语言的 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 连接使用的一样。

  在 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。

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

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

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

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

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

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

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

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

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

本文链接:http://quangdungfc.net/dongtaifenxiqi/183.html