Apache Kylin使用总结

Apache Kylin是一款以预处理Cube来提高查询速度的OLAP引擎。

首先对维度表做个简单的介绍。

麒麟只支持星型模型，也就是说一个事实表加上多个维度表。维度表不存在支架型结构。维度表存放的大多是描述性字段，用于筛选。其实以SQL的角度来看就是group by/filter through where 的效果。对于一个有N个维度的Cube，可以构建2的N次方个Cuboid。

最开始对Cuboid的概念不是很清楚。看OLAP的概念可以有上钻，切片之类的操作，但很少说道什么是Cuboid，和Cuboid里面到底存放什么。

首先说下Cuboid里面存放什么？其实就是定义那些指标，比如销售量，货物总量，或者说就是在麒麟建Data Model时的Measure。那么什么是Cuboid呢？Cuboid是某些维度的组合。从包含所有的维度的Base Cuboid到包含0个维度的Apex Cuboid。

在这个Cuboid中会根据维度的值对指标进行聚合，比如Sum，Count。比如日期维度里有20160901-20160930这三十个值，那么麒麟会把定义好的指标预聚合成三十个分组，当使用group by或者filter时只需要选取其中一个或者几个分组，再通过SQL引擎进行聚合。

那么接下来说下我们使用Apache Kylin时候遇到的坑吧，或者说一些我觉得比较难理解的地方。

首先Kylin是一个通过预处理的过程节省查询时间的OLAP工具，也就是说是空间换时间。所以设计的数据仓库模型尽量简洁，把大计算量的数据转换放到之前的ETL中去进行。开始我们陷入了Hive的思路，试想Kylin能不能加载Hive的UDF。事实上是完全没有必要的。

二是维度表中除了代理键外都设置成derived的维度，可以节省很多空间，因为Kylin自身对derived dimension做了优化。

三是如果维度基数大于一百万，Rowkey不建议使用字典，因为要加载进内存。当然如果使用fix_length，可能会增大Cube大小。对于基数较大的维度，可以选择sharding。sharding是一种分表分库的数据库存储方法。由于底层HBase可以并行查询，使用sharding可以提高查询效率。

四是Aggregation Group需要仔细设计。通过AGG可以把原来需要构建多个Cube的工作简化成构建一个Cube，多个AGG，减少了MR Job的开销。实验证明可以至少减少一半的时间。

五是如果维的基数过大时，和事实表join会报错：Scan row count exceeded threshold: 10000000, please add filter condition to narrow down backend scan range, like where clause.原因是Kylin设置了查询时使用内存大小为3G，

可以在kylin.config或者Server Config里添加kylin.query.mem.budget=8589934592解决。

这就是目前使用Apache Kylin遇到的一些坑，匆匆总结如有错误请拍砖