基于通信運(yùn)營(yíng)商數(shù)據(jù)的大數(shù)據(jù)實(shí)時(shí)流處理系統(tǒng)

朱奕健 張正卿

【摘要】 本文利用流式數(shù)據(jù)處理框架探索了一種新的基于運(yùn)營(yíng)商實(shí)時(shí)大數(shù)據(jù)業(yè)務(wù)系統(tǒng)構(gòu)建模式。首先，在充分研究了業(yè)內(nèi)實(shí)時(shí)流式處理技術(shù)的發(fā)展以及運(yùn)營(yíng)商本身實(shí)時(shí)數(shù)據(jù)源的特點(diǎn)之后，確定以Flume作為實(shí)時(shí)采集和分流組件，Kafka作為緩存和多模塊通信組件，以Spark Streaming的分布式結(jié)構(gòu)作為數(shù)據(jù)ETL集群；然后，利用該系統(tǒng)進(jìn)行了重點(diǎn)區(qū)域的人流實(shí)時(shí)監(jiān)控的業(yè)務(wù)，在實(shí)施過(guò)程中為了提供毫秒級(jí)的數(shù)據(jù)結(jié)果流查詢能力，采用了Redis組件提供基于內(nèi)存的Key-Value引擎；最終，通過(guò)流式數(shù)據(jù)處理效率的對(duì)比和實(shí)時(shí)監(jiān)控的人流效果，我們驗(yàn)證了了這種新的技術(shù)架構(gòu)針對(duì)運(yùn)營(yíng)商CS域和PS域數(shù)據(jù)實(shí)時(shí)處理需求的可行性，結(jié)果表明，新的實(shí)時(shí)業(yè)務(wù)架構(gòu)能更加有效的提高從實(shí)時(shí)采集到業(yè)務(wù)觸發(fā)的運(yùn)行效率，并且為公安部門在重大節(jié)假日的區(qū)域級(jí)人流監(jiān)控、預(yù)警和疏導(dǎo)提供了技術(shù)保障。

【關(guān)鍵詞】 大數(shù)據(jù) 流處理 簡(jiǎn)單事件處理引擎（PME） Flume Kafka

一、引言

隨著網(wǎng)絡(luò)、通信和傳感器應(yīng)用的飛速發(fā)展，尤其是移動(dòng)通信全面進(jìn)入移動(dòng)互聯(lián)網(wǎng)時(shí)代，直接帶來(lái)通信網(wǎng)絡(luò)中的數(shù)據(jù)復(fù)雜度、信息量迅速增長(zhǎng)，諸多的移動(dòng)設(shè)備實(shí)時(shí)收集用戶各種信息，如位置、喜愛(ài)偏好、移動(dòng)軌跡、血壓、體溫等，帶來(lái)數(shù)據(jù)的規(guī)模、種類和關(guān)聯(lián)性等急劇膨脹?！按髷?shù)據(jù)”成為時(shí)下各個(gè)行業(yè)中出現(xiàn)頻率最高的關(guān)鍵詞之一。思科估算在2015年僅移動(dòng)網(wǎng)絡(luò)的數(shù)據(jù)量將突破6EB/月，相當(dāng)于億字節(jié)的海量數(shù)據(jù)；而IDC預(yù)計(jì)到2020年全世界的數(shù)據(jù)存儲(chǔ)總量將達(dá)到35萬(wàn)億GB。大數(shù)據(jù)時(shí)代的到來(lái)使得隱藏在海量數(shù)據(jù)中的信息開(kāi)始深刻的影響著人們的日常生活。當(dāng)顧客在網(wǎng)上購(gòu)物時(shí)，推薦系統(tǒng)會(huì)根據(jù)從海量數(shù)據(jù)中挖掘出的信息向其推薦適合的商品；當(dāng)乘客出行時(shí)，打車軟件又替他們搜索周圍空閑出租車并選擇最優(yōu)車輛來(lái)提供服務(wù)；當(dāng)病人看病時(shí)，醫(yī)生又會(huì)根據(jù)該病人的日常醫(yī)療數(shù)據(jù)制定最優(yōu)的治療方案。

而隨著4G時(shí)代的到來(lái)，移動(dòng)通信業(yè)務(wù)已經(jīng)正式全面進(jìn)入移動(dòng)互聯(lián)網(wǎng)時(shí)代，飛速發(fā)展的移動(dòng)網(wǎng)絡(luò)帶寬直接帶來(lái)繁雜的應(yīng)用和用戶行為，而通信網(wǎng)絡(luò)中的數(shù)據(jù)復(fù)雜度、信息量都隨之迅速增長(zhǎng)，通信運(yùn)營(yíng)商所能掌握的數(shù)據(jù)量級(jí)與日俱增，導(dǎo)致數(shù)據(jù)處理的復(fù)雜度和運(yùn)算量要求都隨之有了更高的要求，傳統(tǒng)數(shù)據(jù)庫(kù)體系的數(shù)據(jù)處理能力受到了極大的挑戰(zhàn)，面對(duì)海量數(shù)據(jù)處理需求和更低的時(shí)延性限制要求，傳統(tǒng)數(shù)據(jù)系統(tǒng)投入的CPU計(jì)算能力、內(nèi)存響應(yīng)和吞吐、網(wǎng)絡(luò)帶寬都有著巨大的基準(zhǔn)，且在高安全性，多中心的發(fā)展趨勢(shì)下面臨諸多的瓶頸。

大數(shù)據(jù)時(shí)代的到來(lái)使單節(jié)點(diǎn)的計(jì)算模式已經(jīng)不能滿足數(shù)據(jù)處理的需求，分布式數(shù)據(jù)處理與存儲(chǔ)系統(tǒng)逐步成為大數(shù)據(jù)平臺(tái)首選的架構(gòu)，包括Hadoop，MongoDB等開(kāi)放型的大數(shù)據(jù)技術(shù)成為了眾相研究的熱點(diǎn)。而Hadoop大數(shù)據(jù)平臺(tái)主要基于靜態(tài)數(shù)據(jù)文件的并行處理，雖然在海量數(shù)據(jù)吞吐、計(jì)算、存儲(chǔ)方面有著極高的效率，但是實(shí)時(shí)性較差，屬于高吞吐，高并發(fā)，高時(shí)延的架構(gòu)，對(duì)于小文件的處理性能一直是其不可回避的問(wèn)題，故針對(duì)一些實(shí)時(shí)性較高的數(shù)據(jù)處理和使用場(chǎng)景下無(wú)能為力?；谶@樣的原因，面對(duì)動(dòng)態(tài)數(shù)據(jù)處理的需求，實(shí)時(shí)流式數(shù)據(jù)處理技術(shù)應(yīng)運(yùn)而生。

隨著針對(duì)數(shù)據(jù)流的研究逐漸進(jìn)入學(xué)術(shù)界，大規(guī)模動(dòng)態(tài)數(shù)據(jù)集（也稱為實(shí)時(shí)數(shù)據(jù)流）成為研究及工程人員爭(zhēng)相探索的熱點(diǎn)領(lǐng)域[12]。而實(shí)時(shí)流式數(shù)據(jù)具有海量性、實(shí)時(shí)性和動(dòng)態(tài)變化性三個(gè)基本特點(diǎn)，基于這些特性，數(shù)據(jù)研究領(lǐng)域內(nèi)發(fā)展了諸多的研究方向。如流式數(shù)據(jù)處理的數(shù)學(xué)工具研究[11]，研究如何保證在數(shù)據(jù)流處理過(guò)程中的QoS服務(wù)質(zhì)量[2]，研究利用滑動(dòng)窗口來(lái)實(shí)現(xiàn)實(shí)時(shí)流數(shù)據(jù)處理[1][8]，基于實(shí)時(shí)性流數(shù)據(jù)查詢算法的優(yōu)化[3]，研究數(shù)據(jù)流的分布式處理和最后聚集[6]，流式數(shù)據(jù)的實(shí)時(shí)分類[9]。也有融合流處理技術(shù)在其他科技領(lǐng)域來(lái)完成復(fù)雜性的計(jì)算，如射頻標(biāo)簽領(lǐng)域的實(shí)時(shí)數(shù)據(jù)處理[4]，高速網(wǎng)絡(luò)中的數(shù)據(jù)流模型設(shè)計(jì)[7]，數(shù)據(jù)流量變化的處理模型[10]。而在大數(shù)據(jù)應(yīng)用領(lǐng)域，更多的企業(yè)在開(kāi)發(fā)如何利用流處理技術(shù)來(lái)構(gòu)造一個(gè)企業(yè)級(jí)的實(shí)時(shí)性數(shù)據(jù)業(yè)務(wù)平臺(tái)[5]

本論文所有的研究都集中在如何構(gòu)造基于運(yùn)營(yíng)商大數(shù)據(jù)流處理系統(tǒng)方面，主要圍繞實(shí)時(shí)性的業(yè)務(wù)場(chǎng)景下，如何從數(shù)據(jù)產(chǎn)生，數(shù)據(jù)采集，到數(shù)據(jù)流的處理，再到實(shí)時(shí)業(yè)務(wù)規(guī)則匹配的過(guò)程中尋找最佳流式數(shù)據(jù)平臺(tái)的架構(gòu)展開(kāi)研究。全文采用總分結(jié)構(gòu)給出了實(shí)時(shí)流處理系統(tǒng)的構(gòu)建思路：在第二節(jié)，對(duì)實(shí)時(shí)流處理系統(tǒng)的整體架構(gòu)進(jìn)行整體性闡述；第三節(jié)主要闡述采用Flume+Kafka+SparkStreaming架構(gòu)來(lái)有效解決Hadoop系統(tǒng)對(duì)于小數(shù)據(jù)的流式處理效率的提高；在第四節(jié)中，通過(guò)該系統(tǒng)成功實(shí)現(xiàn)針對(duì)固定區(qū)域進(jìn)行實(shí)時(shí)人流監(jiān)控的業(yè)務(wù)場(chǎng)景，最后，針對(duì)整個(gè)系統(tǒng)對(duì)于流式處理的效率和實(shí)時(shí)監(jiān)控效果進(jìn)行總結(jié)，并形成研究結(jié)論和下一步的研究計(jì)劃。

二、流式大數(shù)據(jù)系統(tǒng)綜述

流式大數(shù)據(jù)系統(tǒng)的總體架構(gòu)如圖1所示。

整個(gè)系統(tǒng)的流處理框架使用了學(xué)術(shù)界內(nèi)公認(rèn)較為高效的開(kāi)源組件，整體系統(tǒng)實(shí)時(shí)數(shù)據(jù)來(lái)源于兩方面：

PS域數(shù)據(jù)：基于移動(dòng)網(wǎng)絡(luò)Gn口中的全量用戶移動(dòng)上網(wǎng)數(shù)據(jù)；

CS域數(shù)據(jù)：基于信令網(wǎng)絡(luò)中A口中的基站定位數(shù)據(jù)。

在系統(tǒng)底層，利用Flume組件來(lái)實(shí)時(shí)采集匯攏2種來(lái)源的數(shù)據(jù)，并根據(jù)上層數(shù)據(jù)需求進(jìn)行分流，對(duì)于需要實(shí)時(shí)處理的數(shù)據(jù)實(shí)時(shí)傳送至Kafka集群，對(duì)于非實(shí)時(shí)性數(shù)據(jù)挖掘模型需要的靜態(tài)數(shù)據(jù)來(lái)形成文件寫(xiě)入Hadoop集群的HDFS文件。

在實(shí)時(shí)數(shù)據(jù)的ETL層，采用Kafka組件來(lái)完成所有的數(shù)據(jù)流緩存，該架構(gòu)可以保證整體數(shù)據(jù)流通訊的可靠性以及短時(shí)延的對(duì)外服務(wù)能力。一些復(fù)雜的數(shù)據(jù)挖掘和處理通過(guò)分布式的流式處理結(jié)構(gòu)-Spark streaming來(lái)實(shí)施，該架構(gòu)充分的結(jié)合了Hadoop的分布式處理的思想和內(nèi)存數(shù)據(jù)庫(kù)的實(shí)時(shí)處理效率，充分保證整體處理過(guò)程的高并發(fā)、低時(shí)延，并實(shí)現(xiàn)了數(shù)據(jù)內(nèi)容和挖掘能力的高魯棒性。而諸多簡(jiǎn)單業(yè)務(wù)規(guī)則和數(shù)據(jù)的匹配則通過(guò)引入簡(jiǎn)單事件匹配引擎（PME）來(lái)完成。處理結(jié)果最終會(huì)回寫(xiě)到Kafka中供應(yīng)用層調(diào)用。

在實(shí)時(shí)業(yè)務(wù)層，實(shí)時(shí)數(shù)據(jù)處理結(jié)果通過(guò)Kafka來(lái)被業(yè)務(wù)觸發(fā)系統(tǒng)調(diào)用，結(jié)合Hadoop的靜態(tài)數(shù)據(jù)挖掘結(jié)果（非實(shí)時(shí)），來(lái)形成最終的業(yè)務(wù)觸發(fā)，而在部分業(yè)務(wù)場(chǎng)景需求中，為了提高整個(gè)處理效率，我們采用了Redis（內(nèi)存Key-Value引擎）來(lái)提供數(shù)據(jù)關(guān)聯(lián)查詢。

三、流式大數(shù)據(jù)處理效率提高

3.1針對(duì)靜態(tài)數(shù)據(jù)的小文件處理效率提升

小文件指的是那些Size比HDFS的Block Size（默認(rèn)64M）小很多的文件。如果在HDFS中存儲(chǔ)許許多多這樣的小文件，我們發(fā)現(xiàn)HDFS根本無(wú)法很有效的處理數(shù)量龐大的小文件。任何一個(gè)文件，目錄和Block，在HDFS中都會(huì)被表示為一個(gè)Object存儲(chǔ)在NameNode的內(nèi)存中，每一個(gè)Object占用150Bytes的內(nèi)存空間。所以，如果有10 Million個(gè)文件，每一個(gè)文件對(duì)應(yīng)一個(gè)Block，那么就將要消耗NameNode 3G的內(nèi)存來(lái)保存這些Block的信息。如果規(guī)模再無(wú)限制的擴(kuò)大下去，那么將會(huì)超出現(xiàn)階段計(jì)算機(jī)硬件所能滿足的極限。

不僅如此，HDFS并不是為了有效的處理大量小文件而存在的。它主要是為了流式的訪問(wèn)大文件而設(shè)計(jì)的。對(duì)小文件的讀取通常會(huì)造成大量從DataNode到DataNode的Seeks和Hopping來(lái)Retrieve文件，而這樣是非常的低效的一種訪問(wèn)方式。

針對(duì)Gn口和A口中的實(shí)時(shí)數(shù)據(jù)結(jié)構(gòu)中存在小容量數(shù)據(jù)塊，如果利用傳統(tǒng)Hadoop結(jié)構(gòu)勢(shì)必需要針對(duì)數(shù)量巨大的小文件進(jìn)行高效處理，雖說(shuō)Hadoop開(kāi)源組件對(duì)小文件提供了許多的解決方案，但是帶來(lái)的系統(tǒng)構(gòu)造成本巨大，而且在運(yùn)營(yíng)商開(kāi)展的具體業(yè)務(wù)場(chǎng)景下并不能完全適用。

在利用實(shí)時(shí)性通訊組件Flume開(kāi)始接管A口信令數(shù)據(jù)以及Gn口數(shù)據(jù)的采集時(shí)，改善平臺(tái)小文件狀況的契機(jī)開(kāi)始顯現(xiàn)。我們?cè)贔lume中使用了Hadoop一個(gè)官方API使之在接收流式數(shù)據(jù)并寫(xiě)入HDFS時(shí)進(jìn)行文件追加，通過(guò)接收一條數(shù)據(jù)追加一條數(shù)據(jù)至當(dāng)天文件內(nèi)，這種快速積聚小文件到標(biāo)準(zhǔn)大小文件的方式解決了小文件在Hadoop集群中需要較多時(shí)延來(lái)存儲(chǔ)至HDFS文件的問(wèn)題。

使用append函數(shù)需要如下兩個(gè)步驟：

配置集群（hdfs-site. xml）

dfs.support.append

true

API實(shí)現(xiàn)（Flume中數(shù)據(jù)輸出邏輯需要進(jìn)行API調(diào)用）

String hdfs_path=”hdfs：//ip：xx/file/fileuploadFileName”；//文件路徑

Configuration conf= new Configuration（）；

FileSystem fs= FileSystem.get（URI.create（hdfs_path），conf）；

InputStream in=new BufferedInputStream（new FileInputsStream（file））；

//要追加的文件流，file為文件

IOUtils.copyBytes（in，out，4096，true）；

3.2針對(duì)實(shí)時(shí)性的流數(shù)據(jù)挖掘結(jié)果的結(jié)果查詢技術(shù)

為了保證事件處理結(jié)果的實(shí)時(shí)讀取，本文選擇Redis來(lái)進(jìn)行結(jié)果存儲(chǔ)。Redis是一個(gè)開(kāi)源、先進(jìn)的key-value內(nèi)存存儲(chǔ)，用于構(gòu)建高性能、可擴(kuò)展的Web應(yīng)用程序的完美解決方案。

Redis從它的許多競(jìng)爭(zhēng)者繼承來(lái)的三個(gè)主要特點(diǎn)：數(shù)據(jù)庫(kù)完全在內(nèi)存中，使用磁盤僅用于持久性；相比許多鍵值數(shù)據(jù)存儲(chǔ)，Redis擁有一套較為豐富的數(shù)據(jù)類型；Redis可以將數(shù)據(jù)復(fù)制到任意數(shù)量的從服務(wù)器。

而對(duì)于時(shí)延要求極低的結(jié)果查詢使用Redis優(yōu)勢(shì)包括：

異?？焖伲篟edis的速度非常快，每秒能執(zhí)行約11萬(wàn)集合，每秒約81000+條記錄。

支持豐富的數(shù)據(jù)類型：Redis支持最大多數(shù)開(kāi)發(fā)人員已經(jīng)知道像列表，集合，有序集合，散列數(shù)據(jù)類型。這使得它非常容易解決各種各樣的問(wèn)題，因?yàn)槲覀冎滥男﹩?wèn)題是可以處理通過(guò)它的數(shù)據(jù)類型更好。

操作都是原子性：所有Redis操作是原子的，這保證了如果兩個(gè)客戶端同時(shí)訪問(wèn)的Redis服務(wù)器將獲得更新后的值。

多功能實(shí)用工具：Redis是一個(gè)多實(shí)用的工具，可以在多個(gè)用例如緩存，消息，隊(duì)列使用（Redis原生支持發(fā)布/訂閱），任何短暫的數(shù)據(jù)，應(yīng)用程序，如Web應(yīng)用程序會(huì)話，網(wǎng)頁(yè)命中計(jì)數(shù)等。

整體優(yōu)化前數(shù)據(jù)流程如下：

話單文件→精細(xì)化預(yù)處理→HDFS→Hive→GreenPlum

整體優(yōu)化后數(shù)據(jù)流程如下：

話單流→HDFS→Hive→GreenPlum

總處理所需時(shí)間較原流程縮短至1/3，效率提高了200%。

四、 流式大數(shù)據(jù)系統(tǒng)實(shí)現(xiàn)的業(yè)務(wù)場(chǎng)景

在互聯(lián)網(wǎng)界，百度、亞馬遜、阿里巴巴、京東、騰訊等大型互聯(lián)網(wǎng)企業(yè)將大數(shù)據(jù)的應(yīng)用提高到前所未有的高度，并形成了了一系列滿足各種業(yè)務(wù)需求的大數(shù)據(jù)處理平臺(tái)，通過(guò)挖掘海量數(shù)據(jù)中蘊(yùn)含的信息點(diǎn)，并用業(yè)務(wù)流程來(lái)關(guān)聯(lián)起來(lái)，真正形成數(shù)據(jù)生產(chǎn)力來(lái)提高業(yè)務(wù)感知和質(zhì)量，向日益增長(zhǎng)的移動(dòng)互聯(lián)網(wǎng)用戶提供更加優(yōu)質(zhì)的服務(wù)。比如：百度通過(guò)典型數(shù)學(xué)計(jì)算工具結(jié)合Hadoop框架向用戶提供搜索引擎，通過(guò)毫秒級(jí)DSP處理引擎向廣告服務(wù)提供商實(shí)時(shí)提供廣告點(diǎn)擊信息；騰訊通過(guò)Storm數(shù)據(jù)流處理系統(tǒng)進(jìn)行簡(jiǎn)單的數(shù)據(jù)處理，如過(guò)濾、聚類等，以及復(fù)雜數(shù)據(jù)處理，如運(yùn)行簡(jiǎn)單的機(jī)器學(xué)習(xí)算法等；阿里巴巴通過(guò)、等計(jì)算框架向用戶提供商品的推薦服務(wù)；京東通過(guò)海量數(shù)據(jù)的挖掘進(jìn)行電子商務(wù)的倉(cāng)儲(chǔ)備貨策略和物流控制策略。在科技學(xué)術(shù)界，《自然》雜志于年出版了大數(shù)據(jù)?？?。

2012年10月，哈佛商業(yè)評(píng)論上發(fā)表了一篇里程碑式的專題文章《Data scientist： The sexist job of 21st century》，標(biāo)志著“數(shù)據(jù)科學(xué)家”已經(jīng)正式在企業(yè)中收到廣泛的尊重，這類專家的主要工作是從海量非結(jié)構(gòu)化數(shù)據(jù)中挖掘出有價(jià)值的信息，而不斷涌現(xiàn)的大數(shù)據(jù)技術(shù)使得從海量數(shù)據(jù)中獲取有價(jià)值信息成為可能。

本次實(shí)時(shí)系統(tǒng)研究過(guò)程中，恰逢2015年上海外灘踩踏事故的發(fā)生，考慮到該系統(tǒng)可以基于基站定位實(shí)時(shí)統(tǒng)計(jì)指定區(qū)域內(nèi)的人流量，因此，在與公安系統(tǒng)對(duì)接后可以通過(guò)有效的技術(shù)手段來(lái)預(yù)先判斷人流擁擠程度，避免踩踏事故的再次發(fā)生。

實(shí)時(shí)人流監(jiān)控架構(gòu)見(jiàn)圖2。

數(shù)據(jù)流程中主要由PME負(fù)責(zé)訂閱kafka中的簡(jiǎn)單的事件并進(jìn)行處理。將A口信令中Cell_id、Lac字段匹配公參表中的經(jīng)緯度信息，輸出用戶號(hào)碼目前匹配的經(jīng)緯度信息。Storm組件負(fù)責(zé)訂閱復(fù)雜事件并進(jìn)行處理（如分析小區(qū)用戶群），同時(shí)將簡(jiǎn)單事件復(fù)雜事件處理結(jié)果輸出至存Redis，以便應(yīng)用頁(yè)面能夠快速查詢結(jié)果。

實(shí)時(shí)人流監(jiān)控系統(tǒng)能力如下（系統(tǒng)界面見(jiàn)圖3）：

客戶信令觸發(fā)30秒后，系統(tǒng)就會(huì)捕捉到信令事件，通過(guò)2-3秒的計(jì)算后即可將用戶位置信息存儲(chǔ)至Redis里。

展示頁(yè)面每5秒刷新一次。這樣在頁(yè)面內(nèi)展示的內(nèi)容都是1分鐘內(nèi)人流變化情況。

通過(guò)在大數(shù)據(jù)平臺(tái)引入實(shí)時(shí)性Flume+Redis的架構(gòu)實(shí)現(xiàn)了實(shí)時(shí)性數(shù)據(jù)采集、處理、展現(xiàn)的大數(shù)據(jù)能力，并利用該能力搭建了從A口信令觸發(fā)開(kāi)始到最終監(jiān)控界面的幾個(gè)熱點(diǎn)區(qū)域?qū)崟r(shí)性人流監(jiān)控，該技術(shù)方案在整個(gè)運(yùn)營(yíng)商業(yè)內(nèi)屬于首創(chuàng)。

五、結(jié)論

本文提出了一種基于運(yùn)營(yíng)商網(wǎng)絡(luò)的實(shí)時(shí)大數(shù)據(jù)系統(tǒng)的構(gòu)建，并成功的利用基于基站定位的實(shí)時(shí)人流監(jiān)控業(yè)務(wù)來(lái)驗(yàn)證了這種技術(shù)架構(gòu)的合理性，這種模式不僅僅為未來(lái)運(yùn)營(yíng)商的實(shí)時(shí)大數(shù)據(jù)業(yè)務(wù)開(kāi)發(fā)提供了新的思路，同時(shí)確保了該技術(shù)架構(gòu)對(duì)于具體運(yùn)營(yíng)商對(duì)外合作業(yè)務(wù)的可實(shí)施型。本文下一步工作首先要對(duì)實(shí)時(shí)處理時(shí)效繼續(xù)優(yōu)化，構(gòu)建在1分鐘內(nèi)從事件觸發(fā)，源數(shù)據(jù)采集，流處理，到業(yè)務(wù)觸發(fā)到用戶的全流程。然后，增強(qiáng)整個(gè)流式數(shù)據(jù)模型開(kāi)發(fā)，以優(yōu)化數(shù)據(jù)流ETL過(guò)程，實(shí)現(xiàn)多條實(shí)時(shí)流大數(shù)據(jù)業(yè)務(wù)的并發(fā)。此外，本文未來(lái)的研究工作還將在將在完善實(shí)時(shí)流處理和運(yùn)營(yíng)商推薦平臺(tái)融合建設(shè)等方面繼續(xù)開(kāi)展。

參 考 文 獻(xiàn)

[1] 李俊奎； 王元珍，可重寫(xiě)循環(huán)滑動(dòng)窗口：面向高效的在線數(shù)據(jù)流處理[J]. 計(jì)算機(jī)科學(xué)， 2007

[2] 武珊珊，于戈，呂雁飛，谷峪，李曉靜， 數(shù)據(jù)流處理中確定性QoS的保證方法[J]， 軟件學(xué)報(bào)， 2008

[3] 左利云，馬英杰， 基于數(shù)據(jù)流處理模型的多查詢優(yōu)化算法[J]， 計(jì)算機(jī)工程與科學(xué)， 2009

[4] 陰曉加，鞠時(shí)光，王英杰， 基于復(fù)雜事件處理機(jī)制的RFID數(shù)據(jù)流處理方法[J]， 計(jì)算機(jī)應(yīng)用， 2009

[5] 楊瑋，企業(yè)級(jí)數(shù)據(jù)中心數(shù)據(jù)流處理方案設(shè)計(jì)[J]， 中國(guó)科技信息 2007

[6] 侯燕，王永利， 基于近似等深柱狀圖的數(shù)據(jù)流并行聚集算法[J]， 解放軍理工大學(xué)學(xué)報(bào)（自然科學(xué)版）， 2008

[7] 陳磊松，林錦賢， 面向高速網(wǎng)絡(luò)的數(shù)據(jù)流處理模型研究[J]， 漳州師范學(xué)院學(xué)報(bào)（自然科學(xué)版）， 2006

[8] Yishan Jiao， Maintaining stream statistics over multiscale sliding windows[J]. ACM Transactions on Database Systems （TODS） ， 2006 （4）[9] 徐花芬，毛國(guó)君，吳靜， 分布式數(shù)據(jù)流分類關(guān)鍵技術(shù)研究[J]， 華北科技學(xué)院學(xué)報(bào)， 2015

[10] 秦首科，錢衛(wèi)寧，周傲英，基于分形技術(shù)的數(shù)據(jù)流突變檢測(cè)算法[J]， ， 2006， （9）

[11] Sudipto Guha， Nick Koudas， Kyuseok Shim， Approximation and streaming algorithms for histogram construction problems[J]， ACM Transactions on Database Systems （TODS）， 2006 （1）

[12] 張鵬，李鵬霄，任彥，林海倫，楊嶸，鄭超，面向大數(shù)據(jù)的分布式流處理技術(shù)綜述，計(jì)算機(jī)研究與發(fā)展[J]，2014