孫紅恩（中國移動通信集團設計院有限公司，北京 100080）

?

電信運營商省級大數(shù)據(jù)平臺建設方案

孫紅恩
（中國移動通信集團設計院有限公司，北京 100080）

摘 要大數(shù)據(jù)時代的到來，讓傳統(tǒng)電信運營商面臨不小機遇。本文總結(jié)當前運營商IT支撐平臺建設和企業(yè)數(shù)據(jù)分布情況，分析國內(nèi)運營商大數(shù)據(jù)發(fā)展所處的階段；給出大數(shù)據(jù)平臺建設架構和技術方案，并對電信運營商大數(shù)據(jù)平臺建設方案中的關鍵點進行研究。

關鍵詞大數(shù)據(jù)平臺；IT支撐平臺；運營商；Hadoop

近年來，以移動終端為基礎的移動互聯(lián)網(wǎng)發(fā)展迅猛，互聯(lián)網(wǎng)終端及廠商在大數(shù)據(jù)技術驅(qū)動下，占據(jù)了信息服務的制高點，全面擠壓傳統(tǒng)通信企業(yè)的利潤，使通信行業(yè)面臨前所未有的壓力，但也是通信行業(yè)的一次發(fā)展機遇。

電信運營商網(wǎng)管支撐系統(tǒng)、業(yè)務支撐系統(tǒng)和管理信息系統(tǒng)經(jīng)過多年的建設和積累，分別匯集了企業(yè)內(nèi)多個領域的數(shù)據(jù)，支撐了公司的生產(chǎn)經(jīng)營工作。但是各系統(tǒng)數(shù)據(jù)未整合、分散存放，支撐建設被動響應、需求臨時性定制的狀況越來越突出?，F(xiàn)有支撐系統(tǒng)的軟硬件架構難以充分發(fā)揮自身擁有大數(shù)據(jù)的價值，研究和探討適合運營商的大數(shù)據(jù)平臺建設方案具有重要的理論和實際意義。

1　運營商大數(shù)據(jù)平臺建設背景

1.1 運營商大數(shù)據(jù)現(xiàn)狀及存在問題

為支撐生產(chǎn)運營，目前運營商已經(jīng)獨立建設了經(jīng)分系統(tǒng)、精準營銷平臺、流量經(jīng)營分析系統(tǒng)、網(wǎng)絡綜合分析平臺、新媒體分析試點平臺等多套分析型系統(tǒng)，數(shù)據(jù)源來自BSS/OSS/MSS三大支撐域以及互聯(lián)網(wǎng)。

公司雖然建設了一些分析型系統(tǒng)，但是我們擁有“大數(shù)據(jù)”，卻只使用了“小數(shù)據(jù)”，各平臺對數(shù)據(jù)的采集、分析處理以及應用各有側(cè)重，煙囪林立，難以發(fā)揮大數(shù)據(jù)價值，且軟硬件架構（包括計算能力、存儲能力等）并非從企業(yè)級大數(shù)據(jù)的技術角度設計。

（1）數(shù)據(jù)分散：目前各類數(shù)據(jù)分散在BSS/OSS/ MSS三大支撐域中，數(shù)據(jù)分散、相互隔離。

（2）重復采集存儲：各系統(tǒng)不同階段獨立建設，存在數(shù)據(jù)重復采集和重復存儲問題。

（3）挖掘能力不足：數(shù)據(jù)不全，無法形成跨專業(yè)、跨域的數(shù)據(jù)關聯(lián)，無法呈現(xiàn)端到端全局數(shù)據(jù)，價值不能深度被挖掘。

（4）應用支撐能力不足：數(shù)據(jù)共享與開放能力不足，不能有效支撐應用。

考慮現(xiàn)有各平臺仍需要支撐現(xiàn)網(wǎng)生產(chǎn)經(jīng)營活動，因此建議采取“先立后破”的方式啟動公司企業(yè)級大數(shù)據(jù)中心的建設。

1.2 大數(shù)據(jù)平臺建設必要性

（1） 海量數(shù)據(jù)處理壓力：海量數(shù)據(jù)處理和存儲，已經(jīng)超出傳統(tǒng)主流軟件工具的處理能力。

（2） 數(shù)據(jù)層面：OSS數(shù)據(jù)沒有全量接收，缺乏集中、統(tǒng)一的數(shù)據(jù)處理。各部門分別探索的工作模式，不適應大數(shù)據(jù)對全量大規(guī)模數(shù)據(jù)的天然要求，從而導致IT整體支撐能力發(fā)展受到制約，整體規(guī)劃缺乏。

（3） 平臺層面：IT支撐缺乏競爭力，業(yè)務支撐能力不足，缺少企業(yè)級數(shù)據(jù)治理、統(tǒng)一數(shù)據(jù)平臺、數(shù)據(jù)挖掘分析相匹配的組織架構和管理流程，現(xiàn)有的工作模式已經(jīng)不適應大數(shù)據(jù)的發(fā)展需要。

（4） 業(yè)務層面：大數(shù)據(jù)應用價值亟待推廣。雖已意識到數(shù)據(jù)分析的重要性，但思維未轉(zhuǎn)換，多為原有工作的延伸，難以支撐商業(yè)模式的創(chuàng)新，最終導致大數(shù)據(jù)文化的缺失。

（5） 運營層面：人員分散、能力未充分聚合?？蛻粞芯磕芰Σ蛔?，缺乏對客戶精確洞察和行為挖掘，無法還原其真實需求，且信息和知識無法對外開放。

1.3 大數(shù)據(jù)平臺發(fā)展階段分析

通過對大數(shù)據(jù)系統(tǒng)發(fā)展歷程分析，大致可將其發(fā)展分為以下3個階段。

（1）數(shù)據(jù)跨域共享階段：拉通企業(yè)各IT系統(tǒng)，充分發(fā)揮數(shù)據(jù)的價值，支撐以數(shù)據(jù)為核心驅(qū)動管理變革，構建企業(yè)精細化、智能化運營管理的生態(tài)服務體系，實現(xiàn)“超細分”、“微營銷”、“精服務”的企業(yè)戰(zhàn)略。

（2）對內(nèi)能力提升階段：從通過網(wǎng)絡分析提升網(wǎng)絡質(zhì)量、通過市場分析提升營銷能力、通過行為分析提升客戶體驗、通過平臺分析優(yōu)化操作流程等角度，大力支持運營商內(nèi)部各業(yè)務需求部門的各類分析應用需求。

（3）對外產(chǎn)品服務能力階段：在確?？蛻粜畔踩那疤嵯?，大力拓展大數(shù)據(jù)的對外服務，實現(xiàn)運營商大數(shù)據(jù)的貨幣化，運營商的數(shù)據(jù)比互聯(lián)網(wǎng)企業(yè)的數(shù)據(jù)更多了真實性、準確性，對客戶的分析更為精準，逐步開放運營商大數(shù)據(jù)分析的結(jié)果，拓展大數(shù)據(jù)在廣告營銷、輿情分析等多領域的對外服務能力。

國外運營商大數(shù)據(jù)系統(tǒng)建設起步較早，主流運營商已經(jīng)可以提供數(shù)據(jù)產(chǎn)品與服務，已經(jīng)進入第3階段，如法國電信客戶維系、沃達豐愛爾蘭公司的Tellabs、西班牙電信的智慧足跡、Verizon精準營銷以及德國電信智能網(wǎng)絡等。國內(nèi)運營商也在積極推進大數(shù)據(jù)平臺與體系的規(guī)劃建設。

2　大數(shù)據(jù)平臺建設方案

2.1 大數(shù)據(jù)平臺總體架構

企業(yè)大數(shù)據(jù)平臺統(tǒng)一采集數(shù)據(jù)、存儲數(shù)據(jù)、計算數(shù)據(jù)、分配數(shù)據(jù)、共享資源，服務于企業(yè)管理、精細營銷、數(shù)據(jù)運營、價值發(fā)現(xiàn)等各種領域，其架構如圖1所示。

圖1　企業(yè)大數(shù)據(jù)平臺總體架構

整個方案體系架構分為應用層、數(shù)據(jù)層和采集層。

（1） 統(tǒng)一應用管理：通過統(tǒng)一的Portal集成框架，將各類專題分析、自助服務、線上運營、數(shù)據(jù)開放等能力進行集成，服務于企業(yè)的管理、營銷、運營和創(chuàng)新。

（2） 統(tǒng)一數(shù)據(jù)存儲和共享：實現(xiàn)企業(yè)跨域數(shù)據(jù)的統(tǒng)一存儲、計算和共享，并實現(xiàn)對用戶事件的感知、分析和實時營銷支持，明確采用唯一的企業(yè)級Hadoop平臺；通過分布式內(nèi)存數(shù)據(jù)庫集群提供標簽查詢、KPI查詢；通過多租戶資源池支撐各類業(yè)務應用。

（3） 統(tǒng)一數(shù)據(jù)采集：采集業(yè)務域、網(wǎng)絡域、管理域、互聯(lián)網(wǎng)域數(shù)據(jù)以及第三方數(shù)據(jù)。

2.2 大數(shù)據(jù)平臺功能架構

2.2.1 數(shù)據(jù)采集及調(diào)度

大數(shù)據(jù)平臺主要完成數(shù)據(jù)的統(tǒng)一采集和處理。大數(shù)據(jù)平臺的統(tǒng)一采集，需要針對多樣化的數(shù)據(jù)進行采集和清洗，需要兼顧現(xiàn)有經(jīng)分系統(tǒng)相關數(shù)據(jù)源的采集能力，以及系統(tǒng)自身的開放性。構建統(tǒng)一調(diào)度模塊，負責整個大數(shù)據(jù)系統(tǒng)的任務調(diào)度管理、調(diào)用和監(jiān)控，并通過調(diào)用接口與ETL計算集群進行交互。

2.2.2 數(shù)據(jù)接口規(guī)劃企業(yè)級統(tǒng)一數(shù)據(jù)采集和調(diào)度作為后續(xù)大數(shù)據(jù)中心的數(shù)據(jù)流轉(zhuǎn)樞紐，實現(xiàn)按需平滑接入數(shù)據(jù)源，經(jīng)過文件解壓、文件合并和拆分、文件級校驗、數(shù)據(jù)級校驗、清洗、轉(zhuǎn)換、關聯(lián)、匯總等步驟對接入數(shù)據(jù)統(tǒng)一進行處理，加載到大數(shù)據(jù)平臺，并負責大數(shù)據(jù)平臺內(nèi)部數(shù)據(jù)統(tǒng)一調(diào)度。

企業(yè)級統(tǒng)一數(shù)據(jù)采集和調(diào)度作為后續(xù)大數(shù)據(jù)中心的數(shù)據(jù)流轉(zhuǎn)樞紐，同時承擔對上層應用提供數(shù)據(jù)服務的能力，服務接口調(diào)用各類數(shù)據(jù)接口（用戶統(tǒng)一視圖、標簽視圖等），實現(xiàn)按需訪問數(shù)據(jù)。

2.2.3 數(shù)據(jù)流規(guī)劃

大數(shù)據(jù)平臺作為大數(shù)據(jù)中心的數(shù)據(jù)流轉(zhuǎn)樞紐，承擔了從數(shù)據(jù)源加載BOM以及互聯(lián)網(wǎng)四域數(shù)據(jù)到大數(shù)據(jù)平臺、大數(shù)據(jù)平臺內(nèi)部數(shù)據(jù)的交互、以及數(shù)據(jù)在流轉(zhuǎn)過程中的數(shù)據(jù)抽取、清洗和加載等三大部分任務。數(shù)據(jù)流向規(guī)劃如圖2所示。

圖2中所示從下至上，從左至右分別說明（與本工程相關的數(shù)據(jù)流）。

（1）CRM/BOSS業(yè)務數(shù)據(jù)、運行狀態(tài)日志數(shù)據(jù)通過CRM/BOSS系統(tǒng)提供，由ETL采集；CRM業(yè)務事件數(shù)據(jù)通過Socket（或類似接口）進行流數(shù)據(jù)采集。

圖2　數(shù)據(jù)流規(guī)劃示意圖

（2）Gn口/A口等信令日志數(shù)據(jù)通過日志留存系統(tǒng)提供，經(jīng)統(tǒng)一采集后由大數(shù)據(jù)處理平臺進行整合處理，其中整合后需要爬取的URL列表，通過Discp推送（或者ftp方式）提供給網(wǎng)絡爬蟲（復用現(xiàn)有能力）進行數(shù)據(jù)爬取。

（3）大數(shù)據(jù)處理平臺整合后的數(shù)據(jù)分別加載到核心數(shù)據(jù)倉庫和MPP數(shù)據(jù)分析集群。

（4）大數(shù)據(jù)處理平臺采集來自網(wǎng)頁分析（復用現(xiàn)有能力）后的URL列表標簽信息，用于與信令日志數(shù)據(jù)的整合，最終將整合后的網(wǎng)絡信令數(shù)據(jù)加載到上網(wǎng)行為分析（復用現(xiàn)有能力）進行后續(xù)深度分析。

（5）關于網(wǎng)絡爬蟲和網(wǎng)頁分析的接口需按照集團公司集中化經(jīng)分下發(fā)的URL列表格式進行設計，以便于后續(xù)與集團公司一級系統(tǒng)進行接口整合。

2.2.4 數(shù)據(jù)生命周期管理

對于大數(shù)據(jù)平臺內(nèi)存儲的數(shù)據(jù)進行有效全面的梳理，實現(xiàn)對于不同數(shù)據(jù)實體和內(nèi)容數(shù)據(jù)生命周期的合理規(guī)劃。

提供可視化的管理服務界面，對于各類數(shù)據(jù)支持按不同級別的生命周期進行監(jiān)控管理，對于過期數(shù)據(jù)定期提示清理。

2.2.5 數(shù)據(jù)可視化查詢

對于大數(shù)據(jù)平臺內(nèi)存儲的數(shù)據(jù)提供可視化的數(shù)據(jù)查詢界面。支持對大數(shù)據(jù)平臺內(nèi)存儲的全部數(shù)據(jù)模型和全部數(shù)據(jù)周期的數(shù)據(jù)內(nèi)容通過可視化SQL界面（如類似PL/SQL工具的界面）進行數(shù)據(jù)的查詢，并支持通過該界面進行Join、Group by等操作。

支持通過該界面查詢某個數(shù)據(jù)對象在大數(shù)據(jù)平臺不同數(shù)據(jù)周期的實際存儲位置。

表1　數(shù)據(jù)源數(shù)據(jù)類型及數(shù)據(jù)量

2.3 關鍵考慮因素

2.3.1 技術選型分析

隨著運營商集約化、互聯(lián)網(wǎng)化等策略的推進，大數(shù)據(jù)平臺面臨的數(shù)據(jù)處理體量急劇增長。以某省運營商為例，其大數(shù)據(jù)平臺2015年面臨的數(shù)據(jù)處理需求單如表1所示。

同時為滿足公司經(jīng)營需求，大數(shù)據(jù)平臺需要支撐實時處理和批量處理等多種計算場景需求。面對如此龐大的數(shù)據(jù)規(guī)模和支撐需求，典型解決方案對比如表2所示。

結(jié)合系統(tǒng)處理性能、投資成本以及技術成熟性等多方面因素考慮，目前階段，運營商大數(shù)據(jù)平臺建議采用以Hadoop為核心的融合化技術方案。現(xiàn)有傳統(tǒng)數(shù)據(jù)倉庫、MPP數(shù)據(jù)倉庫可作為大數(shù)據(jù)平臺的數(shù)據(jù)服務對象，主要專注企業(yè)經(jīng)營分析或?qū)I(yè)數(shù)據(jù)集市應用。

2.3.2 硬件選型分析

運營商大數(shù)據(jù)平臺搭建主要分為兩種：批處理型服務器和流處理型服務器?？紤]到運營商大數(shù)據(jù)平臺存儲規(guī)模較大，且各省普遍存在機房基礎資源緊張的問題，在平臺搭建時要控制節(jié)點數(shù)量，繞開跨機房等問題，在硬件選型時推薦配置較高機器。

（1）批處理型服務器：以平衡計算和存儲為目的，建議采用機架式服務器，硬盤插槽大于10個SATA，最好12個以上，單盤建議選擇量產(chǎn)的2 TB；內(nèi)存采用量產(chǎn)內(nèi)存，目前建議單條8 GB，內(nèi)存槽不少于16個，配置128 GB以上內(nèi)存；配置2顆CPU，CPU建議選擇高性價比CPU，不單純追求計算能力。

表2　解決方案對比分析

（2）流處理型服務器：以保證處理速度和內(nèi)存容量為目的，建議采用4節(jié)點以上的機架服務器，單節(jié)點硬盤不多于2個SAS硬盤，單盤建議選擇量產(chǎn)的300 GB，單節(jié)點內(nèi)存采用量產(chǎn)內(nèi)存，目前建議單條8 GB，內(nèi)存槽不少于8個；單節(jié)點CPU建議配置2顆，CPU建議選擇高性價比CPU。

2.3.3 集成模式分析

根據(jù)企業(yè)級大數(shù)據(jù)平臺的建設，從技術選型上有一體機、混搭和電商定制3類集成模式。

（1）一體機模式：采用軟硬件一體的商業(yè)產(chǎn)品，提升系統(tǒng)穩(wěn)定性，降低建設周期。

（2）混搭模式：采用軟硬件分離、商業(yè)軟件和開源軟件混搭的模式，保持一定的靈活性。

表3　集成模式分析對比表

（3）電商定制模式：對軟硬件深度定制，投入技術團隊持續(xù)跟蹤技術發(fā)展。保持核心能把控。

如表3所示，經(jīng)過對3類模式的分析，綜合考慮平臺建設和投入的關系，推薦采用混搭模式。

3　結(jié)論

電信運營商的大數(shù)據(jù)平臺建設與大數(shù)據(jù)應用方興未艾，研究和探討適合運營商的大數(shù)據(jù)平臺架構具有重要的理論和實際意義。本文根據(jù)電信運營商的業(yè)務特點，研究并給出了一種集約、融合、開放的運營商大數(shù)據(jù)平臺架構設計方案。在實際搭建大數(shù)據(jù)平臺時，應考慮運營商當前IT系統(tǒng)架構的復雜性，根據(jù)不同應用場景以及技術的多樣性，對系統(tǒng)組網(wǎng)方案、管理方案等技術細節(jié)進行深一步的探討。后續(xù)將持續(xù)結(jié)合各運營商大數(shù)據(jù)工程建設和應用實踐進行研究總結(jié)。

The big data platform construction solution of telecom operators

SUN Hong-en
(China Mobile Group Design Institute Co., Ltd., Beijing 100080, China)

AbstractBig data age brings new opportunities to traditional telecom operators. In this thesis, IT supporting platform construction and enterprise data distribution situation of current telecom operators were summarized, the phase of big data development of domestic telecom operators was analyzed, big data platform construction infrastructure and technical solution were proposed, key points in the big data platform construction solution of telecom operators were researched.

Keywordsbig data platform; IT supporting platform; telecom operator; Hadoop

收稿日期：2015-06-29

中圖分類號TN915

文獻標識碼A

文章編號1008-5599（2016）02-0034-06