总结InfoCube的优势分析及维度选择技巧

一直以来，infocube都是一个很纠结的东西。

作为一个SAP设计出来的雪花型架构存储模型，有他独特的优势，包括检索的效率，包括aggregate，包括compress，包括BWA，包括partition等等。

   

先说效率，之所以cube比ods速度快，和它采用的SID机制分不开的。众所周知integer是比char检索速度要快很多的。

   

再就是cube的index，cube里的所有characteristics都是key，都有索引，不然IO的效率就大大降低了。

   

然后aggregate可以为我们报表量身定做出一个小cube，节约用于OLAP的时间。

   

compress，压缩掉requestid，通过整合F表中的内容到E表的过程，减少数据量，其实也就是去掉了一个无关紧要的key，把其他的同key数据整合在一条，这样做即可以减少Data Manager的时间，也可以减少OLAP的时间。

   

BWA，只适用于infocube，即把cube的内容读取到一个独立服务器的内存中，Query直接通过读取内存中的数据进行分析，大大减少Data Manager的时间，毕竟内存的数据要比硬盘快上万倍，即使DB可以有自己的buffer。

   

Partition，分物理分区和逻辑分区，物理分区是为了把F或者E表的数据分散在几个表里，一般是按照年、月区分，可以减少Data Manager的时间。逻辑分区则是拆分成几个小cube，使用M-Cube整合起来，由于M-Cube是并行检索的，可以大大提高效率。

   

其实呢，这些都是大技巧，往往真正会使千里之堤崩溃的是蚁穴，一些小技巧。

   

前面提到，Cube的特征之一，所有的characteristic都是key，这是双刃剑，设计不好，也导致了一种很严重的问题。所以我们提倡，Cube要尽可能保证粒度，不要过于明细，否则会比ODS效果更差，甚至导致数据的错误。

   

最近就遇到一个很诡异的问题，Order在底层的ODS是正常的，可是到了Cube再做统计时，平白无故多出很多，这就是因为过于明细，所有的字段修改都会导致一条新数据的生成，这样如果用来统计条数，就杯具了。

   

哪些特性要加，哪些特性不要加，哪些用Cube，哪些用ODS，这都是需要慎重考虑的。