當資料庫遇上"自動駕駛"，阿里雲 DAS 在自治診斷的突破

作者 | 阿里雲技術專家 殷徵

在智慧化管控資料庫的探索與實踐過程當中，對資料庫SQL的診斷/根因定位是我們一直以來需要面對的問題，從阿里巴巴集團到阿里雲資料庫，我們管控的例項數從幾萬規模擴大到幾十萬規模，DBA在面對資料庫效能問題的時往往需要反覆觀察效能資料、日誌資料、會話資訊等，耗費較多的分析時間。大部分難以被發現的故障往往都是在海量慢SQL中的慢SQL，規則式的排序也許可以解決80%的問題，但是總會有邊界條件導致故障無法被發現或者定位。

DiagnosingRoot Causes of Intermittent Slow Queries in Cloud Databases

1) Cloud Databases  

2）Slow Queries  

3）Diagnose

Cloud Databases

隨著雲資料庫的快速發展，越來越多的企業將資料庫遷移到雲上，當資料庫遇到了雲，兩者的特性會碰撞出何種火花。

雲的本質是各種資源高效的池化，計算機的本質就是計算+儲存，而資料庫的本質是資料在生產、處理、儲存、消費的過程。當Cloud遇到Database，可以透過計算分析一體化來減少資料的移動，透過儲存計算分離實現資源池化和解耦，形成了雲原生+分散式為基礎雲資料庫的發展生態。

Slow Queries

慢SQL與iSQ (Slow Queries & Intermittent SlowQueries)

傳統慢SQL的方式往往會包含本身執行很慢的SQL，例如一個全表掃描查詢，或者複雜的巢狀查詢，或是沒有加入索引的查詢，這一類SQL往往可以透過我們自治場景SQL最佳化的方式來最佳化這類SQL，當然一些SQL本身也沒有什麼最佳化空間但執行時間大於1s，DBA在排查問題的時候往往會收到這些慢SQL的干擾。

而在眾多慢SQL當中，有一類SQL的執行時間比他歷史執行時間要慢的多，這時候我們就應該引起注意了，同樣的SQL為什麼會執行變慢？我們發現很多故障的前兆都伴隨這種SQL的出現，所以我們嘗試給這類SQL下一個統一的定義。

大部分iSQ都會影響使用者體驗，站在使用者視角，他們本身執行的SQL突然變慢了，使用者是可以感知到的。但是為什麼不用其他指標取衡量呢？

Tcp-RT是一個不錯的指標，他也可以反應查詢的RT，但是SQL模板是細粒度的指標，而RT是全域性維度的指標，很多場景下，當使用者QPS升高的時候，Tcp-RT是下降的；某些場景下，整體RT沒有變慢而某類SQL模板執行變慢了；所以全域性維度指標往往是有侷限性的，這就是為什麼我們需要透過下鑽進行根因定位。

因此，對比慢SQL的定義，我們給出了iSQ的定義，並相信透過iSQ方式篩選出來的SQL更能體現出資料庫執行的狀態。透過SQL執行時間>1s,這個規則並不能幫助使用者很好的篩選真正的問題SQL。這裡我們透過機率的方式比較簡單了定義了iSQ，當然我們未來也會根據SQL執行的更多特徵，藉助更多"資料驅動"的方式篩選出iSQ。

因此我們找到了一個根因定位的一個切入點，透過找到iSQ產生的根因來診斷資料庫的效能問題。我們發現傳統慢SQL的定義是透過閾值來定義的，這種規則驅動的方式並不能很好的幫助使用者縮小全量SQL的範圍，我們發現當資料庫出現比較阻塞，密集型Workload，鎖問題的時候，常常會出現iSQ(iSQ Intermittent Slow Queries，雲資料庫發生故障的時候，iSQ往往會提前出現，由於iSQ在其他時間段內執行時間並不慢，SQL的執行時間返回突然增長會導致業務的巨大變化,或者是由於業務變化受影響的）透過對於iSQ的根因定位，我們可以對資料庫常用的故障進行跟細粒度的根因定位，只有將資料庫的現象進行分類，我們後面的自修復/自最佳化Actions才可以減少action執行的衝突，合理的schedule我們的自治action，有效的給使用者提供合理的自治建議併發出自治action，形成閉環。

在與DBA排查問題的過程中，我們發現排查問題，DBA往往要瀏覽超過20個指標，透過監控頁面的對比，以及多指標的時序特徵來確定大致的原因。例如尖刺/均值漂移是DBA最關注的特徵，當然例如週期性和趨勢線的特徵也是DBA關注的。

DBA 在標註case的時候要花大量的時間，而標註往往是case by case，所以我們case的沉澱往往是透過故障文件或者工單，所以我們想到幾個突破點：

1. 是否可以透過模型來沉澱我們的case，透過大量的故障case來沉澱我們的演算法模型，透過資料驅動的方式來劃分我們的根因分類？

2. 是否可以減少DBA在標註過程中的標註時間？

模型的可解釋性是我們需要關注的，不同現象對應這不同根因，如何平衡根因定位準確率與根因定位可解釋性也是我們需要關注的。

從集團到阿里雲，我們管控的例項數從幾萬到超過50萬例項，我們對離線計算鏈路與實時計算鏈路有巨大的挑戰，這裡我們把演算法部署到我們DASMind演算法服務，底層藉助與函式計算的彈性擴充套件能力，最大程度的節省資源和保障我們流計算的穩定性。

我們目前已經支援MySQL/PolarDB 等關係型資料庫，也要支援Redis/Mongo 等NoSQL資料庫，我們希望透過一個具有魯棒性的方式，來沉澱DBA的經驗，而不是針對每一個資料庫單獨設計一套規則式的根因定位方法，儘可能的降低我們跨引擎標註case沉澱經驗的成本。

iSQUAD Overview

我們設計了iSQUAD這套框架並嵌入到DAS演算法服務DASMind當中，方案分為離線和線上兩條鏈路。

離線：透過對歷史iSQ資料的探測，來觸發異常抽取模組，抽取異常的特徵，在透過過濾重複指標，將每個iSQ對應的pattern進行聚類，獲得豐富的cluster，這些cluster透過BCM模組的特徵子空間的抽取後，用來給DBA進行標註，標註的樣本沉澱出pattern的模型，並提供給線上實時根因定位模組做分析，這樣線上鏈路從之前了1-5-10(1分鐘發現異常，5分鐘定位分類，10分鐘發出action)的方式得到了升級，我們把異常發現和根因定位分類這6分鐘時間壓縮到了1分鐘以內，做到了實時根因定位。

對於整體iSQAUD的線上診斷效果，我們對比了SIGMOD 2016 Dbsherlock: A performancediagnostic tool for transactional databases。

本方案系統圖，分為4個模組：

1) 異常檢測模組(Anomaly Extract)：

透過對多指標時序序列異常檢測，透過 Robust Threshold 魯棒性的閾值預測方法，結合時序序列週期性的方法，生成動態閾值，來判定每個指標的上限邊界，並解析出相應特徵是否為spike/meanshift/,此方法對比T-Test等傳統方法對更加實用和快速的判斷指標波動方向，下圖與傳統T-Test方法對比：

在實際業務場景中 Robust Threshold，對於穩定的時序序列可以很好檢測出spike/meanshift 特徵，但是業務場景往往是複雜的，對於Additive Model/Multiplicative Model/Weak-Seasonality, 我們DAS產品採用更加豐富異常檢測演算法庫去識別多個不同的時序特徵，關於異常檢測的方法將在後續文章詳細展開。本paper著重對spike和meanshift特徵進行了檢測。

2) 關聯分析, 指標依賴關係過濾模組(Dependencies cleaning)：

多指標存在依賴，透過大量歷史資料關聯分析，把異常方向總是波動相同的指標清理掉，留下關鍵指標，對比DBA經常關注的指標，有一定的相似性透過A異常/B異常的關聯性推匯出，AB兩個指標是否關聯，此類關聯分析方法用很多，並未對此方法單獨和傳統方法作對比：

3) 異常序列聚類模組(TOPIC)：

透過異常指標的相似度聚類完成iSQ1和iSQ2的相似度匹配，如果兩個iSQ的相似度匹配很高，認定為一類異常序列相似度演算法Sij表示iSQ i與iSQ j的相似度， T表示指標類別，|Kit,Kjt| 表示每個指標之間的相似度。

關聯匹配的演算法如下，透過KDTree的加速，結合層次聚類完成多指標異常序列的相似度匹配，相似度的閾值引數調整可以基於海量資料分類獲得。

聚類方法我們同時也進行了多個方法做了對比，Topic表現較好。同時也對異常抽取模組，和關聯分析模組的作用同時做了相應的對比：

4) 貝葉斯案例模型模組 BCM illustration

BCM作為基於例項的方法主要是透過一些代表性的樣本來解釋聚類/分類結果的方法。透過觀察代表性的樣本，我們可以直觀得獲得其對應族類的樣本宏觀特徵。透過Topic對異常序列的聚類產出的結果還需要增加序列的可解釋性，透過BCM進行相關資料的整合，進而將異常序列(Patterns)進行整合。 

下圖是DBA標註時候的案例，透過標註歷史的案例，來對現有的iSQ進行判定：

例如 mysql.cpu_usage +,mysql.select_ps+, mysql.qps+ 異常，BCM可以透過相似指標序列產出，CPUIntensiveWorkload, 這樣的聚類結果，當異常序列不在我們已知聚類序列裡面時，透過DBA的標註，可以標註出更多的異常序列，我們的後端案例庫會越來越豐富，聚類效果會越來越明顯，總分類如下圖。

我們最終實現了從根因分類到Solution的初步對映，DAS的決策中心會根據不同根因和其現象的patterns，來分發自治Action訊息到各個自治業務模組，擺脫了單純依靠規則驅動的方式，透過資料在各業務場景的內迴圈，我們的模型也同時在不斷更新和迭代，當新的根因和場景出現時，我們的分類會越來越細，同時可以適應多種業務場景和自治場景的根因定位。

我們HA的SQL是一個比較典型的場景，我們通常使用探活SQL去探測資料庫例項的心跳去保證資料庫的可用性。

但是當這個探活SQL變為iSQ的時候，資料庫通常會出現嚴重潛在的問題。對於資料庫無徵兆"突然掛掉"的問題，我們很難透過資料來推算出時間，HA通常透過探活SQL來解決"突然掛掉"的問題，但是在review阿里集團和阿里雲大量的故障case後，我們往往很難取判斷資料庫"半死不活"的場景，因為探活RT的連線還是可用的，但是SQL的RT會變慢，而傳統基於規則的監控時很難能檢測出這一類問題的，我們這兩年線上很多故障都是這種現象，而一直沒有很好的解決辦法。透過探活SQL變為iSQ的檢測，我們可以站在使用者視角第一時間發現SQL請求變慢的現象，一個"監控檢測"的問題就轉化成了一個"預測性維護"的問題, 提前發現潛在問題並定位根因發起自治action。

引入探活iSQ更好的幫助我們，定位流量突增對其他表的影響，下圖是一個探活RT異常的案例，我們發現 16：03的時候，探活SQL的RT有異常。

探活 iSQ 很敏感，透過 16:03 發現異常而慢SQL在16:04發現異常，原因也很簡單，其他慢SQL需要花更長的時間才返回，而探活的iSQ在更短的SQL返回時間內發現了異常

iSQUAD發現指標Patterns的異常，cpu/active_session/DML執行次數都有一定突增，由於CPU密集型workload造成了session的堆積，同時SQL執行時間變慢產生iSQ，而探活SQL變成iSQ這個現象幫助我們發現這類影響資料庫效能的問題，進而幫助我們定位到阻塞性workload流量，很大程度上幫助我們精準定位該型別的異常。

後續SQL自動限流action會根據Pattern得出的異常分析結論，屬於CPU Intensive Workload 分類。

根據分類，後端會拉取全量SQL，將關聯指標和SQL提取，發起發出SQL限流建議，同時我們外接CBO最佳化器會給問題SQL做相應的索引推薦，也可透過使用者的設定，進行彈性擴縮容。下面的例子是DAS自治中心透過透過根因定位後，產生相應自治操作的例項。我們會根據指標的異常patterns和分類做出，自動SQL限流，自動SQL最佳化以及Auto-scale的自治操作。

作為新基建的重要基礎設施，資料庫的完全自治對於企業數字化轉型，高效、安全地管理多種多樣資料庫產品有這重大的意義，最大程度地降低資料庫不可用時間，透過自治服務提高資料庫效能和消除人工操作可能帶來錯誤，進一步解放生產力。面對不斷擴張的資料規模，選擇DAS資料庫自治服務，你可以輕鬆搞定這一切。

在今天，當資料的產生速度已經遠遠超過了手動資料管理和處理的速度，資料庫規模增長的速度遠遠超過對資料本身的分析和洞察的速度。藉助資料庫自動駕駛的特性，資料庫自治服務可提供眾多傳統資料庫無法企及的優勢。

未來，越來越多的企業資料庫將遷移到雲上，隨著雲原生生態的日漸豐富, 透過資料庫自治服務的診斷能力，鞏固和提高競爭優勢，讓 IT 部門專注於創新而不是資料庫管理。透過智慧化和資料驅動的方式讓資料庫執行的更快/更穩/更安全，這也是阿里雲DAS(DatabaseAutonomy Service)產品一直的期望和願景。藉助AutonomousDiagnose的進展，今年我們底層DASMind演算法服務支援全網 50w+(MySQL, PolarDBMySQL, Redis)例項的異常原因分析，從1-5-10（1分鐘發現問題，5分鐘定位問題-10分鐘發起自治action）演進到（1分鐘發現並定位問題-5分鐘內發起自治action)，幫助DAS產品實現自動SQL限流、自動SQL最佳化、Auto-scale等自治服務，距離實現L5 Full-automation更進一步，未來的方向會從區域性的自治逐步演進到全域性的完全自治。

2020年，我們開始嘗試完善感知層與診斷層的演算法，藉助更多自動駕駛領域影像演算法、感知層演算法、構建Autonomous Anomaly Detection/AutonomousForecast/Autonomous Diagnose/Autonomous/Simulation 自治服務的整個pipeline 形成可持續的資料流閉環，透過資料來驅動資料庫的自動駕駛。我們相信在汽車實現自動駕駛之前，我們必然在資料庫智慧化管控領域首先實現資料庫領域的自動駕駛。