徐仕成

（中國移動通信集團(tuán)湖南有限公司，湖南 長沙 410001）

1 引言

突發(fā)事件場景不同于節(jié)假日保障場景、重大活動場景，其發(fā)生時(shí)間和發(fā)生區(qū)域無法提前預(yù)知。一旦突發(fā)事件發(fā)生，如何快速獲取發(fā)生區(qū)域的網(wǎng)絡(luò)性能運(yùn)行情況，并進(jìn)行實(shí)時(shí)性能監(jiān)測是當(dāng)前運(yùn)營商開展突發(fā)事件場景通信保障面臨的一個(gè)難題。早期開展突發(fā)事件場景保障時(shí)，場景的建立需要一線維護(hù)人員提供發(fā)生地點(diǎn)的小區(qū)資源信息，同時(shí)依賴OMC（Operation and Maintenance Center，操作維護(hù)中心）網(wǎng)管數(shù)據(jù)提供相關(guān)性能數(shù)據(jù)，由于OMC指標(biāo)統(tǒng)計(jì)至少有15分鐘粒度的時(shí)延，從突發(fā)事件發(fā)生場景建立到場景性能指標(biāo)呈現(xiàn)往往需要近30分鐘，過長的時(shí)延難以實(shí)現(xiàn)先于客戶投訴發(fā)現(xiàn)網(wǎng)絡(luò)問題。因而需要建立一種針對突發(fā)事件場景快速建立場景并進(jìn)行實(shí)時(shí)性能監(jiān)測的方法和平臺。

2 相關(guān)技術(shù)介紹

2.1 信令大數(shù)據(jù)

通常意義上，信令數(shù)據(jù)指的就是XDR（X Data Recording，X數(shù)據(jù)記錄）數(shù)據(jù)?；谛帕頧DR數(shù)據(jù)開展網(wǎng)絡(luò)性能分析、業(yè)務(wù)質(zhì)量分析已成為運(yùn)營商提升網(wǎng)絡(luò)質(zhì)量、保障客戶感知的關(guān)鍵能力。

首先對移動通信網(wǎng)絡(luò)DPI（Deep Packet Inspection，深度報(bào)文檢測）技術(shù)與XDR數(shù)據(jù)作簡要介紹。DPI是一種基于應(yīng)用層的流量檢測和控制技術(shù)，當(dāng)IP數(shù)據(jù)包、TCP或UDP數(shù)據(jù)流通過基于DPI技術(shù)的信令監(jiān)測系統(tǒng)時(shí)，該系統(tǒng)通過深入讀取載荷的內(nèi)容來對OSI七層協(xié)議中的應(yīng)用層信息進(jìn)行重組，形成可用于網(wǎng)絡(luò)質(zhì)量、業(yè)務(wù)質(zhì)量、用戶行為等分析的XDR結(jié)構(gòu)化數(shù)據(jù)。

XDR是根據(jù)早期CDR（Call Data Recording，呼叫數(shù)據(jù)記錄）概念演變而來，CDR中記錄的是通話過程的關(guān)鍵信息，而XDR是對CDR的擴(kuò)展，泛指移動網(wǎng)絡(luò)、承載網(wǎng)絡(luò)中數(shù)據(jù)流量的關(guān)鍵信息記錄，一般按照用戶會話為單位，一個(gè)會話形成一條XDR記錄。

由于移動互聯(lián)網(wǎng)業(yè)務(wù)的飛速發(fā)展，信令數(shù)據(jù)規(guī)模在不斷增長，目前一個(gè)中等省份信令數(shù)據(jù)量日均近100 T，并且每月還在高速增長，因而稱之為信令大數(shù)據(jù)。在本文中，將基于信令大數(shù)據(jù)而非OMC網(wǎng)管數(shù)據(jù)作為突發(fā)事件場景中的性能指標(biāo)計(jì)算數(shù)據(jù)源。

2.2 流式計(jì)算

針對大數(shù)據(jù)的計(jì)算，總體可以分為批量計(jì)算和流式計(jì)算兩種。

Hadoop分布式計(jì)算框架是大數(shù)據(jù)批量計(jì)算的代表，數(shù)據(jù)先存儲后計(jì)算，數(shù)據(jù)引入至Hadoop文件系統(tǒng)（HDFS）并分發(fā)到各個(gè)節(jié)點(diǎn)進(jìn)行處理，當(dāng)處理完成后，結(jié)果數(shù)據(jù)會返回到HDFS供需求方使用。Hadoop的高吞吐、海量數(shù)據(jù)處理的能力使得可以方便地處理信令大數(shù)據(jù)。但是，Hadoop的缺點(diǎn)也非常明顯：延遲大，響應(yīng)緩慢，很難滿足一些對時(shí)延有特定要求的業(yè)務(wù)需求場景，比如突發(fā)事件場景中實(shí)時(shí)性能計(jì)算。

流式計(jì)算就是為了彌補(bǔ)批量計(jì)算實(shí)時(shí)性的不足，由Twitter公司貢獻(xiàn)的Storm就是典型的大數(shù)據(jù)流式計(jì)算框架，無需先存儲，數(shù)據(jù)直接在有向無環(huán)圖（Directed acyclic graph）的任務(wù)拓?fù)渲校═opology）計(jì)算完成。Storm的數(shù)據(jù)輸入流由spout組件管理，spout把數(shù)據(jù)傳遞給Bolt組件，Bolt可以進(jìn)行數(shù)據(jù)處理，也可以把數(shù)據(jù)傳遞給其它的Bolt，Storm集群就是在多個(gè)Bolt之間處理spout傳過來的數(shù)據(jù)，spout與Bolt間關(guān)聯(lián)關(guān)系圖即為Storm的Topology。Storm流式計(jì)算Topology圖如圖1所示：

圖1 Storm流式計(jì)算Topology圖

Storm是目前比較流行的流式計(jì)算技術(shù)框架，在業(yè)界有著廣泛的應(yīng)用。在本文中，將通過Storm流式計(jì)算技術(shù)完成突發(fā)事件場景中信令大數(shù)據(jù)的實(shí)時(shí)性能計(jì)算。

2.3 快速場景定制

場景的建立一般包括兩種方法：一種是后臺導(dǎo)入方式，也即先收集場景小區(qū)資源信息，通過后臺導(dǎo)入的方式在GIS圖層上呈現(xiàn)；另一種是前臺圈選方式，也即在GIS圖層上以不規(guī)則多邊形、矩形、橢圓形等圈選需要監(jiān)控的區(qū)域，區(qū)域內(nèi)基站小區(qū)自動關(guān)聯(lián)為監(jiān)控的資源信息。在早期的場景定制中，由于小區(qū)經(jīng)度、緯度字段存在較多問題，不夠準(zhǔn)確，一般采用第一種后臺導(dǎo)入方式，對場景資源進(jìn)行關(guān)聯(lián)；但在4G建設(shè)中，小區(qū)的經(jīng)度、緯度字段等資源信息錄入前期就進(jìn)行了嚴(yán)格管控，并增加了校驗(yàn)手段和勘誤流程，準(zhǔn)確性已足夠準(zhǔn)確，可以采用前臺GIS圈選方式。

突發(fā)事件場景因?yàn)榘l(fā)生區(qū)域無法提前預(yù)知，為了實(shí)現(xiàn)場景的快速定制，應(yīng)首先采用前臺GIS圈選方式。

3 平臺設(shè)計(jì)與實(shí)現(xiàn)

3.1 整體架構(gòu)

突發(fā)事件場景的實(shí)時(shí)性能監(jiān)測平臺采用三層體系架構(gòu)，分為數(shù)據(jù)采集層、數(shù)據(jù)實(shí)時(shí)處理層及應(yīng)用層。其中數(shù)據(jù)采集層的主要數(shù)據(jù)為信令XDR數(shù)據(jù)及資源管理系統(tǒng)中小區(qū)等資源數(shù)據(jù)；數(shù)據(jù)實(shí)時(shí)處理層包括信令XDR數(shù)據(jù)實(shí)時(shí)處理、分布式消息分發(fā)、監(jiān)測指標(biāo)流式計(jì)算、內(nèi)存數(shù)據(jù)庫指標(biāo)緩存；應(yīng)用層為突發(fā)事件場景實(shí)時(shí)性能監(jiān)測GIS呈現(xiàn)及預(yù)警展示。

平臺整體架構(gòu)如圖2所示：

圖2 突發(fā)事件場景實(shí)時(shí)性能監(jiān)測平臺體系架構(gòu)

3.2 數(shù)據(jù)處理流程

考慮到信令XDR數(shù)據(jù)的體量規(guī)模非常大，為了縮短突發(fā)事件場景監(jiān)測指標(biāo)性能呈現(xiàn)的時(shí)延，在平臺設(shè)計(jì)時(shí)需重點(diǎn)考慮實(shí)時(shí)ETL、分布式消息分發(fā)、流式計(jì)算、指標(biāo)緩存及監(jiān)測指標(biāo)性能上層應(yīng)用呈現(xiàn)5個(gè)關(guān)鍵點(diǎn)。

（1）實(shí)時(shí)ETL：實(shí)時(shí)接收DPI信令數(shù)據(jù)，并根據(jù)突發(fā)事件場景具體監(jiān)測指標(biāo)對XDR數(shù)據(jù)進(jìn)行針對性的字段篩選以及數(shù)據(jù)轉(zhuǎn)換。

（2）分布式消息分發(fā)：完成篩選、清洗、轉(zhuǎn)換后的數(shù)據(jù)快速分發(fā)。在本次平臺實(shí)現(xiàn)中，由Kafka實(shí)現(xiàn)。

（3）流式計(jì)算：完成場景監(jiān)測指標(biāo)實(shí)時(shí)計(jì)算。在本次平臺實(shí)現(xiàn)中，采用Storm分布式計(jì)算框架。

（4）指標(biāo)緩存：完成場景監(jiān)測指標(biāo)緩存，供應(yīng)用層調(diào)取。在本次平臺實(shí)現(xiàn)中，采用開源Redis框架。

（5）實(shí)時(shí)性能監(jiān)測：完成突發(fā)事件場景實(shí)時(shí)性能監(jiān)測指標(biāo)前臺GIS呈現(xiàn)展示，同時(shí)可以根據(jù)閾值規(guī)則及

時(shí)預(yù)警。

3.3 關(guān)鍵點(diǎn)實(shí)現(xiàn)

（1）實(shí)時(shí)ETL

ETL是數(shù)據(jù)抽?。‥xtract）、轉(zhuǎn)換（Transform）及裝載（Load）的過程，從數(shù)據(jù)源抽取出所需的數(shù)據(jù)，經(jīng)過數(shù)據(jù)清洗，按照業(yè)務(wù)數(shù)據(jù)模型，將數(shù)據(jù)加載到數(shù)據(jù)倉庫中。

由于DPI信令數(shù)據(jù)量體積非常大，在數(shù)據(jù)計(jì)算前應(yīng)當(dāng)先進(jìn)行清洗和轉(zhuǎn)換，也即進(jìn)行實(shí)時(shí)ETL，以便最大程度地減少傳輸、計(jì)算數(shù)據(jù)量，縮短計(jì)算耗時(shí)。在平臺實(shí)現(xiàn)時(shí)，主要完成以下3點(diǎn)：

1）從XDR數(shù)據(jù)源系統(tǒng)（統(tǒng)一DPI）以SDTP接口的形式實(shí)時(shí)接收XDR數(shù)據(jù)流。

2）根據(jù)上層應(yīng)用監(jiān)測指標(biāo)需求，完成入庫的XDR數(shù)據(jù)進(jìn)行針對性的事件、字段篩選，同時(shí)開展數(shù)據(jù)轉(zhuǎn)換、加載。

3）將篩選、清洗、轉(zhuǎn)換后的數(shù)據(jù)發(fā)送至Kafka集群相應(yīng)的Topic中。

（2）Kafka分布式消息分發(fā)

Kafka是一種分布式的、基于發(fā)布/訂閱的消息系統(tǒng)，發(fā)送消息者成為Producer，消息接受者成為Consumer，對消息的接收和分發(fā)按照Topic進(jìn)行歸類。

圖3 突發(fā)事件場景實(shí)時(shí)性能監(jiān)測平臺數(shù)據(jù)流示意圖

在平臺實(shí)現(xiàn)中，Kafka主要用來作為整個(gè)實(shí)時(shí)流系統(tǒng)（Storm）的數(shù)據(jù)源，實(shí)時(shí)流系統(tǒng)（Storm）將從Kafka中讀取相關(guān)數(shù)據(jù)進(jìn)行分析、處理。

1）通過實(shí)時(shí)ETL，將解析處理后的每行XDR數(shù)據(jù)根據(jù)不同業(yè)務(wù)類型寫入Kafka對應(yīng)的Topic中，比如HTTP話單數(shù)據(jù)將寫入對應(yīng)HTTP的Topic中。

2）Storm系統(tǒng)將源源不斷地從Kafka各Topic中獲取數(shù)據(jù)進(jìn)行后續(xù)分析、處理。

（3）Strom實(shí)時(shí)計(jì)算

Kafka將DPI信令數(shù)據(jù)傳至Strom后，Storm創(chuàng)建Topology，并通過Topology建立spout和blot組件之間的關(guān)聯(lián)關(guān)系，其中spout組件進(jìn)行信令數(shù)據(jù)接入處理，同時(shí)將信令數(shù)據(jù)傳給bolt組件，bolt組件完成對數(shù)據(jù)轉(zhuǎn)化、計(jì)算。

在本次平臺實(shí)現(xiàn)中，共涉及4個(gè)組件，分別為KafkaSpout、CleanBolt、SceneCleanBolt以及SceneSummaryBolt。各組件功能如下：

1）KafkaSpout從Kafka中接收信令XDR數(shù)據(jù)，并向CleanBolt組件分發(fā)數(shù)據(jù)。

2）CleanBolt將從KafkaSpout中讀取的數(shù)據(jù)進(jìn)行清洗及轉(zhuǎn)換，然后將清洗轉(zhuǎn)換后的數(shù)據(jù)傳遞給SceneCleanBolt。

3）SceneCleanBolt從數(shù)據(jù)庫中讀取場景與小區(qū)的對應(yīng)關(guān)系配置信息，并通過輸入數(shù)據(jù)中的小區(qū)關(guān)聯(lián)出場景信息，然后將關(guān)聯(lián)轉(zhuǎn)換后的數(shù)據(jù)傳遞給SceneSummaryBolt。

4）SceneSummaryBolt負(fù)責(zé)場景指標(biāo)數(shù)據(jù)匯總運(yùn)算，并將匯總后的結(jié)果存入Redis緩存中。

平臺拓?fù)洌═opology）關(guān)系如圖4所示：

圖4 突發(fā)事件場景實(shí)時(shí)性能監(jiān)測平臺Storm拓?fù)鋱D

（4）Redis指標(biāo)緩存

Redis是一個(gè)key-value存儲系統(tǒng)，它支持存儲的value類型相比其他緩存數(shù)據(jù)庫（如Memcached）更多，包括string（字符串）、list（鏈表）、set（集合）、zset（有序集合）和hash（哈希）等。同時(shí)為了保證效率，Redis數(shù)據(jù)都是緩存在內(nèi)存中，并且Redis支持?jǐn)?shù)據(jù)持久化，即使服務(wù)重啟，Redis中緩存的數(shù)據(jù)也不會丟失。目前Redis已成為緩存數(shù)據(jù)庫的首選，在很多業(yè)務(wù)場景中得到應(yīng)用。

在平臺實(shí)現(xiàn)中，Redis主要作用如下：

1）中間數(shù)據(jù)的匯總及存儲。完成Storm集群流式計(jì)算后各性能指標(biāo)數(shù)據(jù)結(jié)果的匯總和存儲。

2）數(shù)據(jù)同步。將保存在Redis的中場景指標(biāo)數(shù)據(jù)定時(shí)同步至關(guān)系型數(shù)據(jù)庫中（如Oracle），以方便前臺應(yīng)用查詢場景歷史指標(biāo)數(shù)據(jù)。

（5）實(shí)時(shí)性能監(jiān)測

平臺界面依托GIS開發(fā)，場景監(jiān)測的性能指標(biāo)實(shí)時(shí)在GIS上呈現(xiàn)。根據(jù)突發(fā)事件發(fā)生的地理位置，通過GIS圈選方式快速建立場景，按照小區(qū)經(jīng)度、緯度字段屬性進(jìn)行判斷，對于落在圈選區(qū)域的小區(qū)將自動作為監(jiān)測的小區(qū)。在Storm流式計(jì)算集群完成場景監(jiān)測指標(biāo)計(jì)算，并緩存在Redis中，前臺讀取Redis中指標(biāo)性能數(shù)據(jù)，并實(shí)時(shí)在GIS上完成呈現(xiàn)。

平臺界面呈現(xiàn)如圖5所示。

3.4 平臺實(shí)現(xiàn)成效

（1）指標(biāo)呈現(xiàn)時(shí)延

根據(jù)平臺數(shù)據(jù)處理流程，從突發(fā)事件場景建立到監(jiān)測性能指標(biāo)在前臺界面呈現(xiàn)共涉及6個(gè)環(huán)節(jié)，分別為：信令數(shù)據(jù)接收、數(shù)據(jù)ETL、Kafka數(shù)據(jù)分發(fā)、Storm監(jiān)測指標(biāo)計(jì)算、監(jiān)測指標(biāo)輸出與緩存、監(jiān)測指標(biāo)場景呈現(xiàn)。通過設(shè)置信令數(shù)據(jù)時(shí)間戳，平臺各個(gè)環(huán)節(jié)數(shù)據(jù)平均耗時(shí)統(tǒng)計(jì)如表1所示。

總時(shí)延=t（信令數(shù)據(jù)接收）+t（數(shù)據(jù)ETL）+t（Kafka數(shù)據(jù)分發(fā)）+t（Storm監(jiān)測指標(biāo)計(jì)算）+t（監(jiān)測指標(biāo)輸出與緩存）+t（監(jiān)測指標(biāo)場景呈現(xiàn)）=5分鐘。

圖5 突發(fā)事件場景實(shí)時(shí)性能監(jiān)測平臺呈現(xiàn)

表1 突發(fā)事件場景性能呈現(xiàn)各環(huán)節(jié)時(shí)延統(tǒng)計(jì)表 min

由于突發(fā)事件保障的特點(diǎn)，場景性能指標(biāo)呈現(xiàn)的時(shí)延應(yīng)該越短越好。在本平臺設(shè)計(jì)與實(shí)現(xiàn)中，基于信令數(shù)據(jù)，應(yīng)用流式計(jì)算技術(shù)，采用GIS圈選場景的方法，從突發(fā)事件場景建立到監(jiān)測性能指標(biāo)在前臺界面呈現(xiàn)不到5分鐘，大幅縮短了傳統(tǒng)突發(fā)事件場景保障性能指標(biāo)呈現(xiàn)的時(shí)延，而且后續(xù)監(jiān)測指標(biāo)可以實(shí)時(shí)進(jìn)行GIS呈現(xiàn)，平臺應(yīng)用效果良好。

（2）平臺可擴(kuò)展性

突發(fā)事件場景實(shí)時(shí)性能監(jiān)測平臺采用三層架構(gòu)，實(shí)現(xiàn)中應(yīng)用的Kafka、Storm、Redis均為開源框架，同時(shí)在場景性能指標(biāo)實(shí)時(shí)計(jì)算采用的是前臺GIS圈選方式，是基于底層小區(qū)資源數(shù)據(jù)的匯總，因此場景可以任意定制，可以根據(jù)突發(fā)事件保障需求任意增加或刪除監(jiān)控場景，前臺應(yīng)用增加監(jiān)控場景無需對后端Storm集群作任何調(diào)整，平臺可擴(kuò)展性非常強(qiáng)。

4 結(jié)束語

本文結(jié)合突發(fā)事件場景保障的需求，基于信令數(shù)據(jù)、流式計(jì)算、GIS圈選等方法設(shè)計(jì)與實(shí)現(xiàn)了突發(fā)事件場景實(shí)時(shí)性能監(jiān)測平臺，并詳細(xì)描述了平臺的體系架構(gòu)、數(shù)據(jù)處理流程、關(guān)鍵點(diǎn)實(shí)現(xiàn)等，平臺可以大幅縮短從突發(fā)事件場景建立到場景性能監(jiān)測指標(biāo)實(shí)時(shí)呈現(xiàn)的時(shí)延，平臺上線后已多次應(yīng)用于省內(nèi)突發(fā)事件的場景保障，并取得了不錯(cuò)的效果。該平臺的可擴(kuò)展性非常強(qiáng)，也可以作為對信令大數(shù)據(jù)實(shí)時(shí)處理的通用架構(gòu)，應(yīng)對重大活動保障、實(shí)時(shí)人流監(jiān)控、實(shí)時(shí)道路交通擁堵監(jiān)測等業(yè)務(wù)需求。

參考文獻(xiàn)：

[1]楊軍,柴剛,趙越. 基于互聯(lián)網(wǎng)大數(shù)據(jù)的重大場景通信保障[J]. 郵電設(shè)計(jì)技術(shù), 2016(4)： 63-66.

[2]孫大為,張廣艷,鄭緯民. 大數(shù)據(jù)流式計(jì)算：關(guān)鍵技術(shù)及系統(tǒng)實(shí)例[J]. 軟件學(xué)報(bào), 2014(4)： 839-862.

[3]董斌,楊迪,王錚. 流計(jì)算大數(shù)據(jù)技術(shù)在運(yùn)營商實(shí)時(shí)信令處理中的應(yīng)用[J]. 電信科學(xué), 2015(10)：172-178.

[4]張艷榮,張治中. 基于DPI的移動分組網(wǎng)絡(luò)流量分析技術(shù)的研究與實(shí)現(xiàn)[J]. 電信科學(xué), 2014(4)： 88-94.

[5]羅琦芳. 一種基于Lambda架構(gòu)的電信數(shù)據(jù)平臺解決方案[J]. 電子技術(shù)與軟件工程, 2017(11)：182-183.

[6]王巖,王純. 一種基于Kafka的可靠的Consumer的設(shè)計(jì)方案[J]. 軟件, 2016(1)： 61-66.

[7]馬延輝,陳書美,雷葆華. Storm企業(yè)級應(yīng)用實(shí)戰(zhàn)、運(yùn)維和調(diào)優(yōu)[M]. 北京： 機(jī)械工業(yè)出版社, 2015.

[8]曾超宇,李金香. Redis在高速緩存系統(tǒng)中的應(yīng)用[J]. 微型機(jī)與應(yīng)用, 2013(12)： 11-13.

[9]Apache Kafka. A distributed streaming platform[EB/OL]. [2017-12-12]. http：//kafka.apache.org/.

[10]Redis. Redis[EB/OL]. [2017-12-12]. https：//redis.io. ★