基于流式計(jì)算的DPI數(shù)據(jù)處理方案及實(shí)踐

范家杰+田熙清+鄭博

【摘 要】如何對(duì)海量的DPI數(shù)據(jù)進(jìn)行實(shí)時(shí)的采集以及處理是運(yùn)營(yíng)商研究的熱點(diǎn)，傳統(tǒng)基于MapReduce的批處理模式難以滿(mǎn)足流式計(jì)算實(shí)時(shí)性要求，因此首先介紹了流式處理相關(guān)概念，然后分析了目前流行的流式計(jì)算技術(shù)，提出一種基于流式計(jì)算的DPI數(shù)據(jù)處理方案，并應(yīng)用在實(shí)際項(xiàng)目中，滿(mǎn)足電信運(yùn)營(yíng)商對(duì)數(shù)據(jù)處理實(shí)時(shí)性的要求，最后通過(guò)實(shí)踐總結(jié)了流式處理的應(yīng)用場(chǎng)景。

【關(guān)鍵詞】DPI；流式計(jì)算；數(shù)據(jù)處理

Scheme and Practice on DPI Data Processing Based on Stream Computing

FAN Jiajie1， TIAN Xiqing1， ZHENG Bo2

（1. Guangdong Research Institute of China Telecom Co.， Ltd.， Guangzhou 510630， China；

2. China Telecom Co.， Ltd.， Guangdong Branch， Guangzhou 510080， China）

[Abstract] How to collect and process the massive DPI data in real time is the hotspot of telecom operators. The traditional batch mode MapReduce is difficult to meet the real-time requirements based on stream computing. Therefore， the related concepts of stream computing were introduced. Then， popular stream computing technologies were analyzed to propose a DPI data processing scheme based on stream computing which is applied to the practical projects to meet the real-time requirements of data processing for operators. Finally， the application scenario of stream processing was summarized by the practice.

[Key words]DPI； stream computing； data processing

1 引言

隨著移動(dòng)互聯(lián)網(wǎng)的不斷發(fā)展以及各類(lèi)智能設(shè)備日益深入民眾日常生活中，人類(lèi)社會(huì)產(chǎn)生的數(shù)據(jù)量正在以指數(shù)級(jí)快速增長(zhǎng)，人類(lèi)已經(jīng)正式邁入大數(shù)據(jù)時(shí)代[1]。如今，運(yùn)營(yíng)商能夠獲得的用戶(hù)數(shù)據(jù)越來(lái)越豐富，通過(guò)DPI（Deep Packet Inspector，深度分組檢測(cè)）分析技術(shù)，能夠較好地識(shí)別網(wǎng)絡(luò)上的流量類(lèi)別、應(yīng)用層上的應(yīng)用種類(lèi)等[2]。在這個(gè)“數(shù)據(jù)為王”的時(shí)代，如何充分利用這筆重要的戰(zhàn)略資產(chǎn)已成為重中之重。

數(shù)據(jù)規(guī)模的快速增長(zhǎng)給大數(shù)據(jù)分析處理帶來(lái)了巨大的挑戰(zhàn)，尤其是在通信行業(yè)，數(shù)據(jù)越發(fā)呈現(xiàn)出無(wú)限性、突發(fā)性和實(shí)時(shí)性等特征[3]，傳統(tǒng)的基于MapReduce的批處理模式難以滿(mǎn)足數(shù)據(jù)實(shí)時(shí)性的要求，而能否在第一時(shí)間獲得數(shù)據(jù)所蘊(yùn)含的信息決定了數(shù)據(jù)的價(jià)值。因此，流式處理技術(shù)成為大數(shù)據(jù)技術(shù)研究的新熱點(diǎn)[4]。流式處理能夠針對(duì)數(shù)據(jù)的變化進(jìn)行實(shí)時(shí)處理，能夠在秒級(jí)獲得處理結(jié)果，特別適合一些對(duì)時(shí)效性要求很高的場(chǎng)景。

本文結(jié)合電信運(yùn)營(yíng)商的需求，對(duì)DPI數(shù)據(jù)進(jìn)行實(shí)時(shí)的采集及處理，提出一種基于流式計(jì)算的DPI數(shù)據(jù)處理方案，能夠?qū)@得DPI數(shù)據(jù)實(shí)時(shí)信息的時(shí)延降低到分鐘級(jí)，甚至秒級(jí)，實(shí)現(xiàn)對(duì)電信用戶(hù)上網(wǎng)信息的實(shí)時(shí)處理、監(jiān)測(cè)及分類(lèi)匯總，為之后進(jìn)行的大數(shù)據(jù)應(yīng)用提供了良好基礎(chǔ)。

2 流式處理概述

傳統(tǒng)基于MapReduce大數(shù)據(jù)處理技術(shù)實(shí)際上是一種批處理方式，如圖1所示。批處理模式首先要完成數(shù)據(jù)的累積和存儲(chǔ)，然后Hadoop客戶(hù)端將數(shù)據(jù)上傳到HDFS上，最后才啟動(dòng)Map/Reduce進(jìn)行數(shù)據(jù)處理，處理后再寫(xiě)入到HDFS。這種方式必須要所有數(shù)據(jù)都要準(zhǔn)備好，然后統(tǒng)一進(jìn)行集中計(jì)算和價(jià)值發(fā)現(xiàn)，無(wú)法滿(mǎn)足實(shí)時(shí)性的要求。

2015年，Nathan Marz提出了實(shí)時(shí)大數(shù)據(jù)處理框架Lambda架構(gòu)[5]，整合了離線計(jì)算和實(shí)時(shí)計(jì)算，能夠滿(mǎn)足實(shí)時(shí)系統(tǒng)高容錯(cuò)、低時(shí)延和可擴(kuò)展等要求，并且可集成Hadoop、Kafka、Storm、Spark及HBase等各類(lèi)大數(shù)據(jù)組件。

一個(gè)典型的Lambda架構(gòu)如圖2所示，主要使用的場(chǎng)景是邏輯復(fù)雜且延遲低的程序。數(shù)據(jù)會(huì)分別灌入實(shí)時(shí)系統(tǒng)和批處理系統(tǒng)，然后各自輸出自己的結(jié)果，結(jié)果會(huì)在查詢(xún)端進(jìn)行合并。

3 流式計(jì)算架構(gòu)對(duì)比

流式計(jì)算對(duì)系統(tǒng)的容錯(cuò)、時(shí)延、可擴(kuò)展及可靠性能力提出了很高的要求，當(dāng)前有許多流式計(jì)算框架（如Spark streaming[10]、Storm[11]、Kafka Stream[12]、Flink[13]和PipelineDB[14]等）已經(jīng)廣泛應(yīng)用于各行各業(yè)，并且還在不斷迭代發(fā)展，適用的場(chǎng)景也各不相同。

3.1 Spark streaming

Spark是由加州大學(xué)伯克利分校AMP實(shí)驗(yàn)室專(zhuān)門(mén)為大數(shù)據(jù)處理而設(shè)計(jì)的計(jì)算框架[6]。Spark Streaming是建立在Spark上的實(shí)時(shí)計(jì)算框架，是Spark的核心組件之一，通過(guò)它內(nèi)置的API和基于內(nèi)存的高效引擎，用戶(hù)可以結(jié)合流處理、批處理和交互式查詢(xún)開(kāi)發(fā)應(yīng)用。

Spark Streaming并不像其他流式處理框架每次只處理一條記錄，而是將流數(shù)據(jù)離散化處理，每次處理一批數(shù)據(jù)（DStream），使之能夠進(jìn)行秒級(jí)以下的快速批處理，執(zhí)行流程如圖3所示。Spark Streaming的Receiver并行接收數(shù)據(jù)，將數(shù)據(jù)緩存至內(nèi)存中，經(jīng)過(guò)延遲優(yōu)化后Spark引擎對(duì)短任務(wù)（幾十毫秒）進(jìn)行批處理。這樣設(shè)計(jì)的好處讓Spark Streaming能夠同時(shí)處理離線處理和流處理問(wèn)題。endprint

Spark Streaming能在故障報(bào)錯(cuò)下迅速恢復(fù)狀態(tài)，整合了批處理與流處理，內(nèi)置豐富高級(jí)算法處理庫(kù)，發(fā)展迅速，社區(qū)活躍。毫無(wú)疑問(wèn)，Spark Streaming是流式處理框架的佼佼者。缺點(diǎn)是由于需要累積一批小文件才處理，因此時(shí)延會(huì)稍大，是準(zhǔn)實(shí)時(shí)系統(tǒng)。

3.2 Storm

Storm通常被比作“實(shí)時(shí)的Hadoop”，是Twitter開(kāi)發(fā)的實(shí)時(shí)、分布式以及具備高容錯(cuò)計(jì)算系統(tǒng)，可以簡(jiǎn)單、可靠地處理大量數(shù)據(jù)流，用戶(hù)可以采用任意編程語(yǔ)言來(lái)開(kāi)發(fā)應(yīng)用。

在Storm中，一個(gè)用于實(shí)時(shí)計(jì)算的圖狀結(jié)構(gòu)稱(chēng)之為拓?fù)洌╰opology），拓?fù)涮峤坏郊海杉褐械闹骺毓?jié)點(diǎn)分發(fā)代碼，分配任務(wù)到工作節(jié)點(diǎn)執(zhí)行。如圖4所示，一個(gè)拓?fù)渲邪╯pout和bolt兩種角色，其中spout發(fā)送消息，負(fù)責(zé)將數(shù)據(jù)流以tuple元組的形式發(fā)送出去；而bolt則負(fù)責(zé)轉(zhuǎn)換這些數(shù)據(jù)流，在bolt中可以完成映射map、過(guò)濾filter等操作，bolt自身也可以隨機(jī)將數(shù)據(jù)發(fā)送給其他bolt。

Storm能將數(shù)據(jù)在不同的bolt中流動(dòng)、移動(dòng)數(shù)據(jù)，真正實(shí)現(xiàn)流式處理，易于擴(kuò)展，靈活性強(qiáng)，高度專(zhuān)注于流式處理。Storm在事件處理與增量計(jì)算方面表現(xiàn)突出，能夠以實(shí)時(shí)方式根據(jù)不斷變化的參數(shù)對(duì)數(shù)據(jù)流進(jìn)行處理。

3.3 Kafka Stream

Kafka Stream是Apache Kafka開(kāi)源項(xiàng)目的一個(gè)組成部分，是一個(gè)功能強(qiáng)大、易于使用的庫(kù)，它使得Apache Kafka擁有流處理的能力。

Kafka Stream是輕量級(jí)的流計(jì)算類(lèi)庫(kù)，除了Apache Kafka之外沒(méi)有任何外部依賴(lài)，可以在任何Java程序中使用，使用Kafka作為內(nèi)部消息通訊存儲(chǔ)介質(zhì)，因此不需要為流處理需求額外部署一個(gè)集群。

Kafka Stream入門(mén)簡(jiǎn)單，并且不依賴(lài)其他組件，非常容易部署，支持容錯(cuò)的本地狀態(tài)，延遲低，非常適合一些輕量級(jí)流處理的場(chǎng)景。

3.4 Flink

Flink是一個(gè)面向分布式數(shù)據(jù)流處理和批量數(shù)據(jù)處理的開(kāi)源計(jì)算平臺(tái)，同時(shí)支持批處理以及流處理，主要針對(duì)流數(shù)據(jù)，將批數(shù)據(jù)視為流數(shù)據(jù)的一個(gè)極限特例。

Flink核心是一個(gè)流式的數(shù)據(jù)流執(zhí)行引擎，它提供了數(shù)據(jù)分布、數(shù)據(jù)通信以及容錯(cuò)機(jī)制等功能。流執(zhí)行引擎之上，F(xiàn)link提供了更高層次的API以便用戶(hù)使用。Flink還針對(duì)某些領(lǐng)域提供了領(lǐng)域庫(kù)，例如Flink ML、Flink的機(jī)器學(xué)習(xí)庫(kù)等。

Flink適合有極高流處理需求，并有少量批處理任務(wù)的場(chǎng)景。該技術(shù)可兼容原生Storm和Hadoop程序，可在YARN管理的集群上運(yùn)行。目前Flink最大的局限之一是在社區(qū)活躍度方面，該項(xiàng)目的大規(guī)模部署尚不如其他處理框架那么常見(jiàn)。

3.5 PipeLineDB

PipeLineDB是基于PostgreSQL的一個(gè)流式計(jì)算數(shù)據(jù)庫(kù)，效率非常高，通過(guò)SQL對(duì)數(shù)據(jù)流做操作，并把操作結(jié)果儲(chǔ)存起來(lái)。其基本過(guò)程是：創(chuàng)建PipeLineDB Stream、編寫(xiě)SQL、對(duì)Stream做操作、操作結(jié)果被保存到continuous view。

PipeLineDB特點(diǎn)是可以只使用SQL進(jìn)行流式處理，不需要代碼，可以高效可持續(xù)自動(dòng)處理流式數(shù)據(jù)，只存儲(chǔ)處理后的數(shù)據(jù)，因此非常適合流式數(shù)據(jù)處理，例如網(wǎng)站流量統(tǒng)計(jì)、網(wǎng)頁(yè)的瀏覽統(tǒng)計(jì)等。

3.6 架構(gòu)對(duì)比

上文提到的5種流式處理框架對(duì)比如表1所示。

Storm的特點(diǎn)是成熟，是流式處理框架實(shí)際上的標(biāo)準(zhǔn)，模型、編程難度都比較復(fù)雜，框架采用循環(huán)處理數(shù)據(jù)，對(duì)系統(tǒng)資源，尤其是CPU資源消耗很大，當(dāng)任務(wù)空閑時(shí)，需要sleep程序，減少對(duì)資源的消耗。Spark Streaming兼顧了批處理以及流式處理，并且有Spark的強(qiáng)大支持，發(fā)展?jié)摿Υ?，但與Kafka的接口平滑性不夠。Kafka Stream是Kafka的一個(gè)開(kāi)發(fā)庫(kù)，具有入門(mén)、編程、部署運(yùn)維簡(jiǎn)單的特點(diǎn)，并且不需要部署額外的組件，但對(duì)于多維度的統(tǒng)計(jì)來(lái)說(shuō)，需要基于不同topic來(lái)做分區(qū)，編程模型復(fù)雜。Flink跟Spark Streaming很像，不同的是Flink把所有任務(wù)當(dāng)成流來(lái)處理，在迭代計(jì)算、內(nèi)存管理方面比Spark Streaming稍強(qiáng)，缺點(diǎn)是社區(qū)活躍度不高，還不夠成熟；PipeLineDB是一個(gè)流式計(jì)算數(shù)據(jù)庫(kù)，能執(zhí)行簡(jiǎn)單的流式計(jì)算任務(wù)，優(yōu)勢(shì)是基本不需要開(kāi)發(fā)，只要熟悉SQL操作均可以輕松使用，但對(duì)于集群計(jì)算，需要商業(yè)上的支持。

4 DPI數(shù)據(jù)處理方案

基于實(shí)際任務(wù)需求以及上文流式框架的對(duì)比，由于Kafka Stream編程難度小，不需要另外安裝軟件，與Kafka等組件無(wú)縫連接，比較穩(wěn)定，并且各種性能均比較優(yōu)秀，因此本文選擇了Kafka Stream作為流式處理的核心組件。

4.1 寬帶DPI處理

為了完成寬帶DPI數(shù)據(jù)的實(shí)時(shí)抓包、資料填補(bǔ)、清洗、轉(zhuǎn)換及并入庫(kù)等工作，應(yīng)用了上述DPI數(shù)據(jù)處理方案。具體項(xiàng)目方案如圖5所示：

Mina進(jìn)程是一個(gè)JAVA程序，基于Mina框架開(kāi)發(fā)，主要接收AAA數(shù)據(jù)包，獲得用戶(hù)賬戶(hù)信息，解析計(jì)算，并持久化到redis，最后發(fā)送給抓包（Capture）程序。Capture程序由C語(yǔ)言編寫(xiě)，使用開(kāi)源pcap抓取網(wǎng)卡http包，解析，結(jié)合用戶(hù)帳號(hào)資料，把DPI寫(xiě)入到Kafka中。Kafka stream完成DPI的實(shí)時(shí)清洗和轉(zhuǎn)換工作。

Flume[15]是Cloudera開(kāi)源的分布式可靠、可用、高效的收集，聚合和移動(dòng)不同數(shù)據(jù)源的海量數(shù)據(jù)系統(tǒng)，配置簡(jiǎn)單，基本無(wú)需開(kāi)發(fā)，資源消耗低，支持傳輸數(shù)據(jù)到HDFS，非常適合與大數(shù)據(jù)系統(tǒng)結(jié)合。本項(xiàng)目將流式處理完后的數(shù)據(jù)通過(guò)Flume從Kafka中寫(xiě)入到HDFS，建立hive表，為上層應(yīng)用提供數(shù)據(jù)。endprint

Kafka Stream采用自主研發(fā)的ETL框架[16]，負(fù)責(zé)數(shù)據(jù)過(guò)濾（去掉圖片、視頻等），數(shù)據(jù)處理（獲取網(wǎng)絡(luò)ID、字段解析等）。ETL框架采用JAVA語(yǔ)言開(kāi)發(fā)，支持多種數(shù)據(jù)源，包括普通文本、壓縮格式及XML立體格式等。支持多種大數(shù)據(jù)計(jì)算框架，包括Map/Reduce、Spark streaming、Kafka Stream和Flume等；具有擴(kuò)展方便、字段校驗(yàn)、支持字段的通配符及支持維表查詢(xún)等功能。在運(yùn)維方面，支持變量引用以及出錯(cuò)處理等功能。

4.2 4G DPI實(shí)時(shí)統(tǒng)計(jì)

以電信4G DPI信息作為數(shù)據(jù)源，通過(guò)流式處理，完成DPI的實(shí)時(shí)統(tǒng)計(jì)工作，包括多粒度（5分鐘/1小時(shí)/

1天）去重用戶(hù)統(tǒng)計(jì)、多粒度去重不同號(hào)碼頭用戶(hù)統(tǒng)計(jì)、多粒度流量統(tǒng)計(jì)及多粒度去重域名統(tǒng)計(jì)等。4G DPI實(shí)時(shí)統(tǒng)計(jì)具體項(xiàng)目方案如圖6所示：

數(shù)據(jù)源是gzip壓縮文件，因?yàn)閒lume原生不支持.gz或.tar.gz文件格式，所以修改了Flume底層代碼，實(shí)現(xiàn)對(duì)壓縮文件的處理，省去了解壓時(shí)間。Flume采集文件時(shí)以用戶(hù)手機(jī)號(hào)碼作為分區(qū)的key，將同一號(hào)碼的數(shù)據(jù)分到同一分區(qū)，便于去重。通過(guò)Kafka集群管理工具，Kafka Manager[17]可以很好地監(jiān)測(cè)Kafka集群的狀態(tài)。Kafka集群生產(chǎn)者如圖7所示。

Kafka Stream消費(fèi)4GDPI的數(shù)據(jù)，并行處理。在程序里設(shè)置不同的計(jì)數(shù)器，所有數(shù)據(jù)都經(jīng)過(guò)這些計(jì)數(shù)器處理，為了解決去重問(wèn)題，引入了布隆過(guò)濾，雖然有一定的誤判率，但是還是能比較好地完成去重，同時(shí)保證系統(tǒng)的性能。同樣消費(fèi)者也可以通過(guò)Kafka Manager進(jìn)行管理，可以直觀觀察到消費(fèi)者的落后程度。

為了滿(mǎn)足不同的輸出要求，程序設(shè)置了三種輸出供選擇。粒度為天的數(shù)據(jù)將會(huì)寫(xiě)到MySQL作為備份，針對(duì)熱點(diǎn)區(qū)域的監(jiān)控?cái)?shù)據(jù)將會(huì)輸出到Redis，同時(shí)，為了方便管理以及數(shù)據(jù)呈現(xiàn)，還采用了ELK框架（ElasticSearch+Logstash+Kibana），將所有數(shù)據(jù)傳到Kibana做前端展示。Kibana界面如圖8所示。

5 實(shí)踐及分析

5.1 部署實(shí)踐

上述兩個(gè)系統(tǒng)均已應(yīng)用在實(shí)際的生產(chǎn)中，均有不錯(cuò)的表現(xiàn)，能夠滿(mǎn)足任務(wù)需求，并且已經(jīng)穩(wěn)定運(yùn)行。

寬帶DPI處理項(xiàng)目有2臺(tái)采集機(jī)、1臺(tái)AAA服務(wù)器及5臺(tái)Kafka機(jī)器。采集機(jī)每臺(tái)每秒產(chǎn)生115 MB數(shù)據(jù)，兩臺(tái)1.8 G流量。采集機(jī)寫(xiě)Kafka 33萬(wàn)條/s，Kafka Stream寫(xiě)Kafka 22萬(wàn)條/s，清洗率（清洗工作把諸如圖片、視頻及js請(qǐng)求等與業(yè)務(wù)無(wú)關(guān)的DPI信息去掉）為33%。Kafka Stream落后處理穩(wěn)定在500萬(wàn)數(shù)據(jù)，延遲處理在15 s之內(nèi)，F(xiàn)lume寫(xiě)HDFS落后保持在100萬(wàn)左右，5 s內(nèi)的延遲。寬帶DPI處理項(xiàng)目性能如圖9所示。

4G DPI實(shí)時(shí)統(tǒng)計(jì)項(xiàng)目共6臺(tái)機(jī)器，1臺(tái)為Flume采集機(jī)，其余5臺(tái)部署Kafka、Kafka Stream及ELK。采集機(jī)寫(xiě)Kafka一般為10萬(wàn)條/秒，峰值可達(dá)到25萬(wàn)條/秒。ElasticSearch集群一共8個(gè)實(shí)例，每個(gè)實(shí)例配置2 G內(nèi)存。目前集群有13億條數(shù)據(jù)，占361 G空間。通過(guò)Logstash導(dǎo)入數(shù)據(jù)到ElasticSearch峰值可以達(dá)到8～9萬(wàn)條/s。Kafka Stream處理數(shù)據(jù)落后在10 s內(nèi)，Logstash寫(xiě)ElasticSearch落后在5 s內(nèi)，如圖10所示。目前4G DPI實(shí)時(shí)統(tǒng)計(jì)項(xiàng)目日均處理文件超過(guò)15 000個(gè)，大小達(dá)到1.6 T，日均處理記錄數(shù)超過(guò)100億。

5.2 存在的問(wèn)題

在4G DPI實(shí)時(shí)統(tǒng)計(jì)項(xiàng)目開(kāi)發(fā)過(guò)程中，隨著項(xiàng)目的需求越來(lái)越多，后面增加了對(duì)域名和CGI的去重，而且同一域名或者CGI不在同一Kafka分區(qū)，導(dǎo)致結(jié)果有偏差。為了解決這一問(wèn)題，程序設(shè)計(jì)了二次去重，第一次去重的結(jié)果把CGI或者域名作為key輸出到Kafka集群，再做了一次去重工作，導(dǎo)致延遲時(shí)間變大和系統(tǒng)維護(hù)變復(fù)雜。

由于寬帶DPI處理中不涉及去重，只是數(shù)據(jù)過(guò)濾和數(shù)據(jù)轉(zhuǎn)換，因此Kafka Stream是非常適合的。但在涉及分區(qū)和去重的4G DPI實(shí)時(shí)統(tǒng)計(jì)項(xiàng)目中，應(yīng)當(dāng)采用Storm作為流式處理框架。在Storm中，數(shù)據(jù)從一個(gè)bolt流到另外一個(gè)bolt，這樣數(shù)據(jù)可以在一個(gè)bolt中按手機(jī)號(hào)碼分區(qū)，在另外一個(gè)bolt中又可以按CGI或者域名分區(qū)，可以避免二次去重問(wèn)題，降低編程模型復(fù)雜度。

在程序設(shè)計(jì)之初，應(yīng)根據(jù)應(yīng)用場(chǎng)景需求選擇合適的技術(shù)框架。如果項(xiàng)目基礎(chǔ)結(jié)構(gòu)中涉及Spark，那Spark Streaming是不錯(cuò)的選擇；如果像4G DPI實(shí)時(shí)統(tǒng)計(jì)項(xiàng)目一樣需要數(shù)據(jù)轉(zhuǎn)移或者去重，那么Storm是首選；如果是簡(jiǎn)單的數(shù)據(jù)清洗和轉(zhuǎn)換處理，那么Kafka Stream是不錯(cuò)的選擇。對(duì)于簡(jiǎn)單小規(guī)模的實(shí)時(shí)統(tǒng)計(jì)，PipeLineDB足以勝任。

6 結(jié)束語(yǔ)

大數(shù)據(jù)流式計(jì)算和批處理適用于不同的業(yè)務(wù)場(chǎng)景，在對(duì)時(shí)效要求高的場(chǎng)景下，流式計(jì)算具有明顯的優(yōu)勢(shì)。本文首先概述了流式處理以及其與批處理的區(qū)別，然后對(duì)業(yè)界流行的流式計(jì)算框架進(jìn)行了對(duì)比，根據(jù)業(yè)務(wù)需求提出了以Kafka Stream為流式處理框架的DPI數(shù)據(jù)處理方案，搭配Kafka、Flume及ELK等組件，具有入門(mén)迅速、編程難度低和部署維護(hù)簡(jiǎn)單等特點(diǎn)。并且將方案應(yīng)用到了寬帶DPI處理項(xiàng)目以及4G DPI實(shí)時(shí)統(tǒng)計(jì)項(xiàng)目中，完成了任務(wù)需求，性能優(yōu)異，運(yùn)行穩(wěn)定。

在對(duì)實(shí)際項(xiàng)目實(shí)踐中，隨著任務(wù)需求的增多，發(fā)現(xiàn)Kafka Stream在應(yīng)對(duì)多維度數(shù)據(jù)去重問(wèn)題時(shí)表現(xiàn)不力，需要引入二次過(guò)濾來(lái)解決問(wèn)題。因此在項(xiàng)目需求階段，便要在技術(shù)框架選型時(shí)充分考慮可能出現(xiàn)的問(wèn)題，結(jié)合技術(shù)框架適用場(chǎng)景，綜合考慮。

參考文獻(xiàn)：

[1] Zikopoulos P， Eaton C. Understanding Big Data： Analytics for Enterprise Class Hadoop and Streaming Data[M]. McGraw-Hill Osborne Media， 1989.endprint

[2] 陳康，付華崢，陳翀，等. 基于DPI的用戶(hù)興趣實(shí)時(shí)分類(lèi)[J]. 電信科學(xué)， 2016，32（12）： 109-115.

[3] 孫大為，張廣艷，鄭緯民. 大數(shù)據(jù)流式計(jì)算：關(guān)鍵技術(shù)及系統(tǒng)實(shí)例[J]. 軟件學(xué)報(bào)， 2014，25（4）： 839-862.

[4] 董斌，楊迪，王錚，等. 流計(jì)算大數(shù)據(jù)技術(shù)在運(yùn)營(yíng)商實(shí)時(shí)信令處理中的應(yīng)用[J]. 電信科學(xué)， 2015，31（10）： 165-171.

[5] Marz N，Warren J. Big Data： Principles and best practices of scalable realtime data systems[M]. Manning， 2015.

[6] 李祥池. 基于ELK和Spark Streaming的日志分析系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)[J]. 電子科學(xué)技術(shù)， 2015，2（6）： 674-678.

[7] 李圣，黃永忠，陳海勇. 大數(shù)據(jù)流式計(jì)算系統(tǒng)研究綜述[J]. 信息工程大學(xué)學(xué)報(bào)， 2016，17（1）： 88-92.

[8] 姚仁捷. Kafka在唯品會(huì)的應(yīng)用實(shí)踐[J]. 程序員， 2014（1）： 110-113.

[9] 郝璇. 基于Apache Flume的分布式日志收集系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)[J]. 軟件導(dǎo)刊， 2014（7）： 110-111.

[10] Spark. Spark Streaming Programming Guide[EB/OL]. [2017-09-14]. http：//spark.apache.org/docs/latest/streaming-programming-guide.html.

[11] Storm. Apache Storm[EB/OL]. [2017-09-14]. http：//storm.apache.org/index.html.

[12] Kafka Stream. Kafka Streams API[EB/OL]. [2017-09-14]. http：//kafka.apache.org/documentation/streams/.

[13] Flink. Introduction to Apache Flink?[EB/OL]. [2017-09-14]. https：//flink.apache.org/introduction.html.

[14] PipelineDB. The Streaming SQL Database[EB/OL]. [2017-09-14]. https：//www.pipelinedb.com/.

[15] Apache Flume?. Apache Flume?[EB/OL]. [2017-09-14]. http：//flume.apache.org/index.html.

[16] Kafka Stream. ETL[EB/OL]. [2017-09-14]. https：//github.com/styg/bumblebee-ETL.

[17] Kafka Stream. Kafka Manager[EB/OL]. [2017-09-14]. https：//github.com/yahoo/kafka-manager.endprint