一種 基于大數(shù)據(jù)技術(shù)的網(wǎng)管系統(tǒng)數(shù)據(jù)管理層設(shè)計方案
相關(guān)鏈接： 中國安全網(wǎng) 中國質(zhì)量網(wǎng) 中國論文網(wǎng) 中國資訊網(wǎng)
作者：張毅
1 引言
網(wǎng)管支撐系統(tǒng)（network management support system，簡稱網(wǎng)管系統(tǒng)或者網(wǎng)管）是網(wǎng)絡(luò)和業(yè)務(wù)運維的信息化管理平臺。如果以1990年IETF在RFC1157中正式公布的SNMP（simple network management protocol，簡單網(wǎng)絡(luò)管理協(xié)議）和ISO在ISO/IEC 7498-4文檔中定義出的五大功能作為網(wǎng)管系統(tǒng)發(fā)展的起點，那么網(wǎng)管已經(jīng)從簡單的維護管理工具，發(fā)展成為運營商提升服務(wù)質(zhì)量和支撐業(yè)務(wù)可持續(xù)性發(fā)展的關(guān)鍵生產(chǎn)運維系統(tǒng)。在這20多年中，新技術(shù)的不斷涌現(xiàn)，尤其是近年興起的大數(shù)據(jù)技術(shù)，為運營商網(wǎng)管系統(tǒng)進一步充分利用、分析、挖掘其掌握的規(guī)模巨大、種類多樣、覆蓋全面、真實權(quán)威的數(shù)據(jù)帶來嶄新契機。
2現(xiàn)狀分析
目前，運營商的網(wǎng)管主要還是面向網(wǎng)元、網(wǎng)絡(luò)以及業(yè)務(wù)的分專業(yè)網(wǎng)管，如話務(wù)網(wǎng)管、數(shù)據(jù)網(wǎng)管、傳輸網(wǎng)管等。這些專業(yè)網(wǎng)管雖然在專業(yè)網(wǎng)絡(luò)管理、所屬業(yè)務(wù)簡單開通和質(zhì)量保持上發(fā)揮著重要作用，但已經(jīng)不能很好地滿足運營商內(nèi)部能力提升的要求。
·不同專業(yè)網(wǎng)管之間信息需要長流程傳遞，無法做到實時交互，導(dǎo)致跨專業(yè)的業(yè)務(wù)開通能力受限，也不利于跨專業(yè)故障的快速準確定位。
·專業(yè)網(wǎng)管系統(tǒng)各自孤立，信息分散存儲，難以支撐全局意義上的信息共享和關(guān)聯(lián)挖掘分析，無法很好地滿足管理層在資源整體規(guī)劃設(shè)計、預(yù)測分析上的要求，也無法很好地支撐客戶體驗度(quality ofexperience，QoE)提高的需求。
·數(shù)據(jù)共享粒度弱，數(shù)據(jù)重復(fù)采集和重復(fù)處理現(xiàn)象普遍存在；與集中模式相比，建設(shè)和運維成本居高不下；數(shù)據(jù)和應(yīng)用耦合度緊密，開放性較差。來自于市場環(huán)境、方針政策等外部要求，對網(wǎng)管系統(tǒng)也提出了新的要求。
首先，基于互聯(lián)網(wǎng)及移動互聯(lián)網(wǎng)的應(yīng)用和業(yè)務(wù)高速發(fā)展，尤其是4G商用規(guī)模的不斷擴大，促使網(wǎng)管由傳統(tǒng)的面向網(wǎng)絡(luò)和業(yè)務(wù)管理的服務(wù)模式向面向經(jīng)營管理和客戶感知的服務(wù)模式轉(zhuǎn)變。在這一模式要求下，不僅數(shù)據(jù)的來源、類型、內(nèi)容和組織結(jié)構(gòu)會持續(xù)變化更新，而且數(shù)據(jù)體量會急劇增加，這些都是現(xiàn)有網(wǎng)管的數(shù)據(jù)模型和技術(shù)架構(gòu)不能應(yīng)對的。
其次，虛擬運營商、三網(wǎng)融合等政策導(dǎo)向促使“一家獨大、一家專營”向社會資源高效配置和跨產(chǎn)業(yè)鏈合作方式轉(zhuǎn)變。由此，網(wǎng)管不僅可能、而且必須成為連接運營商及其合作伙伴的關(guān)鍵一環(huán)。在精確劃分客戶、發(fā)掘利潤點、消除業(yè)務(wù)增長的制約和牽制因素等方面發(fā)揮出更大作用。在從后臺支撐系統(tǒng)向前臺服務(wù)系統(tǒng)轉(zhuǎn)變的過程中，當(dāng)前按照專業(yè)劃分的網(wǎng)管界限必須被打破，建設(shè)一個能夠集中處理、支持合作開放、與應(yīng)用耦合度更松散的數(shù)據(jù)處理平臺正在成為業(yè)內(nèi)共識。
從根本上解決上述問題，關(guān)鍵一點是要將網(wǎng)管系統(tǒng)中原有的自有、獨享、離散、偏重于當(dāng)前交易應(yīng)用( transaction application)和業(yè)務(wù)管理的專項數(shù)據(jù)，擴充為公有、共享、聚合、兼顧長期分析應(yīng)用( analysis application)和客戶感知的集合數(shù)據(jù)。從體系結(jié)構(gòu)的角度分析，就是要重構(gòu)重建網(wǎng)管系統(tǒng)的數(shù)據(jù)管理層。顧名思義，數(shù)據(jù)管理層負責(zé)各專業(yè)資源、性能和告警數(shù)據(jù)的全面管理和動態(tài)建模，并通過數(shù)據(jù)鏈接將不同類型的數(shù)據(jù)鏈接在一起，最終實現(xiàn)全數(shù)據(jù)的統(tǒng)一管理和分析功能。在網(wǎng)管技術(shù)體系結(jié)構(gòu)上，數(shù)據(jù)管理層位于采集層之上，收集來自采集層的標準化數(shù)據(jù)：位于應(yīng)用層之下，為應(yīng)用層提供統(tǒng)一的接口協(xié)議和信息模型服務(wù)。雖然不同網(wǎng)管系統(tǒng)略有差別，但一般為減少各類數(shù)據(jù)與采集以及應(yīng)用功能的互相過渡依賴，都會引入這一層次。
當(dāng)然，并不是說數(shù)據(jù)管理層改造和革新就會解決所有的問題，而是說作為一個承上啟下的數(shù)據(jù)管理和處理組件，如果能夠?qū)⒃蟹稚⒃诓煌瑢I(yè)網(wǎng)管的數(shù)據(jù)加以匯聚和開放共享，那么就為實現(xiàn)端到端的復(fù)雜業(yè)務(wù)管理、跨專業(yè)數(shù)據(jù)合作、上層經(jīng)營管理、用戶行為感知提供了可行的數(shù)據(jù)基礎(chǔ)和技術(shù)環(huán)境。
3數(shù)據(jù)模型的重構(gòu)
數(shù)據(jù)模型(data model)是數(shù)據(jù)特征的抽象，描述了被管理數(shù)據(jù)的屬性信息、關(guān)系信息等，是構(gòu)建網(wǎng)管系統(tǒng)數(shù)據(jù)管理層的關(guān)鍵，其優(yōu)劣決定了網(wǎng)管系統(tǒng)數(shù)據(jù)存儲、處理和應(yīng)用的一致性、擴展性、易用性和快捷性。
傳統(tǒng)專業(yè)網(wǎng)管以自有資源為主來構(gòu)建數(shù)據(jù)模型：但各自的系統(tǒng)沒有辦法建立跨專業(yè)的數(shù)據(jù)模型，導(dǎo)致無法快速準確實現(xiàn)業(yè)務(wù)的端到端管理，更無法做到客戶感知層面的分析。因此需要在數(shù)據(jù)管理層重新進行數(shù)據(jù)組織和模型構(gòu)建。重構(gòu)后的數(shù)據(jù)模型，不僅應(yīng)該可以有效整合各專業(yè)的數(shù)據(jù)、實現(xiàn)數(shù)據(jù)的標準化和開放共享、全面管控數(shù)據(jù)質(zhì)量，還應(yīng)該具有緩慢變化維技術(shù)對歷史分析實體歸屬變化追溯本源的性能，能夠在諸多不確定的數(shù)據(jù)中發(fā)現(xiàn)確定信息，使得數(shù)據(jù)管理層能夠?qū)λ袛?shù)據(jù)可視、可管和可用。
從當(dāng)前來看，在新一代網(wǎng)管中，數(shù)據(jù)模型不再簡單地僅為本專業(yè)上層應(yīng)用提供數(shù)據(jù)或者存儲數(shù)據(jù)，還需要提供強大的分析能力。之所以在新的數(shù)據(jù)管理層中強調(diào)OLAP（on line analytical processing，聯(lián)機分析處理）的作用，是因為這一技術(shù)可以較好地解決用戶感知、決策支持等傳統(tǒng)專業(yè)網(wǎng)管無法應(yīng)對的問題。
由于數(shù)據(jù)建模的層次、維度、對象和關(guān)系等要素在規(guī)模和復(fù)雜度上大大增加，因此數(shù)據(jù)管理層中的數(shù)據(jù)集合有必要進一步按照來源、類型、目標、應(yīng)用等進行細分，本文暫將其劃分為基礎(chǔ)數(shù)據(jù)域和數(shù)據(jù)匯總域，并針對每一個數(shù)據(jù)域建設(shè)各自的數(shù)據(jù)模型，二者的比較見表1。
4技術(shù)架構(gòu)的混搭
網(wǎng)管正在逐步從設(shè)備和業(yè)務(wù)的管理邁向面向用戶感知、經(jīng)營管理的新階段，因此必須對更加廣泛的、粒度更細的數(shù)據(jù)加以采集、處理、分析和挖掘。數(shù)據(jù)管理層中不僅有傳統(tǒng)網(wǎng)管所需資源、配置、告警、用戶信息等，還需要引入信息量更豐富、涵蓋環(huán)節(jié)更全面的信令數(shù)據(jù)，這就導(dǎo)致了新一代網(wǎng)管系統(tǒng)數(shù)據(jù)管理層處理的數(shù)據(jù)量遠遠大于傳統(tǒng)網(wǎng)管。這里以4G客戶對覆蓋與上網(wǎng)速率的主觀感知分析的應(yīng)用需求為例。實現(xiàn)這一應(yīng)用功能，需要采集大量LTESl-MME、S6a、Sl-U、Uu、X2等接口信令，還要輔以Gn、Mc等信令數(shù)據(jù)。根據(jù)推算每萬用戶忙時生成的信令(XDR)量大概在200～400 GB/天，那么按照1 000萬戶4G用戶考慮，每天需要處理的原始數(shù)據(jù)量就會達到195~390 TB，而基礎(chǔ)數(shù)據(jù)域保存30天的數(shù)據(jù)量將達到5.7～11.4 PB、數(shù)據(jù)倉庫層存儲周期內(nèi)的數(shù)據(jù)也將達到1～2 PB。這一數(shù)據(jù)規(guī)模已經(jīng)超出了運營商一般省份所有專業(yè)網(wǎng)管的存儲數(shù)據(jù)之和。這是“小型機+關(guān)系型數(shù)據(jù)庫+集中存儲”的傳統(tǒng)技術(shù)架構(gòu)根本無法實現(xiàn)的。進而言之，只有在數(shù)據(jù)管理層引人大數(shù)據(jù)技術(shù)，才可能在有效時限內(nèi)完成如此大規(guī)模的數(shù)據(jù)的處理。
對于大數(shù)據(jù)技術(shù)，如Hadoop、MPP的起源、定義、原理、部件組成的研究材料較多，因此本文更多地是從技術(shù)架構(gòu)的角度對大數(shù)據(jù)技術(shù)進行探討。
首先面臨的問題是，在數(shù)據(jù)管理層的技術(shù)架構(gòu)中，單一的大數(shù)據(jù)技術(shù)是否能夠滿足要求。下面從起源初衷、擅長領(lǐng)域和工程造價等因素人手進行探討。
Hadoop產(chǎn)生的初衷實際上與兩個因素有關(guān)，一是互聯(lián)網(wǎng)數(shù)據(jù)分析；二是數(shù)據(jù)的海量性。因此在場景上，Hadoop非常適用于基于海量非結(jié)構(gòu)化、結(jié)構(gòu)化數(shù)據(jù)的分布式數(shù)據(jù)簡單快速處理查詢；而不太適合做復(fù)雜數(shù)據(jù)模型、復(fù)雜關(guān)聯(lián)分析以及按照網(wǎng)元、空間、時間、業(yè)務(wù)做各維度的數(shù)據(jù)匯聚和挖掘分析，而這些正是另一個大數(shù)據(jù)技術(shù)-MPP(massively parallel processing)可以大展身手的領(lǐng)域。除此之外，MPP在OLAP方面的優(yōu)勢也非常突出，如有大量成熟完備的第三方工具可以與之集成、完全支持SQL等。
而從實現(xiàn)角度來看，MPP必須預(yù)先為訪問做優(yōu)化（分區(qū)、索引等），造成其數(shù)據(jù)裝載效率較低；同時在運營商領(lǐng)域，當(dāng)前Hadoop集群節(jié)點數(shù)已經(jīng)超過1 000臺以上；而MPP的節(jié)點數(shù)很少能夠擴展到300臺；此外從采購和建設(shè)成本的角度來看，Hadoop綜合成本在5 000元/TB；而基于通用x86架構(gòu)的MPP成本在3萬~5萬元/TB，是Hadoop成本的數(shù)倍。
總之，在網(wǎng)管系統(tǒng)數(shù)據(jù)管理層的技術(shù)架構(gòu)選擇上，Hadoop、MPP數(shù)據(jù)庫以及傳統(tǒng)數(shù)據(jù)庫并非是互相取代的關(guān)系，而是取長補短、互為補充的，因此采用混搭架構(gòu)是當(dāng)前實現(xiàn)數(shù)據(jù)管理層方案的可行之選，如圖1所示。
5未來演進的設(shè)想
網(wǎng)管系統(tǒng)數(shù)據(jù)管理層在引人大數(shù)據(jù)技術(shù)后，成為管理和加工運營商管道中全面、真實、實時、權(quán)威、海量數(shù)據(jù)的超級引擎。不僅可以在0域大展身手，而且還可以通過監(jiān)測、聚合、分析等手段，挖掘更多的信息為B域甚至M域服務(wù)（0域數(shù)據(jù)一般占到整體數(shù)據(jù)規(guī)模的85%以上）。于是這就出現(xiàn)另外一個問題，能否將網(wǎng)管系統(tǒng)的數(shù)據(jù)管理層建設(shè)成為一個為運營商全局服務(wù)的企業(yè)級大數(shù)據(jù)共享服務(wù)平臺，讓網(wǎng)管數(shù)據(jù)逐步成為整個公司而非某個部門的核心
資產(chǎn)。大數(shù)據(jù)共享服務(wù)平臺既可以推動運營商IT 一體化和BOM三域融合戰(zhàn)略落地，又可以利于它開展跨企業(yè)、跨領(lǐng)域的數(shù)據(jù)合作。這一設(shè)想雖然優(yōu)勢明顯，但面臨的困難也是巨大的。
首先是技術(shù)隊伍的問題。和互聯(lián)網(wǎng)公司不同，運營商在網(wǎng)管的自運營與核心自研能力方面還處于一個比較初級的水平，較為嚴重地依賴于第三方廠商。如果把原有0域中的數(shù)據(jù)管理層拓展為一個面向所有部門、甚至合作伙伴的平臺，則各方訴求的快捷準確響應(yīng)要求對數(shù)據(jù)管理層的運營者和研發(fā)人員都提出極高的要求。其次，運營商部門之間已經(jīng)形成了較為完整和清晰的分工界面。如果由某個現(xiàn)有部門來籌建和運維大數(shù)據(jù)共享服務(wù)平臺，那么必然會造成其他部門在優(yōu)先級別、服務(wù)水平上的擔(dān)心。另外從技術(shù)上看，當(dāng)前大數(shù)據(jù)處理中多租戶等相關(guān)資源分配和權(quán)限管理方面的一些問題還在演進和研究的過程中。因此從現(xiàn)狀來看，網(wǎng)管中的數(shù)據(jù)管理層雖然在定位、功能、涵蓋范圍、技術(shù)架構(gòu)與企業(yè)級大數(shù)據(jù)共享服務(wù)平臺有高度的吻合，但是在管理上卻有必要成立專職的運營研發(fā)部門，在技術(shù)上也有諸多困難。
6 結(jié)束語
網(wǎng)管發(fā)展到今天，海量數(shù)據(jù)的統(tǒng)一建模、統(tǒng)一管理、統(tǒng)一服務(wù)等要求正在成為一種必要，而大數(shù)據(jù)技術(shù)的出現(xiàn)使之成為一種可行�；诖髷�(shù)據(jù)技術(shù)搭建的數(shù)據(jù)管理層平臺，為網(wǎng)管系統(tǒng)數(shù)據(jù)架構(gòu)的分布式、標準化、集中化奠定了基礎(chǔ)，在數(shù)據(jù)向高緯度內(nèi)聚的同時，促進數(shù)據(jù)與應(yīng)用的解耦，為網(wǎng)管未來的應(yīng)用開發(fā)模式奠定了堅實基礎(chǔ)。
7摘要：
數(shù)據(jù)管理層是運營商網(wǎng)管系統(tǒng)中數(shù)據(jù)處理和管理的核心。從網(wǎng)管現(xiàn)狀和問題分析人手，提出打破專業(yè)網(wǎng)管之間的隔離、推進數(shù)據(jù)的公有共享，進一步細分數(shù)據(jù)管理層的數(shù)據(jù)域和重構(gòu)數(shù)據(jù)模型，并使用Hadoop+MPP混搭的技術(shù)架構(gòu)建設(shè)數(shù)據(jù)管理層平臺，為網(wǎng)管系統(tǒng)的規(guī)劃和設(shè)計指明了方向。最后，還對數(shù)據(jù)管理層平臺和企業(yè)級大數(shù)據(jù)共享服務(wù)平臺的關(guān)系進行了論述。
下一篇:返回列表
