多维分析预汇总的存储容量 | 润乾 -九游会登陆

多维分析一般是交互式操作的，也就要求有极高的响应速度，而多维分析涉及的数据量常常很大，几千万上亿行甚至更大都有，临时统计很可能跟不上界面的操作。为了保证性能，一些多维分析产品采用了预汇总方案，也就是把需要看到的统计结果事先计算好，这样计算复杂度就从o(n)变成o(1)，在常数时间（秒级甚至毫秒级）内就可以返回结果，满足了交互分析的需求。

我们都知道，预汇总的基本逻辑就是用空间换时间，将会额外占用许多存储空间，但很多人对它到底会占用多大空间却没有什么感性认识。我们现在就来算一算看。

假设一个原始的cube有50个独立维度（所谓独立维度是指互相不依赖的维度，象年/月/日这种是不独立的，可以算成一个），如果我们把所有可能的维度组合都预先汇总出来的话，会有多少个中间cube（更精确的术语是cuboid)呢？很容易算，2^50个！注1

注意这是中间cube的个数，而不是数据的行数，每个cube还会有很多数据，就算每个cube只占用1k字节（显然不可能这么少），2^50个cube将占用的存储空间也是个天文数字，超过1mt，也就是要上百万块1t的硬件才能放得下:)。

好吧，我们没必要预汇总所有的维度组合，一般人同时看的汇总维度也没有那么多。我们按20个来算，只汇总所有不超过20个维度的组合，那是多少个中间cube呢？c(50,1) c(50,2) … c(50,20)。我们只看最后一项c(50,20),大概是4.7e13，如果每个中间cube按1万行算（其实太保守了，20个维度很容易乘出上百万甚至上亿行出来注2），这样就会有4.7e17以上的数据行。维度信息因为有不少重复值，就认为有什么高效压缩手段给彻底忽略掉算了，我们仅仅考虑一个测度的统计值，一行数据也要占1-4个字节，就算只有1字节，实在没有办法再压缩了，这也要有470000t以上的容量，还是要几十万块硬盘:)。

50个独立维度是不是太多了？还是20个维度组合数量太多了？熟悉金融、通信等行业的同学会知道，这些数量还是比较常规的，并不算过份。

我们继续来缩小任务空间。

一般来讲我们查询多维分析的结果是用一个交叉表，交叉表层数太多显然看着不方便了，我们就假定左3层上3层，也就是总共最多6层。50个维度中取6个的组合数为c(50,6)，大概是1589万，我们仍然按每个中间cube有1万行数据来算，这样算下来不到160g行。每行数据有十几个测度统计值，一般不会超过1k，总容量差不多能在100t左右了。这个数量似乎可以接受，只要100块硬盘了:)。

且慢，这只是我们看到的交叉表部分。我们在多维分析时还常常要提一些切片条件，比如针对某个月、某个地区、某个产品来看其它维度的交叉表。预汇总的数据，不仅要考虑到交叉表本身的维度，还要加上切片用到的维度。6这个组合数量只够交叉表的，我们把它凑成10再来计算容量，也就是留4个维度用来切片。

还是按上面的估算方法，c(50,10)大概是100亿，每个中间cube按一万行算，就是100t行。看起来还行，但这只是数据的行数，如果我们事先汇总上10几个测度，那又是几千t空间了，硬盘数还得上千:)。

预汇总占用的空间实在太大，看起来没什么实用性了。而且，我们的计算已经很保守了，比如cube数量只算了最大项，中间cube容量只算成一万行，维度用的空间没有算，一个测度汇总值也只算了一个字节。实际情况远没有这么理想了，占用空间比估算数值再大几倍到几十倍也是很正常的。

那么，预汇总到底还能不能做？

当然还是能的。维度比较少的时候没问题，比如只有10几个维度时，中间cube的数量也就是几千到几万的量级，空间占用会在百十块硬盘的范围内。一般来说，如果独立维度数超过30个时，就不要再指望能够把可能查询到的维度组合都事先汇总出来了，也就不可能把计算复杂度降成o(1)了。当然具体数值也要根据维度和测度统计需求的情况来定，可以用上面的办法自己估算。

那是不是维度较多时不能做预汇总了？也不是，在有限的空间内虽然没办法把计算复杂度降到o(1)，但能降上几十几百倍也很有意义。我们后续会再讨论这个话题。

注1：如果把年/月/日这种分层维度考虑进去，就不是2^n，会比这个数更大，应当是(l1 1)*(l2 1)*…*(ln 1)，n是维度数，li是第i个维度的层数，比如年/月/日这种维度的层数是3，没有层的维度可以看成是1层情况。

注2：cube的行数，理论上是各维度取值可能性数量的乘积，即使每个维度只有2种取值，20个维度的cube行数就可能2^20=100万行，远远超过1万。每个维度有5种取值可能时，6个维度的cube就会有上万行了。