運營商大規模資料叢集治理的實踐指南

Q:  我以前聽說過資料治理，你這裡說大規模資料叢集的治理，有什麼具體差異嗎？

A:  好問題！不過要搞清楚這塊，得先了解一下我們資料資產管理體系建設的實施路徑——主要分三個子工程，同步開展實施推進：

• 工程一：搭建核心業務資料治理框架，包括基礎平臺的建設、治理規範的制定，後設資料管理、資料血緣和資料質量工具開發和應用實踐，構建上層資料產品體系和資料能力開放平臺，讓資料多用活用，形成符合公司業務和組織協作特點的治理文化。

• 工程二：實現全域資料計算叢集的深度治理，完成全域資料治理後設資料的自動化採集、儲存和分析，構建資料能力開放平臺多租戶專項治理機制，沉澱資料治理中臺能力，基於大資料叢集底層核心元件（如YARN、HDFS）的深入洞察，孵化出資料叢集治理的應用。

• 工程三：完善治理機制體制建設，構建資料資產管理體系，並利用該系統的運營逐步重塑最佳化業務流程，實現可支撐全業務流程的成本評估機制，讓資料價值持續攀升。

Q:  你剛才說的好像很有道理，但是我還是不太明白，為何不是在資料治理工程中擴充套件一個子任務去做，而是要另起爐灶，搞一個新的大工程來做資料叢集的專項治理？

A:  好問題！恭喜你！你快要觸控到資料叢集治理問題的核心了。我們不妨再捋一下資料叢集治理的背景，主要是遇到的歷史部分叢集無序建設的種種問題：

這些問題可進一步分為幾類，簡單分析完你就自然明白了：

Q:  聽你這麼說，針對大規模資料叢集的治理工程還是很有必要的！

A：是的，“大規模”帶來的問題，肯定不止上面這幾類，實際上會遠超你的想象，傳統的資料治理工具（如後設資料、資料質量、資料血緣分析）可能就不靈了，必須要根據叢集規模、資料倉儲新型技術方案選型以及業務流程進行重構，才可能得到預期的治理效果。再強調一句，大規模資料是長在叢集之上，而叢集裡面的很多關鍵元件不是傳統的商業關係型資料庫，而是開源社群的通用版本，其可維護性、穩定性和功能侷限性等方面都存在較大的挑戰，效能這塊也需要深入到原始碼層進行重構調優處理，你得做好準備。

所以，我們做大規模叢集治理的核心目標聚焦在①確保叢集穩定，充分保障叢集資源算力；②以效果為導向，有效驅動平臺資料治理：

毫無疑問，在大規模叢集計算環境，保障叢集資源算力是首要任務。如果這一塊稍有閃失，資料採集、資料儲存、資料加工、資料建模分析、資料測試、資料稽核、資料遷移、資料同步、資料計算、資料作業重跑等流程可能都要崩潰，因為這些環節背後都涉及到大量的資料作業任務排程執行，其成功與否取決於分散式系統元件整體的通訊、資源的申請、以及任務例項的執行結果，因此除了足夠的物理資源池之外，還需要特別保障叢集Master程式類服務的效能表現和穩定性。

開展叢集治理的工作，最重要的目標就是有效支撐資料治理工程的建設。

資料治理是一個系統工程，通常是按照類似下面的框架做：

其關鍵是組織、流程、平臺工具、評價考核機制的全面協同。

首先是從資料採集加工流程中梳理出資料治理體系最需關注的各環節建設內容和目標：

然後構建後設資料管理、資料質量稽核、資料血緣分析、資料地圖等工具集：

• 後設資料管理：資料庫表、模型指令碼等後設資料資訊龐大複雜，可透過全文檢索功能迅速查詢和關鍵字匹配的許可權範圍內的後設資料資訊，為海量資料分析提供更快、更正確的查詢處理、更好的資料質量、更易使用的操作介面等。

• 資料血緣分析：後設資料管理重要應用之一，展示表、檢視、過程之間的關係，表和指標間的關係。採用NET模式或FLOW模式進行資訊呈現。血緣關係的資料來源支援透過解析資料加工SQL指令碼、儲存過程註釋的方式；可支援透過ETL流程自動生成的方式，亦可支援透過配置表的方式。

• 資料地圖：後設資料資訊的全景檢視，描述所有後設資料物件的血緣關係，所處層級覆蓋範圍由ODS->DWA->DWD->DM層，全面呈現了資料倉儲中資料之間的關係。

如果你的資料叢集規模不大，比如百節點以內，有非常完備的治理組織架構，按照傳統的工具流程和方法論去做資料治理，一般問題不大。但是，如果是在運營商大規模叢集環境，隨著業務的發展，遇到新的問題時，光靠一些老套路是行不通的，或者說整體治理成本是極大的。

簡而言之，叢集治理支撐資料治理，資料治理驅動資料資產管理。資料中心的資產包括資料、程式、流程、服務及資源5大類，透過叢集治理和資產的有效管理，對於促進資料價值持續發現、資料能力持續開放、資料的持續變現有巨大的促進作用，從而逐步推動資料治理體系向資產管理體系演進。

Q:  軍哥，說了半天，你好像還沒有告訴我，到底如何開展叢集的治理工作呀？

A:  不急，只要你明白了叢集治理的定位、背景、目標，其實搞大規模資料叢集的治理工作就沒有那麼難，按照以下8個步驟做就行：

第一步：理清大規模資料叢集的現狀和治理需求點

第二步：明確治理的組織架構、方法論、技術框架

第三步：構建針對大資料叢集的智慧運維技術平臺

第四步：實現YARN作業&HDFS畫像、小檔案洞察

第五步：實現NN RPC畫像、關鍵Master服務預警

第六步：實現冗餘計算挖掘，以目錄維度評估冗餘度

第七步：重構資料血緣、後設資料、資料資產管理應用

第八步：智慧分析叢集使用者行為畫像，檢測預測異常

下文中將對以上八個步驟進行具體解讀。

五、叢集治理的案例實踐

第一步：理清大規模資料叢集的現狀和治理需求點

• 現狀：Hadoop叢集的計算能力已達到數千節點，平臺部分叢集初期由外部廠商進行建設，為了支撐業務快速上線，並沒有統一規劃，無序建設引發的問題逐漸暴露出來，許可權混亂、計算能力下降、資源冗餘計算、資源浪費等問題頻發，針對該部分叢集的穩定性和資源利用最佳化治理工作挑戰巨大。

• 需求點：資料治理專案實施的整體難點主要集中在運營商多源頭資料質量持續改進、日萬億級大規模資料加工處理、資料平臺資源彈性交付與產品化快速響應支撐能力、資料能力開放平臺租戶高效運營、資料平臺智慧運維體系建設、資料安全合規保障等六個方面。其中跟叢集本身治理特別相關的是：叢集智慧運維平臺搭建、Hadoop元件洞察應用、冗餘計算挖掘、叢集使用者行為智慧分析、資料血緣與後設資料管理系統重構等五個方面。

第二步：明確治理的組織架構、方法論、技術框架

治理組織架構

• 叢集治理組：負責叢集治理平臺應用和最佳化評測工具研發、治理方案的制定、組織治理周例會和專項最佳化虛擬小組聯合討論會、定期跟蹤巡檢治理效果，像牽引器一樣驅動大家協同完成工作。

• 資料治理組：除了負責資料質量和常規治理工作以外，還要配合叢集治理組的方案，評估涉及到業務資料域基礎模型採集加工過程中的改進最佳化需求點，然後負責具體實施，當然還包括相關產品支撐模型的重構、融合模型的整合最佳化工作。

• 租戶運營組：配合資料治理組、資料建模組和叢集治理組完成租戶場景叢集治理專項方案的實施。

• 平臺維護組：配合產品應用部、資料治理組、租戶運營組、資料建模組、叢集治理組完成叢集治理專項最佳化方案的實施。

• 資料建模組：配合資料治理組、叢集治理組完成叢集治理平臺AI類模型的開發。

• 產品應用部：配合資料治理組和叢集治理組完成叢集治理專項最佳化方案的實施。

治理方法論

這裡的核心就是建立自下而上、自發協同、精益推進式的資料治理文化。

治理技術框架

Q: 這個技術框架理解起來太抽象了，要解決的問題可以再解釋一下嗎？

A: 其實沒有那麼難以理解，主要是公司業務高速發展過程中資料業務需求越來越複雜，所需算力也越來越大，進一步導致某些叢集的規模越來越大，承載的產品也越來越多，部分叢集面臨資源負載過高、資源搶佔嚴重、RPC請求負載過高等問題；儲存系統也面臨空檔案、垃圾檔案、小檔案過多，平均檔案大小過小、檔案數持續增長等問題，儲存系統穩定性面臨很大隱患；作業又面臨執行耗時過長、耗資源大、資料傾斜嚴重等問題，直接導致資料加工異常率過高、資料具備時間有延遲風險、產品交付面臨風險。

Q:  軍哥，搞大規模資料叢集的治理怎麼扯到智慧運維平臺上面去了呢？必須要建這個平臺嗎？

A:  好問題！前面說過，叢集治理的首要目標就是充分保證叢集資源算力，實際上就是要保障叢集關鍵服務執行和資料作業資源排程的穩定性，以及相對不錯的效能表現。

這裡的穩定性和效能就是IT運維領域的事情，從業界發展來看，主要經歷了四個階段：

一般來說，企業IT建設的頭幾年，會逐步上線CMDB、ITSM、Job自動化作業、SOP等子系統，然後開始考慮DevOps、容器雲、AIOps等方向的建設。對於大規模資料叢集來說，我們必須先構建好這個基礎的智慧運維技術平臺。

資料生產監測視覺化大屏

具體實施過程中，前期需重點關注平臺最佳化和跨部門業務協同子系統的運營成效。

以底層技術為核心，從資源、儲存、計算三大維度進行聯合治理，深度監控各業務資源佇列使用狀態、儲存系統檔案分佈、作業執行事件和配置，建立視覺化工具體系，驅動日常最佳化和運營。

• 從資源角度，對線上叢集的資源佇列狀態進行秒級資料採集，包含佇列最大容量、佇列配置容量、佇列已使用容量多維度的資料採集，實時監控不同業務線、不同週期資源使用狀態，以達到動態調整資源規劃、加工週期保障產線加工正常進行。

• 從計算角度，透過採集全域作業資訊，解析出數十項核心指標和千個作業配置，計算出作業耗時TOP、耗記憶體TOP、耗CPU TOP、資料傾斜TOP、高IO TOP以及從不同業務、不同週期、不同賬戶洞察待最佳化作業，針對不同異常型別給出相應最佳化方案，降低作業資源負載、降低輸出檔案數、提升輸出檔案大小，從而減低整個叢集資源負載和提升儲存系統穩定性。

• 從儲存角度，採集分散式儲存系統的後設資料映象和後設資料操作日誌，洞察分散式儲存系統檔案數趨勢、檔案分佈統計、平均檔案大小趨勢統計、空檔案分佈、垃圾檔案分佈。

技術實現方案

第五步：實現NN RPC畫像、關鍵Master服務預警

大資料叢集有很多關鍵服務，這些服務的健康異常狀態，需要重點監控，且儘可能做到實時處理效果，這樣在故障發生後可以組合多種監控和日誌資訊，從多個維度交叉定位問題，提升解決問題效率。

技術實現方案

冗餘計算意味著同一份資料被多個加工流程加工，主要是由於前期為了支撐業務快速上線、沒有統一規劃、無序建設過程中所引發的問題，在運營商海量資料背景下，資料重複加工意味著對記憶體、CPU、儲存容量、IO、檔案數量、RPC負載有著全面且巨大的影響，在全域數十萬加工作業中如何全面且精準定位冗餘計算成為不小的挑戰，基於此持續最佳化線上加工流程更是一個緩慢的過程，需要詳細梳理業務需求，制定資料標準，明確資料口徑。

洞察冗餘計算主要思路是解析全域數十萬個作業並從每個作業千個配置項中解析出輸入目錄，每個作業會有多個輸入目錄，最多的有上百個甚至上千個，且目錄中含有省份、賬期、基站等各種分割槽型別，我們需要對目錄進行通用化處理，以目錄為維度統計對應的加工流程以及每個加工流程對應的作業例項，從每個作業例項中計算記憶體消耗、CPU消耗、儲存消耗、IO負載、檔案數增長、RPC負載以評估冗餘計算帶來的成本、最佳化後達到的效果、執行週期內對其他資料加工產生的影響，以精細化資料為基礎協調各組織進行持續治理。

技術實現方案

第七步：重構資料血緣、後設資料、資料資產管理應用

面臨挑戰

在某叢集長期的無序建設中，由於對資料缺少平臺級的運營手段，比如缺少資料庫、資料表以及資料列統一的資訊維護平臺和整體的物理檢視，導致底層資料存在過多垃圾表，且缺少對底層資料的認知；

對後設資料的變更無監控無跟蹤，缺少全域加工資料血緣關係，不能追溯資料加工流向，導致故障發生後不能明確影響範圍，資料成本與價值也難以衡量，在安全合規為第一紅線的背景下，對敏感資料也沒有效跟蹤；

缺少資料資產管理，沒有展示資料應有的支撐能力，造成組織架構內資料服務資訊不對稱。

基於以上痛點，著手重構了企業級全域後設資料平臺，提供全域物理檢視、業務檢視、後設資料變更跟蹤監控、全域資料血緣關係圖等核心功能，物理檢視提升對資料的認知，業務檢視展示資料支撐能力，後設資料變更跟蹤實時瞭解產線環境異常修改，資料血緣可提供資料追溯、資料成本價值洞察、敏感資料流向。

後設資料平臺檢視

後設資料平臺應用

全域資料血緣關係圖

技術實現方案

第八步：智慧分析叢集使用者行為畫像，檢測預測異常

產線環境難免存在資料被誤刪除的情況，故障發生後，一般要透過較複雜的綜合定位過程才能發現根因，此時產線加工可能受阻、資料具備時間延遲，進一步影響到產品質量和使用者體驗；由於此類故障從根本上難以徹底消除，為儘可能的降低負面影響，可建立使用者行為異常操作智慧檢測機制，對不正常的使用者操作及時預警，在一定程度上提前發現問題、規避故障。

技術實現方案

根據產線環境千萬級的作業資訊，結合當下的資源狀態進行特徵抽取，建立實時的機器學習模型，對當前以及未來一段時間視窗的資源佔用進行預測，將檢測到的異常狀態波動進行告警。

六、結語