丁亦志,李邵平,牛瑛霞/Ding Yizhi,Li Shaoping,Niu Yingxia
(中國移動(dòng)通信集團(tuán)設(shè)計(jì)院有限公司 北京100080)
大數(shù)據(jù)(Big Data)技術(shù)或稱巨量資料,是指所涉及的資料量規(guī)模巨大到無法通過目前主流軟件工具,在合理時(shí)間內(nèi)達(dá)到擷取、管理、處理,并整理成為幫助企業(yè)經(jīng)營決策更積極目的的資訊。自2012年以來,大數(shù)據(jù)一詞越來越多地被提及,人們用它來描述和定義信息爆炸時(shí)代產(chǎn)生的海量數(shù)據(jù),并命名與之相關(guān)的技術(shù)發(fā)展與創(chuàng)新。數(shù)據(jù)已經(jīng)滲透到當(dāng)今每一個(gè)行業(yè)和業(yè)務(wù)職能領(lǐng)域,成為重要的生產(chǎn)因素。
作為云計(jì)算、物聯(lián)網(wǎng)后IT 行業(yè)又一顛覆性的技術(shù)革命,大數(shù)據(jù)隨著近年來互聯(lián)網(wǎng)和信息行業(yè)的發(fā)展而引起人們的廣泛關(guān)注,本文旨在對電信行業(yè)中的大數(shù)據(jù)應(yīng)用進(jìn)行研究探討。
通過對互聯(lián)網(wǎng)行業(yè)大數(shù)據(jù)的研究,歸納出以下4 項(xiàng)發(fā)展趨勢。
(1)去小型機(jī)化
“傳統(tǒng)數(shù)據(jù)庫+小型機(jī)+高端陣列”的模式在性價(jià)比上很難再延續(xù),SMP的擴(kuò)展能力接近上限。
(2)計(jì)算與數(shù)據(jù)處理一體機(jī)化
軟硬件垂直整合帶來高性能優(yōu)勢和高集成度。
(3)內(nèi)存和多核計(jì)算的崛起
磁盤已經(jīng)落伍,內(nèi)存才是王道;1 TB RAM PC已可行,新的壓縮算法允許在內(nèi)存里完整儲(chǔ)存大量數(shù)據(jù);16 核擴(kuò)充至64 核,為CPU 提供足夠的指令和數(shù)據(jù)是高效處理數(shù)據(jù)的關(guān)鍵。
(4)MPP/列存儲(chǔ),Hadoop 低成本海量分布式架構(gòu)強(qiáng)勢
通用x86 服務(wù)器+Linux+高速網(wǎng)絡(luò)+SSD 存儲(chǔ)、MPP+列存儲(chǔ)集群的Scale Out 和OLAP 高性能、Hadoop 生態(tài)圈的蓬勃發(fā)展。
洛杉磯警察局和加利福尼亞大學(xué)合作利用大數(shù)據(jù)預(yù)測犯罪的發(fā)生,Google 流感趨勢(Google Flu Trends)利用搜索關(guān)鍵詞預(yù)測禽流感的散布,統(tǒng)計(jì)學(xué)家內(nèi)特·西爾弗(Nate Silver)利用大數(shù)據(jù)預(yù)測2012年美國選舉結(jié)果。類似的應(yīng)用在互聯(lián)網(wǎng)行業(yè)不勝枚舉,對運(yùn)營商來說,大數(shù)據(jù)又有哪些方面的價(jià)值?本文總結(jié)出以下6 種典型的應(yīng)用場景,見表1 所列。
本文提出移動(dòng)互聯(lián)網(wǎng)時(shí)代運(yùn)營商的大數(shù)據(jù)價(jià)值體系,包括客戶研究、精準(zhǔn)營銷、智能管道、全業(yè)務(wù)融合和新業(yè)務(wù)模式等,如圖1所示。
客戶研究包括用戶內(nèi)容偏好、用戶行為偏好、用戶位置軌跡、用戶交往圈、用戶分群。精準(zhǔn)營銷包括內(nèi)容偏好營銷、事件營銷、位置營銷、業(yè)務(wù)交叉推薦、渠道協(xié)同營銷、體驗(yàn)式營銷。智能管道包括管道可視化、差分服務(wù)、公平使用、策略計(jì)費(fèi)、信息與內(nèi)容過濾、競爭/替代業(yè)務(wù)監(jiān)控分析。全業(yè)務(wù)融合包括統(tǒng)一客戶信息提升管理水平、統(tǒng)一產(chǎn)品信息提升優(yōu)化程度、統(tǒng)一服務(wù)信息改善客戶體驗(yàn)、統(tǒng)一資源信息保障協(xié)同調(diào)度。新商業(yè)模式包括后向收費(fèi)模式支撐、合作產(chǎn)品引入分析、新流量產(chǎn)品引入分析、行業(yè)分析報(bào)告發(fā)布、數(shù)據(jù)服務(wù)開放共享。
表1 運(yùn)營商典型應(yīng)用場景
圖1 運(yùn)營商大數(shù)據(jù)價(jià)值體系
圖2 割裂式混搭架構(gòu)
圖3 混搭架構(gòu)+深度定制化部件架構(gòu)
大數(shù)據(jù)平臺(tái)架構(gòu)主要包括割裂式混搭架構(gòu)、混搭架構(gòu)+深度定制化部件、Hadoop 深度定制架構(gòu)和自主研發(fā)新架構(gòu)4 類架構(gòu)。
(1)割裂式混搭架構(gòu)
割裂式混搭架構(gòu)模式是Hadoop+MPP RDB/SMP RDB,以Hadoop 處理非結(jié)構(gòu)化為輔,RDB 處理結(jié)構(gòu)化為主。主要應(yīng)用于eBay、KDDI、中國移動(dòng)省級(jí)經(jīng)分等,架構(gòu)如圖2所示。
(2)混搭架構(gòu)+深度定制化部件
混搭架構(gòu)+定制化部件是Hadoop+MPP RDB+NoSQL/MyFox/Prom/glider/OceanBase、Hadoop 海量結(jié)構(gòu)化/非結(jié)構(gòu)化存儲(chǔ)、ETL 和離線計(jì)算基礎(chǔ);MPP DB面向高速訪問存儲(chǔ)和部分實(shí)時(shí)計(jì)算; 專用場景部件,例如基于NoSQL的Prom/OceanBase,解決特定業(yè)務(wù)場景問題(全屬性查詢)和復(fù)雜的實(shí)時(shí)計(jì)算。阿里巴巴和淘寶是此架構(gòu)最好的代表,如圖3所示。
(3)Hadoop 深度定制架構(gòu)
Hadoop 深度定制架構(gòu)即Hadoop Enhanced,圍繞Hadoop 生態(tài)圈進(jìn)行深度定制和優(yōu)化。騰訊和百度是此架構(gòu)的代表,如圖4所示。
(4)自主研發(fā)新架構(gòu)
自主研發(fā)架構(gòu)包括Caffeine、Pregel、Dremel、Power Drill、Storm、Qubole、RCFile 等,擁有核心知識(shí)產(chǎn)權(quán)和創(chuàng)新技術(shù)驅(qū)動(dòng)業(yè)務(wù)革新。Google、Twitter、Facebook 都是基于自主研發(fā)的新架構(gòu),如圖5 和圖6所示。
(5)運(yùn)營商平臺(tái)架構(gòu)的演進(jìn)
在大數(shù)據(jù)中,運(yùn)營商在3~5年內(nèi)仍然是以結(jié)構(gòu)化數(shù)據(jù)處理為主。但今后的趨勢是往混合結(jié)構(gòu)方向演進(jìn)。當(dāng)前建設(shè)方案應(yīng)采取Hadoop+MPP RDB 集群的混搭模式,為使上層應(yīng)用平滑過渡,需要在混搭的架構(gòu)上建設(shè)透明訪問層,以屏蔽數(shù)據(jù)源的異構(gòu)、多實(shí)例特性。Hadoop平臺(tái)承擔(dān)了原始海量數(shù)據(jù)的抽取、轉(zhuǎn)換、加載和輕度匯總等計(jì)算任務(wù)。同時(shí)新建MPP RDB 集群的深度分析庫,支撐查詢模型復(fù)雜、多變的自助分析應(yīng)用。具體架構(gòu)演進(jìn)示意如圖7所示。
圖4 Hadoop 深度定制架構(gòu)
圖5 自主研發(fā)新架構(gòu)示意
①專用數(shù)據(jù)倉庫(如TD)+MPP RDB 集群混搭模式,支撐傳統(tǒng)的固定查詢,如報(bào)表類應(yīng)用等。
②用Hadoop平臺(tái)支撐流量清單查詢,這需要對Hadoop 進(jìn)行深度定制、改造。否則需要將清單數(shù)據(jù)加載到MPP RDB 集群的數(shù)據(jù)倉庫中支撐查詢。
③MPP RDB 集群支撐自助分析類應(yīng)用,此類查詢模型復(fù)雜、多變,且要求實(shí)時(shí)展現(xiàn)。
大數(shù)據(jù)涉及的關(guān)鍵技術(shù)主要包括流數(shù)據(jù)處理、費(fèi)關(guān)系型數(shù)據(jù)庫技術(shù)、MPP DB 和文件型分布式存儲(chǔ)。
為應(yīng)對海量數(shù)據(jù)實(shí)時(shí)處理的需求,業(yè)界引入了流處理的機(jī)制。在數(shù)據(jù)流動(dòng)的過程中分析和計(jì)算,分析只對一定時(shí)間段內(nèi)(Δt)的數(shù)據(jù)進(jìn)行處理,事件/數(shù)據(jù)觸發(fā)分析,分析過程始終在線,流處理又分為狹義流處理和廣義流處理兩大類。
狹義流處理為ESP(Event Stream Process,事件流處理)和CEP(Complex Event Process,復(fù)雜事件處理)。
廣義流處理不但提供結(jié)構(gòu)化數(shù)據(jù)的離散事件流處理能力,同時(shí)提供非結(jié)構(gòu)數(shù)據(jù)的連續(xù)流處理,如Video、Image、Text。對非結(jié)構(gòu)化數(shù)據(jù)一般主要提供分布式計(jì)算機(jī)制。
相比于RDBMS,NoSQL 數(shù)據(jù)存儲(chǔ)不需要固定的表結(jié)構(gòu),通常也不存在連接操作,在解決大規(guī)模數(shù)據(jù)的可擴(kuò)展性上有獨(dú)到的解決方案,因此,在大數(shù)據(jù)存取上具備RDBMS 無法比擬的性能優(yōu)勢,非常適合超大規(guī)模和高并發(fā)的SNS 型Web2.0 網(wǎng)站;但在一致性方面,則不如RDBMS,不適用于企業(yè)的關(guān)鍵應(yīng)用。
圖7 由混搭架構(gòu)向深度定制架構(gòu)演進(jìn)
NoSQL 一般與具體應(yīng)用強(qiáng)綁定,主要由開源項(xiàng)目推動(dòng),F(xiàn)acebook、Digg、Twitter、Amazon 等都是NoSQL的推動(dòng)者,其中,F(xiàn)acebook的Cassandra、Google的Big Table、Amazon的Dynamo 等都是非常成功的NoSQL商業(yè)實(shí)現(xiàn)。
目前,NoSQL家族中應(yīng)用較為廣泛的有HBase(Hadoop的衍生項(xiàng)目,類似Google的Big Table)、Cassandra(由Facebook 開發(fā),用于存儲(chǔ)特別大的數(shù)據(jù),是網(wǎng)絡(luò)社交云計(jì)算方面理想的數(shù)據(jù)庫)、MongoDB(功能最豐富、最像關(guān)系型數(shù)據(jù)庫的非關(guān)系型數(shù)據(jù)庫,可存儲(chǔ)比較復(fù)雜的數(shù)據(jù)類型)。
MPP DB 是指大規(guī)模并行處理(Massive Parallel Processing)數(shù)據(jù)庫,有兩種基本形式:Share Disk 和Share Nothing。
Share Disk:性能比較高,由于需要在節(jié)點(diǎn)間共享鎖和緩存,可擴(kuò)展性受到一定限制。適合高并發(fā)的OLTP 應(yīng)用和數(shù)據(jù)量較小的OLAP 應(yīng)用。
Share Nothing:每個(gè)節(jié)點(diǎn)的存儲(chǔ)、計(jì)算、內(nèi)存完全獨(dú)立,數(shù)據(jù)分區(qū)存放,可擴(kuò)展性好。適合大數(shù)據(jù)量的OALP 引用,但計(jì)算設(shè)備不容易做到熱備,可用性級(jí)別略低。
兩種基本形態(tài)都比較適合大數(shù)據(jù)的處理??紤]到擴(kuò)展性,主存儲(chǔ)和ETL 數(shù)據(jù)加工應(yīng)首選Share Nothing。數(shù)據(jù)分析要求靈活,擴(kuò)容壓力不大,自定義數(shù)據(jù)處理的應(yīng)用建議采用Share Disk,局域網(wǎng)絡(luò)帶寬在不斷提升,Share Disk 前景同樣很好,與Share Nothing 適用不同的場景。
對比MPP DB,文件型分布式存儲(chǔ)的優(yōu)點(diǎn)主要有以下幾個(gè)方面:
①基本實(shí)現(xiàn)了RAID 所具備的數(shù)據(jù)高可用性要求;
②比RAID 自愈能力更強(qiáng);
③沒有數(shù)據(jù)庫冗余開銷。
對比MPP DB,文件型分布式存儲(chǔ)的缺點(diǎn)主要有以下幾個(gè)方面:
①基于指定的Key 散列分布,對數(shù)據(jù)運(yùn)用限制很大;
②Key Value 方式連續(xù)讀寫效率不高;
③沒有事務(wù)、關(guān)聯(lián)、數(shù)據(jù)版本控制等數(shù)據(jù)庫特性。
針對大數(shù)據(jù),運(yùn)營商進(jìn)行了相關(guān)嘗試,下面以BSS 云化ETL、融合通信、某省日志詳單系統(tǒng)為案例進(jìn)行簡單的介紹。
移動(dòng)數(shù)據(jù)業(yè)務(wù)和流量的爆發(fā)式增長,帶來了網(wǎng)絡(luò)建設(shè)和維護(hù)費(fèi)用的成倍增加。數(shù)據(jù)業(yè)務(wù)中大量的非價(jià)值業(yè)務(wù)占據(jù)了60%以上的流量總帶寬。低價(jià)值業(yè)務(wù)造成收入與業(yè)務(wù)量失去關(guān)聯(lián)性,原有技術(shù)方式不能支撐數(shù)據(jù)業(yè)務(wù)盈利,使高價(jià)值業(yè)務(wù)的服務(wù)質(zhì)量難以保證,最終導(dǎo)致終端用戶的體驗(yàn)和滿意度下降。
流量經(jīng)營分析對云化ETL 和數(shù)據(jù)挖掘的要求:對各個(gè)數(shù)據(jù)源的日志進(jìn)行轉(zhuǎn)換裝載,將海量數(shù)據(jù)存儲(chǔ)在分布式存儲(chǔ)中,基于這部分?jǐn)?shù)據(jù)能夠進(jìn)行匯總等計(jì)算。對于ETL的訴求,要求能夠基于海量數(shù)據(jù)做E-T-L 操作,同時(shí)能夠做相應(yīng)的關(guān)聯(lián)匯總統(tǒng)計(jì)等功能。
SmartCare 為用戶提供Network Insight解決方案,包括業(yè)務(wù)質(zhì)量、用戶體驗(yàn)、網(wǎng)絡(luò)性能等。網(wǎng)絡(luò)及業(yè)務(wù)信令實(shí)時(shí)流入,一方面被存儲(chǔ)下來作為詳單存儲(chǔ)和查詢;另一方面被匯總計(jì)算得到統(tǒng)計(jì)結(jié)果,用于OLAP 分析和報(bào)表查詢。Infosea HDFS 和HBase 被用于詳單存儲(chǔ),MR 被用于匯總計(jì)算。
其中,HBase 單點(diǎn)入庫1.3 萬條/s(4.5 MB/s),MR 服務(wù)器單點(diǎn)入庫1.2 萬條/s,單點(diǎn)存儲(chǔ)空間為9.6 T(2 T×8 塊),xDR 單據(jù)產(chǎn)生速率為28.1 萬條/s,每條362 Byte。
圖8 日志詳單系統(tǒng)模型
日志詳單類數(shù)據(jù)云存儲(chǔ)系統(tǒng)基于x86 PC 服務(wù)器集群,通過軟件系統(tǒng)實(shí)現(xiàn)高性能和海量存儲(chǔ),具體如圖8所示。
設(shè)計(jì)目標(biāo)如下。
①高可靠性,通過數(shù)據(jù)和服務(wù)冗余、分布式鎖系統(tǒng)來解決PC 硬件故障率較高的問題。
②高可伸縮性,系統(tǒng)可以容易地增加或者減少容量和性能。
業(yè)務(wù)描述如下。
①基于HDFS的數(shù)據(jù)存儲(chǔ)服務(wù):為數(shù)據(jù)庫系統(tǒng)提供海量結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)服務(wù),通常使用具備冗余存儲(chǔ)、自動(dòng)負(fù)載均衡能力的云計(jì)算分布式文件系統(tǒng)。
②基于MR 和Hive的數(shù)據(jù)查詢服務(wù): 完成用戶查詢的分解、轉(zhuǎn)換、執(zhí)行、結(jié)果收集和優(yōu)化工作,由于數(shù)據(jù)可能被分配在很多存儲(chǔ)服務(wù)節(jié)點(diǎn)上,數(shù)據(jù)查詢服務(wù)必須具備分布式查詢執(zhí)行和結(jié)果收集能力,同時(shí)考慮到硬件的不可靠性,數(shù)據(jù)查詢服務(wù)需要具備很高的容錯(cuò)能力。
③數(shù)據(jù)接口和訪問層:連接應(yīng)用程序和數(shù)據(jù)查詢服務(wù)。主要對應(yīng)用提供兩類接口:數(shù)據(jù)存取接口,如針對非結(jié)構(gòu)化數(shù)據(jù)的HDFS 接口; 數(shù)據(jù)查詢分析接口,MR 接口、標(biāo)準(zhǔn)JDBC/SQL 接口等。
隨著互聯(lián)網(wǎng)業(yè)務(wù)的高速發(fā)展,大數(shù)據(jù)的廣泛應(yīng)用是業(yè)務(wù)發(fā)展的趨勢。運(yùn)營商需要加強(qiáng)對大數(shù)據(jù)的管理,對網(wǎng)絡(luò)和業(yè)務(wù)系統(tǒng)進(jìn)行全方位覆蓋,深刻理解業(yè)務(wù),精確洞察數(shù)據(jù),充分發(fā)揮數(shù)據(jù)價(jià)值。后續(xù),大數(shù)據(jù)技術(shù)與流量經(jīng)營相結(jié)合,對大數(shù)據(jù)應(yīng)用價(jià)值探索,構(gòu)建大數(shù)據(jù)流量增值體系將是研究的重點(diǎn)。