應(yīng)俊

摘要：為了更好地滿足運(yùn)營(yíng)商對(duì)海量非結(jié)構(gòu)化數(shù)據(jù)的處理需求，主要以網(wǎng)絡(luò)告警日志數(shù)據(jù)為例，詳細(xì)闡述如何利用Hadoop+Spark大數(shù)據(jù)技術(shù)挖掘和分析海量的數(shù)據(jù)，進(jìn)而提高網(wǎng)絡(luò)監(jiān)控效率。

關(guān)鍵詞：告警數(shù)據(jù) Hadoop Spark

1 引言

隨著電信網(wǎng)絡(luò)的不斷演進(jìn)，全省數(shù)據(jù)網(wǎng)、交換網(wǎng)、接入網(wǎng)設(shè)備單月產(chǎn)生告警原始日志近億條。以上告警通過(guò)網(wǎng)元網(wǎng)管、專業(yè)綜合網(wǎng)管、智能網(wǎng)管系統(tǒng)[1]三層收斂，監(jiān)控人員每月需處理影響業(yè)務(wù)或網(wǎng)絡(luò)質(zhì)量的告警事件為20萬(wàn)條，但一些對(duì)網(wǎng)絡(luò)可能造成隱患的告警信息被過(guò)濾掉。如何從海量告警數(shù)據(jù)中獲取與網(wǎng)絡(luò)性能指標(biāo)、運(yùn)維效率相關(guān)的有價(jià)值的數(shù)據(jù)，對(duì)于傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)架構(gòu)而言，似乎是一個(gè)不可能完成的任務(wù)。

在一般告警量情況下，ORACLE數(shù)據(jù)處理能力基本可以滿足分析需求，但當(dāng)告警分析量上升到億級(jí)，如果采用傳統(tǒng)的數(shù)據(jù)存儲(chǔ)和計(jì)算方式，一方面數(shù)據(jù)量過(guò)大，表的管理、維護(hù)開(kāi)銷過(guò)大，要做到每個(gè)字段建索引，存儲(chǔ)浪費(fèi)巨大；另一方面計(jì)算分析過(guò)程耗時(shí)過(guò)長(zhǎng)，無(wú)法滿足實(shí)時(shí)和準(zhǔn)實(shí)時(shí)分析需求。因此必須采用新的技術(shù)架構(gòu)來(lái)分析處理海量告警信息，支撐主動(dòng)維護(hù)工作顯得尤為必要，為此我們引入了大數(shù)據(jù)技術(shù)。

2 分析目標(biāo)

（1）數(shù)據(jù)源：電信運(yùn)營(yíng)商網(wǎng)絡(luò)設(shè)備告警日志數(shù)據(jù)，每天50 G。

（2）數(shù)據(jù)分析目標(biāo)：完成高頻翻轉(zhuǎn)類（瞬斷）告警分析；完成自定義網(wǎng)元、自定義告警等可定制告警分析；完成被過(guò)濾掉的告警分析、TOPN告警分析；核心設(shè)備和重要業(yè)務(wù)監(jiān)控。

（3）分析平臺(tái)硬件配置：云計(jì)算平臺(tái)分配8臺(tái)虛擬機(jī)，每臺(tái)虛機(jī)配置CPU16核；內(nèi)存32 G；硬盤2 T。

3 制定方案

進(jìn)入大數(shù)據(jù)時(shí)代，行業(yè)內(nèi)涌現(xiàn)了大量的數(shù)據(jù)挖掘技術(shù)，數(shù)據(jù)處理和分析更高效、更有價(jià)值。Google、Facebook等公司提供可行的思路是通過(guò)類似Hadoop[2]的分布式計(jì)算、MapReduce[3]、Spark[4]算法等構(gòu)造而成的新型架構(gòu)，挖掘有價(jià)值信息。

Hadoop是Apache基金會(huì)用JAVA語(yǔ)言開(kāi)發(fā)的分布式框架，通過(guò)利用計(jì)算機(jī)集群對(duì)大規(guī)模數(shù)據(jù)進(jìn)行分布式計(jì)算分析。Hadoop框架最重要的兩個(gè)核心是HDFS和MapReduce，HDFS用于分布式存儲(chǔ)，MapReduce則實(shí)現(xiàn)分布式任務(wù)計(jì)算。

一個(gè)HDFS集群包含元數(shù)據(jù)節(jié)點(diǎn)（NameNode）、若干數(shù)據(jù)節(jié)點(diǎn)（DataNode）和客戶端（Client）。NameNode管理HDFS的文件系統(tǒng)，DataNode存儲(chǔ)數(shù)據(jù)塊文件。HDFS將一個(gè)文件劃分成若干個(gè)數(shù)據(jù)塊，這些數(shù)據(jù)塊存儲(chǔ)DataNode節(jié)點(diǎn)上。

MapReduce是Google公司提出的針對(duì)大數(shù)據(jù)的編程模型。核心思想是將計(jì)算過(guò)程分解成Map（映射）和Reduce（歸約）兩個(gè)過(guò)程，也就是將一個(gè)大的計(jì)算任務(wù)拆分為多個(gè)小任務(wù)，MapReduce框架化繁為簡(jiǎn)，輕松地解決了數(shù)據(jù)分布式存儲(chǔ)的計(jì)算問(wèn)題，讓不熟悉并行編程的程序員也能輕松寫出分布式計(jì)算程序。MapReduce最大的不足則在于Map和Reduce都是以進(jìn)程為單位調(diào)度、運(yùn)行、結(jié)束的，磁盤I/O開(kāi)銷大、效率低，無(wú)法滿足實(shí)時(shí)計(jì)算需求。

Spark是由加州伯克利大學(xué)AMP實(shí)驗(yàn)室開(kāi)發(fā)的類Hadoop MapReduce的分布式并行計(jì)算框架，主要特點(diǎn)是彈性分布式數(shù)據(jù)集RDD[5]，中間輸出結(jié)果可以保存在內(nèi)存中，節(jié)省了大量的磁盤I/O操作。Spark除擁有Hadoop MapReduce所具有的優(yōu)點(diǎn)外，還支持多次迭代計(jì)算，特別適合流計(jì)算和圖計(jì)算。

基于成本、效率、復(fù)雜性等因素，我們選擇了HDFS+Spark實(shí)現(xiàn)對(duì)告警數(shù)據(jù)的挖掘分析。

4 分析平臺(tái)設(shè)計(jì)

4.1 Hadoop集群搭建

基于CentOS-6.5系統(tǒng)環(huán)境搭建Hadoop集群，配置如表1所示。

4.2 Spark參數(shù)設(shè)置[6]

Spark參數(shù)設(shè)置如表2所示。

4.3 數(shù)據(jù)采集層

數(shù)據(jù)采集：由于需采集的告警設(shè)備種類繁多，故采取分布式的告警采集，數(shù)據(jù)網(wǎng)設(shè)備、交換網(wǎng)設(shè)備、接入網(wǎng)設(shè)備分別通過(guò)IP綜合網(wǎng)管、天元綜合網(wǎng)管、PON綜合網(wǎng)管進(jìn)行采集，采集周期5分鐘一次。采集機(jī)先將采集到的告警日志文件，通過(guò)FTP接口上傳到智能網(wǎng)管系統(tǒng)文件服務(wù)器上，再對(duì)文件進(jìn)行校驗(yàn)，通過(guò)Sqoop推送到Hadoop集群上。

4.4 邏輯處理層

（1）建立高頻翻轉(zhuǎn)告警監(jiān)控工作流程

先將海量告警進(jìn)行初步刪選，通過(guò)數(shù)量、位置和時(shí)間三個(gè)維度的分析，得出高頻翻轉(zhuǎn)類告警清單列表，最后由專業(yè)工程師甄別確認(rèn)，對(duì)某類告警進(jìn)行重點(diǎn)關(guān)注和監(jiān)控。

（2）差異化定制方案

按組網(wǎng)架構(gòu)細(xì)分，針對(duì)核心重要節(jié)點(diǎn)的所有告警均納入實(shí)時(shí)監(jiān)控方案；

按業(yè)務(wù)網(wǎng)絡(luò)細(xì)分，針對(duì)不同業(yè)務(wù)網(wǎng)絡(luò)設(shè)計(jì)個(gè)性化的監(jiān)控方案；

按客戶業(yè)務(wù)細(xì)分，針對(duì)客戶數(shù)字出租電路設(shè)計(jì)個(gè)性化的監(jiān)控方案。

4.5 數(shù)據(jù)分析層

Spark讀取Hive[7]表的告警數(shù)據(jù)，然后在Spark引擎中進(jìn)行SQL統(tǒng)計(jì)分析。Spark SQL模塊在進(jìn)行分析時(shí)，將外部告警數(shù)據(jù)源轉(zhuǎn)化為DataFrame[8]，并像操作RDD或者將其注冊(cè)為臨時(shí)表的方式處理和分析這些數(shù)據(jù)。一旦將DataFrame注冊(cè)成臨時(shí)表，就可以使用類SQL的方式操作查詢分析告警數(shù)據(jù)。表3是利用Spark SQL對(duì)告警工單做的一個(gè)簡(jiǎn)單分析：

5 平臺(tái)實(shí)踐應(yīng)用

探索運(yùn)維數(shù)據(jù)分析的新方法，利用大數(shù)據(jù)分析技術(shù)，分析可能影響業(yè)務(wù)/設(shè)備整體性能的設(shè)備告警，結(jié)合網(wǎng)絡(luò)性能數(shù)據(jù)，找到網(wǎng)絡(luò)隱患，實(shí)現(xiàn)主動(dòng)維護(hù)的工作目標(biāo)。

5.1 高頻翻轉(zhuǎn)類告警監(jiān)控

首先制定了高頻翻轉(zhuǎn)類告警分析規(guī)則，將連續(xù)7天每天原始告警發(fā)生24次以上定義為高頻翻轉(zhuǎn)類告警，并基于大數(shù)據(jù)平臺(tái)開(kāi)發(fā)了相應(yīng)的分析腳本，目前已實(shí)現(xiàn)全專業(yè)所有告警類型的分析。表4是全省高頻翻轉(zhuǎn)類TOP10排名。

5.2 核心設(shè)備和重要業(yè)務(wù)監(jiān)控

目前以設(shè)備廠商或?qū)＜医?jīng)驗(yàn)評(píng)定告警監(jiān)控級(jí)別往往會(huì)與實(shí)際形成偏差，主要表現(xiàn)在以下幾個(gè)方面：監(jiān)控級(jí)別的差異化設(shè)定基于已知的告警類型，一旦網(wǎng)絡(luò)重大故障上報(bào)未知的告警類型就無(wú)法在第一時(shí)間有效監(jiān)控到；同一類型的故障告警出現(xiàn)在不同網(wǎng)絡(luò)層面可能影響業(yè)務(wù)的程度是完全不同的；不同保障級(jí)別的客戶對(duì)故障告警監(jiān)控的實(shí)時(shí)性要求也是不同的。

通過(guò)大數(shù)據(jù)分析平臺(tái)對(duì)差異化監(jiān)控提供了靈活的定制手段，可根據(jù)告警關(guān)鍵字，分專業(yè)、地市、網(wǎng)管、機(jī)房、告警頻次等維度自主定制需要的告警數(shù)據(jù)，實(shí)現(xiàn)日、周、月、某個(gè)時(shí)間區(qū)等統(tǒng)計(jì)分析。

應(yīng)用案例：省NOC通過(guò)大數(shù)據(jù)分析出一條編號(hào)為CTVPN80113的中國(guó)平安大客戶電路在一段時(shí)間內(nèi)頻繁產(chǎn)生線路劣化告警，但用戶未申告，省NOC隨即預(yù)警給政企支撐工程師，政支工程師與用戶溝通后，派維護(hù)人員至現(xiàn)場(chǎng)處理，發(fā)現(xiàn)線路接頭松動(dòng)，緊急處理后告警消除、業(yè)務(wù)恢復(fù)。

5.3 被過(guò)濾告警分析

全省每天網(wǎng)絡(luò)告警數(shù)據(jù)300萬(wàn)條～500萬(wàn)條，其中99%都會(huì)根據(jù)告警過(guò)濾規(guī)則進(jìn)行過(guò)濾篩選，把過(guò)濾后的告警呈現(xiàn)給網(wǎng)絡(luò)監(jiān)控人員。過(guò)濾規(guī)則的準(zhǔn)確性直接影響告警數(shù)據(jù)的質(zhì)量。一般來(lái)說(shuō)告警過(guò)濾規(guī)則可以從具有豐富運(yùn)維經(jīng)驗(yàn)的網(wǎng)絡(luò)維護(hù)人員獲得，但是這個(gè)過(guò)程非常繁瑣，而且通過(guò)人工途徑獲得的告警過(guò)濾規(guī)則在不同的應(yīng)用環(huán)境可能存在差異，無(wú)法滿足網(wǎng)絡(luò)維護(hù)的整體需要。采用大數(shù)據(jù)技術(shù)對(duì)被過(guò)濾的告警進(jìn)行分析可以很好地完善過(guò)濾規(guī)則，讓真正急迫需要處理的告警優(yōu)先呈現(xiàn)給維護(hù)人員及時(shí)處理，真正做到先于客戶發(fā)現(xiàn)故障。表5是動(dòng)環(huán)專業(yè)被過(guò)濾的告警情況分布。

5.4 動(dòng)環(huán)深放電分析

動(dòng)環(huán)網(wǎng)管通過(guò)C接口采集蓄電池電壓數(shù)據(jù)，在停電告警產(chǎn)生之后，電壓數(shù)據(jù)首次下降到45 V，表示該局站電池出現(xiàn)深放電現(xiàn)象，通過(guò)計(jì)算這一放電過(guò)程的持續(xù)時(shí)間，記為深放電時(shí)長(zhǎng)，該時(shí)長(zhǎng)可以初步反映電池的放電性能。一個(gè)局站每天產(chǎn)生幾十萬(wàn)條電壓等動(dòng)環(huán)實(shí)時(shí)數(shù)據(jù)。

在告警數(shù)據(jù)分析的基礎(chǔ)上，實(shí)現(xiàn)對(duì)蓄電池電壓變化數(shù)據(jù)的分析，提醒分公司關(guān)注那些深放電次數(shù)過(guò)多和放電時(shí)長(zhǎng)過(guò)短的局站，核查蓄電池、油機(jī)配置、發(fā)電安排等，并進(jìn)行整治。利用Spark SQL統(tǒng)計(jì)了一個(gè)月內(nèi)撫州、贛州、吉安三分公司幾十億條動(dòng)環(huán)數(shù)據(jù)，分析了其中深放電的情況如表6所示。

6 結(jié)論

本文利用HDFS+Spark技術(shù)，實(shí)驗(yàn)性地解決告警數(shù)據(jù)存儲(chǔ)和分析等相關(guān)問(wèn)題：一是通過(guò)數(shù)據(jù)分析，從海量告警數(shù)據(jù)中發(fā)現(xiàn)潛在的網(wǎng)絡(luò)隱患；二是結(jié)合資源信息和不同專業(yè)的告警，最終為用戶提供綜合預(yù)警；三是轉(zhuǎn)變網(wǎng)絡(luò)監(jiān)控思路和方式，通過(guò)數(shù)據(jù)匯聚、數(shù)據(jù)相關(guān)性分析、數(shù)據(jù)可視化展示，提高了網(wǎng)絡(luò)監(jiān)控效率；最后還擴(kuò)展到對(duì)動(dòng)環(huán)實(shí)時(shí)數(shù)據(jù)、信令數(shù)據(jù)進(jìn)行分析。

從實(shí)際運(yùn)行效果來(lái)看，HDFS和Spark完全可以取代傳統(tǒng)的數(shù)據(jù)存儲(chǔ)和計(jì)算方式，滿足電信運(yùn)營(yíng)商主動(dòng)運(yùn)維的需求。

參考文獻(xiàn)：

[1] 中國(guó)電信股份有限公司. 中國(guó)電信智能網(wǎng)管技術(shù)規(guī)范-總體分冊(cè)[Z]. 2015.

[2] Tom white. Hadoop權(quán)威指南[M]. 4版. 南京： 東南大學(xué)出版社， 2015.

[3] RP Raji. MapReduce： Simplified Data Processing on Large Clusters[Z]. 2004.

[4] Spark. Apache Spark?[EB/OL]. [2016-11-27]. http：//spark.apache.org/.

[5] Matei Zaharia， Mosharaf Chowdhury， Tathagata Das， et al. Resilient Distributed Datasets： A Fault-Tolerant Abstraction for In-Memory Cluster Computing[J]. Usenix Conference on Networked Systems Design & Implementation， 2012，70（2）： 141-146.

[6] 許鵬. Apache Spark源碼剖析[M]. 北京： 電子工業(yè)出版社， 2015.

[7] Hive. Apache HiveTM[EB/OL]. [2016-11-27]. http：//hive.apache.org/.

[8] Holden Karau， Andy Konwinski， Patrick Wendell， et al. Learning Spark： Lightning-Fast Big Data Analysis[M]. Oreilly & Associates Inc， 2015.

[9] 員建廈. 基于動(dòng)態(tài)存儲(chǔ)策略的數(shù)據(jù)管理系統(tǒng)[J]. 無(wú)線電工程， 2014，44（11）： 52-54.

[10] 楊毅. 一種基于網(wǎng)格優(yōu)化的空間數(shù)據(jù)訪問(wèn)與存儲(chǔ)

研究[J]. 無(wú)線電通信技術(shù)， 2014，40（6）：43-46. ★