基于Hadoop的OSS域數據建模與采集方法研究

雷 蕾，李景文，宮大鵬，王 睿，蘇 雷，陳寧江

(1．中國移動通信集團廣西有限公司 南寧530022；2．億陽信通股份有限公司 南寧530022；3．廣西大學計算機與電子信息學院 南寧530004）

1 引言

隨著“大數據時代”的來臨，電信運營商已意識到自己手中“數據金庫”的價值，正在積極推動傳統的分析支撐體系向分布式大數據架構進行演進，以構建集中化的企業級大數據中心，實現整個企業的數據融合，提供開放的數據能力，逐步滿足全網、全渠道、全業務一體化營銷服務的要求。

在廣西移動的企業級大數據中心建設及企業數據融合工作中，主要采用Hadoop架構搭建大數據中心，數據來源主要包括電信行業通常所劃分的OSS（operation support system，運營支撐系統）、BSS（business support system，業務支撐系統）、MSS（management support system，管理支撐系統）3個領域的數據，3個域數據的采集處理復雜度不同，服務于不同的場景。其中，OSS域數據種類繁多，數據量大，采集過程復雜，同時包含結構化及非結構化數據，是三域數據中最復雜的一類，也是建設大數據中心的重點及關鍵工作之一。本文結合業務實際需求，介紹基于Hadoop平臺的OSS域數據采集和數據管理建模的解決方案和實現技術，目標是將域數據有效地傳遞和組織，使得數據中心切實有效地對數據進行管理，對應用進行數據供給。

2 OSS域數據背景與現狀

OSS域系統的主要數據類型包括網絡的資源數據、告警數據、性能數據、網絡測量數據、信令數據、工單數據、日志數據等，每天產生的數據量在60 TB左右，以煙囪的方式在網絡優化系統、話務網管、數據網管、信令監測系統、綜合網絡資源管理系統等多套系統中采集和存儲。

如圖1所示，從數據量來看，來自于信令監測系統的信令數據占整個OSS域數據量的97%，信令數據記錄了用戶的通話記錄和上網記錄等信息，同時含有結構化數據和非結構化數據，是對用戶行為進行分析、開展大數據分析營銷的重要基礎數據；從數據獲取復雜度及采集頻次來看，網絡優化系統（簡稱網優）的數據獲取復雜度最大，采集頻次最高，網優數據全面記錄了網絡的各類性能指標，以結構化數據為主，是利用大數據技術開展2G/3G/TD/WLAN網絡協同性能分析，提升用戶網絡使用感知的重要基礎數據。

在上述的OSS域各系統中，都同時保留了各自采集到的原始數據和經過計算后的匯總數據，這種煙囪式的數據管理方式缺乏有效的管理機制，部分數據存在重復，如網優系統和話務網管系統同時都有話務量、掉話率數據，各系統間的數據也沒有顯性的聯系，如信令系統中的信令數據與網優系統中的網絡性能數據無法實現關聯分析。因此，數據的孤島現象嚴重，數據價值無法得到充分的挖掘和利用。國內許多互聯網公司為了應對這樣的數據自主研發了許多架構，例如騰訊為應對其自有業務的大數據處理構建了一套TDW（Tencent distributed data warehouse,騰訊分布式數據倉庫）架構，小米對HBase進行不斷改進和擴展。中國科學院計算技術研究所對行列混合式存儲技術、HDFS數據壓縮技術的研究也已取得初步成效。

針對上述問題，為實現OSS域各類數據的統一采集、統一存儲、集中建模和數據共享，筆者研發了一個基于Hadoop的OSS數據統一采集平臺（HD-OSS），如圖2所示。HD-OSS平臺基于Hadoop技術架構搭建，實現對各類數據的采集、清理、抽取和轉換，并進行輕量級匯總計算。采用統一的云化ETL技術進行數據預處理，實現數據接入的統一管控、海量多樣化數據處理，提供各個域數據融合的基礎，清洗后的數據在ETL平臺完成統一的調度轉換，最后進入數據中心。采用異構分層存儲架構，引入大規模并行分布式（MPP）數據庫和關系型數據倉庫，按照數據在生命周期中不同階段對存儲的性能需求，數據分類分級后分布存儲在數據倉庫和MPP數據庫。HD-OSS平臺還需實現統一數據建模、統一編碼管理和統一指標管理。在平臺的建設中，數據采集管理和數據建模是確保大數據中心數據的完整性、準確性和一致性的關鍵問題。本文主要對它們進行研究并提出解決方案。OSS域數據面臨的最大問題是業務的影響會直接擴散到網絡設備采集層，一旦上層的應用需求改變，底層數據采集的時間粒度、空間粒度、指標算法、存儲方式等可能會發生改變，OSS域數據與應用解耦是關鍵課題。

圖1 OSS域數據分布

圖2 混搭式數據中心架構

3 基于Hadoop的數據采集管理

OSS數據統一采集平臺主要解決網絡中網元的采集適配問題，統一管理對網元、信令、路測等設備的采集進程，監控整個采集過程和數據質量，通過ETL完成數據清洗和部分輕量級數據的匯總，將數據輸送進入數據中心，這是整個OSS采集的核心。統一采集平臺重點對告警、性能（含網優）、資源和信令四大類數據采用不同的方式進行處理，如圖3所示。

·對于資源數據來說，數據量較小，數據來源主要為工程配置和資源入網割接時錄入的手工數據，對資源狀態的實時性要求不高，每天僅需更新一次，因此每天由統一采集平臺采集后，分別提供給大數據中心和綜合資源系統。

·對于告警數據來說，數據量大，具備流式處理的特征，而且實時性要求非常高，所以統一采集平臺采集到數據后將數據分為兩份，一份送到綜合告警管理系統，一份送入企業大數據中心。

·對于性能數據來說，數據量一般，但數據來源多、采集頻次高、數據結構復雜，統一采集平臺完成數據采集及解析后，再進行輕量級計算及匯總，將原始數據及匯總數據根據需要送到OSS域的各系統及企業大數據中心。

·對于信令數據來說，數據量特別大，但數據來源單一，僅需要全量接入信令監測系統提供的數據或文件即可，但由于存在大量的非結構化數據，因此需要統一采集平臺采用爬蟲技術對非結構化數據進行分析，所有的數據全部送入到企業級大數據中心保存。

下面以最復雜的性能數據為例，說明統一采集平臺基于Hadoop平臺進行ETL數據處理的過程，如圖4所示。

圖3 OSS域數據統一采集示意

圖4 基于Hadoop的ETL數據處理流程

基于Hadoop平臺的ETL與普通的ETL過程沒有本質區別。統一采集平臺完成底層數據采集后即進入ETL過程，主要通過Ooize或其他調度工具實現周期調度，另外HDFS和FS系統可以通過流程打通，Hive與Hbase也可以通過Sqoop與其他數據庫打通。大數據的處理過程也由SQL方式提供，可以引入一些數據挖掘的處理過程。

4 OSS域數據建模管理設計

4.1 數據建模方法論

通過總結實際經驗，筆者提出了一種層次型分類梳理數據建模方法，如圖5所示。數據建模和管理遵從自上而下的分類梳理對數據進行重新規劃，主要根據數據源歸屬、特點、規模等情況對數據進行模型分層和數據粒度分層，按照ODS（operational data store，操作型數據存儲）、DW（data warehouse，數據倉庫）和DM（data market，數據集市）3層進行數據建模。ODS用于存放從數據源直接抽取出來的數據，這些數據在數據結構、數據之間的邏輯關系上與數據源基本保持一致，DW主要根據企業模型而來，而從業務專題出發建立的模型則會固化在DM層。在ODS層和DW層，一般會以運營數據模型和企業模型為出發點，指導數據在采集計算層面大致分出哪些是業務支撐驅動的數據，哪些是運維支撐驅動的數據，例如借助eTOM模型定義出企業規劃、運營支撐、故障、計費、開通、保障等層面數據覆蓋范圍和數據歸屬，并能結合現狀調研初步估算出數據的使用頻度和粒度大小。而DM層的業務模型則主要根據業務應用方向分專題建模，如流量經營業務模型、客戶感知業務模型等。

4.2 數據模型的分層原則

OSS域數據將按照如下原則劃分到數據模型的ODS、DW、DM 3個層次。

（1）ODS層模型

·原則一：按照10億～1 000億的億級數據進行分層。

·原則二：按照數據之間的推演規則進行分層，如圖6所示。

圖5 建模方法論

圖6 ODS層模型

（2）ODS層

ODS層也被稱作數據緩沖區，存儲包括O域專業網性能、告警、資源、DPI等系統數據。建立清單級、會話級數據（PI、KPI級數據）模型。例如網管系統的性能數據會按專業組織最細粒度的數據模型表示。DW層模型如圖7所示，在ODS層保存清單級數據后，通過進一步關聯匯總形成DW層數據，主要為了支撐上層應用分析和鉆取分析，根據業務需求對事實數據和維度數據進行有效的組織和規范，提高數據的訪問效率。按企業模型和不同細分粒度組織建模，并設計出模型間的關聯關系。一般DW層按4類模型進行匯總，分別匯總為維度表、事實表、聚集表、臨時表。

·維度表：根據系統各個主題邏輯數據模型的維度設計的物理數據庫表，記錄模型維度信息。

·事實表：記錄各專題最細粒度的事實信息，物理數據庫表的設計是依據邏輯數據模型設計的。

·聚集表：記錄各專題匯總粒度的事實信息，物理數據庫表的設計是依據邏輯數據模型設計的。

·臨時表：根據數據ETL設計定義，即為中間表，無模型設計意義。

圖7 DW層模型

（3）DM層模型

DM層模型面向應用組織建模，以業務需求應用為單位對DW層的數據進一步組織和存儲，是面向需求以及未來需求變更、擴展的模型。一般以業務作為驅動，在DW模型基礎上按業務專題所需要的業務再次進行數據組織，通過按上層業務組合、業務鉆取等形成最終面向應用的DM層模型；各專題域模型引用ODS層企業流程模型，構成邏輯專題域數據。

以幾個分析專題為例，將所需要的業務進行模型組織，按上層業務組合、業務鉆取等建立模型，具體見表1。

通過以上過程，即完成了數據中心架構支撐下的分析應用建模支撐。圖8給出了一個整體業務數據建模例子，在數據中心中組織了從基礎數據、數據倉庫、數據集市3層數據模型，通過數據抽取進行逐層匯總，匯聚到DM層以后，即可形成高價值業務分析、高流量用戶分析等面向分析專題的模型數據。當上層業務發生變更，開發者可根據情況在DW層再次快速組織數據匯總，省去重新采集建模的開發時間。按這樣層次組織的數據模型即可實現對應用開發的快速模型支撐，響應性能分析需求的高時效性。

表1 分析專題DM模型示意

圖8 按業務分層的數據模型例子

5 應用場景

圖9為OSS域性能分析示意。

基于OSS域數據的分析應用主要集中在客戶感知、業務質量、網絡性能3個方面，這些分析專題的數據來源復雜，結構化程度不統一，以下重點以移動互聯網端到端分析專題為例，進行數據采集及模型管理的介紹。

如圖10所示，移動互聯網端到端分析專題重點圍繞LTE網絡移動互聯網絡業務，開展端到端感知分析。從業務感知指標入口，總結自上而下的問題溯源關聯規則，提供各類型業務（瀏覽、下載、視頻和即時通信四大類業務類型）的業務質量端到端分析，實現精準的問題定界和定位。

圖9 OSS域性能分析示意

圖10 移動互聯網端到端業務質量指標定位

針對業務端到端質量問題，進行問題溯源分為兩大步驟：第一，質差定界；第二，問題溯源。兩大步驟均需要通過梳理指標體系實現。根據業務梳理得到的指標集結合模型分層原則可設計出采集及模型管理的要求，見表2。

目前通過業務質量管理平臺，能夠獲取移動互聯網的4類業務，分別為網頁瀏覽、視頻業務、即時通信、應用下載業務數據。通過DPI平臺可對用戶面S1-U口、Uu口與SGi口信令解析，獲取KQI/KPI/PI指標。表3為過程指標分解。

瀏覽類業務主要包括附著、承載激活、DNS解析、TCP鏈接、HTTP請求的5個階段，當成功率類指標發生波動時，首先關聯KPI指標確定業務失敗在哪個過程，然后根據這個過程中出現的錯誤碼分析失敗原因，最后通過FM/PM/CM排查KPI，橫向對比，定界具體異常點?；跇I務過程的KPI指標能夠定位業務失敗原因，對業務質量進行管理和優化。通過對兩類指標進行業務關聯，即可完成故障溯源的過程。

采集方面，通過OSS統一采集平臺實現初步ETL過程，更好地解決算法不透明、缺乏管控手段、統計口徑不一致、接口雜亂等問題，平臺統一管理所有的采集通道和時間軸。在ETL完成后，數據按專業維度存放在數據中心的ODS層。

一般在ODS層保存兩年的清單級數據（PI、KPI級數據），通過進一步關聯匯總為DW層模型。在DW模型基礎上，按互聯網端到端分析專題所需要的業務再次進行數據組織，按上層業務組合、業務鉆取等建立模型，形成最終面向應用的DM層模型，即完成了整個數據中心架構支撐下的分析應用建模支撐。

關于OSS數據對大數據業務的其他支撐，如圖11所示，還可以通過對信令數據進行深度挖掘，研究客戶的上網行為、基本特征、位置軌跡、消費偏好等信息，對數據進行“脫敏”后，可完成用戶畫像，為自有業務營銷、客戶產品服務提供數據支撐。

6 結束語

電信運營商數據中心建設必須重視OSS域數據建設，這是保證整個數據中心質量、支撐應用分析業務開展的重要基礎。目前中國移動正在全國推動數據中心的建設，在建設過程中怎樣處理好數據采集與數據存儲的關系，受到業界公司的重點關注。本文介紹了對OSS域數據進行大數據中心架構管理的采集流程和數據建模的關鍵方法，為其他省建設企業數據中心提供可實施的建設經驗。目前廣西移動正在借助已有的平臺對數據中心進行重新規劃，對于OSS域的數據供給，建設完成后可以對架設在數據中心之上60%～70%的應用群提供OSS側的數據支撐。下一步的工作主要包括：適應業務發展的多樣化，需要研究將更多的數據采集、計算存儲模型融入到數據中心的整體架構中；深入研究OSS在大數據支撐的應用，例如通過對信令數據的深度挖掘，研究客戶上網行為、位置軌跡、消費偏好等信息，為自有業務營銷、客戶產品服務提供數據支撐。

表2 互聯網端到端指標體系

表3 過程指標分解

圖11 OSS域數據的分析支撐

1 Barroso L A,Dean J,Holzle U.Websearch for a planet:The Google cluster architecture.IEEE Micro,2003，23(2):22～28

2 Xu Y,Kostamaa P,Qi Y.A Hadoop based distributed loading approach to parallel data warehouses.Proceedings of SIGMOD 2011,Athens,Greece,2011

3 詹志強，孟洛明，邱雪松.多專業網綜合網管系統體系結構的研究.北京郵電大學學報，2003(1)Zhan Z Q,Meng L M,Qiu X S.Architecture of network management system for multi-technology network.Journal of Beijing University of Posts and Telecommunications,2003(1)

4 Liu X F,Thomsen C,Pedersen T B.Cloud ETL:Scalable Dimensional ETL for Hadoop and Hive.DB Technical Report,2012

5 Mohammed M,Mohd S A.A Framework for Interoperable Distributed ETL Components Based on SOA.Proceedings of ICSTE 2010,San Juan,PR,USA,2010

6 陳桂漢.綜合電信管理解決方案.北京：電子工業出版社，2002 Chen G H.Integrated Telecommunications Management Solutions.Beijing：Publishing House of Electronics Industry，2002

7 Ghemawat S,Gobioff H,Le-ung S T.The Google file system.Proceedings of 19th Symposium on Operating Systems Principles,Lake George,New York,USA,2003

8 Corbett J C，Dean J,Epstein M.Google’s globally distributed database.Proceedings of the 10th USENIX Symposium on Operating Systems Design and Implementation,OSDI 2012,Hollywood,CA,USA,2012

9 Samuel P,Mall R,Kanth P.Automatic test case generation from UML communication diagrams.Information and Software Technology,2007(49):158～171

10 Ling F,Chang E,Dillon T.A semantic network-based design methodology for XML documents.ACM Transactions on Information System(TOIS),2002,20(4):1～6

11 Dean J,Ghemawat S.MapReduce:Simplified data processing on large clusters.Proceedings of6th Symposium on Operating Systems Design and Implementation,OSDI’04,San Francisco,USA,2004