陳杰 蘇洋 唐勇 龐濤

【摘 要】為了滿足移動(dòng)終端游戲的精準(zhǔn)運(yùn)營需求，需要收集用戶行為數(shù)據(jù)，實(shí)時(shí)分析業(yè)務(wù)狀態(tài)，深度挖掘市場價(jià)值?；贙afka、Flume、Storm、Redis等開源技術(shù)，構(gòu)建了手機(jī)游戲大數(shù)據(jù)實(shí)時(shí)計(jì)算系統(tǒng)，實(shí)現(xiàn)了海量實(shí)時(shí)數(shù)據(jù)的采集、存儲(chǔ)、計(jì)算和查詢，并在現(xiàn)網(wǎng)實(shí)際系統(tǒng)中得到了成功應(yīng)用。

【關(guān)鍵詞】大數(shù)據(jù) 實(shí)時(shí)計(jì)算 開源 手機(jī)游戲

doi：10.3969/j.issn.1006-1010.2016.05.017 中圖分類號(hào)：TP399 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1006-1010（2016）05-0079-06

引用格式：陳杰，蘇洋，唐勇，等. 手機(jī)游戲大數(shù)據(jù)實(shí)時(shí)計(jì)算框架研究與實(shí)踐[J]. 移動(dòng)通信， 2016，40（5）： 79-84.

1 引言

在移動(dòng)互聯(lián)網(wǎng)時(shí)代，以手機(jī)游戲?yàn)榇淼囊苿?dòng)應(yīng)用得到了飛速的發(fā)展。為了實(shí)現(xiàn)精細(xì)化運(yùn)營，迫切要求針對(duì)海量數(shù)據(jù)能夠?qū)崿F(xiàn)實(shí)時(shí)計(jì)算結(jié)果以及秒級(jí)響應(yīng)速度。以移動(dòng)終端手機(jī)游戲平臺(tái)為例，需要處理的流式數(shù)據(jù)主要包括手機(jī)游戲用戶的PV/UV數(shù)值、頁面瀏覽情況、手機(jī)游戲內(nèi)容查找/登錄/支付情況等，這些均要求實(shí)時(shí)數(shù)據(jù)的計(jì)算和分析，以便可以動(dòng)態(tài)地獲取用戶訪問數(shù)據(jù)，展示手機(jī)游戲平臺(tái)實(shí)時(shí)流量的變化情況和用戶行為習(xí)慣等。面對(duì)海量的業(yè)務(wù)數(shù)據(jù)量，傳統(tǒng)的窮舉所有可能條件的查詢組合或者窮舉條件組合的方法失效。

基于分布式處理機(jī)制和實(shí)時(shí)計(jì)算架構(gòu)，將計(jì)算過程移至查詢階段，才能滿足互聯(lián)網(wǎng)業(yè)務(wù)海量數(shù)據(jù)計(jì)算和快速查詢響應(yīng)的需求。

2 實(shí)時(shí)計(jì)算處理流程

對(duì)互聯(lián)網(wǎng)業(yè)務(wù)的海量數(shù)據(jù)（主要為日志流）的實(shí)時(shí)計(jì)算可劃分為三大主要階段：數(shù)據(jù)采集、實(shí)時(shí)計(jì)算處理分析和實(shí)時(shí)查詢展示階段。

在數(shù)據(jù)采集階段，通常采用主要互聯(lián)網(wǎng)公司提供的開源的海量數(shù)據(jù)采集工具，滿足每秒數(shù)百M(fèi)B的日志數(shù)據(jù)采集和傳輸要求，如Facebook的Scribe、LinkedIn的Kafka、Cloudera的Flume，淘寶的TimeTunnel、Hadoop的Chukwa等。

在數(shù)據(jù)實(shí)時(shí)計(jì)算分析階段，首先將數(shù)據(jù)采集并存儲(chǔ)在DBMS（Database Management System，數(shù)據(jù)庫管理系統(tǒng)）中，然后通過查詢和DBMS進(jìn)行交互。但對(duì)于現(xiàn)階段大量存在的實(shí)時(shí)數(shù)據(jù)，比如手機(jī)游戲交易/支付的數(shù)據(jù)，一般采用流計(jì)算技術(shù)。

在實(shí)時(shí)流計(jì)算框架方面，Yahoo推出的開源架構(gòu)S4，Twitter使用的Storm，以及業(yè)界較為常見的Esper、Streambase、HStreaming等相關(guān)技術(shù)架構(gòu)，均基于分布式并行計(jì)算（節(jié)點(diǎn)間的并行、節(jié)點(diǎn)內(nèi)的并行）和熱點(diǎn)數(shù)據(jù)的緩存處理等技術(shù)，提供實(shí)時(shí)計(jì)算服務(wù)。

在實(shí)時(shí)查詢展示階段，按照前端展示或者計(jì)算結(jié)果存儲(chǔ)位置的不同可分為：1）直接提供數(shù)據(jù)讀取服務(wù)，定期采用進(jìn)程的內(nèi)存鏡像到磁盤或數(shù)據(jù)庫全內(nèi)存方法；2）采用Redis、Memcache、MongoDB、BerkeleyDB等內(nèi)存數(shù)據(jù)庫提供數(shù)據(jù)實(shí)時(shí)查詢的半內(nèi)存方法等。

3 手機(jī)游戲大數(shù)據(jù)實(shí)時(shí)計(jì)算

本文提出了手機(jī)游戲大數(shù)據(jù)實(shí)時(shí)計(jì)算架構(gòu)，采用Kafka+Flume集群完成實(shí)時(shí)數(shù)據(jù)采集，利用Storm框架完成數(shù)據(jù)實(shí)時(shí)計(jì)算，采用Redis+HBase模式構(gòu)建查詢服務(wù)，滿足了數(shù)據(jù)本地磁盤存儲(chǔ)的安全性和長久性，實(shí)現(xiàn)基于內(nèi)存提升查詢速度。

3.1 實(shí)時(shí)計(jì)算架構(gòu)

穩(wěn)定可靠且高效的底層架構(gòu)是實(shí)時(shí)計(jì)算的必要基礎(chǔ)。圖1給出了手機(jī)游戲大數(shù)據(jù)實(shí)時(shí)計(jì)算平臺(tái)的總體框架，如圖所示包含數(shù)據(jù)采集、數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)處理、數(shù)據(jù)應(yīng)用四個(gè)層級(jí)。

數(shù)據(jù)采集對(duì)象主要是全體日志數(shù)據(jù)。按照統(tǒng)一規(guī)則整合，為數(shù)據(jù)應(yīng)用提供實(shí)時(shí)數(shù)據(jù)。手機(jī)游戲日志主要包括兩大來源，一是日志服務(wù)器集群實(shí)時(shí)上傳的日志；二是業(yè)務(wù)接口后臺(tái)服務(wù)器實(shí)時(shí)打印的日志。實(shí)時(shí)日志采集框架如圖2所示：

將Flume部署在上述兩大類日志源服務(wù)器上，作為海量日志實(shí)時(shí)采集的框架。如圖2所示，F(xiàn)lume NG節(jié)點(diǎn)由Source、Channel、Sink三部分組成。Channel將Source和Sink連接起來。Flume的Source將外部數(shù)據(jù)源傳遞的數(shù)據(jù)封裝成Flume數(shù)據(jù)模型的最小單位event。該數(shù)據(jù)源主要是業(yè)務(wù)接口實(shí)時(shí)產(chǎn)生的日志文件，使用操作系統(tǒng)原生類型exec來執(zhí)行命令：tail-f/pathname/filename.xxx采集。此方式簡單可靠，適合采集業(yè)務(wù)接口實(shí)時(shí)打印的日志。同時(shí)還需要打開Source的restart開關(guān)，當(dāng)進(jìn)程由于某種原因僵死后，可以自動(dòng)重啟。手機(jī)游戲行為數(shù)據(jù)由客戶端統(tǒng)計(jì)SDK和業(yè)務(wù)接口產(chǎn)生。為了更好地區(qū)分有效日志與程序調(diào)試或其它用途的內(nèi)容，約定了統(tǒng)一的實(shí)時(shí)日志前綴“[REALDATA]”來減少Flume Agent的日志量，提高了日志采集效率。

數(shù)據(jù)存儲(chǔ)層提供了實(shí)時(shí)數(shù)據(jù)處理層需要的類分布式存儲(chǔ)，主要采用了分布式消息隊(duì)列（Apache Kafka）和Apache Zookeeper。通過Flume NG節(jié)點(diǎn)的Sink配置a2.sinks.k1.type=org.apache.flume.sink.KafkaSink，采集數(shù)據(jù)并實(shí)時(shí)存放在Kafka中。

數(shù)據(jù)實(shí)時(shí)處理層采用Storm實(shí)時(shí)從Kafka獲取數(shù)據(jù)。在Storm中，首先需要設(shè)計(jì)一個(gè)用于實(shí)時(shí)計(jì)算的圖狀結(jié)構(gòu)拓?fù)?。拓?fù)鋵⒈惶峤唤o集群，由集群中的主控節(jié)點(diǎn)分發(fā)代碼，將任務(wù)分配給工作節(jié)點(diǎn)執(zhí)行。一個(gè)拓?fù)渲邪⊿pout和Bolt兩種角色，Spout發(fā)送消息，負(fù)責(zé)從Kafka中將數(shù)據(jù)流以tuple元組的形式發(fā)送出去；Bolt則負(fù)責(zé)轉(zhuǎn)換這些數(shù)據(jù)流，完成計(jì)算、過濾等操作。Bolt自身也可以隨機(jī)將數(shù)據(jù)發(fā)送給其他Bolt。由Spout發(fā)射出的tuple是不可變數(shù)組，對(duì)應(yīng)著固定的鍵值對(duì)。相關(guān)的組件架構(gòu)和數(shù)據(jù)流如圖3所示：

Storm計(jì)算后的數(shù)據(jù)結(jié)果將被實(shí)時(shí)地寫入Redis緩存、Mysql、HDFS、HBase中。其中寫入Redis的數(shù)據(jù)用于實(shí)時(shí)展示運(yùn)算結(jié)果，寫入Mysql、HDFS中的數(shù)據(jù)用于后續(xù)的離線計(jì)算任務(wù)，寫入HBase的數(shù)據(jù)可當(dāng)作中間結(jié)果使用。

在實(shí)時(shí)數(shù)據(jù)應(yīng)用層，將根據(jù)業(yè)務(wù)的需要來開發(fā)各類實(shí)時(shí)應(yīng)用，比如手機(jī)游戲分發(fā)平臺(tái)實(shí)時(shí)用戶數(shù)、下載量、收入等。

3.2 實(shí)時(shí)計(jì)算方法

要實(shí)現(xiàn)大數(shù)據(jù)實(shí)時(shí)計(jì)算，僅有框架是不行的，還必須為每個(gè)業(yè)務(wù)設(shè)計(jì)一套專用的處理流程和算法。與離線計(jì)算相比，實(shí)時(shí)計(jì)算在算法上需要考慮的情況更復(fù)雜，這是因?yàn)閷?shí)時(shí)計(jì)算所用到的存儲(chǔ)資源遠(yuǎn)不如離線數(shù)據(jù)，但處理的時(shí)間限制要比離線計(jì)算嚴(yán)格，這都要求實(shí)時(shí)計(jì)算算法必須做更多的優(yōu)化來提升計(jì)算的效率。

以下將以中國電信愛游戲基地手機(jī)游戲業(yè)務(wù)的海量計(jì)數(shù)需求為例，設(shè)計(jì)和優(yōu)化相關(guān)實(shí)時(shí)計(jì)算算法。目前愛游戲手機(jī)游戲業(yè)務(wù)包含近千萬的用戶下載、手機(jī)游戲啟動(dòng)和付費(fèi)數(shù)據(jù)，實(shí)時(shí)追蹤這些數(shù)據(jù)是必須的，這也是個(gè)性化推薦、付費(fèi)預(yù)測和用戶畫像等業(yè)務(wù)的前提。為此，急需設(shè)計(jì)一種算法可實(shí)時(shí)查看任意用戶近24小時(shí)的下載次數(shù)、啟動(dòng)次數(shù)、付費(fèi)次數(shù)等業(yè)務(wù)指標(biāo)。

（1）簡化方案

簡化方案示意圖如圖4所示：

圖中藍(lán)色、黃色和綠色表示不同的用戶，此方案為每個(gè)用戶保存一份付費(fèi)信息，它包含兩個(gè)數(shù)據(jù)結(jié)構(gòu)：

a）歷史付費(fèi)列表（簡稱“歷史”），該列表中每個(gè)元素包含一個(gè)時(shí)間戳和一個(gè)整數(shù)，分別代表過去24小時(shí)中某一秒鐘的啟動(dòng)數(shù)據(jù)并按時(shí)間排序。該列表最多可包含24×3600=86400個(gè)元素，但一般情況不會(huì)超過100個(gè)。

b）累計(jì)付費(fèi)數(shù)據(jù)（簡稱“累計(jì)量”），代表截止到最后一次付費(fèi)時(shí)的付費(fèi)次數(shù)。

如圖4所示，假設(shè)藍(lán)色用戶對(duì)應(yīng)的數(shù)據(jù)是[（t1，a1）， （t2，a2）， …， （tn，an）]和A。這表示t1時(shí)刻的用戶付費(fèi)次數(shù)是a1，t2時(shí)刻是a2，以此類推，累計(jì)量是A。當(dāng)用戶付費(fèi)數(shù)據(jù)不斷進(jìn)入消息隊(duì)列時(shí)，處理進(jìn)程（或者線程）P1， P2…會(huì)實(shí)時(shí)讀取到這些信息并修改對(duì)應(yīng)用戶的數(shù)據(jù)。如P1讀取到t時(shí)刻藍(lán)色用戶的付費(fèi)記錄時(shí)，會(huì)進(jìn)行下面的操作：

a）得到當(dāng)前時(shí)刻ct；

b）對(duì)數(shù)據(jù)庫中藍(lán)色用戶加鎖，加鎖成功后讀取數(shù)據(jù)，假設(shè)為[（t1，a1）， （t2，a2）， …， （tn，an）]，累計(jì)量為A；

c）累計(jì)量遞增：A=A+1；

d）歷史量更新：如果ct=tn，[（t1，a1）， （t2，a2）， …， （tn，an+1）]，否則更新為[（t1，a1）， （t2，a2）， …， （tn，an）， （ct，1）]；最后刪除時(shí)間戳小于ct-24×3600的元素，刪除的同時(shí)從累計(jì)量中減去對(duì)應(yīng)時(shí)刻的啟動(dòng)量；

e）將新的歷史和累計(jì)量輸出至數(shù)據(jù)庫并釋放鎖。

此方案可正確得到每個(gè)用戶24小時(shí)內(nèi)的付費(fèi)次數(shù)，并且只要在資源（計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)）充足的情況下，數(shù)據(jù)庫中用戶的付費(fèi)次數(shù)是實(shí)時(shí)更新的。此方案也是分布式實(shí)時(shí)計(jì)算中最簡單、最常見的一種。

（2）優(yōu)化方案

簡化方案中需要對(duì)數(shù)據(jù)庫加鎖，無論加鎖的粒度有多細(xì)，都會(huì)影響計(jì)算效率。要想提高實(shí)時(shí)處理效率，減少鎖是非常重要的。一種常見的做法是將并行操作串行化，MapReduce中的Reduce，將key相同的數(shù)據(jù)交給同一個(gè)Reducer處理。基于此原理將方案改造如圖5所示：

新增一個(gè)key的HASH處理，保證相同的用戶可以落到相同的處理程序上。由于不存在資源競爭，處理過程不需要對(duì)數(shù)據(jù)庫加鎖。此方案可大大提高計(jì)算效率，整個(gè)計(jì)算過程變?yōu)椋?/p>

b）讀取藍(lán)色用戶數(shù)據(jù)，設(shè)為[（t1，a1）， （t2，a2）， …， （tn，an）]，累計(jì)量為A；

c）累計(jì)量遞增：A=A+1；

d）歷史量更新：如果ct=tn， [（t1，a1）， （t2，a2）， …， （tn，an+1）]，否則更新為[（t1，a1）， （t2，a2）， …， （tn，an）， （ct，1）]；最后刪除時(shí)間戳小于ct-24×3600的元素，刪除的同時(shí)從累積量中減去對(duì)應(yīng)時(shí)刻的啟動(dòng)量；

e）將新的歷史和累計(jì)量直接輸出至數(shù)據(jù)庫。

步驟b）和e）省去了鎖操作，整個(gè)系統(tǒng)的并發(fā)和吞吐量均大大提高。但此方案的缺點(diǎn)是存在單點(diǎn)隱患。一旦P1由于某些原因失效，則藍(lán)色用戶的數(shù)據(jù)將得不到及時(shí)處理，計(jì)算結(jié)果將無法實(shí)時(shí)保障。

在上述計(jì)算步驟b）和e）中總是把歷史和累計(jì)量從數(shù)據(jù)庫中讀寫。但在實(shí)際應(yīng)用中只關(guān)心實(shí)時(shí)累計(jì)值，而歷史數(shù)據(jù)僅用于計(jì)算累計(jì)值，并不需要實(shí)時(shí)持久化。為此，在最終方案中，區(qū)別對(duì)待歷史和累計(jì)量，將歷史和累計(jì)量都緩存在計(jì)算進(jìn)程中，定期更新歷史數(shù)據(jù)到數(shù)據(jù)庫，而累計(jì)量則實(shí)時(shí)更新。最終改良優(yōu)化的方案如圖6所示：

計(jì)算過程為：

b）如果本地沒有藍(lán)色用戶信息，從數(shù)據(jù)庫中讀取藍(lán)色用戶數(shù)據(jù)；否則直接使用本地緩存信息。假設(shè)為[（t1，a1）， （t2，a2）， …， （tn，an）]，累計(jì)量為A；

d）將新的累積量輸出至數(shù)據(jù)庫，如果滿足一定條件（距離上次時(shí)間間隔足夠遠(yuǎn)，或者積累的消息達(dá)到一定量），則將歷史數(shù)據(jù)輸出至數(shù)據(jù)庫。

最終方案可大大降低數(shù)據(jù)庫壓力、I/O和序列化反序列化次數(shù)，從而提高效率。此方案對(duì)系統(tǒng)的穩(wěn)定性要求更高，一旦P1失效則緩存數(shù)據(jù)將永久丟失。

（3）存儲(chǔ)模糊化處理方案

在數(shù)據(jù)存儲(chǔ)時(shí)，假設(shè)時(shí)間戳和整型均為long型（8字節(jié)），按照簡化方案估算，每個(gè)用戶所需要保存的歷史數(shù)據(jù)大小為100×（8+8）=1600字節(jié)≈1.56kB，1000萬用戶的總量將有15G。若考慮到數(shù)據(jù)庫和本地緩存，則系統(tǒng)存儲(chǔ)量至少要30G，由此存在較大的空間浪費(fèi)。

在優(yōu)化過程中，為了降低歷史的存儲(chǔ)密度，將精度定義為小時(shí)級(jí)別，這樣每個(gè)用戶歷史數(shù)據(jù)為24個(gè)，數(shù)據(jù)量為384字節(jié)，1000萬用戶的數(shù)據(jù)總量為3.6G，數(shù)據(jù)庫和緩存的總存儲(chǔ)量不超過8G。更近一步，使用一個(gè)字節(jié)保存當(dāng)前小時(shí)段，使用包含24個(gè)long型的數(shù)組表示付費(fèi)次數(shù)，則數(shù)據(jù)量將固定在196個(gè)字節(jié)，總存儲(chǔ)量不超過4G。步驟如下：

a）得到當(dāng)前時(shí)刻精確到小時(shí)的部分ct；

b）如果本地沒有藍(lán)色用戶信息，從數(shù)據(jù)庫中讀取藍(lán)色用戶數(shù)據(jù)；否則直接使用本地緩存信息。假設(shè)為[time， a1， a2， …， a24]，累計(jì)量為A；

c）累計(jì)量遞增：A=A+1；

d）歷史量更新：令當(dāng)前小時(shí)段為hour，如果ct=time，[time， a1， a2， …， ahour+1， …， a24]，否則更新為[ct， a1， a2， …， 1， …， a24]；最后將時(shí)間坐標(biāo)小于ct-24的元素置為0，同時(shí)A減去對(duì)應(yīng)時(shí)刻的付費(fèi)數(shù)；

e）將新的累積量輸出至數(shù)據(jù)庫，如果滿足一定條件（距離上次時(shí)間間隔足夠遠(yuǎn)，或者積累的消息達(dá)到一定量），則將歷史數(shù)據(jù)輸出至數(shù)據(jù)庫。

存儲(chǔ)模糊化處理示意圖如圖7所示：

4 應(yīng)用效果

4.1 實(shí)時(shí)業(yè)務(wù)監(jiān)控

為了實(shí)時(shí)監(jiān)控手機(jī)游戲平臺(tái)的訪問、下載、收入等情況，將實(shí)時(shí)統(tǒng)計(jì)好的數(shù)據(jù)包存放在Redis中，然后搭建web監(jiān)控系統(tǒng)，圖形化展示多維度的實(shí)時(shí)數(shù)據(jù)。同時(shí)針對(duì)重要的業(yè)務(wù)接口，監(jiān)控每分鐘的連接數(shù)等指標(biāo)，及時(shí)發(fā)現(xiàn)異常日志并報(bào)警，可有效識(shí)別出攻擊和惡意用戶點(diǎn)擊行為。經(jīng)實(shí)際測算，每秒平均運(yùn)算量超3000條，峰值超10 000條，日處理日志總數(shù)超3億條。

4.2 用戶實(shí)時(shí)關(guān)懷

為了提醒用戶的消費(fèi)行為，需要實(shí)時(shí)計(jì)算所有用戶每一次的付費(fèi)行為。如當(dāng)用戶的付費(fèi)總額達(dá)到某一閾值，或首次在平臺(tái)、渠道進(jìn)行付費(fèi)時(shí)，該系統(tǒng)會(huì)立刻給用戶發(fā)送關(guān)懷短信，提醒用戶的消費(fèi)行為，或提醒其參加抽獎(jiǎng)等營銷活動(dòng)。

該功能上線后，新增付費(fèi)用戶的注冊轉(zhuǎn)化率提升3.3%，手機(jī)游戲平臺(tái)投訴用戶下降明顯，萬投比下降8.2。

5 結(jié)束語

本文采用Kafka+Flume集群完成實(shí)時(shí)數(shù)據(jù)采集、采用Storm框架完成數(shù)據(jù)實(shí)時(shí)計(jì)算、采用Redis+HBase模式構(gòu)建實(shí)時(shí)查詢服務(wù)，構(gòu)建了手機(jī)游戲大數(shù)據(jù)實(shí)時(shí)計(jì)算系統(tǒng)。在實(shí)時(shí)計(jì)算方面，為了滿足千萬級(jí)業(yè)務(wù)數(shù)據(jù)的實(shí)時(shí)查詢需求，設(shè)計(jì)了兩種算法。一是需要數(shù)據(jù)加鎖的簡化計(jì)算方案，二是為了提高效率，去除數(shù)據(jù)鎖的并行操作分布式串行化處理的優(yōu)化方案，同時(shí)還進(jìn)行了數(shù)據(jù)分層處理優(yōu)化，降低了數(shù)據(jù)庫壓力。在數(shù)據(jù)存儲(chǔ)方面，結(jié)合模糊化處理方式優(yōu)化數(shù)據(jù)存儲(chǔ)，將存儲(chǔ)資源要求減少到常規(guī)的12%。本項(xiàng)目成果在中國電信愛游戲基地平臺(tái)得到了成功應(yīng)用，每秒平均運(yùn)算量超3000條，峰值超10 000條，日處理日志總數(shù)超3億條。該框架可為其他業(yè)務(wù)平臺(tái)大數(shù)據(jù)實(shí)時(shí)計(jì)算提供良好的參考和借鑒。

參考文獻(xiàn)：

[1] 蘇洋，劉曉軍，唐勇，等. 游戲大數(shù)據(jù)平臺(tái)研究與實(shí)踐[J]. 電信科學(xué)， 2014（10）： 21-26.

[2] 周江，王偉平，孟丹，等. 面向大數(shù)據(jù)分析的分布式文件系統(tǒng)關(guān)鍵技術(shù)[J]. 計(jì)算機(jī)研究與發(fā)展， 2014（2）： 382-394.

[3] 胡宇舟，范濱，顧學(xué)道，等. 基于Storm的云計(jì)算在自動(dòng)清分系統(tǒng)中的實(shí)時(shí)數(shù)據(jù)處理應(yīng)用[J]. 計(jì)算機(jī)應(yīng)用， 2014（S1）： 96-99.

[4] 唐云善，楊志. 一種高效的大數(shù)據(jù)實(shí)時(shí)性解決方案[J]. 計(jì)算機(jī)與數(shù)字工程， 2014（4）： 678-684.

[5] 趙輝，楊樹強(qiáng)，陳志坤，等. 基于MapReduce模型的范圍查詢分析優(yōu)化技術(shù)研究[J]. 計(jì)算機(jī)研究與發(fā)展， 2014（3）： 606-617.

[6] 張華，王東輝，吳烜. 流式計(jì)算的分布式框架的應(yīng)用[J]. 信息與電腦：理論版， 2014（10）： 142-143.

[7] 黃馥浩. 基于Storm的微博互動(dòng)平臺(tái)的設(shè)計(jì)與實(shí)現(xiàn)[D]. 廣州： 中山大學(xué)， 2013.

[8] 高鵬. 當(dāng)新媒體遇到“大數(shù)據(jù)”[J]. 廣播與電視技術(shù)， 2012（10）： 38.

[9] 劉林林. 大數(shù)據(jù)時(shí)代數(shù)據(jù)分析與信息安全[J]. 網(wǎng)絡(luò)安全技術(shù)與應(yīng)用， 2013（12）： 59.

[10] 呂明育. Hadoop架構(gòu)下數(shù)據(jù)挖掘與數(shù)據(jù)遷移系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[D]. 上海： 上海交通大學(xué)， 2013.

[11] 謝超. 大數(shù)據(jù)下的數(shù)據(jù)分析平臺(tái)架構(gòu)[J]. 程序員， 2011（8）： 55-58. ★