電信運營商大數據應用典型案例分析

上海郵電設計咨詢研究院有限公司 上海 200092

1 大數據技術簡介

隨著移動互聯網、云計算、物聯網技術和業務的發展，全球數據量正在呈爆炸性指數級增長。根據IDC發布的報告顯示，2012年全球數據量約為2.8ZB，并以大約每兩年翻一番的速度增長，預計到2020年，全球將產生35ZB的數據量。這意味著我們正進入大數據時代。

維基百科將大數據定義為:大數據是很多各種數據集匯合起來的數據集合，規模非常大并且復雜，以至于很難用常規的數據管理工具或傳統的數據管理技術來處理這些數據。Facebook、Twiteer、微博等各類社交網絡，各種智能終端，醫療影像、監控錄像等各類視頻以及遍布全球各個角落的各種傳感器，無一不是數據來源。大量新數據源的出現導致非結構化的數據迅猛增長，占比超過80%，超越了傳統關系型數據庫的管理能力，使得大數據的存儲、管理和處理很難利用傳統的關系型數據庫去完成，進而無法提取個中價值[1]。

以Hadoop為代表的大數據技術應運而生，它是一種非關系型數據庫系統及分布式運算架構。近幾年，Facebook、Google、Amazon、Yahoo、阿里巴巴和百度等開始了大數據化的進程，他們依托自己的數據優勢，采取靈活深入的分析方法進行基于大數據的挖掘，從中摸索嶄新的商業模式[2]。

2 大數據驅動電信運營商轉型

當前，移動互聯網OTT業務的快速成長，給電信運營商的基礎語音業務和短信業務帶來了不小沖擊，運營商緩慢增長的網絡流量收入和網絡建設成本之間不斷增加的剪刀差，正不斷侵蝕著運營商的利潤。面對互聯網公司的激烈競爭，運營商要如何做才能扭轉逐步被“管道化”的趨勢?

在日常網絡運營中，運營商積累了大量用戶數據，這些數據相比較互聯網公司的用戶數據有著明顯的優勢:一是用戶實名，真實詳細的個人基本信息，比如年齡、性別、工作單位、職位等;二是位置信息，運營商通過技術手段，能輕易獲得通話者的地理位置，且精確度非常高;三是通話信息，包括話費、對方信息等。這些數據正是最具戰略性的資產，使得運營商在利用大數據方面具有天然優勢。但是，沒有管理的數據就像埋藏在地下的礦產，價值無法體現。運營商當前由于沒有全局性大數據管理體系，現存數據呈現出碎片、割裂和孤島狀的特點，難以深入應用。

對于大數據的應用已經成為一種必然趨勢，其發展勢頭非常強勁。大數據驅動不僅是電信運營商增強業務能力和網絡能力的抓手，更重要的是，大數據驅動能促使電信運營商切實學習和領會互聯網的思維，真正實現以用戶為中心，多維度了解用戶，實現數據化運營，借助大數據中蘊含的價值和動力將轉型發展落到實處。

3 電信運營商大數據發展遇到的問題

我國電信運營商由于技術、數據系統限制，用戶隱私和商業模式不明確等問題，目前大數據應用只處在探索階段，主要遇到以下問題。1)系統分散建設，難以實現資源共享。經營分析、信令監測、上網日志留存等眾多數據系統分專業建設，其中部分系統還分省建設，造成資源無法共享。2)數據處理種類多，單一技術難以實現。各大數據系統數據模型不統一，只具備結構化數據處理能力，無法支持非結構化、半結構化數據處理，無法滿足互聯網業務發展要求。3)如何避免隱私泄露。人們對于隱私問題越來越重視，數據公司掌握大量數據和數據制造者要求隱私權之間的矛盾，使得大數據應用變得困難。4)尚未確立商業運營模式。運營商掌握的數據很多，但是這些數據應該怎樣應用、給誰用、應用收益是否可以抵消數據開發分析的成本，這一系列問題也讓運營商非常困擾[3]。

4 電信運營商大數據策略

電信運營商大數據策略的核心在于從這些數據中挖掘價值，因關注點不同可區分為以下四種類型。第一，在市場層面，通過大數據分析用戶行為，改進產品設計，并通過用戶偏好分析，及時、準確且有針對性地開展營銷與維系，不斷改善用戶體驗，增加用戶信息消費以及對運營商的黏度;第二，在網絡層面，通過大數據分析網絡流量、流向變化趨勢，及時調整資源配置，同時還可以分析網絡日志，進行全網優化，不斷提升網絡質量和網絡利用率;第三，在企業經營層面，可以通過業務、資源、財務等各類數據的綜合分析，快速準確地確定公司經營管理和市場競爭策略;第四，在業務創新層面，在保障用戶隱私的前提下，可以對數據進行深度加工，對外提供數據分析服務，為企業創造新的價值。這樣，大數據將助力運營商實現從網絡服務提供商向信息服務提供商的轉變[4]。

5 大數據分析處理應用平臺

5.1 建設背景

以上海某電信運營商為例，2013年流量經營目標十分艱巨，要求月戶均流量達到160M，流量經營收入達到23億。面對如此艱巨任務，采用傳統流量包營銷模式已經不能滿足市場經營分析和前端營銷的需求。并且，面對每天以TB級速度增長的業務數據，該運營商在如何提升分析和管理能力方面遇到較大的瓶頸。另外，企業各類數據分散在各個系統中，缺乏集約化的數據管理和應用手段，導致了需求響應混亂無序，數據安全風險增大，數據無法有效進行關聯從而形成數據資產。

針對以上問題，急需設計一套大數據分析處理應用平臺，作為現有數據倉庫系統的有益補充，形成企業大數據統一匯聚平臺。

5.2 建設目標

大數據分析處理應用平臺(以下簡稱大數據平臺)的建設目標主要分為以下三點。1)通過對移動互聯網上網行為數據、固網寬帶的數據分析和快速分類，將有價值的用戶行為信息進行再次整合后，推送到針對性營銷平臺和客戶維系挽留平臺，完成各個渠道的主動派單，實現快速營銷。2)基于移動互聯網流量營銷功能，提升數據支撐能力，提供流量數據查詢。3)提升EDA現有用戶行為數據分析中時點統計分析能力和深化分析維度。

5.3 平臺技術架構

5.3.1 平臺技術方案要求

大數據平臺面向企業內外部提供數據服務，要求系統必須具備高并發、實時動態數據獲取和更新、海量數據的高效率存儲和訪問、高可擴展性和高可用性等特性，傳統的數據處理技術已經無法很好應對新的挑戰。本平臺引入Hadoop等分布式解決方案以提升系統海量數據和高并發任務處理性能，提升系統可擴展性。平臺支持離線批量處理、流式處理、在線處理、交互式探索等多種計算框架，具備多租戶模式支撐數據應用基礎能力。

5.3.2 基礎存儲、計算平臺技術方案分析

1)基礎平臺技術架構分析及建議。針對海量數據的分析處理，目前業界主流解決方案有以下幾種，如表1所示。①傳統商業數據庫方案:由高性能的主機與大容量存儲組成，通常為UNIX服務器＋存儲磁盤陣列＋傳統關系型數據庫的解決方案。②數據倉庫一體機方案:基于一體機的BI集成化解決方案，一體機含大數據服務器、大數據存儲、數據處理軟件等。③基于X86開放平臺的MPP海量數據方案:采用海量數據處理軟件，基于X86服務器的大規模并行處理解決方案。④基于X86開放平臺的Hadoop為代表的NoSQL分布式方案(通常具有如下特點:高性能、海量存儲、高擴展性、高可用性):采用Hadoop架構，基于X86服務器的大規模分布式解決方案。

表1 體系架構比較

本平臺采用以Hadoop為代表的分布式架構解決方案，原因如下。

①Hadoop等分布式架構通常用于非結構化/半結構化數據處理，已被廣泛應用于多種大數據應用場景，成為業界大數據處理的最主流解決方案之一，具有可靠、高效、可伸縮的特點。另外，Hadoop等分布式架構可以解決系統的I/O問題，通過各服務器的列式數據的關聯，并發生成數據，可解決海量數據的關聯、入庫、查詢、共享等需要。

②Hadoop等分布式解決方案，已有成熟的組件適應各應用場景。如:Hadoop中可采用HDFS存儲層存儲、Hive方式關聯入庫、HBASE方式查詢;具備可擴展性高的特點，并支持數據節點在線調整，擴展更多應用。

③高性能:采用分布式存儲、并行計算技術，充分利用設備性能，提升數據處理速度，避免傳統方案數據庫海量數據處理瓶頸。

④高可靠性:多任務并行計算、數據冗余存儲，有效避免設備單點故障，提供高可靠服務。

⑤高擴展性:X86架構可以通過增加節點，完美支持計算和存儲能力的線性擴容。

⑥高性價比:利用低成本的基于X86的主機設備，有效降低一次性投入成本，更能支持小成本的平滑升級與擴容。

⑦數據源采用非結構化/半結構化數據處理，有利于未來進行各種業務的擴展，有效提高數據的可用性。

2)開源二次開發版本/商業版本對比分析及建議。基于Hadoop的架構特性及平臺需求的多樣化，業界有開源二次開發版本及商業版本的使用情況，對比如表2所示。綜合考慮投資額、業界使用案例等因素，本平臺采用開源二次開發版本。在實際建設中，需重點評估、考核支撐廠家的開發、支撐、服務能力，以保障平臺未來的運營。

3)Hadoop版本對比分析及建議。目前主流的開源Hadoop版本分為Hadoop1.0、Hadoop2.0。Hadoop源代碼可分為Apache版本和CDH版本，比較如表3所示。

①Hadoop1.0仍存在單點故障的問題;Hadoop2.0已消除單點故障(目前為2.2版本，Hadoop2.4版本即將開放)。②相比CDH版本，Apache版本多部門版本并行開發，更新速度較快，及時發布補丁和更新，因更新速度較快對運維能力要求較高。③開源amban管理模塊采用開源模式，可以基于此進行二次開發。

表2 二次開發版本/商業版本對比

表3 Hadoop版本選型對比

綜上所述，建議本平臺采用基于Hadoop2.0以上開源版本進行二次開發的Hadoop版本。

4)Spark框架及支持建議。

①Spark與Hadoop的對比。Spark是UC Berkeley AMP lab所開源的類Hadoop MapReduce的通用并行計算框架，擁有Hadoop MapReduce所具有的優點;但不同于MapReduce的是，Spark的中間數據可以保存在內存中，對于迭代運算效率更高，更適合于迭代運算比較多的ML和DM運算。

Hadoop只提供了Map和Reduce兩種操作類型，而Spark提供了很多種數據集操作類型，比如map、filter、flatMap、sample、groupByKey、reduceByKey、union、join、cogroup、mapValues、sort和partionBy等，同時還提供Count、collect、reduce、lookup和save等多種actions操作。這些多種多樣的數據集操作類型，給上層應用的開發者提供了方便。各個處理節點之間的通信模型不再像Hadoop那樣是唯一的Data Shuffle模式，用戶可以命名、物化、控制中間結果的存儲和分區等;因此，Spark編程模型比Hadoop更靈活[5]。

②Spark與Hadoop的結合。Spark可以直接對HDFS進行數據的讀寫，同樣支持Spark on Yarn;Spark可以與MapReduce運行于同集群中，共享存儲資源與計算;數據倉庫Shark實現上借用Hive，幾乎與Hive完全兼容。讓Spark運行于Yarn上與Hadoop共用集群資源可以提高資源利用率。

③Spark支持建議。考慮到Spark生態系統的成熟現狀及發展前景，建議本平臺以Hadoop生態系統為主體，同時支持Spark計算框架，可采用Spark on Yarn架構，提升基礎平臺的統一性和靈活性。

5)分布式K-V內存數據庫。內存跟傳統磁盤相比，具有更高的讀寫速度。在海量的、高并發的簡單關系查詢中，應用內存數據庫將有效提升系統性能。目前各種類型的內存數據庫已經得到了廣泛的應用，如關系型內存數據庫TimesTen、fastdb，Key-Value型的數據庫等，往往作為前端數據庫的角色出現，處理和存儲短時間段內的實時數據，根本原因在于內存數據庫容量有限，大量的業務應用不得不由后臺的磁盤數據庫負責。為解決傳統集中式內存數據庫的容量、并發、擴展性、持久化等問題，目前可持久化的分布式內存數據庫使用越來越多。

Key-Value內存數據庫的主要特點就是具有極高的并發讀寫性能。以Redis為例，它是一個高性能的Key-Value數據庫，同時支持磁盤數據的持久化。Redis使用內存提供主存儲支持，而僅使用硬盤做持久性的存儲。

Redis支持存儲的Value類型，包括string(字符串)、list(鏈表)、set(集合)和zset(有序集合)等。這些數據類型都支持push/pop、add/remove及取交集、并集、差集和更豐富的操作，而且這些操作都是原子性的。在此基礎上，Redis支持各種不同的方式排序。與memcached一樣，為了保證效率，數據都是緩存在內存中。區別的是Redis會周期性把更新的數據寫入磁盤或者把修改操作寫入追加的記錄文件，并且在此基礎上實現了M/S同步。

綜上所述，本平臺建議引入K-V內存技術。

6)分布式消息中間件。消息中間件是指支持與保障分布式應用程序之間同步/異步收發消息的中間件。消息中間件利用高效可靠的消息傳遞機制進行平臺無關的數據交流，并基于數據通信來進行分布式系統的集成。通過提供消息傳遞和消息排隊模型，它可以在分布式環境下擴展進程間的通信。

消息中間件適用于需要可靠數據傳送的分布式環境。采用消息中間件機制的系統中，不同的對象之間通過傳消息來激活對方的事件，完成相應的操作。發送者將消息發送給消息服務器，消息服務器將消息存放在若干隊列中，在合適的時候再將消息轉發給接收者。消息中間件能在不同平臺之間通信，它常被用來屏蔽掉各種平臺及協議之間的特性，實現應用程序之間的協同，其優點在于能夠在客戶和服務器之間提供同步和異步的連接，并且在任何時刻都可以將消息進行傳送或者存儲轉發。

互聯網等大型分布式解決方案中，往往采用分布式的消息中間件。大數據分析系統分布式解決方案中，broker、producer、consumer都為集群，消息路由對順序和可靠性有極高要求。

綜上所述，本平臺建議引入分布式消息中間件。

5.3.3 平臺技術架構

大數據分析處理應用平臺采用總分架構，通過統一的數據中心來匯聚各類數據源的數據，并進行關聯和整合。整個平臺包括四個部分:數據采集網關、數據存儲處理平臺、數據應用平臺、數據管控平臺，如圖1所示。

圖1 大數據分析處理應用平臺技術架構

1)數據采集網關。負責數據的采集、清洗和安全傳輸等，采集范圍包括移動DPI、固網寬帶DPI數據、MSS/BSS/OSS等。其部署方式采用分布式前置部署，部署在數據采集節點。采集模式采用按專業建立采集通道，避免統一數據源由多方重復采集，進一步實現數據采集的標準化，提升數據時效性和傳輸效率。以移動DPI數據為例:利用現有DPI解析和清洗設備作為數據采集網關，當前不做安全控制，清洗策略按需固定，同時整合終端自注冊數據和PCMD數據(Per Call Measurement Data)。

2)數據存儲處理平臺。負責整合匯聚所有數據并進行關聯，負責對外提供數據，如三戶信息、套餐等IT相關數據、移動DPI和固網寬帶DPI等;利用運營商原有ODS、EDW系統承擔結構化數據存儲和處理，建設新的Hadoop分布式平臺負責海量話單、移動DPI和固網寬帶DPI數據等非結構化和半結構化數據的存儲和處理。

3)數據應用平臺。數據應用網關統一封裝數據，提供統一的數據共享接口，數據應用通過共享接口獲取數據。在數據應用開發平臺中，可以通過建立開發流程中的業務和技術組件，實現數據應用敏捷化和標準化開發，提高開發效率。

4)數據管控平臺。利用運營商現有數據運營管控各子系統，如數據質量稽核、元數據管理等功能，保證數據安全可用，數據運營穩定高效。平臺的數據處理流程如圖2所示。

①移動DPI、固網DPI等數據每5分鐘內準實時加載。②由于運營商目前基于oracle的ODS分析報表展現體系比較完善，日匯總數據量平均為詳單的1/20，因此將日匯總數據的分析結果倒回ODS系統，進行相關的多維分析和渠道展現。③大數據分析處理平臺的準實時分析(小時級)直接在大數據平臺上查詢展現。平臺的邏輯架構如圖3所示。

圖2 大數據分析處理應用平臺數據處理流程

圖3 大數據分析處理應用平臺數據處理流程

5.4 主要功能

1)固網寬帶DPI數據分析功能和應用。包括上網行為總體分析、Top100網站訪問排名、Top1000關鍵字排名、分類網站分析、用戶偏好總體分析和競爭對手網站總體分析和競爭對手網站軌跡分析。

2)移動互聯網行為數據分析功能和應用。

①移動互聯網流量分析。包括:移動用戶上網流量分析、使用終端客戶端上網分析、重點增值業務流量分析、區局3G流量跟蹤分析、存量用戶3G/4G推薦、低流量用戶增值應用推薦、超量用戶升檔/加裝包推薦、寫字樓白領圈及高校圈升檔/加裝包推薦等。

②移動互聯網流量營銷。包括:流量使用情況及通話情況實時查詢、套餐流量情況實時查詢及統計、移動流量用戶行為數據分析、優酷等視頻客戶端搜索指定關鍵詞的用戶清單、安卓市場等應用市場類軟件搜索指定關鍵詞的用戶清單等。

③互聯網分析應用營銷派單。包括:重點增值業務營銷派單、重點推薦手機軟件營銷派單、基于用戶位置的營銷派單等。

5.5 性能指標

1)數據采集性能指標。數據采集處理頻率為5分鐘一次，高峰時段每頻次需要采集的數據量約為1.5億，故數據采集的性能指標為15 000/5/60=50萬條/秒。

2)數據處理性能指標。數據采集有兩個數據源:移動互聯網上網行為數據(每天80億條)和固網寬帶DPI數據(每天100億條)。

①移動互聯網上網行為數據的處理性能指標。移動DPI一天的數據量約為80億條，每天有4個匯總處理需求，每個匯總的時間要求為1小時(共需4小時)，性能指標為222萬條/秒。

②固網寬帶DPI數據的處理性能指標。固網DPI一天的數據量約為100億條，總共1.9TB，每天1個匯總處理需求，匯總時間要求為1小時，性能指標為278萬條/秒。

5.6 組網方案及軟硬件配置

本大數據分析處理應用平臺的網絡拓撲如圖4所示。

圖4 大數據分析處理應用平臺網絡拓撲

由圖4可知，本平臺硬件配置方面主要有:1臺日志采集服務器、2臺AAA Radius采集服務器、4臺固網HTTP Get前置采集服務器、4臺固網雙向DPI前置采集服務器、11臺固網雙向DPI清洗服務器、11臺固網HTTP Get清洗服務器、93臺Hadoop數據節點服務器和2臺Hadoop控制節點服務器(需要安裝Hadoop、hive、hbase、Zookeeper、pig、ganglia、Spark、K-V)、16臺Hadoop ETL節點服務器(需要安裝sqoop、flume)、2臺門戶服務器、10臺應用服務器、4臺一級匯聚分流設備、1臺二級匯聚分流設備、2臺前置采集交換機及若干核心交換機、防火墻等。

本平臺軟件配置方面主要包括1套大數據分析處理應用軟件、1套Hadoop分布式平臺基礎軟件。

6 總結

近年來伴隨云計算和大數據的發展熱潮，數據作為一種無形資產的價值正在日益得到社會廣泛認可。面向大數據時代，運營商的及時轉型成為必然，否則將有被互聯網企業超越的可能性。電信運營商需要重視并建立大數據體系，掌握大數據技能，發掘大數據價值，對內可實現智慧運營，為用戶提供精細化營銷服務，對外可提供增值化業務，將數據提供給零售行業、金融業和保險業等，實現數據的二次營銷，從而為自身的轉型發展提供強勁的動力。

[1]馮明麗,陳志彬.基于電信運營商的大數據解決方案分析[J].通信與信息技術,2013(05):12-13

[2]于艷華,宋美娜.大數據[J].中興通訊技術,2013(03):57-58

[3]顧基發.大數據要注意的一些問題[J].科技促進發展,2014(01):25-26

[4]陳勇.大數據及其商業價值[J].通信與信息技術,2013(01):10-11

[5]夏俊鸞,邵賽賽.Spark Streaming:大規模流式數據處理的新貴[J].程序員,2014(02):21-22