運營商大規(guī)模數(shù)據(jù)集群治理的實踐指南

寫在開頭的話

Q: 軍哥，你們運營商行業(yè)的大規(guī)模集群，都有啥特點�。�

A: 我們集群主要是承載B域、信令和互聯(lián)網(wǎng)日志等去標識化數(shù)據(jù)，簡單的說，有三個特點：

1）集群規(guī)模較大：數(shù)千節(jié)點規(guī)模，近百PB數(shù)據(jù)量，日新增處理數(shù)據(jù)百TB以上；

2）組織干系人多：數(shù)據(jù)平臺開發(fā)運維過程涉及到數(shù)百人以上的不同團隊組織協(xié)同；

3）數(shù)據(jù)合規(guī)要求高：數(shù)據(jù)租戶服務涉及到數(shù)據(jù)安全、用戶隱私保護的合規(guī)要求高。

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

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

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

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

一、集群治理的定位

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

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

工程一：搭建核心業(yè)務數(shù)據(jù)治理框架，包括基礎平臺的建設、治理規(guī)范的制定，元數(shù)據(jù)管理、數(shù)據(jù)血緣和數(shù)據(jù)質(zhì)量工具開發(fā)和應用實踐，構建上層數(shù)據(jù)產(chǎn)品體系和數(shù)據(jù)能力開放平臺，讓數(shù)據(jù)多用活用，形成符合公司業(yè)務和組織協(xié)作特點的治理文化。

工程二：實現(xiàn)全域數(shù)據(jù)計算集群的深度治理，完成全域數(shù)據(jù)治理元數(shù)據(jù)的自動化采集、存儲和分析，構建數(shù)據(jù)能力開放平臺多租戶專項治理機制，沉淀數(shù)據(jù)治理中臺能力，基于大數(shù)據(jù)集群底層核心組件（如YARN、HDFS）的深入洞察，孵化出數(shù)據(jù)集群治理的應用。

工程三：完善治理機制體制建設，構建數(shù)據(jù)資產(chǎn)管理體系，并利用該系統(tǒng)的運營逐步重塑優(yōu)化業(yè)務流程，實現(xiàn)可支撐全業(yè)務流程的成本評估機制，讓數(shù)據(jù)價值持續(xù)攀升。

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

二、集群治理的背景

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

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

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

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

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

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

三、集群治理的目標

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

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

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

1、充分保障集群資源算力

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

2、有效驅(qū)動平臺數(shù)據(jù)治理

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

數(shù)據(jù)治理是一個系統(tǒng)工程，通常是按照類似下面的框架做：

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

首先是從數(shù)據(jù)采集加工流程中梳理出數(shù)據(jù)治理體系最需關注的各環(huán)節(jié)建設內(nèi)容和目標：

然后構建元數(shù)據(jù)管理、數(shù)據(jù)質(zhì)量稽核、數(shù)據(jù)血緣分析、數(shù)據(jù)地圖等工具集：

元數(shù)據(jù)管理：數(shù)據(jù)庫表、模型腳本等元數(shù)據(jù)信息龐大復雜，可通過全文檢索功能迅速查找和關鍵字匹配的權限范圍內(nèi)的元數(shù)據(jù)信息，為海量數(shù)據(jù)分析提供更快、更正確的查詢處理、更好的數(shù)據(jù)質(zhì)量、更易使用的操作接口等。

數(shù)據(jù)血緣分析：元數(shù)據(jù)管理重要應用之一，展示表、視圖、過程之間的關系，表和指標間的關系。采用NET模式或FLOW模式進行信息呈現(xiàn)。血緣關系的數(shù)據(jù)來源支持通過解析數(shù)據(jù)加工SQL腳本、存儲過程注釋的方式；可支持通過ETL流程自動生成的方式，亦可支持通過配置表的方式。

數(shù)據(jù)地圖：元數(shù)據(jù)信息的全景視圖，描述所有元數(shù)據(jù)對象的血緣關系，所處層級覆蓋范圍由ODS->DWA->DWD->DM層，全面呈現(xiàn)了數(shù)據(jù)倉庫中數(shù)據(jù)之間的關系。

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

在這樣的大規(guī)模集群環(huán)境下，數(shù)據(jù)治理的本質(zhì)其實就是：解決人與人的對抗、人與機器的對抗、人與工具的對抗、人與數(shù)的對抗問題。實踐經(jīng)驗發(fā)現(xiàn)，只是靠堆人的方式，或者只在數(shù)據(jù)治理文化層面強調(diào)人機數(shù)的全面協(xié)同，要做好大規(guī)模集群的數(shù)據(jù)治理是不太現(xiàn)實的。更務實的做法是基于公司業(yè)務和組織架構特點，不斷驅(qū)動和協(xié)同優(yōu)化，還要借助大數(shù)據(jù)技術手段，精益推動數(shù)據(jù)集群側的持續(xù)治理，形成數(shù)據(jù)治理+集群治理+資產(chǎn)管理的整體協(xié)同效應。

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

四、集群治理的實施路徑

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

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

第一步：理清大規(guī)模數(shù)據(jù)集群的現(xiàn)狀和治理需求點

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

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

第四步：實現(xiàn)YARN作業(yè)&HDFS畫像、小文件洞察

第五步：實現(xiàn)NN RPC畫像、關鍵Master服務預警

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

第七步：重構數(shù)據(jù)血緣、元數(shù)據(jù)、數(shù)據(jù)資產(chǎn)管理應用

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

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

五、集群治理的案例實踐

1、第一步：理清大規(guī)模數(shù)據(jù)集群的現(xiàn)狀和治理需求點

現(xiàn)狀：Hadoop集群的計算能力已達到數(shù)千節(jié)點，平臺部分集群初期由外部廠商進行建設，為了支撐業(yè)務快速上線，并沒有統(tǒng)一規(guī)劃，無序建設引發(fā)的問題逐漸暴露出來，權限混亂、計算能力下降、資源冗余計算、資源浪費等問題頻發(fā)，針對該部分集群的穩(wěn)定性和資源利用優(yōu)化治理工作挑戰(zhàn)巨大。

需求點：數(shù)據(jù)治理項目實施的整體難點主要集中在運營商多源頭數(shù)據(jù)質(zhì)量持續(xù)改進、日萬億級大規(guī)模數(shù)據(jù)加工處理、數(shù)據(jù)平臺資源彈性交付與產(chǎn)品化快速響應支撐能力、數(shù)據(jù)能力開放平臺租戶高效運營、數(shù)據(jù)平臺智能運維體系建設、數(shù)據(jù)安全合規(guī)保障等六個方面。其中跟集群本身治理特別相關的是：集群智能運維平臺搭建、Hadoop組件洞察應用、冗余計算挖掘、集群用戶行為智能分析、數(shù)據(jù)血緣與元數(shù)據(jù)管理系統(tǒng)重構等五個方面。

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

治理組織架構

集群治理組：負責集群治理平臺應用和優(yōu)化評測工具研發(fā)、治理方案的制定、組織治理周例會和專項優(yōu)化虛擬小組聯(lián)合討論會、定期跟蹤巡檢治理效果，像牽引器一樣驅(qū)動大家協(xié)同完成工作。

數(shù)據(jù)治理組：除了負責數(shù)據(jù)質(zhì)量和常規(guī)治理工作以外，還要配合集群治理組的方案，評估涉及到業(yè)務數(shù)據(jù)域基礎模型采集加工過程中的改進優(yōu)化需求點，然后負責具體實施，當然還包括相關產(chǎn)品支撐模型的重構、融合模型的整合優(yōu)化工作。

租戶運營組：配合數(shù)據(jù)治理組、數(shù)據(jù)建模組和集群治理組完成租戶場景集群治理專項方案的實施。

平臺維護組：配合產(chǎn)品應用部、數(shù)據(jù)治理組、租戶運營組、數(shù)據(jù)建模組、集群治理組完成集群治理專項優(yōu)化方案的實施。

數(shù)據(jù)建模組：配合數(shù)據(jù)治理組、集群治理組完成集群治理平臺AI類模型的開發(fā)。

產(chǎn)品應用部：配合數(shù)據(jù)治理組和集群治理組完成集群治理專項優(yōu)化方案的實施。

治理方法論

這里的核心就是建立自下而上、自發(fā)協(xié)同、精益推進式的數(shù)據(jù)治理文化。

治理技術框架

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

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

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

3、第三步：構建針對大數(shù)據(jù)集群的智能運維技術平臺

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

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

這里的穩(wěn)定性和性能就是IT運維領域的事情，從業(yè)界發(fā)展來看，主要經(jīng)歷了四個階段：

1）運維1.0，主要關注網(wǎng)管軟件和ITSM工單系統(tǒng)，講究業(yè)務協(xié)同和運維流程化。

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

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

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

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

總體架構

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

數(shù)據(jù)生產(chǎn)監(jiān)測可視化大屏

具體實施過程中，前期需重點關注平臺優(yōu)化和跨部門業(yè)務協(xié)同子系統(tǒng)的運營成效。

4、第四步：實現(xiàn)YARN作業(yè)&HDFS畫像、小文件洞察

以底層技術為核心，從資源、存儲、計算三大維度進行聯(lián)合治理，深度監(jiān)控各業(yè)務資源隊列使用狀態(tài)、存儲系統(tǒng)文件分布、作業(yè)運行事件和配置，建立可視化工具體系，驅(qū)動日常優(yōu)化和運營。從資源角度，對線上集群的資源隊列狀態(tài)進行秒級數(shù)據(jù)采集，包含隊列最大容量、隊列配置容量、隊列已使用容量多維度的數(shù)據(jù)采集，實時監(jiān)控不同業(yè)務線、不同周期資源使用狀態(tài)，以達到動態(tài)調(diào)整資源規(guī)劃、加工周期保障產(chǎn)線加工正常進行。

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

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

技術實現(xiàn)方案

5、第五步：實現(xiàn)NN RPC畫像、關鍵Master服務預警

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

技術實現(xiàn)方案

6、第六步：實現(xiàn)冗余計算挖掘，以目錄維度評估冗余度

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

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

技術實現(xiàn)方案

7、第七步：重構數(shù)據(jù)血緣、元數(shù)據(jù)、數(shù)據(jù)資產(chǎn)管理應用

面臨挑戰(zhàn)

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

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

缺少數(shù)據(jù)資產(chǎn)管理，沒有展示數(shù)據(jù)應有的支撐能力，造成組織架構內(nèi)數(shù)據(jù)服務信息不對稱。

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

元數(shù)據(jù)平臺視圖

元數(shù)據(jù)平臺應用

全域數(shù)據(jù)血緣關系圖

技術實現(xiàn)方案

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

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

技術實現(xiàn)方案

根據(jù)產(chǎn)線環(huán)境千萬級的作業(yè)信息，結合當下的資源狀態(tài)進行特征抽取，建立實時的機器學習模型，對當前以及未來一段時間窗口的資源占用進行預測，將檢測到的異常狀態(tài)波動進行告警。

六、結語

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

1）領導的支持力度非常關鍵。公司領導對數(shù)據(jù)資產(chǎn)管理建設的價值認可，能夠在核心數(shù)據(jù)質(zhì)量持續(xù)優(yōu)化過程中提供組織協(xié)調(diào)支持，有效推動集團和各省分公司配合改進，保障端到端質(zhì)量優(yōu)化效果。

2）數(shù)據(jù)治理文化建設是核心。建立專業(yè)的數(shù)據(jù)治理團隊，優(yōu)化數(shù)據(jù)資產(chǎn)管理組織架構，以自底向上的完整血緣分析、核心數(shù)據(jù)質(zhì)量為入口，建立自下而上、自發(fā)協(xié)同、精益推進的數(shù)據(jù)治理文化。

3）數(shù)據(jù)資產(chǎn)管理架構和配套工具是基礎。在業(yè)務發(fā)展過程中，逐步打造體系化的數(shù)據(jù)治理實施能力，安全合規(guī)標準規(guī)范先行，建立持續(xù)優(yōu)化的治理體制。

4）數(shù)據(jù)能力開放平臺是優(yōu)勢。通過面向外部租戶自助建模平臺的綜合運營，可大幅提升內(nèi)部數(shù)據(jù)治理工程跨組織的協(xié)同效率，數(shù)據(jù)用多了，自然會激發(fā)治理的原動力。

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

來源：廠商供稿