陶彩霞,謝曉軍,陳 康,郭利榮,劉 春
(中國電信股份有限公司廣東研究院 廣州 510630)
從2010年開始,國內移動互聯網進入快速發展階段,領先的電信運營商開始布局移動互聯網,同時,互聯網公司全面介入,終端廠商也基于應用商店模式快速加入移動互聯網領域。根據艾瑞咨詢發布的數據,全球移動互聯網用戶數正呈爆發式增長,2014年全球移動互聯網用戶數有望達到14億。然而在數據流量快速增長的同時,電信運營商卻出現數據業務收入增速放緩的困境,面臨被管道化的威脅。為應對移動互聯網帶來的挑戰,中國電信提出了從話務量經營轉向流量經營的戰略目標,從傳統的注重用戶規模轉變為注重流量發展。運營商擁有龐大的用戶,同時具有對終端及用戶上網通道的掌控能力,使得在用戶行為分析方面具有很好的數據基礎,深入分析用戶流量行為特征和規律,發現用戶潛在流量使用需求,是提升流量規模和價值、提高流量經營水平的有效手段。
然而隨著移動互聯網的迅速發展,用戶行為分析面臨著新的挑戰:一是移動互聯網新業務、新產品“短、平、快”的特征,要求運營商支持快速變化的營銷活動;二是隨著移動互聯網業務及終端、傳感器技術發展帶來的數據量的急劇膨脹,需要分析和處理的數據規模從GB級邁向TB級甚至PB級。傳統的數據分析架構已經不能適應這種海量數據處理和快速、深度挖掘的需求,迫切需要引入大規模并行處理技術和分布式架構,構建基于云計算的移動互聯網用戶行為分析引擎系統,以應對移動互聯網大數據時代的挑戰。
本文設計的移動互聯網用戶行為分析引擎通過云計算技術實現分布式并發的大規模計算能力,構建移動互聯網端到端的大數據挖掘分析系統,實現對DPI和應用平臺用戶上網行為的偏好分析,提供個性化推薦服務,打通從數據采集、分析到服務提供、營銷執行的全過程。
系統通過FTP服務器獲取數據,在接口層采用分布式計算與批量處理相結合的方式,將大數據存入Hbase數據庫中,支持海量數據和非結構化數據的存儲,數據入庫之后利用Hive進行整合層和匯總層的ETL處理,再基于MapReduce計算框架設計大數據分析模型,最后通過Hive數據庫將結果導入前端展現數據庫。在數據處理層,利用Hbase、Hive的優勢進行海量數據的存儲和處理,考慮到前端展現要求的靈活性,采用關系型數據庫MySQL作為前端展現。系統總體技術架構如圖1所示。
系統的總體拓撲如圖2所示,系統由一臺服務器作為Hadoop平臺和Hbase的主節點服務器,其他服務器為Hadoop平臺和Hbase的從節點服務器,從節點服務器的數量可根據系統處理需求動態擴展。主節點服務器主要負責從節點服務器任務和流量的分配,并對從節點服務器的執行狀態進行監控,多臺從節點服務器在主節點服務器的控制下執行具體的任務。

圖1 基于云計算的移動互聯網大數據用戶行為分析引擎總體技術架構

圖2 系統總體拓撲
主節點服務器的軟件功能架構如圖3所示,各模塊具體介紹如下。

圖3 主節點服務器功能架構
(1)任務管理與調度模塊
集中式的任務調度控制臺,提供任務的創建、調整和刪除等功能,通過業務類型選擇、執行周期設置等,定義應用的處理邏輯;自動控制數據抽取、數據整理到數據建模、模型運行、結果輸出等過程,根據任務設置的激活處理條件,自動加載任務運行,系統提供任務的暫停、恢復以及優先級管理功能。
(2)大數據入庫與預處理組件
將DPI用戶的上網行為、應用平臺的用戶行為和內容信息等大數據,及時導入用戶行為分析引擎系統,作為數據分析和模型挖掘的數據源。
(3)大數據用戶行為分析模型組件
基于匯聚到系統中的海量移動互聯網用戶行為數據,利用MapReduce計算框架構建用戶行為分析模型資源池,快速分析用戶的偏好、社會關系信息,且支持多類業務實現精準的內容推薦。
從節點服務器的軟件結構與主節點服務器基本相同,區別主要在于從節點服務器不需要部署任務管理和調度模塊。
移動互聯網用戶行為分析引擎的數據來源主要有兩類:應用平臺數據和DPI數據。兩類數據源的特點不同:應用平臺的數據主要集中在一個訪問行為表上,每天一個文件,每個文件的大小為GB級;而DPI數據的特點是大量的小文件,每個文件大小在10 MB以內,但文件來源頻率快,一般2 min就有好幾個文件,一個省份累計1天的數據量可達1 TB。
針對上述不同的數據源特點,系統采用不同的技術方案,具體介紹如下。
(1)應用平臺數據入庫
由于Hadoop通常使用的TextInputFormat類,在map中讀取到的是文件的一行記錄。因此,系統使用N LineInputFormat類實現在MapReduce中的批量入庫。通過使用N LineInputFormat類,每個分片有N行記錄,通過參數的配置,每次可讀取文件的N行記錄,那么可以在map中直接執行批量入庫的操作,效率相對較高。
(2)DPI數據入庫
由于DPI的行為數據是大量來源頻率很快的小文件,在Hadoop平臺下處理小文件采取的措施通常如下。
· 利用SequenceFiles將小文件打包上傳,可從源頭避免小文件產生,但無論是Hadoop shell還是MapReduce,都不能進行靈活讀取。
·使用HAR將HDFS中的小文件打包歸檔 (從HDFS),可減少既有 HDFS中的小文件數量,但HAR文件讀取性能差。
·Hadoop append可直接追加數據到相同文件中,但每個小文件的大小不同,同時考慮每天的DPI日志有峰值和低谷,對文件數量的控制和處理來說有一定的麻煩。
· Flume、FlumeNG、Scribe,可通過中間層匯聚數據的辦法減少小文件數量,但FlumeNG和Scribe都不能很好地傳輸壓縮文件。
通過以上分析可以看到,上述4種方式均存在一定的缺點,因此針對DPI數據的特征,采用Hadoop平臺的CombineFileInputFormat類方式,即通過繼承CombineFile InputFormat,實現 CreateRecordReader,同時設置數據分片的大小,通過這種方式實現DPI大數據的入庫。
大數據用戶行為分析模型組件提供多個在Hadoop分布式平臺上運行的分析模型,其功能結構及其與其他組件的關系如圖4所示。
2006年,隨著“三湖三河”污染治理工程的提出,巢湖流域受到了廣泛關注。巢湖流域以巢湖為中心,匯集了大小河流33條,是安徽省人口較集中的地區之一。近30年來,巢湖流域的經濟發展加快,城鎮化程度越來越高?,F今巢湖流域的國內生產總值已約占全省的三分之一,其產業結構特點突出,以第一二產業為主,第三產業比例較低。隨著城鎮化和經濟發展的加速,巢湖流域的生態問題和人地矛盾愈發尖銳。

圖4 大數據用戶行為分析模型組件
本組件主要由以下幾個模塊組成。
· 模型參數調整:提供對模型算法中的變量設定、參數調整、樣本空間規模設置等功能。
· 模型評估:提供創建模型校驗任務,將實際數據與模型計算結果進行比對,輸出模型校驗指標,進行模型校驗和模型有效性評價。
· 多業務數據關聯分析模型:對用戶的互聯網行為和愛游戲業務平臺的行為進行關聯分析,判斷DPI用戶上網行為偏好與在應用平臺上的行為偏好是否存在關聯關系,采用關聯算法找出其中存在的規則,并將規則固化到系統中,從而有助于交叉營銷。
· 個性化推薦模型:以協同過濾技術和內容推薦技術為主,采用混合推薦技術,綜合考慮來自產品內容和用戶兩個維度的影響,按照綜合相似度向用戶推薦相應的信息,實現用戶動態推薦算法。
· 文本挖掘模型:對文本內容(如網頁)通過預處理去除噪聲(如網頁導航欄、頁首、頁尾、廣告等不相關內容),提取出文本主體部分,根據文本(網頁)分類標準構造標注語料庫,通過分類訓練算法進行模型訓練和機器學習,建立文本(網頁)人工智能分類模型。
·DPI訪問偏好模型:基于網頁內容分類,通過用戶訪問網頁分析,計算用戶Web訪問興趣偏好。
·DPI應用偏好模型:基于DPI采集數據,通過應用知識庫識別應用,計算用戶應用興趣偏好。
· 應用平臺用戶偏好模型:依據用戶在應用平臺上的各種操作行為,找出用戶對應用平臺各種內容的偏好規律。
· 社交關系挖掘模型:社交關系挖掘包括用戶社交圖譜和興趣圖譜的構建。社交圖譜通過用戶的位置軌跡進行挖掘分析,建立用戶之間的好友等社交關系;興趣圖譜基于用戶偏好模型,計算用戶偏好的相似度,得到與用戶興趣最相近的鄰居集合,建立用戶之間的相同興趣愛好關系。
以上模型的建模過程中很多用到了MapReduce計算框架。在MapReduce計算框架中,每個MapReduce作業主要分為兩個階段:map階段和reduce階段,分別用map函數和reduce函數實現。map函數對一個
(1)job1:計算用戶對內容的偏好度
map函數:從Hbase中讀取用戶行為數據,組合相關的數據。key為用戶ID,value為用戶瀏覽過的內容信息(如游戲、視頻等)。
reduce函數:獲取每個用戶所有的行為信息,計算用戶對內容的偏好度。key為用戶ID+內容ID,value為內容偏好度。
(2)job2:計算用戶對內容屬性的偏好度
map函數:讀取內容偏好度信息傳給reduce函數。key為用戶ID,value為內容ID+內容偏好度。
reduce函數:計算每個用戶的內容屬性偏好度。
(3)job3:計算基于內容的推薦列表
map函數:獲取用戶內容屬性偏好度和用戶內容偏好度,key為用戶ID,value為屬性偏好度+內容偏好度。
reduce函數:計算推薦列表。
通過這種方式,系統把數據密集型的大數據用戶行為分析模型運算任務分配到各個計算節點分布式運行,從而大大提高模型運算性能。
為了驗證本文提出的基于云計算的移動互聯網大數據用戶行為分析引擎設計方案,在實驗室用PC服務器搭建了4個節點的Hadoop分布式平臺,其中一個為主節點,3個為從節點,以大數據入庫為測試場景,與單機運行環境進行對比,測試了5組不同數據規模情況下的系統運算時間,測試結果如圖5所示。

圖5 單機與分布式批量入庫測試性能對比
從測試結果可以看出,單機批量入庫方式的性能很低,對于 3 GB、6 GB、9 GB、12 GB、15 GB 的 5組數據規模,其系統運算時間分別為 32 min、60 min、95 min、121 min、151 min,系統運算時間隨著數據量的增長幾乎呈線性增長,對于海量的大數據來說,很難在合理的時間內快速完成數據的入庫操作;而采用云計算分布式批量入庫方式,系統處理時間大大縮短,對于3 GB、6 GB、9 GB、12 GB、15 GB 的5組數據規模來說,系統運算時間分別為14 min、29 min、35 min、47 min、55 min。從兩種方式的測試結果對比可以看出,隨著數據規模的增大,云計算分布式批量入庫方式與單機批量入庫方式的處理時間差距越大,優勢越明顯。
本文針對移動互聯網大數據時代給運營商帶來的挑戰,提出了一種基于云計算的移動互聯網大數據用戶行為分析引擎設計方案。通過實驗驗證,該方案能有效地應對移動互聯網新業務、新產品“短、平、快”的特征和數據規模急劇膨脹等問題,能夠在有效的時間內完成大數據處理和分析任務。
1 陳康,鄭緯民.云計算:系統實例與研究現狀.軟件學報,2009,20(5)
2 馮銘,王保進,蔡建宇.基于云計算的可重構移動互聯網用戶行為分析系統的設計.計算機科學,2011(8)
3 Anand Rajaraman,Jeffrey David Ullman.Mining of Massive Datasets.Cambridge University Press,2011