翁锐浩++段新++黄倚霄++王锐

摘 要：网管系统是各运营商最核心的生产保障系统，负责核心网、智能网、数据网等的安全、高效、稳定运行，确保数亿用户的通信质量和信息安全。随着4G LTE技术的深度应用及移动互联网的不断发展，用户对移动网络的依赖度越来越高，同时对网络质量和性能的要求也越来越高，对于网管系统要求更全面分析用户感知、更深层次挖掘网络隐患、更实时发现故障和质量下降、更准确预测用户投诉行为、更快速解决故障和质量问题。由于此前的网管系统监控、性能、资源、工单、投诉等系统各自建设、数据分散不利于构建面向用户的网络质量管理及优化体系，该文通过运用大数据技术，构建运营商网管数据互联中心，接入网管各类数据，进行关联、清洗、互联，建立统一融合的数据模型，集中对外提供数据，通过灵活统一的分布式数据互联中心方案，大大提升网管数据服务能力。

关键词：数据互联中心 数据建模 数据仓库 管控分析门户

中图分类号：TP399 文献标识码：A 文章编号：1674-098X（2017）01（c）-0087-05

1 运营商网管系统数据现状及问题

随着移动LTE业务的迅速发展，网管数据迅速增长，对网管系统的数据支撑要求也越来越高，急需网管数据能更全面分析用户感知、更深层次挖掘网络隐患、更实时发现故障和质量下降、更准确预测用户投诉行为、更快速解决故障和质量问题。但目前各网管系统仍以功能性场景服务为主，只能解决单一场景的问题，在数据的关联服务能力方面较弱，无法有效支撑面向用户的数据服务支撑能力。目前主要存在以下问题。

（1）在使用方层面，希望能将各类网管数据（告警、性能、资源、工单、工程、拓扑、拨测、投诉）进行集中管理、对地市共享，实现各类网管数据的集中互联、关联、清洗、共享，并希望实现网管数据和信令数据的关联，支持从网管数据到信令详情的追溯。

（2）从应用层面考虑，应用对于数据实时性要求越来越高，目前已有的系统无法满足应用的实时性要求；应用从多个系统获取数据成本较大，不利于上层应用敏捷开发、快速部署的诉求，与互联网新架构的发展趋势不相符。

（3）从数据层面考虑，多个系统形成数据孤岛，缺少统一的接入、清洗、建模的管理，需要统一的数据接入、统一的计算、统一的接口共享来打破数据孤岛；各自独立系统运维、管理面临很大难题，通过数据互联统一运维，提高资源利用率和处理效率；匹配互联网的发展趋势，数据统一互联形成大数据平台成为互联网主流选择。

2 利用大数据技术构建运营商网管数据互联中心的方法

针对目前网管系统数据分散、数据服务能力较弱，无法有效支撑运营商面向用户的网络质量管理要求，该文提出利用大数据技术构建网管数据互联中心，对分散的网管数据进行互联、清洗、关联，并构建灵活统一的数据服务层，有效提高数据服务能力，支撑面向用户的网络质量管理要求，如投诉预警、实时监控、省市共享、挖掘分析等应用。

该文方法主要包括两大阶段：调研分析验证阶段和融合互联实现阶段。

（1）调研分析验证阶段。

该阶段主要是研究需求与数据、探索数据之间的业务联系，可按如下步骤进行。

①调研梳理。

调研梳理各类业务和数据模型分布、用途等信息。

调研梳理各系统数据对外提供共享接口形式、共享机制、更新频率、数据粒度等。

数据资源调研分析示例见表1。

②模型分析。

对各应用需求分类汇总，进行共性分析。

分析各应用需求与数据支撑的差距，了解短板所在。

分析省級数据，研究数据关联节点，进行多数据关联模型设计。

建模分析方法示例如下。

需要解决的问题：定位用户投诉原因。

数据建模方法：数据源：信令数据、投诉数据、性能数据、资源数据。关联维度：用户、时间、业务、网元。关联指标：投诉事件、信令事件、网元性能、网元资源。模型价值：实现快速地投诉问题原因溯源定位。

数据融合互联分析模型：多数据源，跨数据维度匹配、指标关联，实现深入分析。

用户投诉无法呼叫。

根据投诉号码时间点关联用户信令事件（是否网络原因）。

根据信令中位置信息关联资源数据。

根据资源数据关联呼叫失败发生的小区接通性能指标。

小区资源不足、小区覆盖质量差、小区设备存在故障等原因定位。

③实施验证。

预采集所需各类数据，包括传统性能数据、工单数据、告警数据、投诉数据等。

关联建模，构建新的数据模型。

搭建数据DEMO，验证模型设计。

（2）融合互联实现阶段。

利用大数据技术构建运营商网管数据互联中心的构建方法，构建网管数据互联中心，主要包括5个步骤：统一数据接入、统一数据建模、集中数据存储、统一数据共享、统一平台管控。

统一数据接入：负责统一的数据接入。可根据业务需求和数据类型提供多种接入方式；数据接入后根据规则对数据进行初次清洗。

统一数据建模：负责对接入数据进行统一建模。对数据做统一的标准化处理，同时也可以根据业务规则对多数据源进行关联。

集中数据存储：负责对建模后数据的统一存储。运用Hadoop分布式技术，对于数据查询时延要求高的可以存储在Hbase上；对于数据需要提供灵活查询方式的可以存储在Hive上。

统一数据共享：负责数据的统一对外共享。统一的数据共享可以有效防止数据泄露，降低上层应用获取数据的成本。可根据业务需求提供多种数据共享方式，整体上分实时获取和非实时获取方式。

统一平台管控：负责对网管数据互联中心进行管理和控制。包括对用户的安全认证、数据获取方的权限管理、互联中心的数据进行质量监控等。

3 具体实现方法

3.1 互联中心建设

3.1.1 总体架构图

网管数据互联中心的架构，主要包括5个核心模块：南向数据接入层、数据关联中心、数据仓库、北向共享接口层、互联中心管控分析门户（见图1）。

3.1.2 功能模块介绍

（1）南向数据接入层。

负责各种网络数据的实时性接入和非实时性接入，实时性要求高的数据通过Kafka方式接入，对实时性无要求的数据则通过Flume方式接入。需接入的数据如下。

①工单：开通、故障、投诉。

②网络变更：工程割接、其他变更操作等。

③网络资源：2/3/4G基站信息、2/3/4G小区信息、BSC、RNC、SGSN、MME等网络资源信息。

④网管性能：从采集平台获取分支进行计算汇总，实时监控需求从采集平台直接送综合监控。

⑤告警：历史告警（补充了很多处理信息）；实时告警（没有工单状态），综合监控目前没有实时的告警的对外共享接口，通过MQ消息送到Kafka总线，经过storm清洗后入Hbase。

⑥拨测：基于探针拨测和仿真测试。

⑦用户投诉：批量投诉、广义投诉等。

⑧其他网络数据，如日志等，后续检视具体应用的数据需求再确定。

⑨无线专业的数据范围待后续结合地市需求和无优中心沟通后细化，比如投诉黑点、MR等。

（2）数据关联中心。

数据关联中心是对南向接入数据进行数据建模、对数据模型化处理，主要分为“资源ODM化”和“多数据源关联”。

①资源信息ODM化：通过加载资源数据后，采用Spark Streaming技术对南向接入的其他数据源，以实时流的方式进行高效资源维度信息规范化处理，回填资源信息，为后续的多数据源关联提供统一标准的资源维度。

②多数据源关联：是依据数据融合模型场景，对实时计算需求场景中使用Spark SQL，在离线计算需求场景中使用Hive，对ODM化输出的各数据源的以资源维度为索引进行数据关联和汇聚的处理。

数据源关联原则（三同一全原则）：同最小维度关联，对最小维度级别相同的数据源进行关联。同网络类型关联，关联的数据源中只存在某种网络类型（2、3、4G）的，则根据网络类型维度分别关联输出模型。同数据量级关联，进行关联的数据源必须在同一数据量级，否则分开模型输出。全字段关联，关联的各数据源中维度外的字段全部输出到模型里。

数据管理中心处理包括实时计算框架和离线计算框架2类。

①实时计算框架：接入流式消息数据，数据从接入系统到计算出结果耗时在1 min内，进程常驻；计算框架为Spark Steaming，对接消息队列Kafka获取消息。

②离线计算框架：接入文件数据，数据从接入系统到计算出结果耗时在5 min以上，按需启动/结束进程；计算框架为Spark和Hive，从HDFS获取输入数据。

（3）数据仓库。

数据仓库负责共享数据的统一存储，包括ODM化后的原始接入数据和关联后的融合模型数据。ODM化后的原始接入数据因其数据量大，存储在Hbase集群以提供高速的海量数据查询响应。关联后的融合模型数据是对多数据源关联汇聚后的统计数据，存储在Hive以提供灵活组合的高效查询。

（4）北向共享接口层。

北向共享接口层是一种分布式接口服务层，负责数据对外开放共享。外部系统可以通过5种方式获取数据。

实时获取Hbase数据。以REST API方式，对外发布GET（URL）接口，将查询条件封装在URL？para1=xxx&

para2=xxx，以JSON的格式返回查询数据。此方式主要用于查询结果集较小、实时性要求高的场景。

异步获取Hbase数据。以Kafka+FTP方式，查询结果较大时使用此方式，将结果写入文件中，然后上传到FTP服务器上，通过Kafka返回如何获取文件的信息。此方式主要用于查询结果集较大、实时性要求低的场景。

异步获取即系查询数据。以Kafka+FTP方式，查询结果较大时使用此方式，将结果写入文件中，然后上传到FTP服务器上，通过Kafka返回如何获取文件的信息。此方式主要用于查询结果集较大、实时性要求低的场景。与第二种的差别是，第二种方式查询的是Hbase数据、而此方式查询的是Hive数据。

FTP定期获取数据。数据互联中心把使用方需要的数据（Hbase、Hive数据）上传至FTP，使用方定期扫描FTP服务器，发现有新文件則获取下来。考虑到多用户频繁扫描FTP服务器会增加服务器压力，目前未使用该方式。

获取Kafka实时数据。通过Kafka接口，实时传输数据，使用方订阅相应Topic即可获取所需数据。此方式主要用于对数据实时性要求极高的场景。

（5）互联中心管控分析门户。

互联中心管控分析门户用于对互联中心进行可视化管理和控制，分5个子模块：元数据管理、数据质量、接口管理、安全管理、用户权限管理。

元数据管理。对南向接入数据进行可视化管理；对资源数据的管理和对数据源的资源关联规则配置，包括资源列表和资源关联规则两部分；提供在ODM化和数据源关联以后、最终共享给外部系统的模型数据视图；提供接入数据的数据流向图。

数据质量。对互联中心的接入数据的完整性进行统计、给出缺失的文件；统计各模型的资源关联率、关联率低的模型及时告警。

接口管理。管理南向数据接入的种类、接入方式、采集频率等信息；管理北向共享数据的种类、共享方式、时间粒度等信息。

安全管理。对用户行为进行监控、对敏感数据进行脱敏等。

用户权限管理。对每个访问互联中心的账号进行权限管理，按要求进行授权。

3.1.3 数据总体的流向处理

互联中心数据流总体上分2类：实时数据流和非实时数据流。

（1）实时数据流。实时数据流向如图2所示。

（2）非实时数据流。非实时数据流向如图3所示。

3.2 互联中心应用场景介绍

3.2.1 已落地应用

网管数据互联中心目前已接入5类数据，有效支撑智能研判、自研竞赛、地市共享等应用。接入数据及支持的应用情况见表2。

后续将接入话务网性能数据、数通网性能数据、综分系统数据、有线网优等性能指标数据，客响数据，广义投诉，集客、家宽等资源数据，HSS日志数据等数据，丰富网管数据，以便支持更多的网管应用。

3.2.2 典型应用介绍

故障投诉预警系统：通过互联中心北向接口，获取所需要的告警、工单、网络变更、用户投诉等数据。

数据共享方式如图4所示。

对于工单、网络变更、投诉等数据量较小、实时性要求高的数据，故障投诉预警系统可以实时查询Hbase获取数据，即图4中A方式。

对于告警数据，由于数据量大、且实时性要求也较高，故障投诉预警系统可以通过异步查询Hbase，即图4中B方式，在Hbase查询完数据后把数据文件上传至数据共享机，同时会发一条通知消息至Kafka，故障投诉预警系统可以从该消息中获取到文件信息，然后根据获取的文件信息通过FTP方式从数据共享机获取数据文件。

对于投诉历史数据、告警历史数据等，数据量较大、实时性要求较低，故障投诉预警系统可以通过异步查询Hive，即图4中C方式，在Hive查询完数据后把数据文件上传至数据共享机，同时会发一条通知消息至Kafka，故障投诉预警系统可以从该消息中获取到文件信息，然后根据获取的文件信息通过FTP方式从数据共享机获取数据文件。

4 结语

利用成熟的大数据技术，借鉴互联网公司经验，构建统一的网管数据互联中心，统一数据处理，融合多源数据，进行关联分析、挖掘分析，可以構建更高效的业务分析模型，满足业务发展要求；通过有效数据融合互联，进行线性回归，溯源分析，实现更精准的端到端分析，可以更好地优化客户体验，提高客户满意度。

该文的意义在于提供一个高效可行的方法，破除网管系统烟囱建设、数据孤岛、支撑力度不足问题，通过集中的网管数据互联中心，提供更强大的数据处理能力，更高效的分析模型，更好地促进业务发展，提高企业综合竞争力。

参考文献

[1] 单绍龙，张西群，刘光富.互联异构数据库系统构建综合数据中心平台的研究[J].计算机光盘软件与应用，2012（11）：155.

[2] 陈吉荣，乐嘉锦.基于Hadoop生态系统的大数据解决方案综述[J].计算机工程与科学，2013，35（10）：25-35.

[3] 石岚.电信综合网管系统中的数据管理[J].广东通信技术，2007，27（12）：40-44.