Cube模型刷新调研措施.docVIP

Cube模型刷新调研方案 Cube模型刷新 全量更新和增量更新 全量更新 Tip 1: 当刷新立方体时间不是很长，要刷新的立方体的数量不是很多的时候，这时我们就可以考虑用Cube模型的全量更新。 Tip 2:目前IFAR项目组用的全部是全量更新，据他们的经验所得，大概一个刷出来的Cube模型700M需要1小时20分钟左右. 增量更新 当刷新立方体时间过长的时候，增量更新是缩短刷新时间的好办法。增量更新的时候，只会对立方体加载新增加的数据，以前的数据不会进行更改，这样会缩短读取数据的时间；另外在刷新立方体的时候，也会缩短刷新时间。 目前，增量更新的方式有两种： 普通增量更新（立方体属性/processing/The Cube is incrementally updated）（适用目前市场上的所有版本） Tip 1: 在立方体的结构（包括指标，维度，层次等）发生变化，必须重新全部加载数据 Tip 2: 推荐您定期重建立方体。第一次建立立方体时，自动分区（ Auto-Partitioning）功能可以将维度和层分割为多个分区层（partitioning level）。 在此之后所有新的类别将被加到 “0”分区层上。 如果随时间的变化增加了很多类别，PowerCube用户最终会遇到性能问题。通常建议7次增量更新之后，需要重新全量加载一次立方体 按时间分区更新（新增立方体/Cube Group/Enable Time-based Partitioning）（7.0以后版本支持） 按时间分区更新技术是基于普通增量更新之上的，使用按时间分区会生成一个虚拟立方体（该立方体并不保存数据，只保存维度信息），一个定义文件，还有包含数据的若干子立方体。 举例说明：有一年的数据，按月分区，这样每个月就会有一个立方体，总共是12个。 Tip 1: 立方体增量更新之后，请保存模型，这样可以保证Category的完整性。如果Category不完整，可能会存在子立方体的Category在虚拟立方体中找不到的情况，这样立方体的刷新是无法继续的。 Tip 2: 子立方体默认都是增量更新的，所以和普通增量更新一样，如果某个子立方体有了多次刷新之后，也必须进行一次全量更新。比如：按月分区但是每天都刷新数据，当月的立方体必然会进行多次更新，这时候就必须删掉当月的立方体，重新刷新一下。 Tip 3: 通常建议按月分区，按日分区的话，一年的子立方体太多，打开虚拟立方体的时候速度会比较慢，如果按季度、年分区的话，可能会有Tip 2中的问题。 根据业务分析考虑Cube模型的大小来决定是用全量更新和增量更新 Tip 1:考虑方案1：所有数据都按一个Cube模型来存放， 好处是：可以满足跨年，整体进行数据分析和比较。 坏处是：由于数据量比较大，查询速度就会相应的变慢，这时就不能用全量更新了，只能用增量更新了。 综合以上分析可得，此方案只适合用增量更新，用全量更新的话，会耗很长时间，而用增量更新的话，又面临着对数据非常严格的要求。 Tip 2:考虑方案2：按年月，来划分，到底分多少个Cube模型，比如按年分，一年一个cube模型，这样的话，我们更新的时候，只更新某一年的，这样可以全量更新，速度也相对来说，比较快，不足的地方，数据分析的时候，不能cube模型数据之间的夸年进行比较，如果需要有比较的业务时，也只能事先通过计算得到。 注：在Uinx下单个文件的存储大小，不能超过4G。 全量更新与增量更新执行角本和格式区别 现在要实现增量刷新就要用增量的脚本来执行而不能与全量刷新角本混为一谈。MDL是只能进行全量刷新的，增量刷新只能用PYI，且IQD所引用的表要是增量表，即表中的数据只能包括当前要新增到Cube中的数据，否则会进行累加。在进行增量时，一般的做法是：首先将MDL转为PYI，同时进行一次全量刷新；以后的增量刷新对PYI执行就可以了。 还有一个问题就是，如果真的要采用增量刷新的话，就要准备两套表（一全数据表，一增量表即临时表），两套立方体模型（因为度量IDQ所取的表不同，分别对应两套不同的表）。这对于刚刚开发完的项目存在一定的挑战性。 注：刷CUBE之前需要KILL一进程杀进程命令： taskkill /f /im ppesbusserver 注：上面shell角本，能对Cube模型进行刷新，同时也能对数据进行刷新。 Tip 2:在Uinx下可以开启多线程，对多个shell角本，同时进行执行。 注：技术难点是Uinx不太熟悉，不知道怎样去开启进程和线程去执行shell角本，怎样判断是否执行完成，如果报错了，怎样去处理，怎样用日志记录。 Java程序调用shell角本基本流程图 通过编写一段java代码，进行有规律的去调用shell角本，来刷新Cube模型。 JAVA 调用