数据蒋堂 | 多维分析预汇总的存储容量

作者：蒋步星

来源：数据蒋堂

本文共1700字，建议阅读7分钟。
本文带你感性认识多维分析方案中的预汇总额外占用的存储空间。

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

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

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

[ 注1 ]如果把年/月/日这种分层维度考虑进去，就不是2^n，会比这个数更大，应当是(L1+1)*(L2+1)*...*(Ln+1)，n是维度数，Li是第i个维度的层数，比如年/月/日这种维度的层数是3，没有层的维度可以看成是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以上的数据行。

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

维度信息因为有不少重复值，就认为有什么高效压缩手段给彻底忽略掉算了，我们仅仅考虑一个测度的统计值，一行数据也要占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)，但能降上几十几百倍也很有意义。我们后续会再讨论这个话题。

专栏作者简介

润乾软件创始人、首席科学家

清华大学计算机硕士，中国大数据产业生态联盟专家委员，著有《非线性报表模型原理》等，1989年，中国首个国际奥林匹克数学竞赛团体冠军成员，个人金牌；2000年，创立润乾公司；2004年，首次在润乾报表中提出非线性报表模型，完美解决了中国式复杂报表制表难题，目前该模型已经成为报表行业的标准；2014年，经过7年开发，润乾软件发布不依赖关系代数模型的计算引擎——集算器，有效地提高了复杂结构化大数据计算的开发和运算效率；2015年，润乾软件被福布斯中文网站评为“2015福布斯中国非上市潜力企业100强”；2016、2017年，荣获中国电子信息产业发展研究院评选的“中国软件和信息服务业十大领军人物”；2017年度中国数据大工匠、数据领域专业技术讲堂《数据蒋堂》创办者。

数据蒋堂

《数据蒋堂》的作者蒋步星，从事信息系统建设和数据处理长达20多年的时间。他丰富的工程经验与深厚的理论功底相互融合、创新思想与传统观念的相互碰撞，虚拟与现实的相互交织，产生出了一篇篇的沥血之作。此连载的内容涉及从数据呈现、采集到加工计算再到存储以及挖掘等各个方面。大可观数据世界之远景、小可看技术疑难之细节。针对数据领域一些技术难点，站在研发人员的角度从浅入深，进行全方位、360度无死角深度剖析；对于一些业内观点，站在技术人员角度阐述自己的思考和理解。蒋步星还会对大数据的发展，站在业内专家角度给予预测和推断。静下心来认真研读你会发现，《数据蒋堂》的文章，有的会让用户避免重复前人走过的弯路，有的会让攻城狮面对扎心的难题茅塞顿开，有的会为初入行业的读者提供一把开启数据世界的钥匙，有的甚至会让业内专家大跌眼镜，产生思想交锋。

往期回顾：

数据蒋堂 | JOIN延伸 - 维度概念

数据蒋堂 | JOIN提速 - 有序归并

数据蒋堂 | JOIN提速 - 外键指针的衍生

数据蒋堂 | JOIN提速 - 外键指针化

数据蒋堂 | JOIN简化 - 意义总结

数据蒋堂 | JOIN简化-消除关联

数据蒋堂 | JOIN简化 - 维度对齐

数据蒋堂 | JOIN运算剖析

数据蒋堂 | 迭代聚合语法

数据蒋堂 | 非常规聚合

数据蒋堂 | 再谈有序分组

数据蒋堂 | 有序分组

数据蒋堂 | 非等值分组

数据蒋堂 | 还原分组运算的本意

数据蒋堂 | 有序遍历语法

数据蒋堂 | 常规遍历语法

数据蒋堂 | 从SQL语法看离散性

数据蒋堂 | 从SQL语法看集合化

数据蒋堂 | SQL用作大数据计算语法好吗？

数据蒋堂 | SQL的困难源于关系代数

数据蒋堂 | SQL像英语是个善意的错误

数据蒋堂 | 开放的计算能力为数据库瘦身

数据蒋堂 | 计算封闭性导致臃肿的数据库

数据蒋堂 | 怎样看待存储过程的移植困难

数据蒋堂 | 存储过程的利之弊

数据蒋堂 | 不要对自助BI期望过高

数据蒋堂 | 报表的数据计算层

数据蒋堂 | 报表应用的三层结构

数据蒋堂 | 列式存储的另一面

数据蒋堂 | 硬盘的性能特征

数据蒋堂 | 我们需要怎样的OLAP？

数据蒋堂 | 1T数据到底有多大？

数据蒋堂 | 索引的本质是排序

数据蒋堂 | 功夫都在报表外--漫谈报表性能优化

数据蒋堂 | 非结构化数据分析是忽悠？

数据蒋堂 | 多维分析的后台性能优化手段

数据蒋堂 | JOIN延伸 - 维度查询语法

数据蒋堂 | 文件的性能分析

数据蒋堂 | RDB与NoSQL的访问性能

数据蒋堂 | 报表开发的现状

数据蒋堂 | Hadoop - 一把杀鸡用的牛刀

数据蒋堂 | Hadoop中理论与工程的错位

数据蒋堂 | 存储和计算技术的选择

数据蒋堂 | 人工智能中的“人工”

数据蒋堂 | 中国报表漫谈

数据蒋堂 | 内存数据集产生的隐性成本

数据蒋堂 | 多维分析预汇总的功能盲区