kylin的查询性能优化(一)

     

      平台是基于kylin及hadoop生态，搭建的大数据平台，其中多维数据分析是通过kylin实现的，为了满足大数据量的业务的实时查询并且响应时间秒出的需求，所以采用这套数据架构，实际的查询结果并没有达到预期的秒出结果集，下文及后续文章陆续介绍整个优化的全过程，直至达到业务的要求。

     kylin的强大之处就在于预计算，将时间转换为空间的理论，预计算结果是查询性能的一个很重要的原因；

   项目场景：

   维度：200多个维度值；指标：50个【count distinct ,count,sum】;查询维度在线自由组合

设计：所有的维度表中的维度字段都默认设置成衍生维度，事实表中的维度 关联字段，全部设置成正常维度；【补充：衍生维度不参与计算，正常维度参与预计算结果】，生成的cubeId：8个。

测试：针对项目所有的菜单进行测试，指标【count,sum】的查询性能10s之内，对于【count distinct】查询的时间在2分钟左右，性能比较差。

基于测试的结果和查询命中的cuebId发现，每次命中的cubeId,中包含多个维度字段值；并且对于衍生维度作为条件进行二次运算，这些都是导致查询慢的原因【通过日志观察可以看出】，另外机器资源都比较优秀，对性能是不存在影响的。

下面主要对精确去重【count disntinct】的指标进行调整

方案一：

1、增加cubeId的个数：

主要是在维度设置部分通过必要维度、层级维度、联合维度、包含维度这几个部分进行分配。

1. 衍生维度的处理：

目前kylin支持的最多维度字段63个，cubeId最多4096，，基于场景描述，要合理的将衍生维度变为正常维度，计算出预处理的结果，必须结合业务情况进行设计，多次和业务沟通，将经常使用的场景时间控制在秒级别，不常用的一般控制在1分钟之内或者个别的会更长一些2分钟左右。【离开业务的技术是不存在的】

1. 合理设置rowkey顺序

    Rowkey的顺序对于维度组合查询的性能有一定的印象作用，kylin的rowkey和hbase的rowkey有相似之处【后面会有文章介绍】 。

  通过以上两个方案多次调整，测试：时间较之前有所优化；控制在77s之内，同时发现如下两个问题：

1. kylin预计算的存储的block都特别大，超过了默认的设置；
2. Rowkey顺序超过20的查询性能较差一些；

方案二：

通过在社区进行沟通，发现是kylin默认的参数配置shard-size=256m没有起作用，

因此设置shard-size=64m进行调整，其他的设置保持不变，构建之后测试性能提升到50s;

同时通过查询hdfs上的存储情况都在256m-700m之间

基于方案二在次调小shard-size=16m，查询性能控制在25s之内性能进一步提升，同时通过查询hdfs上的存储情况都在256m，

阶段一：基于方案1和2的调整之后，经常用到的维度组合查询控制在5s内，不常用维度或者高阶维是30s内。

       补充：kylin的查询是基于spark的，默认设置是instance=4,cores=5.同时并发的task是20个，executor.memory=4G;eg：一个cubeId的存储大小是2G,那么在前台查询的时候，后台只会起一个task去执行这个命令；如果一个cubeId的存储变成了4文件，每一个是500m，那么查询的时候后台就会起4个task去执行合格任务;另外，如果一个cubeId的存储分片比较多，由于最多的时候并发是20个，可能执行需要两轮，查询的性能会变的更差一些。要合适的把握参数的调整【kylin的查询详请见后面文章】。

      总结，在使用kylin的时候，不能只但对关注前端的设计问，同时注意后台的处理机制是否合理，每一个场景不同，测试的结果也不同，某一些场景可能覆盖了存在的问题。对所有的自己开发的产品或者第三方产品，都要有这个想法。