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

作者：佚名 2021-07-12 14:20:09

DAS(Database autonomy service)為上百萬數據庫實例的穩定運行保駕護航，其中精準定位數據庫運行過程中的異常SQL是DAS最基本的功能。

業務背景:

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，活躍會話異常的檢測會透傳出黃色異常事件的提示。