基于大數(shù)據(jù)技術(shù)的告警日志數(shù)據(jù)分析

應(yīng)俊

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

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

1 引言

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

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

2 分析目標(biāo)

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

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

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

3 制定方案

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

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

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

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

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

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

4 分析平臺設(shè)計

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è)備分別通過IP綜合網(wǎng)管、天元綜合網(wǎng)管、PON綜合網(wǎng)管進行采集，采集周期5分鐘一次。采集機先將采集到的告警日志文件，通過FTP接口上傳到智能網(wǎng)管系統(tǒng)文件服務(wù)器上，再對文件進行校驗，通過Sqoop推送到Hadoop集群上。

4.4 邏輯處理層

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

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

（2）差異化定制方案

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

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

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

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

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

5 平臺實踐應(yīng)用

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

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

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

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

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

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

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

5.3 被過濾告警分析

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

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

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

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

6 結(jié)論

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

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

參考文獻：

[1] 中國電信股份有限公司. 中國電信智能網(wǎng)管技術(shù)規(guī)范-總體分冊[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] 員建廈. 基于動態(tài)存儲策略的數(shù)據(jù)管理系統(tǒng)[J]. 無線電工程， 2014，44（11）： 52-54.

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

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