寫在開頭的話

Q:  軍哥，你們運營商行業的大規模集群，都有啥特點啊？

A:  我們集群主要是承載B域、信令和互聯網日志等去標識化數據，簡單的說，有三個特點：

1）集群規模較大：數千節點規模，近百PB數據量，日新增處理數據百TB以上；

2）組織干系人多：數據平臺開發運維過程涉及到數百人以上的不同團隊組織協同；

3）數據合規要求高：數據租戶服務涉及到數據安全、用戶隱私保護的合規要求高。

Q:  好吧，聽起來，要搞定這樣的集群，有難度呀！那何時要關注集群的治理呢？

A:  好問題！一般來說，當數據質量問題、數據交付及時性、數據安全問題需要耗費極高的應對成本，或者說，當你經常會碰到以下類似的問題時，就該考慮做系統化的集群治理工作了。

Q:  看起來，集群治理好像需要做很多配套的工作，實際上會有多大的產出效果呢？

A:  說出來，你可能不太信，就拿針對某集群治理的效果為例：在處理數據量翻倍的情況下，集群資源負載降低30%以上，綜合計算節省數百臺節點，每年節省投入上千萬元；減少垃圾數據、測試數據、中間數據、過程數據，占總存儲15%以上；核心產品模型運行時長，縮短30%-80%。

一、集群治理的定位

Q:  我以前聽說過數據治理，你這里說大規模數據集群的治理，有什么具體差異嗎？

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

• 工程一：搭建核心業務數據治理框架，包括基礎平臺的建設、治理規范的制定，元數據管理、數據血緣和數據質量工具開發和應用實踐，構建上層數據產品體系和數據能力開放平臺，讓數據多用活用，形成符合公司業務和組織協作特點的治理文化。
• 工程二：實現全域數據計算集群的深度治理，完成全域數據治理元數據的自動化采集、存儲和分析，構建數據能力開放平臺多租戶專項治理機制，沉淀數據治理中臺能力，基于大數據集群底層核心組件（如YARN、HDFS）的深入洞察，孵化出數據集群治理的應用。
• 工程三：完善治理機制體制建設，構建數據資產管理體系，并利用該系統的運營逐步重塑優化業務流程，實現可支撐全業務流程的成本評估機制，讓數據價值持續攀升。

回到你剛才的提問，數據治理基本上可以理解為工程一的核心目標；大規模集群的治理對應工程二，它需要長期支撐工程一的具體建設任務，并為數據資產管理體系的運營夯實基礎。

二、集群治理的背景

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

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

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

1）管理類：集群接口機權限管控、數據表不合理創建和刪除、垃圾數據表過多問題。這類問題，可以通過數據治理工程進行持續改進，但是解決時間周期以年為單位。

2）集群類：集群整體加工慢、穩定性欠佳、隊列資源爭搶、資源得不到合理分配的問題。這類問題，基本上要集群底層視角進行深入分析，在業務層做數據治理幾乎無解。

3）洞察類：冗余計算浪費資源問題、智能實時預警、完整血緣和數據價值分析問題。這類問題只能通過大數據技術手段對Hadoop底層核心組件做深入洞察來解決。

三、集群治理的目標

Q:  聽你這么說，針對大規模數據集群的治理工程還是很有必要的！

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

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

1

充分保障集群資源算力

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

2

有效驅動平臺數據治理

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

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

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

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

然后構建元數據管理、數據質量稽核、數據血緣分析、數據地圖等工具集：

• 元數據管理：數據庫表、模型腳本等元數據信息龐大復雜，可通過全文檢索功能迅速查找和關鍵字匹配的權限范圍內的元數據信息，為海量數據分析提供更快、更正確的查詢處理、更好的數據質量、更易使用的操作接口等。
• 數據血緣分析：元數據管理重要應用之一，展示表、視圖、過程之間的關系，表和指標間的關系。采用NET模式或FLOW模式進行信息呈現。血緣關系的數據來源支持通過解析數據加工SQL腳本、存儲過程注釋的方式；可支持通過ETL流程自動生成的方式，亦可支持通過配置表的方式。
• 數據地圖：元數據信息的全景視圖，描述所有元數據對象的血緣關系，所處層級覆蓋范圍由ODS->DWA->DWD->DM層，全面呈現了數據倉庫中數據之間的關系。

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

在這樣的大規模集群環境下，數據治理的本質其實就是：解決人與人的對抗、人與機器的對抗、人與工具的對抗、人與數的對抗問題。實踐經驗發現，只是靠堆人的方式，或者只在數據治理文化層面強調人機數的全面協同，要做好大規模集群的數據治理是不太現實的。更務實的做法是基于公司業務和組織架構特點，不斷驅動和協同優化，還要借助大數據技術手段，精益推動數據集群側的持續治理，形成數據治理+集群治理+資產管理的整體協同效應。

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

四、集群治理的實施路徑

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

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

理清大規模數據集群的現狀和治理需求點

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

第三步：構建針對大數據集群的智能運維技術平臺

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

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

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

第七步：重構數據血緣、元數據、數據資產管理應用

第八步：智能分析集群用戶行為畫像，檢測預測異常

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

五、集群治理的案例實踐

1

理清大規模數據集群的現狀和治理需求點

• 現狀：Hadoop集群的計算能力已達到數千節點，平臺部分集群初期由外部廠商進行建設，為了支撐業務快速上線，并沒有統一規劃，無序建設引發的問題逐漸暴露出來，權限混亂、計算能力下降、資源冗余計算、資源浪費等問題頻發，針對該部分集群的穩定性和資源利用優化治理工作挑戰巨大。
• 需求點：數據治理項目實施的整體難點主要集中在運營商多源頭數據質量持續改進、日萬億級大規模數據加工處理、數據平臺資源彈性交付與產品化快速響應支撐能力、數據能力開放平臺租戶高效運營、數據平臺智能運維體系建設、數據安全合規保障等六個方面。其中跟集群本身治理特別相關的是：集群智能運維平臺搭建、Hadoop組件洞察應用、冗余計算挖掘、集群用戶行為智能分析、數據血緣與元數據管理系統重構等五個方面。

2

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

治理組織架構

• 集群治理組：負責集群治理平臺應用和優化評測工具研發、治理方案的制定、組織治理周例會和專項優化虛擬小組聯合討論會、定期跟蹤巡檢治理效果，像牽引器一樣驅動大家協同完成工作。
• 數據治理組：除了負責數據質量和常規治理工作以外，還要配合集群治理組的方案，評估涉及到業務數據域基礎模型采集加工過程中的改進優化需求點，然后負責具體實施，當然還包括相關產品支撐模型的重構、融合模型的整合優化工作。
• 租戶運營組：配合數據治理組、數據建模組和集群治理組完成租戶場景集群治理專項方案的實施。
• 平臺維護組：配合產品應用部、數據治理組、租戶運營組、數據建模組、集群治理組完成集群治理專項優化方案的實施。
• 數據建模組：配合數據治理組、集群治理組完成集群治理平臺AI類模型的開發。
• 產品應用部：配合數據治理組和集群治理組完成集群治理專項優化方案的實施。

治理方法論

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

治理技術框架

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

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

基于以上面臨的各種困境構建巡山大數據集群治理平臺，以資源、存儲、作業三大角度，從資源畫像、作業畫像、存儲畫像、冗余計算挖掘、數據血緣畫像、RPC畫像六大維度，幾十個小維度進行集群交叉治理并協同各相關組織進行全域治理，使集群全面向良性健康方向發展。

3

第三步：構建針對大數據集群的智能運維技術平臺

Q:  軍哥，搞大規模數據集群的治理怎么扯到智能運維平臺上面去了呢？必須要建這個平臺嗎？

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

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

1）運維1.0，主要關注網管軟件和ITSM工單系統，講究業務協同和運維流程化。

2）運維2.0，主要關注CMDB和SOP標準運維，一般都會強調自動化工具在運維場景的應用，重點解決一些靠堆人方式解不了的問題。

3）運維3.0，主要關注DevOps、微服務、容器化的融合，比如基于容器云的DevOps一體化平臺，打通項目管理、需求、研發、測試、上線、變更處理全流程。

4）運維4.0，主要關注AIOps，實現智能化的健康可用性分析、資源占用預測統計、異常檢測、故障預警、智能擴縮容、日志根因分析應用等，其實就是用大數據的技術手段來搞定AIOps模型數據的采集、存儲和分析處理。

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

總體架構

ITSM：IT流程服務管理系統，支持跨部門業務工作協同；CMDB：配置管理平臺，IT資產應用統一配置化動態管理；Job：自動化作業平臺，運維場景的作業批量自動化調度執行；SOP：標準運維平臺，可視化拖拽模板化的運維流程定義和調度執行；DevOps: 開發運維一體化平臺，公司平臺級開發運維一體化管理模式；大數據集群治理平臺應用：基于Hadoop內核組件深度分析，實現各類運維數據綜合采集和統一整合，基于運維業務場景構建智能調度模型，提升平臺數據處理作業性能，有效節省集群資源占用，實現平臺集群資源利用率較高。Monitor統一監控：先支持基礎設施和平臺集群監控應用，然后完成數據治理及上層產品層對接，逐步形成更全面的端到端統一監控平臺。

數據生產監測可視化大屏

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

4

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

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

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

• 從計算角度，通過采集全域作業信息，解析出數十項核心指標和千個作業配置，計算出作業耗時TOP、耗內存TOP、耗CPU TOP、數據傾斜TOP、高IO TOP以及從不同業務、不同周期、不同賬戶洞察待優化作業，針對不同異常類型給出相應優化方案，降低作業資源負載、降低輸出文件數、提升輸出文件大小，從而減低整個集群資源負載和提升存儲系統穩定性。

• 從存儲角度，采集分布式存儲系統的元數據鏡像和元數據操作日志，洞察分布式存儲系統文件數趨勢、文件分布統計、平均文件大小趨勢統計、空文件分布、垃圾文件分布。

技術實現方案

5

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

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

技術實現方案  

6

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

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

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

技術實現方案 

7

第七步：重構數據血緣、元數據、數據資產管理應用

面臨挑戰

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

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

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

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

元數據平臺視圖 

元數據平臺應用

全域數據血緣關系圖

 技術實現方案

8

第八步：智能分析集群用戶行為畫像，檢測預測異常

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

技術實現方案

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

六、結語

在運營商大規模集群治理的實踐過程中，有幾點感悟：

1）領導的支持力度非常關鍵。公司領導對數據資產管理建設的價值認可，能夠在核心數據質量持續優化過程中提供組織協調支持，有效推動集團和各省分公司配合改進，保障端到端質量優化效果。

2）數據治理文化建設是核心。建立專業的數據治理團隊，優化數據資產管理組織架構，以自底向上的完整血緣分析、核心數據質量為入口，建立自下而上、自發協同、精益推進的數據治理文化。

3）數據資產管理架構和配套工具是基礎。在業務發展過程中，逐步打造體系化的數據治理實施能力，安全合規標準規范先行，建立持續優化的治理體制。

4）數據能力開放平臺是優勢。通過面向外部租戶自助建模平臺的綜合運營，可大幅提升內部數據治理工程跨組織的協同效率，數據用多了，自然會激發治理的原動力。

5）基礎平臺團隊要擁抱并吃透開源技術。能夠從大數據平臺核心組件源碼層進行重構與性能調優，充分保障集群的穩定性和算力要求，在大規模集群故障預測、異常檢測、故障恢復、資源調度優化、跨集群協同計算等方向全面探索和應用AIOps技術解決難題。

 本 文 作 者