Mondrian architecture

Posted on | Edited on | In

Mondrian系统的图层

OLAP: OnlineAnalytical Processing
Mondrian OLAP系统由四层组成; 从最终用户的眼睛到数据中心的核心，有如下：表示层，维度层，星层和存储层。

表示层决定最终用户在他或她的监视器上看到的内容，以及他或她如何交互以提出新问题。有多种方式可以呈现多维数据集，
包括数据透视表（上面显示的表格的交互式版本），饼图，线条和条形图以及高级可视化工具，如可点击的地图和动态图形。
这些可以用Swing或JSP编写，以JPEG或GIF格式呈现的图表或通过XML传输到远程应用程序。所有这些表示形式的共同之处在于
表示层提出问题的维度，度量和单元的多维“语法”，并且OLAP服务器返回答案。

第二层是维度层。维度层解析，验证并执行MDX查询。查询分多个阶段进行评估。首先计算坐标轴，然后计算坐标轴内单元格的值。
为了提高效率，维度层将批量请求发送给汇聚层。查询转换器允许应用程序操纵现有查询，而不是从头开始为每个请求构建MDX语句。
元数据描述了维度模型，以及它如何映射到关系模型。

第三层是星级层，负责维护聚合缓存。聚合是内存中的一组度量值’单元’[cells]，由一组维度列值限定。维度层发送单元组请求。
如果请求的单元格不在高速缓存中，或者通过在高速缓存中汇总聚合进行派生，则聚合管理器会向存储层发送请求。

存储层是一个RDBMS。它负责提供聚合的单元格数据，以及维度表中的成员。
我在下面描述为什么我决定使用RDBMS的功能，而不是开发针对多维数据优化的存储系统。

这些组件可以全部存在于同一台机器上，也可以分布在机器之间。构成Mondrian服务器的第2层和第3层必须位于同一台计算机上。
存储层可以在另一台机器上，通过远程JDBC连接访问。在多用户系统中，表示层将存在于每个最终用户的机器上（除了在服务器上生成的JSP页面的情况）。


存储和聚合策略

OLAP服务器通常根据其存储数据的方式进行分类：

  • MOLAP（multidimensional OLAP）服务器将其所有数据存储在磁盘中，并针对多维访问进行优化。
    通常，数据以密集阵列存储，每个单元值只需要4或8个字节。
  • ROLAP（relational OLAP）服务器将其数据存储在关系数据库中。事实表中的每一行都有一个用于每个维度和度量的列。
    需要存储三种数据：事实表数据（事务记录），聚合和维度。

MOLAP数据库以多维格式存储事实数据，但如果维度不止一个维度，则这些数据将会很稀疏，并且多维格式表现不佳。
HOLAP（混合OLAP）系统通过在关系数据库中保留最细粒度的数据来解决此问题，但将聚合以多维格式存储。

预先计算的聚合对于大型数据集是必需的，否则某些查询在未读取事实表的全部内容的情况下不能被回答。
MOLAP聚合通常是内存数据结构的图像，分解成页面并存储在磁盘上。ROLAP聚合被存储在表中。
在一些ROLAP系统中，这些由OLAP服务器显式管理; 在其他系统中，这些表被声明为物化视图[materialized views]，
并且当OLAP服务器使用 group by子句中列的正确组合发出查询时，它们将被隐式使用。

聚合策略的最后组件是缓存。高速缓存将预先计算的聚合保存在内存中，以便后续查询可以访问单元值而不必访问磁盘。
如果缓存将所需数据集保留在较低级别的聚合中，则它可以通过卷起来计算所需的数据集。

缓存可以说是聚合策略中最重要的部分，因为它是自适应的。很难选择一组聚合来预先计算在不使用大量磁盘的情况下加速系统的速度，
特别是那些维度较高或用户提交不可预知查询的系统。在数据实时变化的系统中，维护预先计算的聚合是不切实际的。
合理大小的缓存可以允许系统在面对不可预知的查询时充分执行，而预先计算的聚合很少或没有。

蒙德里安的汇总策略如下：

  • 事实数据存储在RDBMS中。RDBMS已经有一个存储管理器，为什么还要开发一个？
  • 通过查询提交分组，将聚合数据读入缓存。同样，RDBMS有一个聚合器，为什么还要开发一个？
  • 如果RDBMS支持实体化视图，并且数据库管理员选择为特定聚合创建实体化视图，则Mondrian将隐式使用它们。
    理想情况下，蒙德里安的聚合管理者应该意识到存在这些物化视图，并且这些特定的聚合计算起来很便宜。
    它甚至应该向数据库管理员提供调优建议。

总体思路是将数据库的内容委托给数据库。
这给数据库带来了额外的负担，但是一旦将这些功能添加到数据库中，数据库的所有客户端都将从中受益。
多维存储可以减少I / O，并在某些情况下可以加快操作速度，但我认为这不足以保证现阶段的复杂性。

一个奇妙的副作用是因为Mondrian自己不需要存储空间，所以可以通过将JAR文件添加到类路径中并立即启动并运行来安装它。
由于没有冗余数据集进行管理，数据加载过程更容易，Mondrian非常适合在实时更改的数据集上执行OLAP。

API

Mondrian为客户端应用程序提供执行查询的API。

由于没有普遍接受的用于执行OLAP查询的API，Mondrian的主要API是专有的; 然而，任何使用过JDBC的人都会发现它很熟悉。
主要区别在于查询语言：Mondrian使用称为MDX的语言(M ulti- D dimension e X pressions)来指定查询，其中JDBC将使用SQL。
下面更详细地描述MDX。

连接 经由创建 的DriverManager，以类似的方式来JDBC。
一个 查询是类似于JDBC 声明，并且通过解析MDX字符串创建。
甲 结果是类似于JDBC 结果集 ; 因为我们正在处理多维数据，所以它由轴和单元组成，而不是行和列。
由于OLAP旨在用于数据挖掘，因此可以通过 drillDown和 sort等操作修改查询中包含的分析树 ，然后重新执行查询。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
import mondrian.olap.*;
import java.io.PrintWriter;

Connection connection = DriverManager.getConnection(
    "Provider=mondrian;" +
    "Jdbc=jdbc:odbc:MondrianFoodMart;" +
    "Catalog=/WEB-INF/FoodMart.xml;",
    null,
    false);
Query query = connection.parseQuery(
    "SELECT {[Measures].[Unit Sales], [Measures].[Store Sales]} on columns," +
    "{[Product].children} on rows " +
    "FROM [Sales] " +
    "WHERE ([Time].[1997].[Q1], [Store].[CA].[San Francisco])");
Result result = connection.execute(query);
result.print(new PrintWriter(System.out));

API还将数据库模式呈现为一组对象： 模式， 多维数据集， 维度， 层次结构， 级别， 成员。
有关Mondrian API的更多信息，请参阅 javadoc。

用于分析的XML是通过SOAP（简单对象访问协议）访问OLAP服务器的标准。
这允许Microsoft Excel等非Java组件针对Mondrian运行查询。

蒙德里安包括对 JSR-069(‘JOLAP’)提议标准的支持，
但是在明确标准永远不会被批准的情况下，这一支持在mondrian-2.3中被删除。

https://mondrian.pentaho.com/documentation/architecture.php#Figure_1:_Mondrian_architecture