?一、背景與挑戰

隨著銀行數據業務的飛速發展，傳統數據倉庫也經受著越來越多的挑戰,數據量爆發式增漲，底層資源不斷擴張，業務對數據的時效性要求提升。同時，新技術不斷涌現，技術架構由單一數倉集群轉向功能化拆分，即：將單一數據倉庫經過拆分，分解成不同的功能定位的倉庫集群，以達到提前感知業務變化、快速應對，精準利用資源等目的。

對數據倉庫的運維來說，“一個數據倉庫容納全行業務數據”、“只需維護一個數據倉庫”的日子一去不返，傳統的“人肉運維”滿足不了當前以及未來的運維需求。傳統運維工具在某些場景下可以實現對已知問題和故障的快速處置、恢復生產，但終究還是屬于被動運維的范疇。當前在數據倉庫不斷擴展、業務訴求不斷提升的大背景下，業務中斷越來越不被接受，最終的結果將是被動運維疲于奔命。在數據倉庫發展的大背景下保證業務的正常開展、保障業務的連續性將是數據倉庫運維的首要職責。

二、應對與方案

運維是保障業務的正常運行和開展，不是發生問題之后的“堵窟窿”，盡管運維的經歷告訴我們：由于各種天災人禍，“堵窟窿”的事情肯定少不了，但是很大一部分的事故故障都是有先兆的。正如海恩法則所示，一起重大事故的產生，經由29次輕微事故，300個事故苗頭以及1000個事故隱患，如果能做到變被動為主動，主動捕捉到事故苗頭以及事故隱患，提前發現運維堤壩的薄弱、隱患環節，制定完備的應對方案，就提前進行加固處置，消除隱患。

伴隨銀行數據倉庫的不斷發展，運維的思路也在不斷的演進，逐漸由被動運維向主動運維轉變，結合既有運維的經驗，推動數據倉庫領域的主動運維。經過近幾年的經驗積累，G行建設形成了一套相對成熟的數倉運維方案，即主動運維與應急處置相結合，“主動運維”提前發現問題、消滅隱患，應急處置在問題發生時快速響應、恢復業務，實現對數據業務的保駕護航。

三、數倉運維落地實踐

與傳統的業務庫不同，數據倉庫擁有得天獨厚的條件，數據倉庫是所有業務數據存儲、分析、處理的核心。數據倉庫可以通過就地取材，將自身所有的運行數據進行采集、歸納、匯總、入倉，通過數據倉庫的數據存儲、分析、加工的能力，將數據倉庫的各項運行數據進行歸集處理，最終形成有效的數據倉庫運行數據，將數據倉庫運維轉向數字化。

G行數據倉庫運維探索實踐，始終以保障業務連續性，釋放人力資源，精準故障定位、快速業務恢復等為目標，立足日常的生產運維需求場景，如容量管理、故障處置等。將應用業務運行、底層資源消耗、數據倉庫運行監測等多方面的運行數據進行采集，建立多維數據倉庫運行模型，能夠精準的記錄各個時點，多個維度的運行狀態。

全面的運行數據采集包括底層資源數據、數據倉庫系統運行數據、業務運行數據等眾多方面。

底層資源數據：既包括CPU、內存、IO、網絡，還包括系統層各項進程的資源消耗，尤其是底層資源的橫向對比。數據倉庫的最大特點就是集中，而集中的最大的故障隱患就是牽一發而動全身，資源節點瓶頸很大的概率就會將整個數據倉庫的處理性能拉低。就運維經驗而言，除了全局性的性能問題，大概率的性能突降等問題或由“木桶效應”局部故障引起的整體性能下降，而局部故障能從全局底層資源的橫向對比或歷史資源消耗縱向比對，快速的定位局部，進而快速的處理，恢復業務生產。

數據倉庫運行數據：數據倉庫運行與常規的數據庫運行不同，常規數據庫運行可根據QPS、TPS等指標綜合判斷，而數據參倉庫受限于運行的業務場景特點萬難梳理一兩個指標來判斷整理運行狀態，而由于處理數據規模及場景的復雜，通常一個常規SQL也將會導致整體的數據倉庫運行壓力飆升。這也就是數據倉庫運行與業務數據庫運行的不同之處。

業務運行數據：業務運行數據同樣是不可或缺的一部分。不同于單一的業務系統數據庫，數據倉庫往往立足于復雜的多業務場景，必須適應所有接入的業務。通過對業務運行數據的監測，發現業務場景的變化，能夠有效的快速的定位問題。由果尋因，業務發展變化往往是數據倉庫運行變化的根因，將業務運行數據采集監控并納入數據倉庫的整體運行監測是必須的。

G行在探索實踐過程中，各項數據采集監測告警指標項100多項，其中底層資源采集指標20余項，除常規的CPU、內存、IO等資源更關注可能對數倉運行產生影響明細項，如磁盤壞塊數量，負載波動，進程資源消耗，文件系統文件數，內存分頁效率，句柄使用量，僵尸、殘留進程等明細指標項；數據庫運行等采集指標50余項，包括庫執行效率，實時訪問量、訪問時長，阻塞排隊，庫實例級資源消耗，傾斜SQL，低效節點，Xlog同步、數據頁讀取效率等；業務相關指標采集10余項，時點業務并發，單項任務時長、累計時長，完成任務占比等；其他采集指標項20多項。隨著業務發展，運維場景不斷豐富，所需的采集指標項也不斷完善，簡而言之“與時俱進”。將運行數據終以圖形呈現，全面檢測，快速識別異常。

立足于數據倉庫的各類運行數據，根據生產運行場景以及日常運維需求，形成有針對性的監測模型，通過模型來監測發現運行異常，運行變化等問題。同時，在運行模型基礎上再通過實際結果的反饋，逐步優化監測模型，進而優化各項監測采集指標，形成一個可行性極高的閉環系統。通過場景模型上線、反饋優化，不斷的完善反饋，逐步形成數據倉庫的數字化運維平臺。

隨著運行分析模型的建立和完善，除了在一定程度上實現潛在運行故障的提前預判、突發運行故障的快速定位之外，還有一種重要的運維場景：故障回溯。所以在很多故障發生時，往往不可能有充足的時間分析定位問題，而有些問題又隱藏的很深，一旦發生影響生產的事件，一般采用強制手段恢復生產，強制手段很大程度升就破壞的現場，而全面的運行數據采集保留，能夠在一定程度上實現保留現場，為后續的故障分析定位提供運行數據的支撐。

數據倉庫運行數據采集的基礎建立后，可向上逐步衍生，實現運維功能自動化。G行數據倉庫運維平臺建設本著建立自動化，標準化，數字化的原則，建立在兼顧運維成本、運維質量和運維效率基礎上，包括如下五個方面功能：

業務診斷：通過實施業務運行跟蹤監測，實施探查業務運行狀態；通過歷史故障分析模型對實時提交的業務進行分析，發現模型匹配的異常業務訪問進行自動處理；在針對實時業務進行監測的同時，經運行信息做歷史留存，為后續故障定位、場景分析、業務回溯做好準備。

健康監測：實時監測應用狀態，基礎資源使用情況，模擬業務場景不間斷進行平臺監測，做到實時健康監測，運行出現偏差立即響應。

閉環優化：包括應用業務優化和數倉自優化，應用業務優化通過采集的業務運行信息，進行梳理將低效的業務信息以及優化建議自動推送給相關人員，敦促進行整改，提升業務體驗；數倉自優化通過檢測訪問連接、并發，底層資源使用情況進行動態調整資源分配情況。

容量評估：通過對數倉各個集群的算力、空間、業務運行時效等多個維度進行綜合容量評估，每日、每周、每月形成報告推送，能夠快捷有效的進行數倉容量監測評估，實現有計劃的進行數倉容量管理。

隨著G行各項運行指標數據采集的積累沉淀，立足于業務以及運維需求場景，利用每天幾十GB的運行數據，根據不同需求場景建立支撐模型，利用日趨完善的數字化、自動化框架，實現快速需求響應。

四、數據倉庫運維展望

我們相信，隨著運維技術的不斷演進與發展以及運維經驗的不斷積累、工具化、自動化的深入發展，量變會引起質變，數據倉庫運維的智能化也將在不久的將來實現。