多维分析预汇总的存储容量
多维分析一般是交互式操作的,也就要求有极高的响应速度,而多维分析涉及的数据量常常很大,几千万上亿行甚至更大都有,临时统计很可能跟不上界面的操作。为了保证性能,一些多维分析产品采用了预汇总方案,也就是把需要看到的统计结果事先计算好,这样计算复杂度就从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就会有上万行了。