平台是基于kylin及hadoop生态搭建的大数据平台其中多维数据分析是通过kylin实现的为了满足大数据量的业务的实时查询并且响应时间秒出的需求所以采用这套数据架构实际的查询结果并没有达到预期的秒出结果集下文及后续文章陆续介绍整个优化的全过程直至达到业务的要求。kylin的强大之处就在于预计算将时间转换为空间的理论预计算结果是查询性能的一个很重要的原因项目场景维度200多个维度值指标50个【count distinct ,count,sum】;查询维度在线自由组合设计所有的维度表中的维度字段都默认设置成衍生维度事实表中的维度 关联字段全部设置成正常维度【补充衍生维度不参与计算正常维度参与预计算结果】生成的cubeId8个。测试针对项目所有的菜单进行测试指标【count,sum】的查询性能10s之内对于【count distinct】查询的时间在2分钟左右性能比较差。基于测试的结果和查询命中的cuebId发现每次命中的cubeId,中包含多个维度字段值并且对于衍生维度作为条件进行二次运算这些都是导致查询慢的原因【通过日志观察可以看出】另外机器资源都比较优秀对性能是不存在影响的。下面主要对精确去重【count disntinct】的指标进行调整方案一1、增加cubeId的个数主要是在维度设置部分通过必要维度、层级维度、联合维度、包含维度这几个部分进行分配。衍生维度的处理目前kylin支持的最多维度字段63个cubeId最多4096基于场景描述要合理的将衍生维度变为正常维度计算出预处理的结果必须结合业务情况进行设计多次和业务沟通将经常使用的场景时间控制在秒级别不常用的一般控制在1分钟之内或者个别的会更长一些2分钟左右。【离开业务的技术是不存在的】合理设置rowkey顺序Rowkey的顺序对于维度组合查询的性能有一定的印象作用kylin的rowkey和hbase的rowkey有相似之处【后面会有文章介绍】 。通过以上两个方案多次调整测试时间较之前有所优化控制在77s之内同时发现如下两个问题kylin预计算的存储的block都特别大超过了默认的设置Rowkey顺序超过20的查询性能较差一些方案二通过在社区进行沟通发现是kylin默认的参数配置shard-size256m没有起作用因此设置shard-size64m进行调整其他的设置保持不变构建之后测试性能提升到50s;同时通过查询hdfs上的存储情况都在256m-700m之间基于方案二在次调小shard-size16m查询性能控制在25s之内性能进一步提升同时通过查询hdfs上的存储情况都在256m阶段一基于方案1和2的调整之后经常用到的维度组合查询控制在5s内不常用维度或者高阶维是30s内。补充kylin的查询是基于spark的默认设置是instance4,cores5.同时并发的task是20个executor.memory4G;eg一个cubeId的存储大小是2G,那么在前台查询的时候后台只会起一个task去执行这个命令如果一个cubeId的存储变成了4文件每一个是500m那么查询的时候后台就会起4个task去执行合格任务;另外如果一个cubeId的存储分片比较多由于最多的时候并发是20个可能执行需要两轮查询的性能会变的更差一些。要合适的把握参数的调整【kylin的查询详请见后面文章】。总结在使用kylin的时候不能只但对关注前端的设计问同时注意后台的处理机制是否合理每一个场景不同测试的结果也不同某一些场景可能覆盖了存在的问题。对所有的自己开发的产品或者第三方产品都要有这个想法。