Kylin性能调优记——业务技术两手抓

背景

最近开始使用了新版本的Kylin，在此之前对于新版本的了解只是代码实现和一些简单的新功能测试，但是并没有导入实际场景的数据做分析和查询，线上Hadoop稳定之后，逐渐得将一些老需求往新的环境迁移，基于以前的调研，新版本（V2，版本为1.5.2）的Kylin提供了几个比较显著的功能和优化：

• 新的度量类型，包括TOPN、基于bitmap的精确distinct count和RAW。
• 自定义度量框架，用户可以定义一些特殊的度量需求。
• Fast Cubing算法，减少MR任务，提升build性能。
• 查询优化，Endpoint Coprocessor，并行scan和数据压缩，这部分对于查询性能提升还是比较显著的。
• shard hbase存储，基于一致性哈希的rawkey分布，尽可能的将大的cuboid分散到不同的region上，增加并行扫描度。
• spark计算引擎，in memory准实时计算，这两项目前还处于试验阶段。
• 新的aggregation group分区算法。

有了这么多新的特性和性能提升，经常拿新版本来应付用户的需求：新版本实现了xxx功能，肯定性能会很好，等到新版本稳定了再来搞这个需求吧。等到我们的新版本上线了，业务需求真正上来之后，才发现用起来没有相当的那么简单，对于Kylin这种直接面向用户需求的服务，对于一些特殊的需求更是要不断打磨和调整才能达到更好的性能。本文整理在接入云音乐一个较为复杂的需求的实现和中间调优的过程，一方面开拓一下自己的思路，另外也使得读者能改更好的使用Kylin。

业务需求

数据通过日志导入到Hive中查询，经过一定的聚合运算，整理成如图1中的格式。这个数据源是针对歌曲统计的，每一首歌曲包含歌曲属性信息（歌曲名、歌手ID，专辑ID等）、支付方式、所属圈子ID、标签信息等，需要统计的指标包括每一首歌曲的各种操作的PV和UV，操作包括播放、收藏、下载等10种。因此一共20左右个指标，然后需要按照这20个指标的任意一个指标计算TOP N歌曲和其他统计信息（N可能是1000,1W等），除此之外，在计算TOP N的时候还需要支持字段的过滤，可以执行过滤的字段包括支付方式、圈子ID、标签等。歌曲ID全部的成员数大概在千万级别，该表的数据每天导入到hive，经过初步的聚合计算生成图1中的格式，基本上保证了每天的每一个用户对于每一首歌曲只保留一条记录，每天的记录数大概在几亿条（聚合之后），查询通常只需要查询不同条件下的TOPN的song_id。查询性能尽可能的高（秒级&