Hawkeye:TopN慢query的獲取與優化

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分析已經能起到一定的問題診斷和優化的作用了，未來還需要持續的挖掘和深入。如果你對資料分析和引擎優化方面有心得，歡迎與我交流，也歡迎有才的你加入搜尋事業部。