优化InfoCube性能_小七_新浪博客

这个问题不仅实践中经常要遇到。

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

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

简单总结一下：

1. 尽量不要在Cube里放太detail的数据，这种需求首先考虑R3用ABAP解决，如果非要在BW，可以考虑在DSO出明细报表，在Cube出汇总报表，通过RRI接口调用明细报表。关于RRI，请看：
http://help.sap.com/saphelp_sm32/helpdata/en/99/08629bd3e41d418530c6849df303c9/content.htm

2. 当Cube的数据量很大时，可以拆分成多个Cube, 再用MultiProvider拼起来，这样query会在N个Cube中并行，提高效率。这就是所谓的逻辑分区。常见的分区方式有按年月，按国家，按BU，按类型等。

3. 对于很大的Cube，可以做partition, 这是物理分区，只支持按时间分区。

4. 使用Aggregation可以提高性能。但是Aggregation本身是cube的一个子集，提高性能的同时也加大了数据冗余，所以不要用太多。

5. 使用BIA是比Aggregation更有效的方法，就是要花不少钱。

6. 维度设计上，避免很多数据量很大char.放在一个维度上，因为这样会让维度表变得很大。通常，尽可能拆分成更多的维度，然后在 multiprovider层面，把相关的char都放一个维度里，然后做好Mapping，这样可以让用户更容易理解MultiProvider. 不过维度太多会导致fact table巨大，所以要做好平衡。

7. 对于material等很大的主数据，使用Line item Dimension. 此类Dimension只可以有一个Char.

8. 定期刷新DB Statistics 可以提高reporting的效率。

9. 给Cube做Compression。 Compression 本质上是去掉Data Dimension，这样fact table就被压缩了，但是request id 也消失了，将无法通过request id去管理数据。

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

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

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

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