1.3 OLAP常见架构分类

OLAP领域技术发展至今方兴未艾，分析型数据库百花齐放。然而，看似手上拥有很多筹码的架构师们，有时候却面临无牌可打的窘境，这又是为何呢？为了回答这个问题，我们需要重温一下什么是OLAP，以及实现OLAP的几种常见思路。

之前说过，OLAP名为联机分析，又可以称为多维分析，是由关系型数据库之父埃德加·科德（Edgar Frank Codd）于1993年提出的概念。顾名思义，它指的是通过多种不同的维度审视数据，进行深层次分析。维度可以看作观察数据的一种视角，例如人类能看到的世界是三维的，它包含长、宽、高三个维度。直接一点理解，维度就好比是一张数据表的字段，而多维分析则是基于这些字段进行聚合查询。

那么多维分析通常都包含哪些基本操作呢？为了更好地理解多维分析的概念，可以使用一个立方体的图像具象化操作，如图1-1所示，对于一张销售明细表，数据立方体可以进行如下操作。

❑ 下钻：从高层次向低层次明细数据穿透。例如从“省”下钻到“市”，从“湖北省”穿透到“武汉”和“宜昌”。

❑ 上卷：和下钻相反，从低层次向高层次汇聚。例如从“市”汇聚成“省”，将“武汉”“宜昌”汇聚成“湖北”。

❑ 切片：观察立方体的一层，将一个或多个维度设为单个固定值，然后观察剩余的维度，例如将商品维度固定为“足球”。

❑ 切块：与切片类似，只是将单个固定值变成多个值。例如将商品维度固定成“足球”“篮球”和“乒乓球”。

❑ 旋转：旋转立方体的一面，如果要将数据映射到一张二维表，那么就要进行旋转，这就等同于行列置换。

为了实现上述这些操作，将常见的OLAP架构大致分成三类。

第一类架构称为ROLAP（Relational OLAP，关系型OLAP）。顾名思义，它直接使用关系模型构建，数据模型常使用星型模型或者雪花模型。这是最先能够想到，也是最为直接的实现方法。因为OLAP概念在最初提出的时候，就是建立在关系型数据库之上的。多维分析的操作，可以直接转换成SQL查询。例如，通过上卷操作查看省份的销售额，就可以转换成类似下面的SQL语句：

        SELECT SUM（价格）FROM销售数据表GROUP BY省

图1-1 多维分析的常见操作

但是这种架构对数据的实时处理能力要求很高。试想一下，如果对一张存有上亿行数据的数据表同时执行数十个字段的GROUP BY查询，将会发生什么事情？

第二类架构称为MOLAP（Multidimensional OLAP，多维型OLAP）。它的出现是为了缓解ROLAP性能问题。MOLAP使用多维数组的形式保存数据，其核心思想是借助预先聚合结果，使用空间换取时间的形式最终提升查询性能。也就是说，用更多的存储空间换得查询时间的减少。其具体的实现方式是依托立方体模型的概念。首先，对需要分析的数据进行建模，框定需要分析的维度字段；然后，通过预处理的形式，对各种维度进行组合并事先聚合；最后，将聚合结果以某种索引或者缓存的形式保存起来（通常只保留聚合后的结果，不存储明细数据）。这样一来，在随后的查询过程中，就可以直接利用结果返回数据。但是这种架构也并不完美。维度预处理可能会导致数据的膨胀。这里可以做一次简单的计算，以图1-1中所示的销售明细表为例。如果数据立方体包含了5个维度（字段），那么维度组合的方式则有25（2n, n=维度个数）个。例如，省和市两个维度的组合就有<湖北，武汉>、<湖北、宜昌>、<武汉、湖北>、<宜昌、湖北>等。可想而知，当维度数据基数较高的时候，（高基数意味着重复相同的数据少。）其立方体预聚合后的数据量可能会达到10到20倍的膨胀。一张千万级别的数据表，就有可能膨胀到亿级别的体量。人们意识到这个问题之后，虽然也实现了一些能够降低膨胀率的优化手段，但并不能完全避免。另外，由于使用了预处理的形式，数据立方体会有一定的滞后性，不能实时进行数据分析。而且，立方体只保留了聚合后的结果数据，导致无法查询明细数据。

第三类架构称为HOLAP（Hybrid OLAP，混合架构的OLAP）。这种思路可以理解成ROLAP和MOLAP两者的集成。这里不再展开，我们重点关注ROLAP和MOLAP。