摘要：本文主要介紹GaussDB（DWS）資料庫智慧監控運維服務體系的設計規劃和現狀。
本文分享自華為雲社群《眼觀六路耳聽八方還不知疲倦？數倉智慧運維服務體系是怎麼做到的？》，原文作者：魯大師。
背景介紹
早期，資料庫系統僅僅提供SQL命令來查詢其內部的執行狀態，導致資料庫運維操作門檻高，易用性差，DBA一度成為高度專業化的關鍵崗位，享受高薪和大家羨慕的目光的同時，也為企業的資料安全帶來了不確定性風險。並且，命令列運維不直觀，嚴重依賴運維人員經驗，不能做到快速的發現、定位、解決問題，導致資料庫運維問題，發現難，定位難，解決難。
為了應對這個窘境，資料庫執行狀態視覺化（資料庫監控系統）應運而生，通過視覺化的手段以人類便於理解的圖表形式，將重點資料以圖形化的手段展示給運維人員，從而顯著的降低了資料庫運維的門檻，提高了資料庫運維的效率。這個階段有一些代表性的產品比如：OEM(Oracle), ViewPoint(Teradata)，等等。但是，這個時期使用者的資料的規模不是很大，資料庫也依然部署在使用者自己的資料中心，依然是幾個DBA運維幾套資料庫的階段。
隨著雲時代的到來，雲資料庫逐漸託管了客戶的資料儲存服務，雲化將一切繁重的IT運維工作都集中在雲後臺管理了起來，從而把客戶從專業，複雜，繁重的資料中心運維活動中解放了出來，使客戶能夠更加專注於其核心業務。同時，雲服務提供商作為資料儲存服務的提供者，則需要在IT運維與資料庫運維上深耕細作，發揮其團隊穩定，專業化程度高，掌握海量資料庫執行資料的優勢；充分利用目前機器學習、人工智慧領域的科研成果，使用技術手段逐步提高每名運維人員所能管理的資料庫數量，從而實現資料庫運維工作的“減員增效”。另一方面，資料庫服務上雲後，雲服務提供商所需要運維的資料庫數量與之前相比天差地別，以前的工具可能已經不適應雲時代的需求。如何做好雲上海量資料庫的運維工作將成為雲服務提供商的一個巨大挑戰。
資料庫智慧運維體系
傳統意義上的資料庫監控服務僅僅是指（1）採集資料庫執行狀態；（2）上報/儲存資料庫執行資料；（3）圖形化展示資料庫執行狀態資料。但是，這僅僅是資料庫智慧監控運維體系的一部分。
如果把整個資料庫智慧監控運維體系比作一個人的話，傳統意義上的資料庫監控服務僅僅代表了，眼睛的角色。該服務只能做到發現問題，識別定位問題和解決問題都需要DBA的介入。因此DBA才是傳統資料庫監控運維體系中的核心要素，這也是DBA人才為何如此關鍵的原因之一。
而云時代的到來和大資料分析、人工智慧等技術的成熟，給了資料庫監控運維更多的想象空間。我可以在傳統資料庫監控（眼睛）的基礎上，增加預測分析和根因判斷模組，建立現象-根因-解決方案的對映關係（大腦），最後通過資料庫管理模組執行解決方案（雙手），從而實現從發現問題，定位問題，到解決問題的運維閉環。並且機器不同於人類，只要算力允許，它可以做到眼觀六路，耳聽八方，不知疲倦，也不會覺得無聊，7x24的盯著成百上千資料庫系統的各種執行資料，不會放過任何一個微小的潛在問題。因此，資料庫運維工作的智慧化中，使用規則或演算法固化DBA判斷和決策經驗將是非常重要的一環。
友商的資料庫智慧運維體系
綜合來看目前亞馬遜在雲資料庫的智慧監控體系上切入的比較早，也發展了很多成果。相對而言，其他傳統廠商在資料的智慧監控體系上雖然各有所長，但是並沒有像亞馬遜一樣能夠形成運維閉環。亞馬遜Redshift在資料庫監控運維設計上體現了資料庫服務化的思想，他們只提供了非常簡單的系統負載分析和問題SQL定位工具幫助雲上應用開發者發現業務層面的問題。而把資料庫系統的複雜性全部隱藏在了雲服務運維層的後臺，我個人猜測（因為我們看不到AWS的運維介面）亞馬遜AWS後臺應該有一整套自動發現問題，定位問題和解決問題的工具。否則，僅僅憑一個公司的人力肯定是無法運維全球海量的資料庫的。
更多的友商智慧運維產品分析和對比相關內容，我們就不在這裡贅述了，後續我們會有專題展開討論。
GaussDB(DWS)的資料庫智慧運維體系
參考友商資料庫監控運維體系的建設經驗，結合GaussBD(DWS)數倉的自身特點，我們準備從眼，腦，手三個方面發力建立閉環的資料庫智慧監控運維體系。
GaussDB(DWS)使用DMS來承載資料庫的智慧運維體系。DMS將會串起資料庫運維過程中的監控，分析，處理三個步驟，分別對應上文提到的資料庫智慧運維體系中的眼，腦，手三部分，從概念設計上形成運維體系的閉環。
監控部分：主要負責資料庫執行狀態資料的採集、儲存和視覺化展示，這一部分基本等同於傳統的資料庫的監控業務。這一部分功能和指標的選取，我們參考了友商以及運維團隊的建議，將監控指標分為底層IT系統運維指標和資料庫系統運維指標兩類，正在分別逐步補齊和完善中。監控模組是DMS資料庫運智慧監控運維體系首先發力，並要在短時間內形成競爭力的模組。
分析部分：作為整個DMS資料庫智慧運維體系的大腦，該部分是承擔運維資料分析與決策的關鍵模組。該部分因為其複雜性，目前還處於設計構想階段。初步規劃有三個子模組，時間序列的趨勢分析子模組，該模組主要用來做趨勢預測分析，用來預判潛在的問題；邏輯推斷子模組，使用者分析問題現象與實際根因之間的關係，可以實現從問題現象到觸發原因的推斷，初步考慮使用搜尋引擎技術實現；知識圖譜子模組，主要用於現象、根因與解決方案之間的對映關係表示，方便從定位的根因中找到最合適的解決方案。
處理部分：主要由DWS提供的資料庫管理功能承擔，目前可以提供資料庫引數配置（可配置引數少，需要進一步豐富），工作負載佇列配置，叢集安裝/解除安裝，叢集重啟，叢集擴容，叢集資料重分佈以及節點溫備等運維能力。
GaussDB(DWS)資料庫智慧運維典型使用者與需求
為了進一步理清資料庫智慧運維產品的設計思路，我們計劃從使用者的角度分析其需求，然後從需求匯出功能（工具）頁面設計，從功能（工具）頁面總結出所需監控資料庫指標。通過分析資料庫監控系統的各種使用場景，我們對資料庫監控系統的使用者做了使用者角色畫像，定義了資料庫運維過程中的三種角色，並認為不同角色僅僅關注資料庫運維的一個側面。在實際的資料庫運維場景中，可能同一個使用者會身兼多種角色，但是這裡我們為了方便分析僅僅從邏輯上定義這三種角色。
應用開發：主要指客戶側的應用開發角色，他們負責設計具體的業務SQL。他們關心業務SQL執行的正確性和執行效率。應用開發工程師需要用到web SQL來除錯其SQL語句的查詢效率；需要用到查詢監控頁面來檢視業務SQL在實際執行場景中的表現和資源消耗；需要用到工作負載佇列監控來確認新開發的業務SQL是否在合適的工作負載佇列中，以及所配置的熔斷規則是否合理，等等。
SRE：指的是華為雲側的資料庫運維角色，他們通常一個人需要負責成百上千個叢集的穩定執行，他們需要能夠迅速識別出叢集執行狀態的異常，叢集資源瓶頸以及叢集潛在的擴容需求，並且他們還需要積極響應客戶的求助，幫助客戶定位，確認和解決問題。SRE需要節點資源監控來識別叢集中的資源傾斜；需要識別叢集資源消耗基線變化趨勢，從而識別到擴容需並提醒使用者；需要關注儲存變化以推算下一次常規保養的時間點並自動規劃；同時還需要響應使用者需求，使用DMS提供的問題定位工具，輔助使用者定位現網問題。
DBA：指的是GaussDB(DWS)資料庫叢集專家，他們熟悉資料庫設計方法論，資料庫的調優，資料庫問題定位。他們需要分析定位資料庫的故障，從資源和業務角度運用多種工具綜合分析定位系統故障，系統穩定性和潛在瓶頸；也需要幫助使用者從業務、資料庫設計的角度去推薦資料庫的索引，分佈列配置，根據使用者業務水平推薦使用者購買合適的叢集規模等等；同時還需要輔助應用開發工程師調優引起效能劣化的SQL語句；在找到確切的故障根因後，推薦合適的解決方案修復故障。
在一般來說在公有云場景中，使用者角色一般只有應用開發和SRE兩種，公有云場景中的SRE角色往往涵蓋了DBA的角色。我們在這裡將運維角色細分的目的，其實是要展示一個完整的運維場景沙盤，將客戶的運維訴求分門別類的羅列出來，為後續進一步的功能（工具）頁面設計和運維場景設計提供基礎。
GaussDB(DWS)資料庫智慧運維指標
資料庫監控指標數量多，形式和邏輯複雜，根據指標型別可以分為邏輯關係與物理關係兩種。其中邏輯關係指數庫內部邏輯關係，比如，最頂層是資料庫，資料庫中有多個schema，schema中有多個表，資料庫中有多個使用者，一個使用者可以有多個schema和表。而物理關係是指，gaussDB(DWS)叢集的拓撲關係，比如，一個資料庫叢集是由多個計算節點構成，每個計算節點上會部署多個計算例項。這兩種指標關係都會影響到資料庫指標的採集維度和聚合展示維度。
因為上面已經分析了指標的維度關係，所以我們下面將只討論具體的資料庫指標型別，而不會對指標的維度進行展開。資料庫是一個軟體服務，而它必須執行在一個宿主機和作業系統之上，因此監控指標大致可以分為兩類：
系統資源類指標：這一類指標主要描述系統上的各種資源消耗
資料庫相關指標：這一類指標主要描述資料效能相關的業務負載水平
上圖總結了DMS採集的資料庫主要指標，具體指標項按照指標大類，原子指標和派生指標三個層次排列。不過，目前該指標地圖並不固定，未來隨著GaussDB(DWS)智慧運維繫統的逐步成熟，該指標地圖會逐步完善並固定下來。
因為MPP資料庫的特殊構型，資料庫例項是作為程式試執行在節點上的。因此，我們的指標設計其實本身會自帶維度屬性，比如磁碟使用率指標，最小的維度應該是某個DN例項，上一級是節點級，再上一級就是整個叢集。所以，我們實際提供的監控指標應該是指標維度關係與叢集指標地圖的一個笛卡爾積。為了描述這種情形，我們引入原子指標，派生指標和組合指標的概念。以上面的磁碟使用率為例，我們將DN例項的磁碟使用率作為原子指標，而其他維度的磁碟使用率作為派生指標。
- 原子指標：描述資料庫某個特性的最小維度指標，比如節點的CPU使用率，DN例項的磁碟使用率，等等。
- 派生指標：（1）原子指標在不同維度上的聚合結果，比如叢集平均CPU使用率，叢集磁碟使用率，等等；（2）對原子指標做統計運算得到的新指標，比如CPU傾斜率，等等。
- 組合指標：將多個原子指標或者派生指標組合在一起，從而得到的更加便於理解的新指標。比如叢集健康度，等等。
目前DMS的指標建設更多停留在原子指標和派生指標階段，因為我們認為應該首先補齊資料庫的基礎指標形成基本的監控運維能力之後，才能結合使用者使用習慣，深度挖掘指標在各個維度下的運維含義以及多種指標組合後所代表的運維意義。
總結
最後，總結一下，本文主要介紹了GaussDB（DWS）資料庫智慧監控運維服務體系的設計規劃和現狀。本文作為DMS系列文章的第一篇，主要起到一個概要介紹的作用，讓大家對GaussDB（DWS）資料庫智慧監控運維服務體系有個概略的認識，更多幹貨細節歡迎期待後續的文章。
想了解GuassDB(DWS)更多資訊，歡迎微信搜尋“GaussDB DWS”關注微信公眾號，和您分享最新最全的PB級數倉黑科技，後臺還可獲取眾多學習資料哦~