SQL請求行爲識別新功能，幫助解決異常SQL檢測之大海撈針問題

簡介：對於異常SQL中存在的業務屬性的類似性以及錯綜複雜的影響與被影響的關係，理清楚問題SQL與各類資源的異常現象的傳播關係是具備挑戰的。DAS團隊仍然在如何找到異常SQL這個課題上繼續進行了研究和探索，在探索的過程當中咱們提供了一個新的分析功能SQL請求行爲識別幫助用戶更好的定位SQL問題。

業務背景:

DAS(Database autonomy service)爲上百萬數據庫實例的穩定運行保駕護航，其中精準定位數據庫運行過程當中的異常SQL是DAS最基本的功能。數據庫90%以上的問題都來源於數據庫的異常請求，不管是雙十一的集團海量交易請求行爲，仍是用戶業務變化的請求行爲，每時每刻都影響着數據庫的性能。自動駕駛汽車經過感知路況圖像變化的行爲來掌握車的方向，而自動駕駛數據庫經過感知和識別用戶請求行爲來不斷修復優化數據庫的各類問題，爲雲數據庫保駕護航。如何從海量數據庫中的海量請求定位出不一樣數據庫引擎不一樣場景的問題是多年以來困擾DBA的難題。在推薦領域，經過分析用戶的行爲習慣代替了機械式網頁展現精準推薦給用戶指望的文字/視頻/產品，提高用戶體驗和產品轉化率，一樣下一代數據庫自動駕駛平臺也須要分析用戶請求行爲，用戶開發業務行爲，推薦出相應優化修復擴容等操做，提高自動駕駛數據庫的效率，讓數據庫更快更穩更安全。因此從用戶請求行爲和業務行爲出發，在海量數據庫實例的海量請求中進行數據挖掘是一個很是值得深刻研究的課題，同時也是數據庫自動駕駛平臺很是依賴的底層技術能力, 向上支撐DAS數據庫自治服務各個場景的自治能力。

DAS這這些年提供了多個對SQL數據進行分析的L2功能包括：專業版SQL洞察，全量SQL，慢日誌， 一鍵診斷， 鎖分析，會話等。每個功能沉澱了DBA在不一樣角度分析不一樣問題的方法，不一樣實例，不一樣業務診斷問題的方法略有不一樣。對於並非很熟悉DB運維的用戶來講，DAS在提供一個統一高效簡單的方式去幫助用戶去定位問題。咱們結合SQL變慢的多指標特徵，提出一種基於特徵類似度匹配的方法 VLDB 2020 沉澱到自治中心功能當中, 但對於異常SQL中存在的業務屬性的類似性以及錯綜複雜的影響與被影響的關係，理清楚問題SQL與各類資源的異常現象的傳播關係是具備挑戰的問題，DAS團隊仍然在如何找到異常SQL這個課題上繼續進行了研究和探索，在探索的過程當中咱們提供了一個新的分析功能SQL請求行爲識別幫助用戶更好的定位SQL問題。

問題描述:

如下圖爲例，實例CPU出現尖刺突增的現象，數據庫有cpu打滿潛在風險，當用戶的請求量較少或者請求的SQL模式較少的時候，經過指標的排序篩選是很容易找到問題SQL的，但當用戶的全量SQL模板超過上萬甚至上億條，用戶經過當前DAS頁面沒法快速定位異常SQL，咱們須要經過更多數據提供更高效的方式，來定位異常請求。

當用戶使用DAS專業版SQL洞察的功能的時候，即便咱們將全量SQL流水，壓縮聚合成模板，模板的數量也是驚人的，咱們能夠看到大量特徵趨勢相近的模板。因此若是咱們根據SQL的請求行爲將模板進一步壓縮，這樣用戶能夠更好的定位異常SQL的問題

目前DAS產品功能和業界AWS Azure等其餘產品都有初步的異常SQL定位能力，經過對採集的SQL數據在各個維度的排序，讓用戶本身定位數據庫問題，這種方式對於80%以上簡單的數據庫問題是有效的，可是在複雜業務場景和DBA都很難定位的數據庫問題效果是不好的。以阿里雲內部管控的元數據庫集羣實例爲例，今年平均每個月發生10屢次的CPU打滿問題，整年發生數次性能相關的故障問題，可是每次的問題都不一樣，有時候DBA只能找到現象，難以快速定位問題根因。因此經過對用戶請求行爲的分析，會更好的迭代DAS數據庫自治服務產品，解決咱們複雜場景的數據庫性能問題，提升整個數據庫各個引擎的穩定性，易用性，效率。

業界產品:

AWS: RDS： Performance Insight

和目前DAS產品功能同樣，採集的數據維度相似，經過Top N ranking的方式進行異常SQL定位，沒有SQL請求行爲分析功能

Azure: Query Performance Insight

經過取Top N的方式對SQL請求進行定位，能夠定位到60%的明顯問題，可是沒法定位SQL請求複雜業務的數據庫問題，沒有SQL請求行爲分析功能

騰訊雲：DB Brain功能，和目前DAS現有功能相似，沒有SQL請求行爲分析功能

華爲雲：Database Admin Service，和目前DAS現有功能相似，沒有SQL請求行爲分析功能

挑戰&難點

Challenges:

規模化挑戰:

The sea of performance issues in the sea of queries from the sea of the databases

用戶的業務請求豐富，如何從海量數據庫實例中的海量請求中定位多種數據庫引擎的性能問題。

監控診斷挑戰：

7*24 real time anomaly detection => 7*24 root cause analysis in near real time

針對潛在的SQL請求致使的數據庫性能問題，根因定位須要作到近實時問題定位。

繁雜的數據庫異常現象：

異常指標一般與多條SQL請求有關，沒法用單條SQL來解釋異常緣由且多個業務的SQL請求之間相互影響，關聯的問題包括全表掃描/索引/鎖問題/緩存擊穿/內核問題等。多個問題在指標現象存在類似性和不一樣Motivations:

人工根因定位：

幫助DBA或用戶解決性能問題，工單問題

幫助後端開發人員合理安排請求查詢的流程，儘可能讓資源密集型請求從業務角度打散

幫助DBA找到不一樣請求之間在業務層面直接和間接的關係。

賦能自治服務：

更加精細化的限流: Limit anomalous SQL more meticulous

更加準確對workload預測: Forecast workload more accurate

更好的劃分workload: Workload can be well-partitioned

更好的預估自治操做的資源收益: Estimate the SQL Resource Cost for autonomous actions

在第一時間解決潛在的性能問題：Crack the potential performance issue at the first place

DAS解決方案:

啓發思路：

在不少後端應用開發的過程當中，後端架構設計每每會保證接口的冪等性，例如項目中爲了解決timeout問題，一般會引入重試機制，有時候會請求重複數據，消費消息有時候讀重複數據之類的冪等性問題。例如屢次insert或update可能會形成數據錯誤。

爲了解決這些冪等性的方法，後端一般會使用這些方式例如 先select再insert，加悲觀鎖/樂觀鎖/分佈式鎖，或者根據狀態機來管理有狀態的業務。

支付場景狀態機示例：

......

update \`bill\` set status=1 where id=520 and status=0;

下單行爲 SQL A

update \`bill\` set status=2 where id=520 and status=1;

支付行爲 SQL B

update \`bill\` set status=3 where id=520 and status=2;

取消訂單行爲 SQL C

.....

因此同一個業務流程會伴隨這多個SQL請求，串行或並行，這就意味着這些SQL在執行趨勢上存在這關聯性，這種關聯性和業務有關。當咱們發現業務異常的時候，同時伴隨這指標異常，因此當咱們定位異常SQL的時候，同一業務下的SQL都會有異常現象，因此經過這些SQL的趨勢特徵咱們能夠將海量SQL數據進行經過算法進行聚類。因此咱們想到經過分析SQL的同源性，站在業務視角來定位異常SQL，能夠更有效率的定位異常SQL

流程框架：

感知過程：

在診斷的過程當中，DAS後端首先從統一數據層(DataSet Layer)請求，性能數據(Perf Data)和SQL請求數據（SQL Query Data），性能數據經過多指標異常檢測(MTS Anomaly Detection)/特徵提取(Feature Extraction)

異常請求定位過程：

示例：

模板集合X:{sql\_a , sql\_b, sql\_c} ==> 影響了 mysql.cpu\_usage 指標變化 

         ==>sql 集合的影響程度 (推算cpu\_time佔比)

模板集合Y: {sql\_i , sql\_j, sql\_k } ==> 影響了 mysql.active\_session 指標變化 

         ==> sql 集合的影響程度 (推算session佔比)

感知層感知到時序指標異常後，經過全量SQL通過模板化處理後的數據，運用Graph Based的聚類方法，將海量的SQL按照請求行爲的特徵進行劃分，最後根據聚合後請求行爲的貢獻度評分進行排序(Query Behavior Ranking)，檢測異常請求及其做用於性能指標的現象.

根因分析過程：

示例：

爛SQL模板 sql\_i --> 形成了鎖等待現象---> 影響了mysql.rows\_lock\_wait\_time指標 

               --> 形成模板Y集合的SQL被阻塞 -->  形成session的突增 

               --> 被阻塞的Y集合中X集合中的CPU密集型SQL被阻塞 --> 形成了CPU突增 

經過SQL解釋了指標異常現象以後，還有不少故障問題咱們沒法精肯定位，例如主備延遲,鎖問題,OOM,內核問題等，這些問題可能致使了執行SQL的耗時增長，反過來，SQL也有可能產生這些問題的現象。

(Anomaly Propagation Analysis )幫助咱們對這些現象之間，進行傳播關係的分析。這裏的分析咱們經過時間前後關係結合咱們歷史案例數據綜合進行比對, 最後將得出的異常傳播鏈和整個DAS分析過程和建議並添加到後端的case庫並更細case model。Case Model會根據反饋不斷疊加調整匹配參數，給出更精準的建議。

基於請求行爲識別的異常SQL定位案例:

定位會話(active\_session)突增尖刺問題：

下圖數據庫實例活躍會話有異常的尖刺，這種尖刺持續時間過長，對一些敏感業務會有形成潛在的問題，咱們想要定位尖刺的緣由，首先DAS的實時異常檢測能夠檢測出多指標的異常時間段。對於CPU，活躍會話異常的檢測會透傳出黃色異常事件的提示。

活躍會話一般和總執行耗時強相關，經過SQL請求行爲分析選擇對應指標，並點擊分析

找到和會話類似的指標，並點擊查看，按照總耗時排序，能夠找到對會話異常"貢獻"最大的異常SQL，

點擊對應SQL\_ID 查看詳情，經過趨勢行爲ranking的結果，能夠清楚的看到這個SQL變慢了和歷史趨勢相比變慢了。經過執行趨勢能夠看到異常趨勢和歷史趨勢徹底不一樣，且與活躍會話異常的趨勢相吻合

最終定位：這條SQL執行次數突增(從1000次執行超過8000屢次)，致使其餘SQL執行耗時變慢，形成了活躍會話堆積產生了active\_session指標突增現象

CPU打滿(cpu\_usage)突增問題：

下圖數據庫實例CPU被打滿，

除了SQL設計CPU密集型計算諸如join，等比較昂貴的操做外，絕大部分狀況，CPU和掃描行數成正相關，在SQL請求行爲分析選擇，cpu\_usage和總掃描行數,

咱們比較容易定位到和CPU關聯的指標

最終定位：這條全表掃描的SQL，形成了CPU被打滿從而致使了會話的堆積

將來計劃

DAS會支持更多引擎的實時檢測和異常定位，專業版結合用戶的全量SQL幫助更多用戶定位更多類型的數據庫實例問題。不只讓專業DBA更好的使用DAS管控數據庫實例，也讓數據庫領域的初學者無門檻的管控數據庫，真正保證數據庫實例自感知，自優化，自修復。

**相關閱讀：
**

數據庫自治服務DAS發佈年度新版本：1-5000，」數據庫自動駕駛「進入規模化時代

深度技術揭祕 | 大促狂歡背後，如何有效評估並規劃數據庫計算資源？

重磅 | 數據庫自治服務DAS論文入選全球頂會SIGMOD，領航「數據庫自動駕駛」新時代

功能更新｜DAS推出全局Workload優化功能，實現SQL自動診斷

乾貨｜一文讀懂阿里雲數據庫Autoscaling是如何工做的

本文內容由阿里雲實名註冊用戶自發貢獻，版權歸原做者全部，阿里雲開發者社區不擁有其著做權，亦不承擔相應法律責任。具體規則請查看《阿里雲開發者社區用戶服務協議》和《阿里雲開發者社區知識產權保護指引》。若是您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將馬上刪除涉嫌侵權內容。