電信運(yùn)營商大數(shù)據(jù)應(yīng)用典型案例分析

上海郵電設(shè)計(jì)咨詢研究院有限公司 上海 200092

1 大數(shù)據(jù)技術(shù)簡介

隨著移動(dòng)互聯(lián)網(wǎng)、云計(jì)算、物聯(lián)網(wǎng)技術(shù)和業(yè)務(wù)的發(fā)展，全球數(shù)據(jù)量正在呈爆炸性指數(shù)級增長。根據(jù)IDC發(fā)布的報(bào)告顯示，2012年全球數(shù)據(jù)量約為2.8ZB，并以大約每兩年翻一番的速度增長，預(yù)計(jì)到2020年，全球?qū)a(chǎn)生35ZB的數(shù)據(jù)量。這意味著我們正進(jìn)入大數(shù)據(jù)時(shí)代。

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

以Hadoop為代表的大數(shù)據(jù)技術(shù)應(yīng)運(yùn)而生，它是一種非關(guān)系型數(shù)據(jù)庫系統(tǒng)及分布式運(yùn)算架構(gòu)。近幾年，F(xiàn)acebook、Google、Amazon、Yahoo、阿里巴巴和百度等開始了大數(shù)據(jù)化的進(jìn)程，他們依托自己的數(shù)據(jù)優(yōu)勢，采取靈活深入的分析方法進(jìn)行基于大數(shù)據(jù)的挖掘，從中摸索嶄新的商業(yè)模式[2]。

2 大數(shù)據(jù)驅(qū)動(dòng)電信運(yùn)營商轉(zhuǎn)型

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

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

對于大數(shù)據(jù)的應(yīng)用已經(jīng)成為一種必然趨勢，其發(fā)展勢頭非常強(qiáng)勁。大數(shù)據(jù)驅(qū)動(dòng)不僅是電信運(yùn)營商增強(qiáng)業(yè)務(wù)能力和網(wǎng)絡(luò)能力的抓手，更重要的是，大數(shù)據(jù)驅(qū)動(dòng)能促使電信運(yùn)營商切實(shí)學(xué)習(xí)和領(lǐng)會(huì)互聯(lián)網(wǎng)的思維，真正實(shí)現(xiàn)以用戶為中心，多維度了解用戶，實(shí)現(xiàn)數(shù)據(jù)化運(yùn)營，借助大數(shù)據(jù)中蘊(yùn)含的價(jià)值和動(dòng)力將轉(zhuǎn)型發(fā)展落到實(shí)處。

3 電信運(yùn)營商大數(shù)據(jù)發(fā)展遇到的問題

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

4 電信運(yùn)營商大數(shù)據(jù)策略

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

5 大數(shù)據(jù)分析處理應(yīng)用平臺

5.1 建設(shè)背景

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

針對以上問題，急需設(shè)計(jì)一套大數(shù)據(jù)分析處理應(yīng)用平臺，作為現(xiàn)有數(shù)據(jù)倉庫系統(tǒng)的有益補(bǔ)充，形成企業(yè)大數(shù)據(jù)統(tǒng)一匯聚平臺。

5.2 建設(shè)目標(biāo)

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

5.3 平臺技術(shù)架構(gòu)

5.3.1 平臺技術(shù)方案要求

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

5.3.2 基礎(chǔ)存儲、計(jì)算平臺技術(shù)方案分析

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

表1 體系架構(gòu)比較

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

①Hadoop等分布式架構(gòu)通常用于非結(jié)構(gòu)化/半結(jié)構(gòu)化數(shù)據(jù)處理，已被廣泛應(yīng)用于多種大數(shù)據(jù)應(yīng)用場景，成為業(yè)界大數(shù)據(jù)處理的最主流解決方案之一，具有可靠、高效、可伸縮的特點(diǎn)。另外，Hadoop等分布式架構(gòu)可以解決系統(tǒng)的I/O問題，通過各服務(wù)器的列式數(shù)據(jù)的關(guān)聯(lián)，并發(fā)生成數(shù)據(jù)，可解決海量數(shù)據(jù)的關(guān)聯(lián)、入庫、查詢、共享等需要。

②Hadoop等分布式解決方案，已有成熟的組件適應(yīng)各應(yīng)用場景。如:Hadoop中可采用HDFS存儲層存儲、Hive方式關(guān)聯(lián)入庫、HBASE方式查詢;具備可擴(kuò)展性高的特點(diǎn)，并支持?jǐn)?shù)據(jù)節(jié)點(diǎn)在線調(diào)整，擴(kuò)展更多應(yīng)用。

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

④高可靠性:多任務(wù)并行計(jì)算、數(shù)據(jù)冗余存儲，有效避免設(shè)備單點(diǎn)故障，提供高可靠服務(wù)。

⑤高擴(kuò)展性:X86架構(gòu)可以通過增加節(jié)點(diǎn)，完美支持計(jì)算和存儲能力的線性擴(kuò)容。

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

⑦數(shù)據(jù)源采用非結(jié)構(gòu)化/半結(jié)構(gòu)化數(shù)據(jù)處理，有利于未來進(jìn)行各種業(yè)務(wù)的擴(kuò)展，有效提高數(shù)據(jù)的可用性。

2)開源二次開發(fā)版本/商業(yè)版本對比分析及建議?；贖adoop的架構(gòu)特性及平臺需求的多樣化，業(yè)界有開源二次開發(fā)版本及商業(yè)版本的使用情況，對比如表2所示。綜合考慮投資額、業(yè)界使用案例等因素，本平臺采用開源二次開發(fā)版本。在實(shí)際建設(shè)中，需重點(diǎn)評估、考核支撐廠家的開發(fā)、支撐、服務(wù)能力，以保障平臺未來的運(yùn)營。

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

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

表2 二次開發(fā)版本/商業(yè)版本對比

表3 Hadoop版本選型對比

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

4)Spark框架及支持建議。

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

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

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

③Spark支持建議?？紤]到Spark生態(tài)系統(tǒng)的成熟現(xiàn)狀及發(fā)展前景，建議本平臺以Hadoop生態(tài)系統(tǒng)為主體，同時(shí)支持Spark計(jì)算框架，可采用Spark on Yarn架構(gòu)，提升基礎(chǔ)平臺的統(tǒng)一性和靈活性。

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

Key-Value內(nèi)存數(shù)據(jù)庫的主要特點(diǎn)就是具有極高的并發(fā)讀寫性能。以Redis為例，它是一個(gè)高性能的Key-Value數(shù)據(jù)庫，同時(shí)支持磁盤數(shù)據(jù)的持久化。Redis使用內(nèi)存提供主存儲支持，而僅使用硬盤做持久性的存儲。

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

綜上所述，本平臺建議引入K-V內(nèi)存技術(shù)。

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

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

互聯(lián)網(wǎng)等大型分布式解決方案中，往往采用分布式的消息中間件。大數(shù)據(jù)分析系統(tǒng)分布式解決方案中，broker、producer、consumer都為集群，消息路由對順序和可靠性有極高要求。

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

5.3.3 平臺技術(shù)架構(gòu)

大數(shù)據(jù)分析處理應(yīng)用平臺采用總分架構(gòu)，通過統(tǒng)一的數(shù)據(jù)中心來匯聚各類數(shù)據(jù)源的數(shù)據(jù)，并進(jìn)行關(guān)聯(lián)和整合。整個(gè)平臺包括四個(gè)部分:數(shù)據(jù)采集網(wǎng)關(guān)、數(shù)據(jù)存儲處理平臺、數(shù)據(jù)應(yīng)用平臺、數(shù)據(jù)管控平臺，如圖1所示。

圖1 大數(shù)據(jù)分析處理應(yīng)用平臺技術(shù)架構(gòu)

1)數(shù)據(jù)采集網(wǎng)關(guān)。負(fù)責(zé)數(shù)據(jù)的采集、清洗和安全傳輸?shù)?，采集范圍包括移?dòng)DPI、固網(wǎng)寬帶DPI數(shù)據(jù)、MSS/BSS/OSS等。其部署方式采用分布式前置部署，部署在數(shù)據(jù)采集節(jié)點(diǎn)。采集模式采用按專業(yè)建立采集通道，避免統(tǒng)一數(shù)據(jù)源由多方重復(fù)采集，進(jìn)一步實(shí)現(xiàn)數(shù)據(jù)采集的標(biāo)準(zhǔn)化，提升數(shù)據(jù)時(shí)效性和傳輸效率。以移動(dòng)DPI數(shù)據(jù)為例:利用現(xiàn)有DPI解析和清洗設(shè)備作為數(shù)據(jù)采集網(wǎng)關(guān)，當(dāng)前不做安全控制，清洗策略按需固定，同時(shí)整合終端自注冊數(shù)據(jù)和PCMD數(shù)據(jù)(Per Call Measurement Data)。

2)數(shù)據(jù)存儲處理平臺。負(fù)責(zé)整合匯聚所有數(shù)據(jù)并進(jìn)行關(guān)聯(lián)，負(fù)責(zé)對外提供數(shù)據(jù)，如三戶信息、套餐等IT相關(guān)數(shù)據(jù)、移動(dòng)DPI和固網(wǎng)寬帶DPI等;利用運(yùn)營商原有ODS、EDW系統(tǒng)承擔(dān)結(jié)構(gòu)化數(shù)據(jù)存儲和處理，建設(shè)新的Hadoop分布式平臺負(fù)責(zé)海量話單、移動(dòng)DPI和固網(wǎng)寬帶DPI數(shù)據(jù)等非結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)的存儲和處理。

3)數(shù)據(jù)應(yīng)用平臺。數(shù)據(jù)應(yīng)用網(wǎng)關(guān)統(tǒng)一封裝數(shù)據(jù)，提供統(tǒng)一的數(shù)據(jù)共享接口，數(shù)據(jù)應(yīng)用通過共享接口獲取數(shù)據(jù)。在數(shù)據(jù)應(yīng)用開發(fā)平臺中，可以通過建立開發(fā)流程中的業(yè)務(wù)和技術(shù)組件，實(shí)現(xiàn)數(shù)據(jù)應(yīng)用敏捷化和標(biāo)準(zhǔn)化開發(fā)，提高開發(fā)效率。

4)數(shù)據(jù)管控平臺。利用運(yùn)營商現(xiàn)有數(shù)據(jù)運(yùn)營管控各子系統(tǒng)，如數(shù)據(jù)質(zhì)量稽核、元數(shù)據(jù)管理等功能，保證數(shù)據(jù)安全可用，數(shù)據(jù)運(yùn)營穩(wěn)定高效。平臺的數(shù)據(jù)處理流程如圖2所示。

①移動(dòng)DPI、固網(wǎng)DPI等數(shù)據(jù)每5分鐘內(nèi)準(zhǔn)實(shí)時(shí)加載。②由于運(yùn)營商目前基于oracle的ODS分析報(bào)表展現(xiàn)體系比較完善，日匯總數(shù)據(jù)量平均為詳單的1/20，因此將日匯總數(shù)據(jù)的分析結(jié)果倒回ODS系統(tǒng)，進(jìn)行相關(guān)的多維分析和渠道展現(xiàn)。③大數(shù)據(jù)分析處理平臺的準(zhǔn)實(shí)時(shí)分析(小時(shí)級)直接在大數(shù)據(jù)平臺上查詢展現(xiàn)。平臺的邏輯架構(gòu)如圖3所示。

圖2 大數(shù)據(jù)分析處理應(yīng)用平臺數(shù)據(jù)處理流程

圖3 大數(shù)據(jù)分析處理應(yīng)用平臺數(shù)據(jù)處理流程

5.4 主要功能

1)固網(wǎng)寬帶DPI數(shù)據(jù)分析功能和應(yīng)用。包括上網(wǎng)行為總體分析、Top100網(wǎng)站訪問排名、Top1000關(guān)鍵字排名、分類網(wǎng)站分析、用戶偏好總體分析和競爭對手網(wǎng)站總體分析和競爭對手網(wǎng)站軌跡分析。

2)移動(dòng)互聯(lián)網(wǎng)行為數(shù)據(jù)分析功能和應(yīng)用。

①移動(dòng)互聯(lián)網(wǎng)流量分析。包括:移動(dòng)用戶上網(wǎng)流量分析、使用終端客戶端上網(wǎng)分析、重點(diǎn)增值業(yè)務(wù)流量分析、區(qū)局3G流量跟蹤分析、存量用戶3G/4G推薦、低流量用戶增值應(yīng)用推薦、超量用戶升檔/加裝包推薦、寫字樓白領(lǐng)圈及高校圈升檔/加裝包推薦等。

②移動(dòng)互聯(lián)網(wǎng)流量營銷。包括:流量使用情況及通話情況實(shí)時(shí)查詢、套餐流量情況實(shí)時(shí)查詢及統(tǒng)計(jì)、移動(dòng)流量用戶行為數(shù)據(jù)分析、優(yōu)酷等視頻客戶端搜索指定關(guān)鍵詞的用戶清單、安卓市場等應(yīng)用市場類軟件搜索指定關(guān)鍵詞的用戶清單等。

③互聯(lián)網(wǎng)分析應(yīng)用營銷派單。包括:重點(diǎn)增值業(yè)務(wù)營銷派單、重點(diǎn)推薦手機(jī)軟件營銷派單、基于用戶位置的營銷派單等。

5.5 性能指標(biāo)

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

2)數(shù)據(jù)處理性能指標(biāo)。數(shù)據(jù)采集有兩個(gè)數(shù)據(jù)源:移動(dòng)互聯(lián)網(wǎng)上網(wǎng)行為數(shù)據(jù)(每天80億條)和固網(wǎng)寬帶DPI數(shù)據(jù)(每天100億條)。

①移動(dòng)互聯(lián)網(wǎng)上網(wǎng)行為數(shù)據(jù)的處理性能指標(biāo)。移動(dòng)DPI一天的數(shù)據(jù)量約為80億條，每天有4個(gè)匯總處理需求，每個(gè)匯總的時(shí)間要求為1小時(shí)(共需4小時(shí))，性能指標(biāo)為222萬條/秒。

②固網(wǎng)寬帶DPI數(shù)據(jù)的處理性能指標(biāo)。固網(wǎng)DPI一天的數(shù)據(jù)量約為100億條，總共1.9TB，每天1個(gè)匯總處理需求，匯總時(shí)間要求為1小時(shí)，性能指標(biāo)為278萬條/秒。

5.6 組網(wǎng)方案及軟硬件配置

本大數(shù)據(jù)分析處理應(yīng)用平臺的網(wǎng)絡(luò)拓?fù)淙鐖D4所示。

圖4 大數(shù)據(jù)分析處理應(yīng)用平臺網(wǎng)絡(luò)拓?fù)?/p>

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

本平臺軟件配置方面主要包括1套大數(shù)據(jù)分析處理應(yīng)用軟件、1套Hadoop分布式平臺基礎(chǔ)軟件。

6 總結(jié)

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

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

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

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

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

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