乾貨｜數據庫自治服務DAS首創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模板的數量也是相當龐大的，我們可以看到大量特徵趨勢相近的模板。所以如果我們根據SQL的請求行為將模板進一步壓縮，這樣用戶可以更清晰的搜索SQL模板。

目前DAS產品功能和業界雲廠商都有初步的異常SQL定位能力，功能大同小異，都是通過對採集的SQL數據在各個維度的排序，讓用戶自己定位數據庫問題，這種方式對於60%以上簡單的數據庫問題是可行的，但是在複雜業務場景和DBA都很難定位的數據庫問題效果是很差的。例如，數據庫請求SQL模板數量幾萬~幾億的數量級，單純依靠多維指標的排序搜索很難快速定位問題，所以通過對用戶請求行為的分析，可以更好的幫助解決我們複雜場景的數據庫性能問題，提高整個數據庫各個引擎的穩定性，易用性，效率。

挑戰&難點

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

監控診斷挑戰：針對潛在的SQL請求導致的數據庫性能問題，根因定位需要做到近實時問題定位

繁雜的數據庫異常現象：

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

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

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

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

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會根據反饋不斷疊加調整匹配參數，給出更精準的建議。