突发事件场景的实时性能监测设计与实现

徐仕成

（中国移动通信集团湖南有限公司，湖南 长沙 410001）

1 引言

突发事件场景不同于节假日保障场景、重大活动场景，其发生时间和发生区域无法提前预知。一旦突发事件发生，如何快速获取发生区域的网络性能运行情况，并进行实时性能监测是当前运营商开展突发事件场景通信保障面临的一个难题。早期开展突发事件场景保障时，场景的建立需要一线维护人员提供发生地点的小区资源信息，同时依赖OMC（Operation and Maintenance Center，操作维护中心）网管数据提供相关性能数据，由于OMC指标统计至少有15分钟粒度的时延，从突发事件发生场景建立到场景性能指标呈现往往需要近30分钟，过长的时延难以实现先于客户投诉发现网络问题。因而需要建立一种针对突发事件场景快速建立场景并进行实时性能监测的方法和平台。

2 相关技术介绍

2.1 信令大数据

通常意义上，信令数据指的就是XDR（X Data Recording，X数据记录）数据。基于信令XDR数据开展网络性能分析、业务质量分析已成为运营商提升网络质量、保障客户感知的关键能力。

首先对移动通信网络DPI（Deep Packet Inspection，深度报文检测）技术与XDR数据作简要介绍。DPI是一种基于应用层的流量检测和控制技术，当IP数据包、TCP或UDP数据流通过基于DPI技术的信令监测系统时，该系统通过深入读取载荷的内容来对OSI七层协议中的应用层信息进行重组，形成可用于网络质量、业务质量、用户行为等分析的XDR结构化数据。

XDR是根据早期CDR（Call Data Recording，呼叫数据记录）概念演变而来，CDR中记录的是通话过程的关键信息，而XDR是对CDR的扩展，泛指移动网络、承载网络中数据流量的关键信息记录，一般按照用户会话为单位，一个会话形成一条XDR记录。

由于移动互联网业务的飞速发展，信令数据规模在不断增长，目前一个中等省份信令数据量日均近100 T，并且每月还在高速增长，因而称之为信令大数据。在本文中，将基于信令大数据而非OMC网管数据作为突发事件场景中的性能指标计算数据源。

2.2 流式计算

针对大数据的计算，总体可以分为批量计算和流式计算两种。

Hadoop分布式计算框架是大数据批量计算的代表，数据先存储后计算，数据引入至Hadoop文件系统（HDFS）并分发到各个节点进行处理，当处理完成后，结果数据会返回到HDFS供需求方使用。Hadoop的高吞吐、海量数据处理的能力使得可以方便地处理信令大数据。但是，Hadoop的缺点也非常明显：延迟大，响应缓慢，很难满足一些对时延有特定要求的业务需求场景，比如突发事件场景中实时性能计算。

流式计算就是为了弥补批量计算实时性的不足，由Twitter公司贡献的Storm就是典型的大数据流式计算框架，无需先存储，数据直接在有向无环图（Directed acyclic graph）的任务拓扑中（Topology）计算完成。Storm的数据输入流由spout组件管理，spout把数据传递给Bolt组件，Bolt可以进行数据处理，也可以把数据传递给其它的Bolt，Storm集群就是在多个Bolt之间处理spout传过来的数据，spout与Bolt间关联关系图即为Storm的Topology。Storm流式计算Topology图如图1所示：

图1 Storm流式计算Topology图

Storm是目前比较流行的流式计算技术框架，在业界有着广泛的应用。在本文中，将通过Storm流式计算技术完成突发事件场景中信令大数据的实时性能计算。

2.3 快速场景定制

场景的建立一般包括两种方法：一种是后台导入方式，也即先收集场景小区资源信息，通过后台导入的方式在GIS图层上呈现；另一种是前台圈选方式，也即在GIS图层上以不规则多边形、矩形、椭圆形等圈选需要监控的区域，区域内基站小区自动关联为监控的资源信息。在早期的场景定制中，由于小区经度、纬度字段存在较多问题，不够准确，一般采用第一种后台导入方式，对场景资源进行关联；但在4G建设中，小区的经度、纬度字段等资源信息录入前期就进行了严格管控，并增加了校验手段和勘误流程，准确性已足够准确，可以采用前台GIS圈选方式。

突发事件场景因为发生区域无法提前预知，为了实现场景的快速定制，应首先采用前台GIS圈选方式。

3 平台设计与实现

3.1 整体架构

突发事件场景的实时性能监测平台采用三层体系架构，分为数据采集层、数据实时处理层及应用层。其中数据采集层的主要数据为信令XDR数据及资源管理系统中小区等资源数据；数据实时处理层包括信令XDR数据实时处理、分布式消息分发、监测指标流式计算、内存数据库指标缓存；应用层为突发事件场景实时性能监测GIS呈现及预警展示。

平台整体架构如图2所示：

图2 突发事件场景实时性能监测平台体系架构

3.2 数据处理流程

考虑到信令XDR数据的体量规模非常大，为了缩短突发事件场景监测指标性能呈现的时延，在平台设计时需重点考虑实时ETL、分布式消息分发、流式计算、指标缓存及监测指标性能上层应用呈现5个关键点。

（1）实时ETL：实时接收DPI信令数据，并根据突发事件场景具体监测指标对XDR数据进行针对性的字段筛选以及数据转换。

（2）分布式消息分发：完成筛选、清洗、转换后的数据快速分发。在本次平台实现中，由Kafka实现。

（3）流式计算：完成场景监测指标实时计算。在本次平台实现中，采用Storm分布式计算框架。

（4）指标缓存：完成场景监测指标缓存，供应用层调取。在本次平台实现中，采用开源Redis框架。

（5）实时性能监测：完成突发事件场景实时性能监测指标前台GIS呈现展示，同时可以根据阈值规则及

时预警。

3.3 关键点实现

（1）实时ETL

ETL是数据抽取（Extract）、转换（Transform）及装载（Load）的过程，从数据源抽取出所需的数据，经过数据清洗，按照业务数据模型，将数据加载到数据仓库中。

由于DPI信令数据量体积非常大，在数据计算前应当先进行清洗和转换，也即进行实时ETL，以便最大程度地减少传输、计算数据量，缩短计算耗时。在平台实现时，主要完成以下3点：

1）从XDR数据源系统（统一DPI）以SDTP接口的形式实时接收XDR数据流。

2）根据上层应用监测指标需求，完成入库的XDR数据进行针对性的事件、字段筛选，同时开展数据转换、加载。

3）将筛选、清洗、转换后的数据发送至Kafka集群相应的Topic中。

（2）Kafka分布式消息分发

Kafka是一种分布式的、基于发布/订阅的消息系统，发送消息者成为Producer，消息接受者成为Consumer，对消息的接收和分发按照Topic进行归类。

图3 突发事件场景实时性能监测平台数据流示意图

在平台实现中，Kafka主要用来作为整个实时流系统（Storm）的数据源，实时流系统（Storm）将从Kafka中读取相关数据进行分析、处理。

1）通过实时ETL，将解析处理后的每行XDR数据根据不同业务类型写入Kafka对应的Topic中，比如HTTP话单数据将写入对应HTTP的Topic中。

2）Storm系统将源源不断地从Kafka各Topic中获取数据进行后续分析、处理。

（3）Strom实时计算

Kafka将DPI信令数据传至Strom后，Storm创建Topology，并通过Topology建立spout和blot组件之间的关联关系，其中spout组件进行信令数据接入处理，同时将信令数据传给bolt组件，bolt组件完成对数据转化、计算。

在本次平台实现中，共涉及4个组件，分别为KafkaSpout、CleanBolt、SceneCleanBolt以及SceneSummaryBolt。各组件功能如下：

1）KafkaSpout从Kafka中接收信令XDR数据，并向CleanBolt组件分发数据。

2）CleanBolt将从KafkaSpout中读取的数据进行清洗及转换，然后将清洗转换后的数据传递给SceneCleanBolt。

3）SceneCleanBolt从数据库中读取场景与小区的对应关系配置信息，并通过输入数据中的小区关联出场景信息，然后将关联转换后的数据传递给SceneSummaryBolt。

4）SceneSummaryBolt负责场景指标数据汇总运算，并将汇总后的结果存入Redis缓存中。

平台拓扑（Topology）关系如图4所示：

图4 突发事件场景实时性能监测平台Storm拓扑图

（4）Redis指标缓存

Redis是一个key-value存储系统，它支持存储的value类型相比其他缓存数据库（如Memcached）更多，包括string（字符串）、list（链表）、set（集合）、zset（有序集合）和hash（哈希）等。同时为了保证效率，Redis数据都是缓存在内存中，并且Redis支持数据持久化，即使服务重启，Redis中缓存的数据也不会丢失。目前Redis已成为缓存数据库的首选，在很多业务场景中得到应用。

在平台实现中，Redis主要作用如下：

1）中间数据的汇总及存储。完成Storm集群流式计算后各性能指标数据结果的汇总和存储。

2）数据同步。将保存在Redis的中场景指标数据定时同步至关系型数据库中（如Oracle），以方便前台应用查询场景历史指标数据。

（5）实时性能监测

平台界面依托GIS开发，场景监测的性能指标实时在GIS上呈现。根据突发事件发生的地理位置，通过GIS圈选方式快速建立场景，按照小区经度、纬度字段属性进行判断，对于落在圈选区域的小区将自动作为监测的小区。在Storm流式计算集群完成场景监测指标计算，并缓存在Redis中，前台读取Redis中指标性能数据，并实时在GIS上完成呈现。

平台界面呈现如图5所示。

3.4 平台实现成效

（1）指标呈现时延

根据平台数据处理流程，从突发事件场景建立到监测性能指标在前台界面呈现共涉及6个环节，分别为：信令数据接收、数据ETL、Kafka数据分发、Storm监测指标计算、监测指标输出与缓存、监测指标场景呈现。通过设置信令数据时间戳，平台各个环节数据平均耗时统计如表1所示。

总时延=t（信令数据接收）+t（数据ETL）+t（Kafka数据分发）+t（Storm监测指标计算）+t（监测指标输出与缓存）+t（监测指标场景呈现）=5分钟。

图5 突发事件场景实时性能监测平台呈现

表1 突发事件场景性能呈现各环节时延统计表 min

由于突发事件保障的特点，场景性能指标呈现的时延应该越短越好。在本平台设计与实现中，基于信令数据，应用流式计算技术，采用GIS圈选场景的方法，从突发事件场景建立到监测性能指标在前台界面呈现不到5分钟，大幅缩短了传统突发事件场景保障性能指标呈现的时延，而且后续监测指标可以实时进行GIS呈现，平台应用效果良好。

（2）平台可扩展性

突发事件场景实时性能监测平台采用三层架构，实现中应用的Kafka、Storm、Redis均为开源框架，同时在场景性能指标实时计算采用的是前台GIS圈选方式，是基于底层小区资源数据的汇总，因此场景可以任意定制，可以根据突发事件保障需求任意增加或删除监控场景，前台应用增加监控场景无需对后端Storm集群作任何调整，平台可扩展性非常强。

4 结束语

本文结合突发事件场景保障的需求，基于信令数据、流式计算、GIS圈选等方法设计与实现了突发事件场景实时性能监测平台，并详细描述了平台的体系架构、数据处理流程、关键点实现等，平台可以大幅缩短从突发事件场景建立到场景性能监测指标实时呈现的时延，平台上线后已多次应用于省内突发事件的场景保障，并取得了不错的效果。该平台的可扩展性非常强，也可以作为对信令大数据实时处理的通用架构，应对重大活动保障、实时人流监控、实时道路交通拥堵监测等业务需求。

参考文献：

[1]杨军,柴刚,赵越. 基于互联网大数据的重大场景通信保障[J]. 邮电设计技术, 2016(4)： 63-66.

[2]孙大为,张广艳,郑纬民. 大数据流式计算：关键技术及系统实例[J]. 软件学报, 2014(4)： 839-862.

[3]董斌,杨迪,王铮. 流计算大数据技术在运营商实时信令处理中的应用[J]. 电信科学, 2015(10)：172-178.

[4]张艳荣,张治中. 基于DPI的移动分组网络流量分析技术的研究与实现[J]. 电信科学, 2014(4)： 88-94.

[5]罗琦芳. 一种基于Lambda架构的电信数据平台解决方案[J]. 电子技术与软件工程, 2017(11)：182-183.

[6]王岩,王纯. 一种基于Kafka的可靠的Consumer的设计方案[J]. 软件, 2016(1)： 61-66.

[7]马延辉,陈书美,雷葆华. Storm企业级应用实战、运维和调优[M]. 北京： 机械工业出版社, 2015.

[8]曾超宇,李金香. Redis在高速缓存系统中的应用[J]. 微型机与应用, 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. ★