《Apache Kylin cube优化指南》

1.生产场景

号称亚秒级的大数据分析引擎---Apache Kylin就要投产了，但这只OLAP中的神兽，在build数据的时候，速度奇慢且太耗空间，大概一个月的数据，build将近半个小时，且大小将近2GB！！！

2.需求

如何正确驾驭这只OLAP界的“神兽”，让它发挥应有的水平，降低数据膨胀率并且缩短Cube的build时间。

3.解决方案

①数据层面

生产场景中Kylin是以Hive做MetaData的，之前会有这么一种Cube，一个大表，关联两个数据量也颇多的表，经Kylin官方人士解答，这样子是不行的，所以更新后的建表方案转为若干大表关联成的一个视图，类似一张宽表，作为Cube的主表，而和这个主表相关联的lookup表均为数据量相当小的小表。

②Kylin层面

1.尽量将需要展现的字段作为维度，没必要所有的一股脑加进去。

2.每次查询或者要经常group by的字段作为Mandatory维度。且该维度放在rowkey的最前面。

3.将数量相近也就是说某两个字段通过select count("字段名")获取的结果近似1:1，设置为joint维度。

4.rowkey的顺序按查询频率从高到低，从前往后排。

5.将经常出现在同一SQL中的不同维度放置在一个维度组中，将从不出现在一个SQL查询中的不同维度设置在不同的维度组中。

6.Dictionary默认为dict类型，如果某个字段中的值非常大（小幽遇到过的一个字段中的值保存成文本足足有23Kb！！！），大到以至或者可能使得Cube在build过程中出现OOM的错误，则需要将该字段的值设置为fixed_length类型,取可以展现这个维度的前length个字节，比如对于之前那个23kb的字段值，经和业务人员协商，发现取前4000个字节就可以表示这个字段了。所以fixed_length的值设置为4000.值得一提的是，Dictionary默认为false，是不给该字段在内存中建立词典树的，而更改为true则表示给该字段建立词典树。有词典树，则会优化带有该字段的SQL查询，提升查询速度，但相应地也会消耗一些内存。

4.优化结果

经过优化，近似每月数据量均匀分布的一年Cube，build时长均在10min中以内，且大小也维持在10M以内。

5.参考文献

Apache Kylin的Joint Dimensions怎么用

Kylin使用之创建Cube和高级设置