張永華（中國(guó)移動(dòng)通信集團(tuán)廣西有限公司，南寧 530022）

?

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

張永華
（中國(guó)移動(dòng)通信集團(tuán)廣西有限公司，南寧 530022）

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

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

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

本文提出了基于分布式存儲(chǔ)、內(nèi)存計(jì)算的電信告警數(shù)據(jù)處理在關(guān)聯(lián)分析下的通用分析應(yīng)用領(lǐng)域的擴(kuò)展方案，進(jìn)一步拓展本案的應(yīng)用范圍。

1 研究背景

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

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

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

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

1.2 對(duì)海量的業(yè)務(wù)告警數(shù)據(jù)缺乏有效的應(yīng)對(duì)技術(shù)和架構(gòu)

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

2 課題意義

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

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

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

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

3.1 分析算法

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

算法描述如下。

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

3.2 在電信網(wǎng)絡(luò)告警分析場(chǎng)景中改進(jìn)關(guān)聯(lián)分析算法

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

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

圖1 算法的整體結(jié)構(gòu)

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

4 系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)

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

4.1 解決方案對(duì)比

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

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

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

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

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

4.2 實(shí)施方案

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

4.3 軟件部署

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

4.4 功能模塊設(shè)計(jì)

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

4.5 平臺(tái)管理功能

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

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

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

圖3 系統(tǒng)功能設(shè)計(jì)

5 實(shí)施效果

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

圖4 平臺(tái)運(yùn)維管理界面

6 總結(jié)

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

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

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

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

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

本刊設(shè)置OVUM觀察專欄，定期發(fā)表OVUM的研究成果，包括翔實(shí)的相關(guān)信息，供信息通信業(yè)有關(guān)管理、規(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

中圖分類號(hào)TN915

文獻(xiàn)標(biāo)識(shí)碼A

文章編號(hào)1008-5599（2016）04-0018-06

收稿日期：2016-03-03