業(yè)務背景:

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

DAS這這些年提供了多個對SQL數(shù)據(jù)進行分析的L2功能包括：專業(yè)版SQL洞察，全量SQL，慢日志， 一鍵診斷， 鎖分析，會話等。每一個功能沉淀了DBA在不同角度分析不同問題的方法，不同實例，不同業(yè)務診斷問題的方法略有不同。對于并不是很熟悉DB運維的用戶來說，DAS在提供一個統(tǒng)一高效簡單的方式去幫助用戶去定位問題。我們結合SQL變慢的多指標特征，提出一種基于特征相似度匹配的方法 VLDB 2020 沉淀到自治中心功能當中, 但對于異常SQL中存在的業(yè)務屬性的相似性以及錯綜復雜的影響與被影響的關系，理清楚問題SQL與各種資源的異?，F(xiàn)象的傳播關系是具有挑戰(zhàn)的問題，DAS團隊仍然在如何找到異常SQL這個課題上繼續(xù)進行了研究和探索，在探索的過程中我們提供了一個新的分析功能SQL請求行為識別幫助用戶更好的定位SQL問題。

問題描述:

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

當用戶使用DAS專業(yè)版SQL洞察的功能的時候，即使我們將全量SQL流水，壓縮聚合成模板，模板的數(shù)量也是驚人的，我們可以看到大量特征趨勢相近的模板。所以如果我們根據(jù)SQL的請求行為將模板進一步壓縮，這樣用戶可以更好的定位異常SQL的問題。

目前DAS產品功能和業(yè)界AWS Azure等其他產品都有初步的異常SQL定位能力，通過對采集的SQL數(shù)據(jù)在各個維度的排序，讓用戶自己定位數(shù)據(jù)庫問題，這種方式對于80%以上簡單的數(shù)據(jù)庫問題是有效的，但是在復雜業(yè)務場景和DBA都很難定位的數(shù)據(jù)庫問題效果是很差的。以阿里云內部管控的元數(shù)據(jù)庫集群實例為例，今年平均每月發(fā)生10多次的CPU打滿問題，全年發(fā)生數(shù)次性能相關的故障問題，但是每次的問題都不同，有時候DBA只能找到現(xiàn)象，難以快速定位問題根因。所以通過對用戶請求行為的分析，會更好的迭代DAS數(shù)據(jù)庫自治服務產品，解決我們復雜場景的數(shù)據(jù)庫性能問題，提高整個數(shù)據(jù)庫各個引擎的穩(wěn)定性，易用性，效率。

業(yè)界產品:

AWS: RDS： Performance Insight

和目前DAS產品功能一樣，采集的數(shù)據(jù)維度類似，通過Top N ranking的方式進行異常SQL定位，沒有SQL請求行為分析功能

Azure: Query Performance Insight

通過取Top N的方式對SQL請求進行定位，可以定位到60%的明顯問題，但是無法定位SQL請求復雜業(yè)務的數(shù)據(jù)庫問題，沒有SQL請求行為分析功能

騰訊云：DB Brain功能，和目前DAS現(xiàn)有功能類似，沒有SQL請求行為分析功能

華為云：Database Admin Service，和目前DAS現(xiàn)有功能類似，沒有SQL請求行為分析功能

挑戰(zhàn)&難點

Challenges:

規(guī)?；魬?zhàn):

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

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

監(jiān)控診斷挑戰(zhàn)：

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

針對潛在的SQL請求導致的數(shù)據(jù)庫性能問題，根因定位需要做到近實時問題定位。

繁雜的數(shù)據(jù)庫異?，F(xiàn)象：

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

人工根因定位：

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

幫助后端開發(fā)人員合理安排請求查詢的流程，盡量讓資源密集型請求從業(yè)務角度打散

幫助DBA找到不同請求之間在業(yè)務層面直接和間接的關系。

賦能自治服務：

更加精細化的限流: 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解決方案:
啟發(fā)思路：

在很多后端應用開發(fā)的過程中，后端架構設計往往會保證接口的冪等性，例如項目中為了解決timeout問題，通常會引入重試機制，有時候會請求重復數(shù)據(jù)，消費消息有時候讀重復數(shù)據(jù)之類的冪等性問題。例如多次insert或update可能會造成數(shù)據(jù)錯誤。

為了解決這些冪等性的方法，后端通常會使用這些方式例如 先select再insert，加悲觀鎖/樂觀鎖/分布式鎖，或者根據(jù)狀態(tài)機來管理有狀態(tài)的業(yè)務。

支付場景狀態(tài)機示例：

......

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

.....

所以同一個業(yè)務流程會伴隨這多個SQL請求，串行或并行，這就意味著這些SQL在執(zhí)行趨勢上存在這關聯(lián)性，這種關聯(lián)性和業(yè)務有關。當我們發(fā)現(xiàn)業(yè)務異常的時候，同時伴隨這指標異常，所以當我們定位異常SQL的時候，同一業(yè)務下的SQL都會有異?，F(xiàn)象，所以通過這些SQL的趨勢特征我們可以將海量SQL數(shù)據(jù)進行通過算法進行聚類。所以我們想到通過分析SQL的同源性，站在業(yè)務視角來定位異常SQL，可以更有效率的定位異常SQL

流程框架：

感知過程：

在診斷的過程中，DAS后端首先從統(tǒng)一數(shù)據(jù)層(DataSet Layer)請求，性能數(shù)據(jù)(Perf Data)和SQL請求數(shù)據(jù)（SQL Query Data），性能數(shù)據(jù)通過多指標異常檢測(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經過模板化處理后的數(shù)據(jù)，運用Graph Based的聚類方法，將海量的SQL按照請求行為的特征進行劃分，最后根據(jù)聚合后請求行為的貢獻度評分進行排序(Query Behavior Ranking)，檢測異常請求及其作用于性能指標的現(xiàn)象.

根因分析過程：

示例：

爛SQL模板 sql_i --> 造成了鎖等待現(xiàn)象---> 影響了mysql.rows_lock_wait_time指標

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

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

通過SQL解釋了指標異?，F(xiàn)象之后，還有很多故障問題我們無法精確定位，例如主備延遲,鎖問題,OOM,內核問題等，這些問題可能導致了執(zhí)行SQL的耗時增加，反過來，SQL也有可能產生這些問題的現(xiàn)象。

(Anomaly Propagation Analysis )幫助我們對這些現(xiàn)象之間，進行傳播關系的分析。這里的分析我們通過時間先后關系結合我們歷史案例數(shù)據(jù)綜合進行比對, 最后將得出的異常傳播鏈和整個DAS分析過程和建議并添加到后端的case庫并更細case model。Case Model會根據(jù)反饋不斷疊加調整匹配參數(shù)，給出更精準的建議。

基于請求行為識別的異常SQL定位案例:

定位會話(active_session)突增尖刺問題：

下圖數(shù)據(jù)庫實例活躍會話有異常的尖刺，這種尖刺持續(xù)時間過長，對一些敏感業(yè)務會有造成潛在的問題，我們想要定位尖刺的原因，首先DAS的實時異常檢測可以檢測出多指標的異常時間段。對于CPU，活躍會話異常的檢測會透傳出黃色異常事件的提示。

活躍會話通常和總執(zhí)行耗時強相關，通過SQL請求行為分析選擇對應指標，并點擊分析

找到和會話相似的指標，并點擊查看，按照總耗時排序，可以找到對會話異常"貢獻"最大的異常SQL，

點擊對應SQL_ID 查看詳情，通過趨勢行為ranking的結果，可以清楚的看到這個SQL變慢了和歷史趨勢相比變慢了。通過執(zhí)行趨勢可以看到異常趨勢和歷史趨勢完全不同，且與活躍會話異常的趨勢相吻合

最終定位：這條SQL執(zhí)行次數(shù)突增(從1000次執(zhí)行超過8000多次)，導致其他SQL執(zhí)行耗時變慢，造成了活躍會話堆積產生了active_session指標突增現(xiàn)象

CPU打滿(cpu_usage)突增問題：

下圖數(shù)據(jù)庫實例CPU被打滿，

除了SQL設計CPU密集型計算諸如join，等比較昂貴的操作外，絕大部分情況，CPU和掃描行數(shù)成正相關，在SQL請求行為分析選擇，cpu_usage和總掃描行數(shù),

我們比較容易定位到和CPU關聯(lián)的指標

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

未來計劃

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

原文鏈接：http://click.aliyun.com/m/1000282743/