">

如所介绍，利用Transwarp Rubik设计并实例化OLAP Cube，采用的是空间换区时间的策略来优化OLAP业务执行的。系统将根据业务逻辑，对查询访问的数据进行预计算并缓存计算结果。但是在基于预计算的OLAP应用中，维度爆炸是一个广为诟病的问题。也就是说，为了优化业务执行，OLAP模型占用了系统过多的存储空间。其中很多的维度组合被用于优化的次数寥寥可数，甚至根本不会被访问，所以实际上空间是被浪费的。为了避免制造不必要的维度组合，同时能起到优化业务的作用，提高Cube的产出和代价比，在建立的Cube的时候应该遵循一些减少维度组合的优化策略。

原始Cube引发的空间问题

对于原始的未经任何优化Cube来说，维度表中的任意一个字段或字段表达式即是一个维度。Cube就是所有可能的维度组合的集合，例如维度表中有两个字段A,B，维度组合有四种：{A,B}、{A}、{B}、{}，实例化Cube时，系统会根据每种维度组合物化分别出一张表，下图给出了每一种维度组合所对应的SQL示例。

因此一个n维的Cube中，共有2^n个可能的维度组合，将对应产生2^n张物化表。当Cube维度变成n+m时，物化表的个数急剧增加到2^(n+m)，呈指数级增长。当维度数量较多时，空间资源将趋于爆炸。

所以在保证解决OLAP业务优化绝大部分需求的前提下，减少维度组合数量，是至关重要的。

Rubik支持的OLAP Cube降维方法

减少维度组合数量要需要遵循一定策略，Rubik支持以下降维优化方式，用户可以结合业务需求和实际业务进行选择，设计合适的OLAP Cube模型。

聚合组（Aggregation Group）

当维度数目比较多时（>10），建议根据查询习惯和业务模式将维度按照使用场景进行分组。

示例：

假设，原Cube的维度数量高达50，其中的维度分为对公业务和对私业务两部分，两部分业务互不相干，那么就可以根据业务信息将该Cube的50个维度分割成20维度+30维度两个子Cube。

优化效果：

物化Cube表的数量从2^(m+n)变为2^m + 2^n，占用的空间以指数级减少。

除了划分聚合组之外，下面还有一些常用的组内维度优化的手段。所以，在完成聚合组拆分后，还可以在组内进行进一步优化。

必备维度（Mandatory Dimension）

必备维度是在OLAP业务中，参与所有业务查询的维度，从预计算SQL角度来说总是会出现在WHERE或GROUP BY里。将某个或者某些维度设置为必备维度后，没有包括必备维度的组合就会被舍弃。

示例：

例如，在数据立方体中，银行客户想统计交易金额相关的业务（如交易金额总量、月平均等），查询时必须指定币种字段，因为相同币种的统计分析结果才有意义。所以，可以把币种字段设为Mandatory，从而将Cube的体积减少一半。

优化效果：

将某个维度指定为Mandatory，将只留下包含必备维度的组合。每指定一个必备维度，Cube表数就减少一半；若设置n个必备维度，物化Cube表的数量将从2^m 减少到2^(m-n)。

联合维度（Joint Dimension）

对于某些维度，可以将它们的组合视为一个维度。

通常适用于如下两种场景：

优化效果：

假设原有m个维度，其中n个维度组合为联合维度后，组合数由2^m 变为 2^(m-n+1) 。

衍生维度（Derived Dimension）

当维度表中的某一列（例如主键）可以推导出其它列值时，就可以构造衍生维度。称该列为Basic Column，被推导出的列称为Derived Column，

示例：

例如用户维度表中，给定id可以推出其余字段name、sex，所以GROUP BY id,name和GROUP BY id,sex的结果完全等价于GROUP BY id，因此只需一种维度组合{id,name,sex}。

优化效果：

若Basic Column数为1，Derived Column数为m，则设置衍生维度后，相关的组合维度数从2^m减少到1。

层次维度（Hierarchy Dimension）

Hierarchy是一组有层级关系的维度，可用于减少没有业务需求的字段间的聚合。

示例：

例如某维度表中有“省”，“市”，“县”三个字段，在做聚合查询时，通常都是从高层维度往下伸展的，如GROUP BY “省”，“市”，“县”等，而不会单独出现GROUP BY “市”，“县”之类的情况，因此可以抛弃不满足层次关系的组合。

优化效果：

对于有m个维度的Cube，假设其所有维度构成了一个Hierarchy，那么Cube表的数量就会从2^m减少到m。若能保证潜在的查询严格符合预设的层级关系模型，按照模型设置层次维度将不仅可以大幅减少Cube表数量，而且完全不会影响查询效率。

Partial Cube

Partial Cube优化的思路是，当一个维度组合包含两个中基维（基数为1000到10000）或者一个高基维（基数大于100000）时，我们可以认为该组合没有聚合度可言，其预计算结果用于OLAP优化的效果将很差，而且计算该维度组合物化表所消耗的时间和空间都非常大，所以抛弃该组合。

OLAP Cube构建步骤总结

如何选择和使用以上降维手段都是由实际的数据和业务特征决定的，因此在创建OLAP Cube时必须学会分析真实场景，运用以上降维优化技巧，达到OLAP优化的目的。下面结合优化策略，对OLAP Cube的创建步骤进行简单总结。

首先，根据业务范围，将所有维度进行分组(Aggregation Group)，将维度列分成n种大类的业务场景，按照实际情况建立多个Cube实例或者Cube模型。

然后，对于每类业务场景进行单独的分析：

是否存在必备维度，是否可以创建层级维度，当层级维度数较多时，即组合数量从2^m减少到m后，m的值依然很大的情况下，可以考虑创建衍生维度，对于数据量较大的表，衍生维度将造成较为严重的性能损失，不过大幅度降低存储压力，需要进行权衡，接着考虑是否可以构成组合维度，最后根据实际的数据特征和聚合情况决定是否采用Partial Cube来进行优化。

按照上述步骤，做到既提高Cube存储空间利用价值，又实现可观的优化效果。

下期文章中我们将介绍具体如何在Rubik中实现这些优化方法