BI 中的多维分析要求前端有极高的响应速度，多维分析所涉及的数据量常常很大，几千万上亿行甚至更大的基础表都有，基于这样的表做汇总，性能基本无法保证，所以后台计算性能不好，前端交互感受也就很差了。

为了解决后台计算性能差的问题，一些多维分析产品采用了预汇总方案，把需要前端呈现或看到的统计结果事先基于基础表计算好，放在另外的汇总表里存着，后面分析的时候直接使用汇总表出结果就快了，这里面的逻辑很容易理解，也就是用空间换时间。

把所有的汇总组合情况全量搞成汇总表（全量预汇总），感觉上解决了所有问题，但这种空间换时间也有个问题，预汇总表会额外占用更多的存储空间，但到底会占用多大很多人可能没有太准确的认识，在多维分析预汇总的存储容量有具体的容量估算方案和数据可参考。

通过文章估算数值上我们可以了解到，预汇总方案性能优良，但占用大量存储空间，像金融行业中几十个维度是很常见的，这种情况如果全量预汇总，就会产生几百 T 甚至几万 T 的预汇总数据，全部存放这些数据不太现实或说是不可行的。

当然如果维度较少 (最好<=10) 且中间汇总表数据不太大的时候，还是可以考虑用全量预汇总的。

但，全量预汇总也有功能盲区，包括非常规聚合（唯一计数、中位数等）、组合聚合（组合太多，无法预测，如月平均孝顺、月平均销售额的 top3 等）、条件测度（测度带条件，如金额大于 500 的订单总金额、销量大于 500 的订单总金额等）以及时间段统计（时间段是灵活定义的，无法预测）。具体情况可参考多维分析预汇总的功能盲区详细了解。

尴尬！维度多了不能用全量预汇总，用了全量汇总还有解决不了的功能盲区，难道预汇总方案不能用？

不是，不能全量预汇总的情况，我们还可以选择部分预汇总。

比如基于“支付表”，我们做了按“年月、运货商、支付金额汇总”的预汇总表（可叫中间汇总表），当我们前端仅用“运货商”汇总“支付金额”的时候，让后台引擎更聪明的去选择基于可用的中间汇总表聚合出结果，显然这个效率比基于基础表聚合汇总要快的多，虽然无法做到《多维分析预汇总的存储容量》中介绍的 O(1) 复杂度，但也能把计算性能从基于基础表的全量硬遍历提高几十倍甚至上百倍，这对于大多数多维分析场景已经够用了。

预汇总方案我们了解了，接下来我们结合润乾的多维分析功能来看下，是怎么做的。

润乾透明化的预汇总机制

1、 基于基础表准备预汇总表

如数据库中有“支付单”表

准备两个汇总表

（1） 按月汇总支付金额的“支付月汇总”

（2） 按月和供应商汇总支付金额的“支付供应商月汇总”

2、 元数据中建立基础表与汇总表的关系

（1） 为“支付月汇总”表添加“基础表”及字段关系，如下

（2） 为“支付供应商月汇总”表添加“基础表”及字段关系，如下

做完以上配置，通过基础表“支付表”也可以查看到对应的汇总表配置，如下

3、 采用隐身（对终端用户透明）汇总表分析效果

在前端分析页面上，只会发现基础表，汇总表是隐身的。

接下来，分三种情况分析看看后台引擎对汇总表的智能使用。

（1） 按月汇总支付金额

拖拽“月”分析维度和“支付金额”统计维度

看后台输出

自动找到合适的汇总表，基于汇总表统计。

（2） 按月和供应商汇总支付金额

拖拽“月”和“供应商”分析维度和“支付金额”统计维度

看后台输出

也自动找到合适的汇总表，基于汇总表统计。

（3） 按供应商汇总支付金额

这个情况相对特殊，没有并没有准备按供应商的汇总表，看下是如何处理的。

拖拽“供应商”分析维度和“支付金额”统计维度

看后台输出

可以看出，引擎智能的找到了最合适的数据出处，不是傻傻的去原始基础表统计，而是找到了“支付供应商月汇总”这个中间汇总表，这里有目前分析可用的维度且数据是经过聚合过的相对数据量最少的，这里实际就是上面提到的采用部分预汇总的方案。

总的来说，润乾多维分析的预汇总机制提高性能且灵活，还解决了 ROLAP 较难处理的预汇总表透明化问题，终端用户无需关心汇总表的存在，用起来也更人性化。