基于大數(shù)據(jù)技術的電信網(wǎng)絡告警關聯(lián)分析設計與實現(xiàn)

張永華（中國移動通信集團廣西有限公司，南寧 530022）

?

基于大數(shù)據(jù)技術的電信網(wǎng)絡告警關聯(lián)分析設計與實現(xiàn)

張永華
（中國移動通信集團廣西有限公司，南寧 530022）

摘 要本文研究將網(wǎng)絡告警數(shù)據(jù)進行合理有效的存儲和篩選之后，通過分布式內存計算，將同一時間窗口內同時出現(xiàn)的告警進行采集，計算出告警的共現(xiàn)的頻率大小，根據(jù)共現(xiàn)頻率的高低判斷潛在告警之間的關聯(lián)關系，提供給相關網(wǎng)絡專業(yè)做出進一步確認。

關鍵詞電信大數(shù)據(jù)；分布式計算；告警關聯(lián)；數(shù)據(jù)挖掘

本文為解決現(xiàn)有廣西移動公司綜合告警平臺因應用場景不同而無法進行海量告警信息的數(shù)據(jù)關聯(lián)分析和挖掘，日常需依賴專業(yè)人員的經(jīng)驗來獲取的告警關聯(lián)規(guī)則等存在的不足，提出利用大數(shù)據(jù)技術實現(xiàn)自動化網(wǎng)絡告警關聯(lián)分析。本系統(tǒng)設計能夠滿足海量電信網(wǎng)絡告警數(shù)據(jù)存儲與分析要求，基于Hadoop云存儲構架，管理海量告警數(shù)據(jù)，通過MapReduce并發(fā)處理的每日全量告警FTP文件和關聯(lián)計算任務，實現(xiàn)告警分析的快速查詢、統(tǒng)計與關聯(lián)分析，解決了大并發(fā)、高讀取問題，全面提升了集中化故障告警運維管理水平和工作效率。

本文提出了基于分布式存儲、內存計算的電信告警數(shù)據(jù)處理在關聯(lián)分析下的通用分析應用領域的擴展方案，進一步拓展本案的應用范圍。

1 研究背景

廣西移動的綜合告警平臺，主要規(guī)劃是實現(xiàn)“設備告警、性能監(jiān)控、拓撲監(jiān)控、場景監(jiān)控”一體化的移動通信網(wǎng)絡全專業(yè)網(wǎng)元綜合告警監(jiān)控平臺，支撐全專業(yè)的集中故障管理的運維工作。

目前，綜合告警平臺基本能夠滿足全專業(yè)網(wǎng)元的監(jiān)控告警及故障處理需求，然而在告警分析方面仍存在不足。

1.1 目前告警處理模式無法提前發(fā)現(xiàn)問題

平臺在實際使用過程中，每天大約產生4～5 GB的告警數(shù)據(jù)量（文本，約60～80萬條告警信息）。由于目前的告警信息主要依賴于監(jiān)控人員進行手動確認，監(jiān)控人員通常會忽略75％以上的低級別告警信息，而重點處理一些更加緊急的高級別告警問題。在實際排查問題中發(fā)現(xiàn)，高級別告警問題往往在前期就會有部分低級別告警表征。而現(xiàn)有的系統(tǒng)下，這些有預警價值的低級別告警完全被忽略，只有等到發(fā)生較嚴重問題時監(jiān)控人員才去處理，這是以降低網(wǎng)絡運維的管理質量和犧牲數(shù)據(jù)的分析質量為代價的管理模式。如何針對性地對大量告警數(shù)據(jù)下，如何快速甄別出現(xiàn)頻率高的告警數(shù)據(jù)的問題亟需得到解決。

1.2 對海量的業(yè)務告警數(shù)據(jù)缺乏有效的應對技術和架構

目前，使用消息隊列和關系數(shù)據(jù)庫等技術來傳輸和存儲告警數(shù)據(jù)，每天的數(shù)據(jù)庫增量為16 GB。而目前的告警系統(tǒng)存儲設計容量為2 000 GB。因此，目前的架構下和性能條件下，系統(tǒng)只能保存3個月左右的告警數(shù)據(jù)信息，超過3個月的數(shù)據(jù)只能被丟棄或歸檔。這使得歷史數(shù)據(jù)的分析和處理受到很大的限制，只能做簡單的近期數(shù)據(jù)的統(tǒng)計分析。

2 課題意義

針對現(xiàn)有綜合告警平臺分析能力的欠缺，提出利用大數(shù)據(jù)技術實現(xiàn)全專業(yè)網(wǎng)絡告警數(shù)據(jù)同步存儲、同步分析以及針對海量告警進行關聯(lián)分析和數(shù)據(jù)挖掘的思路，并進行系統(tǒng)設計與實現(xiàn)。

分布式多層級的存儲框架告警存儲主要是在保證數(shù)據(jù)處理性能和查詢性能的情況下，解決海量告警數(shù)據(jù)存儲的問題。通過當下流行的大數(shù)據(jù)技術，使用廉價的分布式存儲，能夠支撐以后的容量擴展和更健壯的運維能力。同時，針對不同的數(shù)據(jù)處理需求和目標，利用多層級和多目標的數(shù)據(jù)存儲系統(tǒng)來存儲和管理不同的數(shù)據(jù)。系統(tǒng)實現(xiàn)主要包括存量數(shù)據(jù)處理和每天的增量數(shù)據(jù)處理，使用基于本地計算優(yōu)先的分布式海量數(shù)據(jù)處理對告警數(shù)據(jù)進行高效并發(fā)數(shù)據(jù)處理和分析，實現(xiàn)快速有效的數(shù)據(jù)分析、過濾、挖掘工作。

為此，提出一種基于大數(shù)據(jù)處理平臺的大規(guī)模告警關聯(lián)分析方案，針對電信網(wǎng)絡告警關系進行梳理和挖掘告警關聯(lián)之間的依賴、因果關系的方案具有十分重要的意義。

3 關聯(lián)分析原理

3.1 分析算法

關聯(lián)分析的基本原理是，首先找出所有的頻繁項集，然后，根據(jù)頻繁項集產生強關聯(lián)規(guī)則，這些規(guī)則必須滿足告警出現(xiàn)的最小頻率。緊接著使用第一步找到的頻繁項集產生期望的規(guī)則，產生只包含集合的項的所有規(guī)則。一旦這些規(guī)則被生成，那么只有那些大于設定的支持度即最小頻率的規(guī)則才被留下來。為了生成所有頻集，使用了遞歸的方法。

算法描述如下。

將該思想應用到電信網(wǎng)絡告警數(shù)據(jù)，可以理解為將頻繁出現(xiàn)的一種告警篩選出來，再根據(jù)規(guī)則將頻繁出現(xiàn)的兩種告警進行過濾，依此類推，選擇出頻繁共現(xiàn)的告警進行分析，達到數(shù)據(jù)挖掘在告警分析應用中的效果；規(guī)則的使用可以溯源到關聯(lián)分析中的規(guī)則。

3.2 在電信網(wǎng)絡告警分析場景中改進關聯(lián)分析算法

關聯(lián)分析算法在電信行業(yè)應用廣泛。武麗芬等人利用關聯(lián)分析算法對移動用戶的消費習慣進行分析為移動制定套餐提供科學參考。石永革等人針對告警網(wǎng)元每天產生的大量數(shù)據(jù)，通過過濾冗余告警之后，提出將關聯(lián)挖掘算法Apriori與事件滑動窗口相結合的告警相關性規(guī)則生成算法,實現(xiàn)自動生成告警相關性規(guī)則。關聯(lián)分析算法在電信行業(yè)有著豐富的應用案例和成果，證明了本論文研究的可行性。

我們結合廣西移動通信網(wǎng)絡告警數(shù)據(jù)特點，分析每天產生大量非結構化的告警日志。這些告警日志一方面是故障事件的集合，該集合與連續(xù)性時間緊密相關，因此沒有明顯的事務的特征，導致其并不能直接使用關聯(lián)算法進行分析；另一方面，這些大量的告警蘊含了豐富的網(wǎng)元關聯(lián)關系，一旦分析出這些關系將大大簡化了故障定位過程提高故障定位速度，為快速響應故障處理提供強有力的支持，基于大數(shù)據(jù)技術的電信日志關聯(lián)分析算法，在原有的關聯(lián)算法（如Apriori算法）的基礎之上進行包裝，算法的整體結構如圖1所示。

圖1 算法的整體結構

從圖中可以發(fā)現(xiàn)，我們使用并行化內存計算框架Spark實現(xiàn)了關聯(lián)分析中的核心算法，并圍繞該算法外層加入了日志語義提取算法、事務化算法和語義復現(xiàn)算法。

4 系統(tǒng)設計與實現(xiàn)

本系統(tǒng)實現(xiàn)方案主要由分布式存儲模塊，智能數(shù)據(jù)轉換模塊、基于分布式內存計算高速報表模塊以及智能告警模塊組成。

4.1 解決方案對比

現(xiàn)有的關聯(lián)分析解決方案主要分成3種，第1種是基于多算法的數(shù)據(jù)挖掘平臺Weka；第2種是基于大數(shù)據(jù)處理開源挖掘框架，包括Apache Mahout、Spark MLlib、Cloudera Impala等大數(shù)據(jù)平臺；第3種是針對行業(yè)特點，結合行業(yè)場景定制開發(fā)的專業(yè)關聯(lián)分析解決方案。

Weka是一個Java實現(xiàn)的GUI數(shù)據(jù)挖掘平臺，該平臺集成了大量的數(shù)據(jù)挖掘算法，也包括Apriori和FP-Growth關聯(lián)分析算法。該平臺主要的優(yōu)點在于使用簡單，無需過多的配置，下載安裝即可，然后提供符合Weka要求格式的分析數(shù)據(jù)，即可選用其中的現(xiàn)成的算法進行關聯(lián)挖掘的分析。Weka的主要問題有：第一，Weka是基于Java實現(xiàn)的單機挖掘平臺，故難以適應大規(guī)模通信網(wǎng)絡設備告警關聯(lián)關系的挖掘；第二，Weka僅僅接受標準的事務數(shù)據(jù)的挖掘，大規(guī)模通信網(wǎng)絡設備告警的日志信息無法在該平臺上運行；第三，使用Weka平臺進行關聯(lián)關系的挖掘全程需要人工參與，無法實現(xiàn)自動挖掘分析每日告警關聯(lián)關系。

Apache Mahout是開源分布式挖掘平臺的典型代表。Apache Mahout是基于分布式MapReduce系統(tǒng)實現(xiàn)的大規(guī)模數(shù)據(jù)挖掘平臺。以Apache Mahout為代表的開源分布式分析系統(tǒng)，其優(yōu)點有以下幾點：第一，算法全面，通用性強。Mahout實現(xiàn)了線性回歸、關聯(lián)分析、協(xié)同過濾等數(shù)10種數(shù)據(jù)挖掘方向，過百種算法，能夠滿足一般領域，具備一定數(shù)據(jù)規(guī)模的數(shù)據(jù)挖掘、分析場景。第二，有成熟的應用案例可以參考。Mahout開源分布式挖掘平臺，存在以下不足：第一，追求過強的通用性的同時，缺乏對于專有領域的支持深度。目前Apache Mahout能夠成功應用在行為數(shù)據(jù)分析、電商精準營銷等領域，但是對以大規(guī)模通信網(wǎng)絡設備設施為代表的隱式事務的特征的挖掘卻不盡人意。主要表現(xiàn)在通信網(wǎng)絡設備告警專有領域不具備事務特征，沒有明顯的事務邊界，其次，電信專有領域的分析挖掘要求輸入的大量的包括結構化、半結構化和非結構化的數(shù)據(jù)，要求輸出的是結構化或者可視化的分析結果。第二，Mahout分析的結構分布在分布式系統(tǒng)的每一臺參與計算的節(jié)點，并且是二進制流的格式存在，不便于查看和可視化全局的分析效果。

基于通信網(wǎng)絡設備告警特性為基礎，以解決電信行業(yè)關聯(lián)分析痛點為宗旨的，以Spark分布式內存計算框架為依托的大規(guī)模告警關聯(lián)解決方案，其最大的優(yōu)點在于：第一，深入了解大規(guī)模通信網(wǎng)絡設備告警所具備的告警數(shù)量規(guī)模大、告警噪聲強、告警數(shù)據(jù)難以事務化的特點；第二，深入理解通信網(wǎng)絡設備告警挖掘的實際場景，針對性對挖掘算法進行改造和補償。

海量告警關聯(lián)分析解決方案，利用先進的標簽提取和復原技術，與現(xiàn)有流行的Apache Mahout解決方案進行對比，詳情如表1所示。

4.2 實施方案

本系統(tǒng)實驗環(huán)境由4臺主機組建而成，每臺計算機的配置為24 cores CPU,64GB RAM，4臺計算機分別命名為Hadoop-Master、Hadoop-Worker1、Hadoop-Worker2和Hadoop-Worker3.在實驗環(huán)境中使用Hadoop 2.2.0提供的HDFS分布式文件儲存服務，其中后3臺主機均是HDFS DataNode節(jié)點，內存計算框架采用Spark-1.0.1版本，其中Hadoop-Master為master節(jié)點，Hadoop-Worker1、Hadoop-Worker2和Hadoop-Worker3均為worker節(jié)點。

4.3 軟件部署

軟件部署采用大數(shù)據(jù)處理套件CDH進行部署，其中Hadoop-Worker1、Hadoop-Worker2、Hadoop-Worker3作為分布式存儲節(jié)點和內存計算節(jié)點。在大數(shù)據(jù)和云計算時代，CDH很好地融合了基于Apache協(xié)議與大數(shù)據(jù)處理技術如Hadoop、Spark之間的關系。它可以做批量處理，交互式SQL查詢和及時查詢，基于角色的權限控制；是在企業(yè)中使用最廣的Hadoop分發(fā)版本。采用該軟件，可以使關聯(lián)分析計算更及時和更有效，系統(tǒng)軟件部署如圖2所示。

4.4 功能模塊設計

為了更好地利用電信網(wǎng)絡告警大數(shù)據(jù)處理技術上豐富的數(shù)據(jù)資源和快速的處理技術優(yōu)勢，關聯(lián)分析模塊可以設計為嵌入大數(shù)據(jù)的通用方案，將分布式文件系統(tǒng)存儲功能、分布式內存計算功能、結構化數(shù)據(jù)庫存儲功能綜合一起，整個大規(guī)模告警數(shù)據(jù)處理方案包含數(shù)據(jù)接入與轉換，數(shù)據(jù)分析與處理，海量數(shù)據(jù)存儲，前端系統(tǒng)等4個子系統(tǒng)。系統(tǒng)功能設計如圖3所示。

4.5 平臺管理功能

圖2 系統(tǒng)軟件部署

表1 關聯(lián)分析方案比較

系統(tǒng)后臺采用可視化處理，對不同的功能組件，如分布式存儲HDFS、內存計算框架Spark等，進行插拔式管理，并對機器的運行狀態(tài)采用曲線趨勢圖進行展示，運維人員就可以避免繁瑣的命令行方式，直接點擊圖形實現(xiàn)故障定位和運行狀態(tài)獲取，如圖4所示。

圖3 系統(tǒng)功能設計

5 實施效果

系統(tǒng)可將告警數(shù)據(jù)進行合理有效的篩選之后，通過分布式內存計算，將每5min內同時出現(xiàn)的告警標題進行采集，計算出告警標題的出現(xiàn)頻率大小，如我們選取2015年7月18日廣西省的網(wǎng)絡告警數(shù)據(jù)進行關聯(lián)分析計算，選擇維度為全廣西省和全專業(yè)，得到結果如圖5所示。在圖中可以看到，告警“RRU光口故障”出現(xiàn)頻率為52％，即在7月18日，廣西省電信網(wǎng)絡告警“RRU光口故障”每5min就出現(xiàn)一次的頻率為52％。我們還可以發(fā)現(xiàn)，“S1ap鏈路故障”出現(xiàn)頻率為100％，即在7月18日，廣西省每5min就出現(xiàn)一次該網(wǎng)絡告警。二項告警集合“Smartgroup接口失效告警”和“交流缺相告警”共同出現(xiàn)的頻率為65％，即7月18日在廣西省“Smartgroup接口失效告警”和“交流缺相告警”兩個告警每5min出現(xiàn)一次的頻率為65％。

圖4 平臺運維管理界面

6 總結

本文針對廣西移動網(wǎng)絡綜合告警平臺現(xiàn)有應用場景不足以及海量告警數(shù)據(jù)分析的關鍵性能分析需求，設計了一套基于分布式技術的電信網(wǎng)絡告警關聯(lián)分析模型，同時提出了基于大數(shù)據(jù)技術處理平臺的模型設計與實現(xiàn)方案，通過實驗表明，在全網(wǎng)網(wǎng)絡告警規(guī)模也越來越龐大，網(wǎng)絡廠家的網(wǎng)元類型和型號呈現(xiàn)多樣化，故障也日益呈現(xiàn)規(guī)模化的背景下，本系統(tǒng)能夠解決電信網(wǎng)絡中海量告警數(shù)據(jù)的智能化挖掘及特定場景分析需求等問題，解決了告警分析大并發(fā)、高讀取問題，全面提升了集中化故障工作的告警管理水平與效率。

后續(xù)工作我們將進一步研究在如何做到分網(wǎng)元類型、分告警內容、分時間粒度的事務提取，實現(xiàn)更多的潛在告警關聯(lián)分析，同時在此基礎上擴展告警維度在不同的時間和空間中的拓撲關系，達到深入挖掘現(xiàn)有電信網(wǎng)絡告警數(shù)據(jù)價值的目的。

圖5 告警關聯(lián)分析界面

【編者按】OVUM是一家在世界電信產業(yè)界富有權威性的獨立/中立咨詢顧問公司； 從事信息通信技術（ICT）商業(yè)策略研究，研究領域涉及電信、IT、廣電及互聯(lián)網(wǎng)4大領域。OVUM擁有30年協(xié)助全球電信業(yè)制定策略、規(guī)劃及國家電信法規(guī)的豐富經(jīng)驗。

OVUM全球電信研究報告在大量有關情報研究的基礎上從商業(yè)的角度對運營商的網(wǎng)絡投資及運營、業(yè)務創(chuàng)新、營銷策略、 政策法規(guī)、客戶市場需求、新興技術和前景預測，幫助運營商在不斷變化的政策環(huán)境和市場環(huán)境中穩(wěn)固地位的同時，更加有效地謀取潛在的商業(yè)價值; 并為運營商的規(guī)劃設計單位提供不斷更新的全球電信市場動態(tài)和戰(zhàn)略視野以幫助產品創(chuàng)新。

本刊設置OVUM觀察專欄，定期發(fā)表OVUM的研究成果，包括翔實的相關信息，供信息通信業(yè)有關管理、規(guī)劃、決策人士參考。

Design and implementation of telecommunication network alarm analysis based on big data technology association

ZHANG Yong-hua
(China Mobile Group Guangxi Co., Ltd., Nanning 530022, China)

AbstractWe collect the concurrent alarm occurred in the same time window after storing and fi ltering the network alarm data effectively. The concurrent frequency of alarm occurred in the same window will be computed leveraging distributed memory computing and the system will mine the potential association among alarms according to the concurrent frequency. The result will be offered to network maintainer to make a primary decision.

Keywordstelecommunication big data; distributed computing; alarm associated; data mining

中圖分類號TN915

文獻標識碼A

文章編號1008-5599（2016）04-0018-06

收稿日期：2016-03-03