商业转载请联系作者获得授权，非商业转载请注明出处。

提到‘数据库’，首先被想到的肯定是Oracle、DB2、SQL Server、MySql这些传统的关系型数据库。数据库的概念是非常宽泛的，除了上述的关系数据库，还有NoSQL（Not Only SQL）数据库，还有一些基于分布式技术框架（Hadoop、Spark）的大数据存储和处理体系也被称为数据库，以及基于逻辑多维结构的多维数据库（Multi Dimensional Database，MDD）。今天这里要介绍的就是这个多维数据库。

 

如果您做过数据分析相关的工作，那应该对多维结构和多维数据分析不陌生。

关系数据库中的ROLAP星型表结构是较为常见的“数据分析模型”，但从严格意义上来讲，它并不具备多维分析的能力，ROLAP之所以被广泛认知，是因为它易于被理解，只要是接触过关系数据库，就能很快搞懂ROLAP的套路。

ROLAP有两个比较明显的问题，难以优化和模型抽象程度低。

难以优化。对关系型数据库来说，如果一套表结构模型具有非常复杂的关联关系，但是这些表的数据量并不大，那么在进行复杂逻辑的查询时并不需要过多考虑性能优化问题，把精力专注在查询逻辑即可。另外一种情况，如果一个数据库表有大量的数据，但是其结构和查询逻辑很简单，那么是可以对其进行一些通用的优化，使其能够满足大部分查询的效率要求。

对ROLAP体系来说，它的复杂逻辑查询与对海量数据的运算是严重耦合的。

如果是对一套星型结构的查询，要处理的情况相对还是简单些的；如果是对多套星型结构进行跨业务的查询，那么情况会非常复杂。

 

即使是能对某一个复杂查询进行很好的优化，而对于并不可预知的其他查询逻辑，并没有办法进行通用的优化。

模型抽象程度低。由于ROLAP是基于关系数据库表结构的，所以其描述的模型始终摆脱不了‘表、字段、数据行’等概念，这些概念都是关系数据路中技术相关的概念，而真正的多维数据分析要求维度描述的是纯粹的业务角度，不应该暴露任何技术细节。

 

这里并不是说ROLAP跟多维数据分析完全不沾边，只是如果没有在其上进行更高级模型的抽象，ROLAP本身的数据分析能力是很弱的。

如何构建真正的多维数据模型？要真把这个事情的全部细节说清楚，小编也不知道需要多长时间，下图是一本讲解多维数据结构的书籍，800多页，各位可以自己估算一下时间。

 

ROLAP本身是不能等同于多维数据模型的，而且其本身的数据分析能力也是很弱的。

小编几年前曾经接触过一个开源的ROLAP系统Mondrian，虽然它也是将数据以星型结构存储，但在星型结构之上做了大量的模型映射工作，其提供给上层应用的数据模型已经是屏蔽了技术细节的逻辑维度模型。目前Mondrian与其属主项目Pentaho貌似被收购并商业化了，对开源的支持也降低了。

对比一下传统报表，ROLAP体系除了星型结构使数据更加规整和采用分布式等手段处理大体量数据之外，和传统报表几乎没有本质的区别。

目前流行的Hadoop、Spark等开源大数据框架可以被视为ROLAP的延伸，但是这种数据分析体系同样存在抽象程度低的问题，基于Hadoop和Spark等框架可以建立起解决某种特定需求的数据分析体系，这种面向特定需求的项目型系统的通用化和移植性并不会很好（BAT内部建立的很多类似系统就属于这种情况），而且只能面向技术人员，想要在商业信息等更高层面体现价值的话必须依赖IT部门的大力支持。

ROLAP说的够多了，下面言归正传，讲解真正的多维数据库。

以Oracle Essbase和IBM Cogons为例，多维数据库向上提供的是以维度（Dimension）和Cube（数据立方体）为基本结构的逻辑模型。维度类似于坐标轴，Cube则相当于这个N维空间中的一个结构体。

• 在0维空间中，Cube没有可关联的维度，可以将Cube想象成一个点，确定一个度量值不需要任何维度信息。
• 在1维空间中，Cube结构是一条线。
• 在2维空间中，Cube结构是一个平面。
• 在3维空间中，Cube是一个立方体结构。
• N（N > 3）维空间中的Cube则可以被想象成一个超立方体结构。

 

相当一部分BI行业从业者认为ROLAP的星型结构与逻辑多维结构是等同的，实际上这是对多维数据库及多维数据模型的最大误解。

从表面来看，星型结构与多维数据库在数据持久化方面提供的能力是相当的，甚至基于关系数据库的ROLAP会更方便一些，但一旦涉及对数据的多维分析，ROLAP相对于多维数据库来说基本可以被视为传统报表。

多维数据模型的标准查询语言是多维表达式（MDX，Mutil Dimensional Expressions），MDX是微软公司发明的面向多维数据模型的结构化查询语言，在语法结构和长相上MDX和SQL是很类似的。

 

对于多维逻辑模型，可以使用MDX进行查询；对于ROLAP，则使用SQL查询。人们很容易将ROLAP星型结构等同于多维结构，同样也容易将MDX想象成SQL的简单变体。实际情况是这两种数据分析套路的差别是非常大的，多维数据库可以支持100%面向业务式的数据分析，而基于ROLAP则始终无法摆脱关系数据库表与字段的查询思路。

现在我们来假设一个多维数据模型，以此为例来探究一下传统多维数据库的内部原理。

此模型是全国各个地区各种服装的销售数据集，有三个维度：地区、日期、服装类别，两个度量：销售额和售卖数量。

 

多维数据库从接收MDX到返回查询结果大致要经过MDX解析、中间结构处理、度量聚集计算、返回结果等几个步骤。

 

• MDX解析步骤负责对输入的MDX语句进行词法和语法分析，然后生成中间表示结构。
• 中间结构处理步骤的工作是对多维查询的复杂逻辑和函数进行处理、确定查询结果的结构和调用度量聚集计算对结构进行填充，这个步骤的工作非常复杂，是由多维数据库内核调用各个组件来完成的。
• 度量聚集计算负责将明细级度量汇总成非明细度量，是多维数据库底层的原子级运算。
• 返回结果将一个M维（M <= N）的结构进行填充并返回，0维Cube的查询结果只能是标量值，1维Cube的查询结果可以是一个标量也可以是一个1维结构，2维Cube可以返回标量值、1维结构和2维结构作为结果，大于等于3的N维Cube返回结果形态可以以此类推。

 

在大多数情况下，查询Cube返回的结构都是2维的，因为这是最容易被人们直观理解的。

多维数据库的优点之一是查询速度非常快，这就要着重说一下度量聚集计算这个步骤。

多维数据库对数据的管理主要由两部分组成，概要文件（Profile）和数据块（Data Blocks）。概要文件负责对维度、维度成员、Cube与维度的关联关系等信息进行管理，把它想象成一个迷你的主数据管理系统即可。数据块则负责管理度量数据。

以前文提到的那个服装销售Cube为例，它的度量数据可以被想象成是存放在一个 192×2 的二维数组中。

一个N维Cube模型的数据可以直接被映射为N + 1维数组，这个多出来的1代表的是度量，度量本身也可以被看做一个维度，后文会进行说明。此文中会将N + 1维数组的