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

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

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

   

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

   

再就是cubeindexcube里的所有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,这都是需要慎重考虑的。

你可能感兴趣的:(cube)