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

孫向征

（天津市機器人產業協會，天津 300384）

1 相關工作

1.1 OLTP環境

國外研究人員提出數據庫輔助診斷框架，此框架能夠對數據庫運行時相關運行指標進行監測，性能出現問題是，用戶能夠劃出存在性能異常區域，并通過框架搜索異常指標，此類異常指標具備一定劃分能力，給定指標斷言，通過斷言能夠將處于正常區域點與處于異常區域點有效分開，按照遺產指標，用戶便能夠發現問題產生原因。框架能夠把用戶反饋進行整合，生成因果模型，模型原因便為數據庫的性能問題出現根因，結果為異常指標斷言，同時在未來推斷中也可以應用相關模型[1-2]。該框架能夠合并因果模型，有效提升模型診斷能力。另外，國外學者還提出數據庫的性能診斷框架與以往工作形式不同主要表現為，此框架能夠自行診斷性能問題，并在決策樹模型中將診斷功能和調優功能融合應用，決策樹非葉節點屬于條件判斷，葉節點屬于需調優資源，針對數據庫診斷，系統將按照數據庫的當前運行狀態由根節點開始，按照非葉節點相關條件有選擇性地訪問子節點，系統對以上步驟進行重復，循環制葉節點停止，葉節點資源為需調優資源。同時，框架能夠對數據庫資源、負載進行建模，通過數據庫結構信息提升準確性，用戶通過不同資源的配置情況下數據庫的運行性能對決策樹進行調優。但是，決策模型需通過特定專家系統領域知識和數據庫中的文檔作為基礎，通用性存在一定的限制。

1.2 OLAP環境

診斷工具DIADS，其適用于SAN做底層存儲結構的DBMS上，注釋計劃圖是一種模型，Query Layer為數據庫查詢計劃，其中Database Layer為數據庫運行性能指標，SAN Layer為儲存物理結構體系，把查詢計劃中操作符與相關物理、邏輯資源以圖方式相互聯系，便能夠發現性能問題，借助此模型和歷史數據加以診斷[3]。如果查詢的執行時間與預期不符，系統將按照查詢計劃提取各操作符消耗時間，把存在異常操作符通過學習算法進行提取，按照模型查詢存在異常硬件資源。

2 算法描述

2.1 異常監測

通過使用LSTM編碼器－解碼器模型監測高維時間的序列異常，在設定時間中監測指標數據時間序列，系統能夠自身判斷其正常與否。此算法主要思想為，建立編碼器－解碼器。如圖1所示，其輸入為某段時間監控數據，輸出為相同維度、相同長度時序數據，模型對某段時間序列以逆序方式重建，按照重建的結果質量對時間序列異常性進行判斷。訓練階段，只需要借助正常數據對神經網絡進行訓練，損失函數為重構結果相關誤差，通過訓練，神經網絡便將具備正常序列建模能力，出入異常的時間序列，模型將出現誤差重構。在結構部分設置有Attention機制和記憶網絡，提升模型的擬合數據性能。

因為實際應用中，對于收集異常數據比較困難，所以，通過設定算法中異常閾值，借助極值理論方式，此方式為：設定異常數據出現在數據集概率非常小，設定比較小的概率，按照數據集對異常閾值進行求解。第一，在數據集內選擇分位數，之后選擇大于該數部分數據，按照極值理論，部分數據線性變換后符合帕累托分布，對分布參數進行求解，之后按照概率對異常閾值進行求解。

應用此算法的優勢主要表現在：神經網絡能夠對時間序列有效應用，監控數據存在互相關聯情況，神經網絡能夠準確獲取高維數據關聯性；相比部分時間序列異常算法監控數據庫時，對區域異常加以關注，并非單點異常關注，此方式具有一定考慮時間的策略，提升監控的魯棒性；對異常閾值進行設定時，無需提前搜集異常數據樣本，只需設定異常發生概率求解閾值即可，實際應用中，用戶能夠按照業務需求對概率進行調整。同時，該異常監測手段能夠在數據動態環境中對閾值進行調整，適用于數據動態偏移場景中。

2.2 提取監控指標

確定異常區域之后，需找出具備強特征指標，系統通過模仿DBA自動收集在異常區域下形狀特異的監控指標，并且能定量地描述這種異常的程度。設計Kolmogorov-Smirnov（KS）檢測方式對問題進行解決。KS檢驗方式屬于統計檢驗，對兩組數據的分布相似情況進行比較，優點為，其為非參數檢驗方式，與T檢驗不同，該檢驗手段無需提前對數據分布進行假設，少量點存在偏差，不會對結果造成影響，所以，在大噪音、小樣板數據場景中應用穩定性較高。此方式有效性建立在兩個假設之上：第一，異常發生，特征較為明顯指標數據分布將出現較大變化；第二，數據庫處于正常運行情況時，在一段時間中指標點分布較為穩定，滿足未知分布情況。通過實踐操作發現，多數的監控指標均滿足這兩個假設，指標呈現為線性遞增，采用差分方式與護理，因為考慮根因的觸發時間無法準確定位，則指標記錄將存在滯后性，僅能夠在特定時間窗口中對數據進行處理，假設時間窗口中數據分為3段，前2段屬于正常數據，第3段為異常數據，系統首先對前2段數據檢驗，之后對后2段檢驗，經過檢驗，對結果差值進行統計，作為異常指標評價依據，當數據庫中的異常實例轉變為異常向量V，則向量內各維均對應指標異常程度，取值范圍設定為[0，1]，倘若數值接近0，說明監控指標不存在異常。

3 實驗結果分析

實驗中需要對三個問題進行驗證：AutoMonitor是否對數據庫運行狀態存在影響；監測模塊是否能夠以較快的速度進行部署，達到高精度監測；分析模塊與其他方法相比，準確率情況。

3.1 環境配置

將兩部配置完全一致的阿里云服務器為實驗環境，服務器性能參數為：操作系統為Ubuntu16.04 64位；內存2G；CPU單核Intel（R）Xeno（R）Platinum 8163 CPU@2.5GHz。Python2.7和Python3.6為解釋器。實驗借助TPC-C為Benchmark，整理數據庫運行中常見問題根因。如表1所示。

表1 Pos tgre SQL數據庫常見的問題根因

在實驗中借助OLTP工具實現TPC-C基準，應用此工具能夠產生不同的請求頻率與不同時間長度的TPC-C負載以及不同規模表數據。因為在實際環境中數據庫運行狀態相關數據無法準確獲取，上表所述故障案例借助手動方式模擬觸發，借助兩部服務部，一部為用戶，另一部用于數據庫的服務器。實驗時，用戶啟動OLTP執行負載，實驗中啟動異常程序生成性能異常，異常結束后，讓數據庫處于正常狀態運行，之后結束實驗。在實驗中需要注意的是，對I/O、CPU瓶頸，實驗中借助開源工具搶占I/O、CPU資源。數據表的備份、還原，借助數據導出和數據導入命令進行。物理設計錯誤，開銷查詢以及負載超常實驗中則按照具體情況發生現象產生。網絡故障，借助內置命令對流量進行控制，通過手動方式減緩通信速度。鎖競爭，借助TPC-C部分數據表在短時間中進行大量訪問，因為考慮數據庫的訪問請求多樣性，當各組生成數據，應當設定不同訪問頻率。

3.2 監控工具性能開銷測試

選取不同請求頻率，因為單次實驗存在不穩定性，在不停請求頻率進行20組實驗。另外，因為考慮實驗平均數不穩定性，在試驗中將分位數做評價指標。對實驗結果進行分析，開啟監控工具的性能損失比較小，分位數平均延遲的增加小于5%。分析原因為：監控數據的請求頻率是1 s/次，用戶訪問數據庫頻率較短，實踐中，該請求頻率滿足推斷精確程度，倘若按照具體需求降低訪問頻率，能夠在此基礎上降低性能損失；收集包括操作系統和數據庫，兩者數據都將被數據庫、操作系統進程生成。即系統沒有提升數據收集開銷，開銷的增加是源自于訪問數據，I/O、CPU額外增加開銷較小。通過以上分析可以得出，現存數據庫的監測框架為輕量，實用價值較高。

3.3 異常檢測模塊測試

該試驗是對數據庫診斷系統監測模塊有效性進行驗證，選取8 000段長度32正常時間的序列作模型訓練數據，神經網絡超參數見表2。

表2 神經網絡模型超參數

對神經網絡的訓練結果、監測模塊的實驗結果以及算法性能對比結果進行分析，得出AutoMonitor方式最優。首先，復雜深度的生成模型存在較多參數，倘若沒有充分調優將難以學習，導致性能下降。針對工程類型任務，在選用模型算法時不可過于注重精度，還應當考慮模型訓練速度和穩定性。

4 結論

本文實驗內容對監測模塊、推斷模塊應用的準確性進行分析，實驗結果說明兩個模塊局具備較高的準確性，具有一定應用價值。但是，該系統也存在一定不足，僅適用于PostgreSQL數據庫，系統處于離線狀態時需要進行大量的訓練，可嘗試把框架應用至MySQL數據庫中，并把框架可以擴展至云數據庫中。