Hawkeye的底层分析系统基于Blink进行大数据分析，前段时间在优化慢query查询的过程中开发了应用TopN慢query获取的分析任务，其中用到的分析方法适用于其他类似求TopN的问题中。本文的TopN问题属于批处理范畴。

一、背景

经过hawkeye之前的慢query分析，每个应用不同程度的存在慢query,大量的慢query大大影响了引擎的性能，也会带来机器资源的浪费。为了优化Ha3的查询性能，我们将分析更深入了一步，分为如下三部分进行慢query的优化。。

• 应用TopN慢query的获取：获取top50的慢query，并分析出查询各阶段耗时占比；
• 各阶段耗时优化&验证：几种常见的优化手段，这些优化手段均是通过验证有效的方法；
• 优化收益评估：经过优化带来的价值主要体现在慢查询数的减少和容量预估的增加。

二、TopN慢查询获取流程

慢query数据来自应用的访问日志，query数量和应用的访问量有关，通常在千万甚至亿级别。从海量日志中获取TopN慢query属于大数据分析范畴。我们借助Blink的大数据分析能力，采用分治+hash+小顶堆的方式进行获取，即先将query格式进行解析，获取其查询时间，将解析后的k-v数据取md5值，然后根据md5值做分片，在每一个分片中计算TopN慢query，最后在所有的TopN中求出最终的TopN。下面图示为慢query任务的处理过程。

定时任务每天执行一次，将应用昨天的AccessLog按照上述流程处理一遍，从而获取应用的Top50慢query，从获取的top50慢query可以分析出一些应用访问不合理的地方，虽然不能完全代表高频慢query，但对于Top级的query优化也可以持续的对应用进行优化，提高查询性能，节约机器资源。

三、慢query的优化手段

按照平台用户易优化的原则，根据分析的结论数据提供了四种不同的query优化手段，按照阶段分为：

粗排阶段三种：

• rank_size数过大，建议减少rank_size数量，可能会影响效果，需业务方评估；
• rank_size数量合理，但粗排阶段耗时占比超过50%，检查海选插件的性能；
• 正排过滤改为倒排召回，对于特定场景有很大作用，第四部分会讲到具体case；

精排阶段一种：

• 战马耗时占比超过50%，建议检查战马相关插件的性能。

目前的优化手段在tisplus2平台上进行透出，点击优化可以看到诊断具体慢query的优化建议，如果上述四条建议条件均不满足，则需要联系平台管理员具体诊断下慢的原因了。

四、优化的收益

第四部分介绍下采用上述优化带来的效果，某应用采用正排过滤改为倒排召回的优化，采用此优化的前提是：1.swift消息无update消息；2.对应字段是可枚举类型；3.非子doc并且seek数远大于match数。采用此优化之后，慢query数直线下降，由百万级别降到0，且容量预估提升了8倍（即相同资源可抗的访问量上涨了8倍）。

五、总结

目前慢query的优化功能已上线，用户可以自行查看应用的访问状况和访问较慢的query，并针对性的进行分析和初步的优化，相比较之前是一个从无到有的过程。但是目前的慢query分析还有很多可以优化的地方，比如优化建议的丰富、慢query的自动优化以及实时慢query的分析等，目前的慢query分析已经能起到一定的问题诊断和优化的作用了，未来还需要持续的挖掘和深入。如果你对数据分析和引擎优化方面有心得，欢迎与我交流，也欢迎有才的你加入搜索事业部。