Hawkeye的底層分析系統基于Blink進行大資料分析，前段時間在優化慢query查詢的過程中開發了應用TopN慢query擷取的分析任務，其中用到的分析方法适用于其他類似求TopN的問題中。本文的TopN問題屬于批處理範疇。
經過hawkeye之前的慢query分析，每個應用不同程度的存在慢query,大量的慢query大大影響了引擎的性能，也會帶來機器資源的浪費。為了優化Ha3的查詢性能，我們将分析更深入了一步，分為如下三部分進行慢query的優化。。
應用TopN慢query的擷取：擷取top50的慢query，并分析出查詢各階段耗時占比；
各階段耗時優化&驗證：幾種常見的優化手段，這些優化手段均是通過驗證有效的方法；
優化收益評估：經過優化帶來的價值主要展現在慢查詢數的減少和容量預估的增加。
慢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優化手段，按照階段分為：
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分析已經能起到一定的問題診斷和優化的作用了，未來還需要持續的挖掘和深入。如果你對資料分析和引擎優化方面有心得，歡迎與我交流，也歡迎有才的你加入搜尋事業部。
