【转】kylin优化

转自：

http://www.bitstech.net/2016/01/04/kylin-olap/

http://www.csdn.net/article/2015-11-27/2826343

http://tech.youzan.com/kylin-mondrian-saiku/

Apache Kylin对传统MOLAP的改进

计算Cube的存储代价以及计算代价都是比较大的， 传统OLAP的维度爆炸的问题Kylin也一样会遇到。 Kylin提供给用户一些优化措施，在一定程度上能降低维度爆炸的问题：

1. Cube 优化：

• Hierachy Dimension
• Derived Dimension
• Aggregation Group

Hierachy Dimension， 一系列具有层次关系的Dimension组成一个Hierachy， 比如年、月、日组成了一个Hierachy， 在Cube中，如果不设置Hierarchy， 会有 年、月、日、年月、年日、月日 6个cuboid， 但是设置了Hierarchy之后Cuboid增加了一个约束，希望低Level的Dimension一定要伴随高Level的Dimension 一起出现。设置了Hierachy Dimension 能使得需要计算的维度组合减少一半。

Derived Dimension, 如果在某张维度表上有多个维度，那么可以将其设置为Derived Dimension， 在Kylin内部会将其统一用维度表的主键来替换，以此来达到降低维度组合的数目，当然在一定程度上Derived Dimension 会降低查询效率，在查询时，Kylin使用维度表主键进行聚合后，再通过主键和真正维度列的映射关系做一次转换，在Kylin内部再对结果集做一次聚合后返回给用户

Aggregation Group， 这是一个将维度进行分组，以求达到降低维度组合数目的手段。不同分组的维度之间组成的Cuboid数量会大大降低，维度组合从2的（k+m+n）次幂至多能降低到 2的k次幂加2的m次幂加2的n次幂。Group的优化措施与查询SQL紧密依赖，可以说是为了查询的定制优化。 如果查询的维度是夸Group的，那么Kylin需要以较大的代价从N－Cuboid中聚合得到所需要的查询结果，这需要Cube构建人员在建模时仔细地斟酌。

1. 数据压缩：

Apache Kylin针对维度字典以及维度表快照采用了特殊的压缩算法，对于Hbase中的聚合计算数据利用了Hadoop的LZO或者是Snappy，从而保证存储在Hbase以及内存中的数据尽可能的小。其中维度字典以及维度表快照的压缩考虑到DataCube中会出现非常多的重复的维度成员值，最直接的处理方式就是利用数据字典的方式将维度值映射成ID， Kylin中采用了Trie树的方式对维度值进行编码

1. distinct count聚合查询优化：

Apache Kylin 采用了HypeLogLog的方式来计算DistinctCount。好处是速度快，缺点是结果是一个近似值，会有一定的误差。在非计费等通常的场景下DistinctCount的统计误差应用普遍可以接受。

具体的算法可见Paper，本文不再赘述：

http://algo.inria.fr/flajolet/Publications/FlFuGaMe07.pdf

使用Apache Kylin的实践总结

1、大的事实表采用天分区增量构建，为了不影响查询性能，可以定期做合并(Merge)，周期可以根据实际情况确定，我们一周进行一次合并。

2、对于维表比较大的情况，或者查询Select部分存在复杂的逻辑判断，存在Apache Kylin不支持的函数或语句时，可以将事实表和维表的关联处理创建为Hive视图，之后根据视图创建Cube模型。

3、每次查询必然带有的条件建议在字典设置步骤将其设置为Mandatory。这样会最终 Build出来Cube的大小会减少一半。

4、Cube的维度如果超过10个，建议将常用的聚合字段做分组，我们对于最大的16个维度分了三个组，每组大概在5个维度左右。

5、Cube定义中RowKey顺序：Mandatory维度，Where过滤条件中出现频率较多的维度，高基数维度，低基数维度。

6、对于Hierarchies，Derived维度方面配置优化可以参考社区文档：

http://kylin.incubator.apache.org/docs/howto/howto_optimize_cubes.html

7、部署层面，可以通过Nginx在前端做负载均衡，后端启动多个Query Server接收查询请求处理。