基于人工智能方法的數據庫智能診斷?

金連源,李國良

(清華大學 計算機科學與技術系,北京 100084)

IT 運維,指的是和IT 服務管理相關的人員及管理過程,IT 運維可以讓公司提供的服務保持良好的質量,并且使服務達到用戶付款后的預期.運維在人類未來的生產生活中的作用會越來越重要.2017 年,清華大學裴丹提出“預計到2020 年,全球將有500 億到1 000 億的IT 設備,這些設備會承載無數的服務,覆蓋互聯網、金融、物聯網、智能制造、電信、電力網絡、政府等等的生產生活的方方面面”(https://yq.aliyun.com/articles/272155).在運維發展的過程中,最先出現的是依靠手工的運維;后來,人們把重復的手工操作代碼化,基于大量腳本的自動化運維就開始流行了起來;其后又出現了DevOps 和智能運維[1].智能運維,指的是使用大數據、機器學習技術來支持IT 運維.機器學習可以處理海量的監控數據并且提供強大的推斷能力.目前已經有許多公司和研究機構使用智能運維技術在許多方向取得了非常顯著的進展,包括云數據庫服務質量分析[2]、磁盤故障的預測[3]、微服務故障的定位[4]等等.

數據庫是各種企業常用的系統軟件,根據所執行任務的不同,可以將數據庫分為執行大量簡單事務的OLTP 型數據庫、執行復雜分析任務OLAP 型數據庫和兼顧執行上述兩種任務的TATP 型數據庫.作為一種傳統的系統軟件,近年來出現了許多利用人工智能技術優化數據庫部件的工作[5],可以發現,人工智能技術賦能的數據庫具有更加強大的綜合能力,智能運維技術在數據庫領域也有著廣泛的應用場景.

本研究聚焦于智能運維中的OLTP 環境數據庫性能異常監測診斷,在數據庫性能下降時發現問題并診斷問題發生的根因.該問題有如下幾個難點.

? 監控指標和數據庫性能異常之間的對應關系比較復雜,一種根因所引發的異常往往會導致多個監控指標出現問題,而單個監控指標的異常可能由不同的根因所導致的.此外,系統中會存在數百個指標,因此,采用簡單的規則來進行數據庫異常診斷精確度不高;

? OLTP 環境下的數據庫執行的是大量簡單的事務,如果監控指標數據成本較大,可能會使執行時間較短的事務變慢,帶來數據庫性能下降的問題;

? 由于OLTP 任務請求的不穩定性以及操作系統、數據庫系統的復雜性,監控指標中會有許多噪音,在這類監控指標中提取有用信息難度較大.

下面是關于第一個難點的一個具體案例:當我們執行數據庫備份操作的時候,我們觀察到了很多指標均產生了異常,其中包括了CPU、I/O、中斷計數,數據庫等待進程等等,如圖1 所示.

Fig.1 Anomaly metrics triggered by database backup圖1 數據庫備份引發的監控指標異常

同一個指標的異常可能是由不同的根因所造成的,我們以CPU 統計指標舉例,可以看到:在外部進程搶占CPU、數據庫備份和數據庫外部文件導入這3 個根因下,CPU 的指標均產生了異常.

圖2 展示了在3 種異常觸發的時候,CPU 指標變化的示意圖.這是因為以上3 個行為均需要計算機提供較高的計算資源.通過可視化我們發現,其他很多的指標均存在著相似的性質.因此,我們很難從單個異常的指標去推定數據庫性能異常問題的根因.

Fig.2 CPU metrics under different anomaly cases圖2 不同異常下,CPU 監控指標

已有的數據庫異常診斷方法并不完全適用于我們的問題,這些方法中有的過于依賴專家知識,需要依靠有經驗DBA 設計模型[6],并且這些模型只適用于一種數據庫,不具備遷移性;還有的需要通過修改數據庫系統源代碼的方式獲取細粒度監控信息[7],雖然提高了診斷的精度,但是這樣既增加了開銷,也帶來更大的系統維護成本.

針對以上的問題,本文作者提出了一種自動、輕量級的監控診斷框架AutoMonitor.通過模擬數據庫故障分析挖掘數據庫性能故障下的一系列監控指標所表現出來的特征,使用基于深度循環神經網絡的模型完成對數據庫性能異常的監控.在這里,循環神經網絡能以較低的成本和較快的速度完成對時序數據進行建模,并捕捉不同監控指標之間的相關性,進而實現高質量的異常監測.針對監控指標的數據特點,提出了基于Kolmogorov-Smirnov 檢驗的異常指標提取算法.該方法利用異常時序數據統計分布的差異來判斷是否為異常監控指標,模擬人眼判斷異常的過程,并且有一定的魯棒性.最后,我們使用優化的K近鄰算法挖掘了異常監控指標和異常根因之間的對應關系,實現了數據庫異常根因診斷.相比于其他方法,我們這種基于特征距離比較的方法不僅利用了所有監控指標信息,而且還考慮到了不同監控指標的重要性,因而具有更高的診斷精度.

本文第1 節是相關工作的介紹.第2 節是論文總體研究方案的介紹.第3 節是論文所使用到的算法的具體描述.第4 節是關于實驗結果展示和分析.第5 節是對于本文的總結.

1 相關工作

國內外有許多關于系統性能診斷的研究工作,針對系統面向不同的任務,我們將這些工作分成面向OLTP環境和面向OLAP 環境這兩個大類上面.OLTP 環境下,單條SQL 比較簡單,執行的時間也比較短.因此,面向OLTP 環境的自診斷方法考慮整體工作負載的性能問題.OLAP 環境下,SQL 語句比較復雜,因此診斷時主要考慮單條SQL 語句的執行效率問題.

根據自診斷方法的不同,我們可以將自診斷方法分成基于專家結構模型的和基于機器學習的方法:前者利用專家知識構建的結構模型、決策樹模型或者知識庫進行診斷,后者則是利用歷史運行數據結合已經標注的數據進行診斷.在有些文獻中,這兩種方法都會使用.

1.1 面向OLTP環境

Yoon 等人[8]提出了數據庫性能輔助診斷框架DBSherlock,該框架可以監控數據庫運行期間的若干運行指標,當出現性能問題的時候,用戶就可以劃出性能異常的區域,讓DBSherlock 找出可能出現異常的指標.這些異常的指標具有較強的劃分能力,即給定一個關于指標的斷言(形如Attr>k),使用這個斷言可以把落在正常區域內的點和落在異常區域內的點分開.根據這些異常的指標,用戶就可以找出問題發生的原因.DBSherlock 可以將用戶的反饋整合成因果模型,因果模型的原因是數據庫性能問題的根因,結果是一些關于異常指標的斷言,這些模型會用到未來的推斷里去.DBSherlock 還在語義層面對因果模型進行合并,實驗表明,這種方法大大提高了模型的診斷能力.

Benoit 等人[6]提出了數據庫性能自動診斷框架,和之前工作不同的是,該框架不僅可以對數據庫性能問題進行診斷,還將診斷和調優這兩個部分利用決策樹的模型統一在一起,決策樹的非葉節點是條件判斷,而決策樹的葉節點是需要調優的資源.對于一次關于數據庫的診斷,系統會根據數據庫當前的狀態從根節點出發,根據非葉節點的條件選擇子節點進行訪問.系統重復以上的步驟,直至到達葉節點,葉節點的資源即是我們需要調優的資源.此外,框架對于數據庫的負載和資源分別進行了建模,利用數據庫的結構信息提升了準確性,作者還會使用不同資源配置下數據庫運行的性能結果調優決策樹.不過,該決策樹模型的模型需要依賴特定的數據庫文檔以及數據庫專家的領域知識,因此通用性不是很強.

Belknap 等人在文獻[7]中介紹了Oracle 中SQL 診斷工具Automatic Database Diagnostic Monitor(ADDM),在這項工作中,作者引入了數據庫性能的衡量通貨“數據庫時間(database time)”,即數據庫各個資源模塊、數據庫語句執行的各個階段的運行時間,并且在這個基礎上建立了圖模型DBTime graph,通過對圖的搜索,我們就可以定位問題.針對統計信息收集成本開銷過大的問題,文獻里提出一種基于采樣的方法(active session history),即每隔一段時間觀察用戶的行為,Database Time 大的模塊更加容易被采樣到,診斷系統也會相應地重點分析.

Ma 等人[9]針對OLTP 數據庫中間歇性的慢查詢,提出了診斷框架iSQUAD,包含了異常抽取、相關性清楚、基于類型的模式集成聚類以及貝葉斯樣例模型這4 個部分.作者將該方法應用于阿里云數據庫的實際數據中,取得了較好的實驗效果.

1.2 面向OLAP環境

Borisov 等人[10]提出了診斷工具DIADS,它適用在以SAN 為底層存儲結構的DBMS 上面,注釋計劃圖(annotated plan graph)是文獻[10]中主要用到的模型,該圖分為Query Layer,Database Layer 和SAN Layer:Query Layer 的內容是數據庫的查詢計劃(因為是OLAP 場景,計劃較為復雜),Database Layer 則是數據庫相關性能運行指標,SAN Layer 則是存儲的物理體系結構.通過將查詢計劃里的操作符和相關的物理、邏輯硬件資源通過圖的方式聯系在一起,就能在查詢出現性能問題時,使用該模型結合歷史數據進行診斷.當查詢執行時間和預期不符的時候,系統會根據查詢計劃提取每一個操作符所消耗的時間,將異常的操作符使用機器學習算法提取出來,再根據注釋計劃圖模型找出異常的硬件資源完成診斷.

Kalmegh 等人[11]提出了框架iQCAR,該框架適用于大數據分析處理系統Apache Spark 上,主要的功能是分析一個查詢在運行的時候受到系統中并發執行的查詢的影響.該研究的主要貢獻在于定性地分析查詢間資源搶占的影響,并且提供了多粒度的分析.該研究首先聚焦于不同的任務關于單個資源的搶占問題,作者在這里提出了阻塞時間(blocked time)這一個概念,即單個工作獲取一個特定的資源時的等待時間;此外,作者還提出了資源獲取時間懲罰(resource acquire time penalty)來衡量一個任務獲取特定的資源的效率.在建立相關概念以后,作者定量地分析了一個查詢在獲取資源時,其他并發的查詢對其阻塞造成的貢獻.接著,作者構建了iQC-graph,這是一個層級結構的圖模型,每一層代表著查詢執行過程不同的粒度,根據該圖分析查詢不同執行過程的性能情況.

2 總體研究方案概覽

為了實現對數據庫運行狀況進行監控和診斷,AutoMonitor 需要實時地收集數據庫執行任務時相關的統計信息,并分析這些數據的變化情況.我們設計的異常診斷系統總體框架如圖3 所示,設計的框架分為兩個主要階段:第1 階段是離線的數據分析,第2 階段是在線實時的異常監測和根因診斷.

(1)關于離線的部分.

系統的主要任務是訓練在線階段所使用的模型,共有兩部分訓練數據.

? 一部分是異常時間序列數據,這部分數據通過模擬數據庫異常收集而來,它是高維的時序數據,每一維對應一種監控指標的結果,它們被用來確定每一種根因觸發的異常下監控指標的特征,系統使用Kolmogorov-Smirnov 檢驗給出每一維指標的異常程度,挖掘有異常的監控指標,然后將這些異常指標和正常指標拼接在一起,生成維數固定的異常特征向量,該向量將用于優化的K近鄰算法中.此外,對于每一種異常的診斷,我們需要確定對應的重要監控指標,每個監控指標的重要性由數值αi決定,越重要的指標,對應的αi越大.相比于普通K近鄰算法直接使用歐幾里得距離進行相似度的計算,優化的K近鄰算法在相似度計算時會涉及αi,使得系統對于根因不同但是表現相似的異常具有更強的判別能力,αi的具體計算方法將在第3.3 節描述;

? 另一部分是數據庫正常運行狀態下的數據,該部分數據的結構和異常數據相似,區別在于我們沒有手動注入異常,它們被用以LSTM 循環神經網絡的訓練,訓練以后的模型對于正常監控時序數據具有較強的重構能力,即:將一段時序數據依次輸入到模型,經過處理保存中間結果在一個隱狀態里,模型再從該狀態開始逐步重建還原輸入的時序數據.系統的最終目標是讓輸入和輸出的時序數據盡可能地相似.當異常時序數據進入模型時,由于正常和異常時序數據在結構上的差異,重構的結果會帶來較大的誤差,如此,系統便獲得異常監測的能力.

(2)關于在線的部分.

當用戶執行工作負載的時候,系統將實時地監控信息輸入到數據庫中.模型實時從數據庫讀取這部分時間序列數據并進行異常監測,當監測異常值高于警報閾值(該閾值在離線階段由歷史異常數據和正常數據共同確定,目標是最大化診斷準確度)的時候,便認為此時出現了異常,然后啟動根因分析模塊進行診斷分析.系統先提取未知異常的異常特征向量,然后使用優化的K近鄰算法將未知根因的異常特征向量和已知根因的異常特征向量進行相似度比較,從而讓用戶可以獲取異常監控指標和該問題可能的根因.系統會將診斷的結果匯總成報告反饋給用戶.

Fig.3 Anomaly diagnosis system architecture圖3 異常診斷系統結構示意圖

AutoMonitor 系統收集的統計信息主要包含了兩個部分,分別來自于操作系統和數據庫系統,我們使用了不同的方法收集這兩部分數據.

? 出于統計信息的可獲得性和數據庫部署的實際性考慮,我們選定Linux 作為研究的操作系統.Linux 系統會自動維護系統運行的相關統計數據并存放在特定的目錄下,系統使用開源工具dstat 收集整合這個一部分的信息,其中的監控指標涉及到CPU、I/O、網絡、中斷等部件;

? PostgreSQL 內置了多個統計信息視圖,記錄了數據庫、數據表、索引和連接用戶等模塊的統計信息.通過對視圖構造查詢,就可以定時地獲取DBMS 相關的監控數據.我們將構造的監控數據查詢寫成插件集成到dstat 的工具里,在dstat 運行的時候,它會定時讀取這一部分的數據并和操作系統的數據相對齊.考慮到PostgreSQL 內置統計信息的更新頻率以及查詢開銷,在默認情況下,系統選擇1 秒作為信息收集的間隔.

需要注意的是:以上兩部分數據是操作系統和數據庫自動維護生成的,使用該系統并不需要修改操作系統和數據庫,這也保證在添加監控以后數據庫的性能不會受太大的影響.

當用戶需要使用AutoMonitor 時,系統首先會啟動dstat,開始監控指標數據的收集.dstat 從系統目錄以及PostgreSQL 視圖中讀取這部分數據,并將收集到的數據定時寫入數據庫中,然后自動監測程序定時從數據庫讀取最新的時序數據,并將這一段時間的數據輸入到LSTM 模型進行異常監測.如果AutoMonitor 認為此時出現了異常,就調用根因診斷程序,并將這段時序數據傳入進行根因診斷.最終的結果會以報告的形式反饋給網頁端的用戶.

3 算法描述

3.1 異常監測

我們使用基于LSTM 的編碼器-解碼器模型來進行針對高維時間序列異常監測[12].給定一段時間監控指標數據的時間序列,系統可以判斷它是正常還是異常的.該算法的主要思想是:構造一個編碼器-解碼器,如圖4 所示,它的輸入是一段時間的高維監控指標數據,輸出是同樣長度、同樣維度的時序數據.即:該模型對于一段時間序列按逆序進行重建,根據重建結果的好壞來判斷時間序列的異常性.在訓練的階段,我們只使用正常的數據來訓練LSTM 神經網絡,網絡的損失函數是序列重構結果的誤差.如此訓練下,LSTM 網絡就獲得了對于正常序列較好的建模能力,當異常時間序列輸入的時候,模型就會產生較大的重構誤差.在網絡結構部分采用了深層的長短期記憶網絡和Attention 機制[13],以提高模型擬合數據的能力.

Fig.4 Encoder-decoder structure diagram圖4 編碼器-解碼器結構示意圖

下面是具體算法的描述.

算法1.異常時序數據監測算法.

輸入:正常的時間序列sN,vN1,總訓練輪數Epoch;

輸出:誤差協方差矩陣Σ,誤差向量μ.

由于在實際應用的過程中,異常數據的收集較為困難,因此在設定算法的異常閾值中,我們使用了一種基于極值理論(extreme value theory)[14]的方法,該方法大致原理如下:假定異常數據在一個數據集中出現的概率很小,我們設定一個較小的異常概率;然后,結合數據集求解對應的異常閾值.首先,在數據中選取一個分位數(例如0.95);然后選取大于分位數的小部分數據,根據極值理論,這一部分數據經過線性變換以后滿足帕累托分布.首先使用極大似然估計的方法求解該帕累托分布的參數,然后根據概率求解異常閾值.具體的公式如下:

在這里,zq是最后求解的閾值,t是分位數的值,?σ和?γ是帕累托分布的參數估計結果,q是預先設定異常閾值的概率,n是總的數據集樣本數,Nt是分位數下的樣本數.由于異常監測涉及到流式的數據,因此在實際應用的過程中,系統會實時的更新帕累托分布的相關參數和異常閾值,進而保證異常監測的實時精確性.

選用該算法有如下的優勢.

? LSTM是一種用于有效時間序列分析的神經網絡,監控數據可能存在相互關聯的情況,而LSTM網絡可以較好地捕捉高維數據的關聯性;

? 相比于一些針對時間序列異常點的算法,在數據庫監控的時候,更加關注區域的異常而不是單點的異常.這種考慮一段時間數據異常性的策略,讓監控魯棒性更強;

? 在設定異常閾值的時候,不需要事先獲得異常數據的樣本,而是通過設定一個異常發生的概率來進行異常閾值的求解.在實際應用的過程中,用戶可以根據業務的實際需求來調整這個概率.另外,這種異常監測的方法可以在流數據的環境下動態地調整閾值,可以適應實際場景下數據的動態偏移.

3.2 監控指標提取

在找到異常區域以后,AutoMonitor 需要找出該異常下具有較強特征的指標,即:系統需要模仿DBA 自動收集在異常區域下形狀特異的監控指標,并且能定量地描述這種異常的程度.

我們設計了基于滑動窗口的Kolmogorov-Smirnov 檢驗方法來解決此問題.Kolmogorov-Smirnov 檢驗是一種統計檢驗方法,可以用來比較兩組數據分布的相似程度.它的一個優點就是:它是一種非參數的檢驗方法,相比于T 檢驗,不需要提前假設數據的分布,即使少量的點出現偏差,也不會對整體結果產生大的影響.因此,在小樣本、噪音較大的數據場景下具有更高的穩定性.

該方法的有效性基于以下兩個假設.

? 在發生異常以后,一些特征明顯的指標的數據分布會發生較大的改變;

? 在數據庫正常運行的狀態下,指標點的分布在一段時間里是穩定的,即滿足一個未知的分布.

我們在實踐中發現,大多數監控指標都滿足以上的假設.對于那些呈線性單調遞增的指標,我們使用差分的策略來進行預處理.考慮到根因發生具體觸發的時間難以定位,一些指標的記錄也會有滯后性,只能在一個時間窗口內處理數據.設想時間窗口內的數據被分成了3 段:前兩段是正常的數據,第三段是異常的數據.系統會對前兩段數據進行Kolmogorov-Smirnov 檢驗,然后對后兩段數據進行Kolmogorov-Smirnov 檢驗.檢驗后,統計量結果的差值即作為該指標異常的評價依據.因為具體的異常發生點是未知的,系統會在一個時間窗口內進行多次計算整合結果.在監控指標提取以后,每一個的數據庫異常實例被轉化成了一個異常向量V,向量中的每一維對應了一種指標的異常程度,取值范圍是[0,1],如果該值接近為0,則代表該監控指標沒有出現異常.

3.3 根因診斷算法

AutoMonitor 使用最近鄰算法作為根因診斷算法,雖然K近鄰算法比較簡單,但是在這個問題下有較好的性能.因為同一種問題發生的時候,異常指標的集合也是比較接近的.為了進一步提高性能,我們設計了基于全局信息異常指標權重調整的策略.

該策略的思路來源于文檔搜索,對于文檔搜索問題,簡單的布爾檢索的策略不能取得很好的效果,因為布爾檢索將文檔里的詞語看作一樣的.作為布爾檢索改進,基于tf-idf 文檔向量模型[15]有著更高的搜索準確度,因為每個詞的重要性不一樣,一些出現頻率較高的詞被忽略了.

普通的K近鄰算法對于每一維的指標不做特殊的處理,作為這個方法的改進,優化后的K近鄰算法會重新計算每一種標簽的異常向量每一維的指標權重.

假設原來使用歐幾里得距離L=計算向量之間的差異,新方法對其中的每一項賦予了特定的權重,在這里,距離的計算變成了:

這里,α的計算是通過分析已知樣本所得的.我們希望以下兩類指標的權重盡可能大,因為它們在診斷的場景下具有比較重要的價值.

? 該指標在其他根因中出現的較少,但是在本類根因下出現的比較頻繁;

? 該指標在其他根因的異常中出現的比較頻繁,但是在本類根因下出現的較少.

以上兩點是基于數據庫運維人員對根因診斷的經驗所得出來的,第1 點的思路是和文檔搜索tf-idf 的思路相似,找出根因中最顯著的指標;第2 點的思路類似于醫生對病例的診斷,比方說一個病人的驗血結果白細胞正常,我們就不應該認為該病人出現了炎癥.

為了使系統根因推斷算法可以辨別異常向量相近的不同根因,我們設計了如下的權重調整算法:首先,將每一種的異常根因對應的一系列異常向量聚合成一個向量,代表這種異常根因的特征;然后使用歐幾里得距離計算向量兩兩之間的差異,得到距離矩陣矩陣Dist.如果兩個向量之間的距離較小,將它們之間差異較大的指標提取出來并且放大相應的權重;否則就認為它們之間的距離不會對診斷結果造成影響,進而縮小它們之間差異較大指標的權重.下面是算法的具體偽代碼描述.

算法2.每類異常指標權值計算策略.

輸入:每種異常根因對應的特征向量V1,V2,…,Vn,特征向量的維度k;

輸出:每種異常根因對應的權重向量A1,A2,…,An.

值得注意的是:AutoMonitor 使用的是基于最近鄰的方法,因此當我們引入新的異常類型以后,我們只需要將這些新類型的異常向量添加進訓練集中,然后重新的計算指標權重.由于總的數據集不大,重新計算只需要很短的時間,模型的推斷速度也比較快.由此我們認為:在添加新的數據或者新類型的異常,AutoMonitor 仍然可以有效地工作.

4 實驗結果分析

在實驗部分,我們需要驗證以下3 個問題.

? AutoMonitor 是否會對數據庫實際運行造成較大的影響?

? AutoMonitor 的異常監測模塊是否能快速部署并達到較高的監測精度?

? AutoMonitor 的根因分析模塊相較于同類方法是否能有較高的診斷準確率?

4.1 環境配置

我們使用兩臺配置相同的阿里云服務器作為實驗的環境,服務器具體性能參數如下.

? 操作系統:Ubuntu 16.04 64 位;

? CPU:單核Intel(R)Xeno(R)Platinum 8163 CPU@2.5GHz;

? 內存:2G.

服務器安裝的PostgreSQL 是12.0 版本,使用了python2.7/python3.6 兩種解釋器.實驗使用TPC-C[16]作為實驗的Benchmark.表1 是在和華為高斯數據庫DBA 交流討論后,經過歸納整理的幾種常見的數據庫故障的問題根因,其中的設計參考了文獻[8].這里的問題根因涉及到了數據庫性能異常的各個方面,既包括了數據庫外部進程對CPU、網絡等資源的搶占,也涵蓋了數據庫日常運維的一系列事件,還有一部分訪問數據庫的錯誤行為.

Table 1 PostgreSQL common anomaly root causes表1 PostgreSQL 數據庫常見的問題根因

實驗中使用OLTP-Bench[16]工具實現了TPC-C 基準,該工具可以生成不同請求頻率和不同持續時間的TPC-C 負載,還能生成導入不同規模的表數據.由于真實環境下數據庫的運行數據難以獲得,以上這些異常案例數據我們通過手動模擬觸發異常的方法來產生,即兩臺服務器,一臺作為數據庫服務器,另一臺作為用戶.每一次實驗里,用戶先啟動OLTP-Bench 執行數據庫負載,在實驗中途啟動服務器中的異常程序觸發數據庫性能異常,等到異常程序結束再讓數據庫正常運行一段時間,然后結束單次實驗.下面介紹實驗的具體細節:對于CPU、I/O 瓶頸,實驗使用Linux 環境下開源工具stress-ng 來搶占CPU 以及I/O 的資源;對于數據表備份以及數據表還原,實驗直接使用PostgreSQL 中關于數據導入/導出的命令(pg_dump,psql);對于錯誤的物理設計、開銷巨大的查詢、負載超常和統計信息更新這4 類異常,實驗直接使用描述中的方法來產生;對于網絡故障,我們使用Linux系統內置命令tc 來進行流量控制,手動讓網絡通信速度變慢;對于鎖競爭,我們使用OLTP-Bench 對TPC-C 數據表中的一小部分數據進行短時間大量的訪問;考慮到數據庫訪問請求的多樣性,對于每一組生成的數據,我們設定了不一樣的訪問頻率(每秒事務請求的數目從30～150).

4.2 監控工具性能開銷測試

本實驗旨在探究數據庫根因診斷系統監控工具對OLTP 數據庫性能的影響.

我們選取了不同的請求頻率,并且考慮到單次實驗的不穩定性,在每一種請求頻率下重復進行了20 次實驗.考慮到實驗中平均數的不穩定性,本實驗使用分位數作為分析性能差異的評價指標,圖5 是該實驗的結果.

Fig.5 Database performance comparsion with/without monitor tool圖5 有無監控工具下數據庫性能比較結果

通過觀察可以發現:開啟了監控工具性能的損失相對而言是非常小的,分位數的平均延遲增加一般不會超過5%.原因主要有以下兩點.

(1)當前監控數據請求的頻率為1 秒1 次,這個用戶對數據庫的訪問頻率而言是比較短的.在實踐中,1 秒1 次的數據請求頻率也足以保證推斷的精確程度,如果根據實際需要減少訪問頻率,性能的損失可以進一步降低;

(2)我們收集的數據包含了數據庫和操作系統,以上兩部分的數據均會被操作系統和數據庫相關的進程定期生成.換句話說,系統并沒有增加數據收集上的開銷,增加的開銷僅僅來源于訪問獲取數據,CPU和I/O 增加的額外開銷都比較小.

綜上所述,我們可以確信:當前的數據庫監控診斷框架是輕量的,具有較強的實用價值.

4.3 異常檢測模塊測試

本實驗旨在驗證數據庫根因診斷系統異常監測模塊的有效性,總共選取了8 000 條長度為32 的正常時間序列作為模型的訓練數據.關于神經網絡的一些超參數見表2.

Table 2 RNN model hyper parameters表2 循環神經網絡模型超參數

自編碼器模型于GPU 服務器訓練,圖6 是神經網絡訓練結果.可以觀察到:該神經網絡訓練的開銷是比較小的,網絡也較快地達到收斂的狀態.在實際部署的時候,系統會實時調用最近的歷史數據來更新神經網絡的模型參數,較小的訓練開銷保證了模型的可用性.

Fig.6 Neural network training result圖6 神經網絡訓練結果

實驗選取了基于VAE[17]和基于GAN[18]的時序數據異常監測方法和AutoMonitor 方法進行了對比.在測試階段,我們選取了200 組異常序列數據和500 組正常序列數據,圖7 和表3 是異常監測模塊靈敏度的實驗結果.

Fig.7 Anomaly detection module experimental results圖7 異常監測模塊實驗結果

Table 3 Anomaly detection performance comparison表3 各算法性能的對比結果

可以看到:我們的監測模型同時達到較高的精度和召回率.對比結果表明,AutoMonitor 方法是最優的.我們認為,原因有如下幾點.

(1)已有的基于生成模型的方法雖然可以在一些時序數據異常檢測的任務中取得比較好的效果,但是因為時序數據的模式各異,數據庫的監控數據又和負載相關,因此,生成模型很難去學習到隱變量參數;

(2)復雜的深度生成模型往往有較多的參數,如果未經充分的調優會難以學習,從而造成性能的下降;

(3)對于一個偏向于工程的任務,我們認為:在選擇模型算法的時候不應該只追求精度,同樣要考慮到模型的穩定性和訓練速度.

4.4 根因分析模塊測試

本實驗旨在驗證AutoMonitor 中根因分析模塊的有效性.對于每一種異常設置,在不同的用戶請求頻率下,各生成25 組數據(總共為250 組數據).這250 組實驗數據被隨機劃分成了訓練集(80 組)和測試集(170 組),我們的方法將會和DBSherlock[8]、普通的K近鄰算法和決策樹算法進行對比.

圖8 是實驗總體的精度對比,可以看到:AutoMonitor 的表現比其他3 種算法要出色;權重調整的K近鄰算法要比普通K近鄰算法精度提升10 個百分點,比決策樹算法精度高近5 個百分點.可以看到:DBSherlock 在實驗數據集上的表現并不出色,只有不到60%的診斷精度.這說明在比較復雜的環境下(每組數據用戶的請求頻率不同),DBSherlock 并不能起到很好的效果.

Fig.8 Comparison on diagnosis precision of different diagnosis methods圖8 根因分析各方法精度對比

圖9 是關于3 種分類器對于每一種異常的識別能力比較,我們使用F-Score 作為評價標準.從實驗結果圖中可以看到:AutoMonitor 在各類異常的根因診斷上均有較為出色的表現,并不存在對于某種異常根因診斷能力較弱的情況.而DBSherlock 方法對于某幾類異常的診斷精度較高,但是對于另外幾類異常的診斷精度確不盡如人意.主要的問題在于:DBSherlock 生成的斷言對于數據的敏感度較高,并且合并因果模型的策略也存在著較大的不確定性.表4 是對于每一種根因診斷的具體指標結果,包含了精確度(第1 行)和召回率(第2 行).

Fig.9 Comparisionon F-score of different diagnosis methods圖9 不同算法F-score 比較結果

Table 4 Precision/Recall comparison result表4 各算法精確度/召回率的對比結果

5 總結與未來工作

本文研究了OLTP 數據庫在實際運行時可能遇到的異常,分析了這些異常和一系列監控指標之間的影響關系,以及對這些異常的監測和根因推斷方法.

針對上面的問題,本文設計了一個部署在PostgreSQL 數據庫管理系統上的自動監控診斷框架,該框架造成的額外開銷較小,能為經驗較少的數據庫使用者提供自動異常監測診斷的服務.在根因推斷上面,本文使用了一種權重調整的K近鄰算法.和普通的K近鄰算法相比,這種K近鄰算法可以更好地捕捉到不同根因之間的差異關系,并且可以提取關于某種根因相對重要的監控指標.

本文的實驗部分探究了自動異常監測模塊和根因推斷模塊的準確性,結果表明:上述的兩個模塊準確性都較高,經過權重調整的K近鄰算法對于表現比較接近的問題根因具有更加好的辨別區分能力.總體來說,我們的系統具有實際的應用價值.

該系統目前的不足之處在于只適用于普通的單機PostgreSQL 數據庫,擴展性較差,并且診斷系統在離線的過程中需要比較多的訓練數據.下一步計劃將框架移植到MySQL 等主流開源數據庫上,并且考慮將框架擴展到分布式數據庫、云數據庫上.此外,目前的異常數據主要是人工合成模擬的,我們計劃通過和數據庫主流廠商合作的形式,研究更加實際的場景.