運用大數據技術構建運營商網管數據互聯中心 提升網管數據服務能力

翁銳浩++段新++黃倚霄++王銳

摘 要：網管系統是各運營商最核心的生產保障系統，負責核心網、智能網、數據網等的安全、高效、穩定運行，確保數億用戶的通信質量和信息安全。隨著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.