本發(fā)明屬于大數(shù)據(jù)處理技術(shù)領(lǐng)域，具體地涉及一種基于海量實時互聯(lián)網(wǎng)dpi數(shù)據(jù)的流式處理方法及系統(tǒng)。

背景技術(shù)：

近年來，互聯(lián)網(wǎng)發(fā)展速度飛速增長，其上的數(shù)據(jù)也在不斷增長，尤其隨著移動互聯(lián)網(wǎng)的崛起，多元化的數(shù)據(jù)使得我們對各類數(shù)據(jù)的分析挖掘需求更為迫切。如何從這些海量的數(shù)據(jù)中深入挖掘并創(chuàng)造更大更有用的價值，是大數(shù)據(jù)行業(yè)一直以來的目標(biāo)。

目前，主流的大數(shù)據(jù)處理方法都是基于hadoop進(jìn)行的，hadoop的出現(xiàn)使得人們分析海量數(shù)據(jù)更為簡單容易，其上的mapreduce編程模型可以并行的在各個節(jié)點上運(yùn)行處理，而且hadoop具備良好的可擴(kuò)展性，節(jié)點可以動態(tài)的加入而不影響集群的正常運(yùn)行。然而hadoop同樣存在著一些不足，它只能支持離線的數(shù)據(jù)處理，只有當(dāng)數(shù)據(jù)寫入到hadoop的本地存儲中，才可以進(jìn)一步的進(jìn)行計算分析，存在較大的時延，不適合處理實時海量數(shù)據(jù)，無法滿足和響應(yīng)對數(shù)據(jù)處理時延較為敏感的一些需求和業(yè)務(wù)，所以需要構(gòu)建一種可以處理實時數(shù)據(jù)的流式處理方法來滿足實時業(yè)務(wù)需求。

kafka是分布式發(fā)布與訂閱消息系統(tǒng)。它是一個分布式的，可劃分的，冗余備份的，持久性的日志服務(wù)，主要用于處理活躍的流式數(shù)據(jù)。在大數(shù)據(jù)系統(tǒng)中，數(shù)據(jù)通常需要在其下的各個子系統(tǒng)中高效低時延的運(yùn)轉(zhuǎn)。為了能很好的統(tǒng)籌這些數(shù)據(jù)的分發(fā)，滿足實時應(yīng)用和離線應(yīng)用，kafka的出現(xiàn)正好解決了這一問題，其作為一條高速的數(shù)據(jù)總線，統(tǒng)籌數(shù)據(jù)的分發(fā)，降低了系統(tǒng)組網(wǎng)、編程的復(fù)雜度。

storm是一個分布式、高容錯的實時計算系統(tǒng)。storm對于實時計算的意義相當(dāng)于hadoop對于批處理的意義。其提供了類似于hadoop中map與reduce的計算框架spout與bolt。storm非常適用于流數(shù)據(jù)的處理，可以用來處理源源不斷的數(shù)據(jù)流，并且也可以將處理的結(jié)果保存到持久化介質(zhì)中。

sparkstreaming是建立在spark上的實時計算框架，用戶可以通過調(diào)用其豐富的api接口進(jìn)行基于內(nèi)存的高速流式批處理。sparkstreaming使用基于內(nèi)存的spark作為執(zhí)行引擎，具有高效性和容錯性，并可以部署在100個以上的節(jié)點上，同時能達(dá)到秒級的延遲。它還為實現(xiàn)復(fù)雜的算法提供簡單的api調(diào)用接口，方便用戶的編程使用。

kv(key-value)數(shù)據(jù)庫集群是一個具有高并發(fā)實時查詢能力的非關(guān)系型數(shù)據(jù)庫。該集群主要基于nginx+netty的框架，其中nginx提供高并發(fā)的對外服務(wù),netty提供高性能和高可用性的網(wǎng)絡(luò)應(yīng)用框架，提升查詢效率。集群采用基于token(令牌)的用戶身份驗證機(jī)制，使用戶在訪問受保護(hù)的服務(wù)資源時僅需提供token，而不需要提供用戶名和密碼。token是包含用戶名、有效期和某些專有信息并通過共享密鑰加密的信息字符串。kv集群提供了安全高速低時延的結(jié)果數(shù)據(jù)接口。

將這幾類大數(shù)據(jù)領(lǐng)域的實時處理組件進(jìn)行設(shè)計、配置與組合，構(gòu)建一種可以滿足處理各類海量實時互聯(lián)網(wǎng)dpi數(shù)據(jù)的方法和系統(tǒng)，可以最大程度的提高大數(shù)據(jù)挖掘的能力，創(chuàng)造更多更大的價值，從而更好的支撐上層大數(shù)據(jù)業(yè)務(wù)的發(fā)展。

技術(shù)實現(xiàn)要素：

本發(fā)明的目的在于提供一種可以最大程度的提高大數(shù)據(jù)挖掘能力的基于海量實時互聯(lián)網(wǎng)dpi數(shù)據(jù)的流式處理方法及系統(tǒng)。

本發(fā)明的技術(shù)方案如下：一種基于海量實時互聯(lián)網(wǎng)dpi數(shù)據(jù)的流式處理方法，包括如下步驟：

一、接口協(xié)議層接收海量實時互聯(lián)網(wǎng)dpi數(shù)據(jù)，并對所述dpi數(shù)據(jù)進(jìn)行清洗過濾；

二、kafka集群接收來自所述接口協(xié)議層的dpi數(shù)據(jù)，并存放在對應(yīng)topics的具體分區(qū)中；

三、storm集群間隔設(shè)定的時間去所述kafka集群的topics中去獲取所述dpi數(shù)據(jù)，且對應(yīng)的處理單元topology對這些數(shù)據(jù)進(jìn)行相應(yīng)的預(yù)處理，并將預(yù)處理后的結(jié)果數(shù)據(jù)輸出到所述kafka集群對應(yīng)的topics中；

四、sparkstreaming集群間隔設(shè)定的時間去所述kafka集群的topics中獲取經(jīng)所述strom集群預(yù)處理后的dpi數(shù)據(jù)，對所述預(yù)處理后的dpi數(shù)據(jù)進(jìn)行復(fù)制和分發(fā)，并將最終的處理結(jié)果以<key，value>的形式存入kv數(shù)據(jù)庫集群的數(shù)據(jù)庫中。

優(yōu)選地，在步驟一中，對所述dpi數(shù)據(jù)進(jìn)行清洗過濾步驟包括如下步驟：

過濾清洗所述dpi數(shù)據(jù)中的httppost流量，只保留httpget流量；

過濾清洗httpget流量中非用戶點擊行為的流量；

在源數(shù)據(jù)中僅保留與業(yè)務(wù)相關(guān)聯(lián)的字段，并清洗其他剩余的字段，且對保留的字段的進(jìn)行重新排列；

對關(guān)鍵字段imei進(jìn)行md5不可逆加密，保障數(shù)據(jù)的隱私安全。

優(yōu)選地，所述步驟二中，將過步驟一中濾清洗后的dpi數(shù)據(jù)分別傳輸?shù)絢afka集群對應(yīng)的topic中，即每過濾清洗產(chǎn)生一條有用的dpi數(shù)據(jù)記錄就傳輸?shù)絢afka對應(yīng)隊列中。

優(yōu)選地，在步驟三中，所述預(yù)處理步驟包括：清洗ad/mdn字段為空的記錄和清洗url字段中帶password信息的記錄。

優(yōu)選地，在步驟四之后還包括步驟五，在所述步驟五中，業(yè)務(wù)平臺系統(tǒng)通過所述kv數(shù)據(jù)庫集群獲取權(quán)限范圍內(nèi)的數(shù)據(jù)，并根據(jù)注冊時使用的用戶名與密碼，以及隨機(jī)生成的apikey獲取訪問令牌token，使得后續(xù)的數(shù)據(jù)請求均帶上所述令牌token。

優(yōu)選地，從步驟一到步驟五的整個處理流程所產(chǎn)生的時延在秒數(shù)量級。

一種根據(jù)上述基于海量實時互聯(lián)網(wǎng)dpi數(shù)據(jù)的流式處理方法的系統(tǒng)，包括：接口協(xié)議層、kafka集群、storm集群、sparkstreaming集群和kv集群，

所述接口協(xié)議層，用于接收海量實時互聯(lián)網(wǎng)，并對所述dpi數(shù)據(jù)進(jìn)行清洗過濾；

所述kafka集群，用于接收來自所述接口協(xié)議層的dpi數(shù)據(jù)，并存放在對應(yīng)topics的具體分區(qū)中；

所述storm集群，用于間隔設(shè)定時間去所述kafka集群的topics中去獲取所述dpi數(shù)據(jù)，且對應(yīng)的處理單元topology對這些數(shù)據(jù)進(jìn)行相應(yīng)的預(yù)處理，并將預(yù)處理后的結(jié)果數(shù)據(jù)輸出到所述kafka集群對應(yīng)的topics中；

所述sparkstreaming集群，間隔設(shè)定時間去所述kafka集群的topics中獲取經(jīng)所述strom集群預(yù)處理后的dpi數(shù)據(jù)，對所述預(yù)處理后的dpi數(shù)據(jù)進(jìn)行復(fù)制和分發(fā)，并將最終的處理結(jié)果以<key，value>的形式存入所述kv數(shù)據(jù)庫集群的數(shù)據(jù)庫中。

優(yōu)選地，在所述kv數(shù)據(jù)庫集群中，業(yè)務(wù)平臺系統(tǒng)通過所述kv數(shù)據(jù)庫集群獲取權(quán)限范圍內(nèi)的數(shù)據(jù)，并根據(jù)注冊時使用的用戶名與密碼，以及隨機(jī)生成的apikey獲取訪問令牌token，使得后續(xù)的數(shù)據(jù)請求均帶上所述令牌token。

本發(fā)明提供的技術(shù)方案具有如下有益效果：

1、目前hadoop集群對于實時數(shù)據(jù)的處理只能將實時數(shù)據(jù)先按照一定時間段(一般為一個小時)進(jìn)行采集落地，然后將這一時間段的數(shù)據(jù)進(jìn)行集中的入庫(加載到hadoop集群)，以60分鐘時間段為例，其產(chǎn)生的平均時延達(dá)到了30分鐘，而本發(fā)明解決了hadoop集群只能處理離線數(shù)據(jù)的不足，通過接口協(xié)議層、kafka數(shù)據(jù)分發(fā)集群、storm流式預(yù)處理集群、sparkstreaming流式分析集群以及kv數(shù)據(jù)庫輸出集群這一整個處理流程，可以達(dá)到秒這個數(shù)量級，極大的降低了數(shù)據(jù)處理的時延，從而實現(xiàn)實時分析與統(tǒng)計；

2、hadoop集群采用文件形式的數(shù)據(jù)集中入庫方式，會使用到磁盤的讀寫，很容易產(chǎn)生數(shù)據(jù)入庫的速率瓶頸，導(dǎo)致數(shù)據(jù)擁塞，而本發(fā)明通過引入kafka數(shù)據(jù)分發(fā)集群，支持從接口協(xié)議層到kafka消息隊列的基于內(nèi)存的數(shù)據(jù)傳輸方式，跳過了磁盤的讀寫，極大的提高了數(shù)據(jù)的吞吐率，從而可以接入更大的源數(shù)據(jù)流量，更好的支撐大數(shù)據(jù)的挖掘分析；

3、目前流式的大數(shù)據(jù)處理系統(tǒng)還是對源數(shù)據(jù)為文件的形式進(jìn)行處理，數(shù)據(jù)采集后需存入hdfs文件系統(tǒng)才分發(fā)到各個spark模塊進(jìn)行處理，數(shù)據(jù)的采集、落地及分發(fā)上需要耗費(fèi)大量的時間，整個處理存在較大的時延，無法做到真正的實時處理；本發(fā)明的系統(tǒng)從數(shù)據(jù)源開始均為實時的流式數(shù)據(jù)，后續(xù)對數(shù)據(jù)的分片處理均為秒級的數(shù)量級，整個處理與輸出過程僅需幾秒的時間即可完成；

4、采用高速低時延的kv數(shù)據(jù)庫集群，可以實現(xiàn)對結(jié)果數(shù)據(jù)進(jìn)行實時高并發(fā)量的查詢調(diào)用，而且可以實現(xiàn)對出口數(shù)據(jù)內(nèi)容的安全審核與統(tǒng)計，保障出口位置的安全與管控。

附圖說明

圖1是本發(fā)明實施例提供的基于海量實時互聯(lián)網(wǎng)dpi數(shù)據(jù)的流式處理方法的流程框圖；

圖2是圖1所示基于海量實時互聯(lián)網(wǎng)dpi數(shù)據(jù)的流式處理方法的基本流程示意圖；

圖3是根據(jù)圖1所示基于海量實時互聯(lián)網(wǎng)dpi數(shù)據(jù)的流式處理方法的系統(tǒng)的結(jié)構(gòu)框圖；

圖4是圖3所示系統(tǒng)的硬件網(wǎng)絡(luò)拓?fù)鋱D。

具體實施方式

為了使本發(fā)明的目的、技術(shù)方案及優(yōu)點更加清楚明白，以下結(jié)合附圖及實施例，對本發(fā)明進(jìn)行進(jìn)一步詳細(xì)說明。應(yīng)當(dāng)理解，此處所描述的具體實施例僅僅用以解釋本發(fā)明，并不用于限定本發(fā)明。

除非上下文另有特定清楚的描述，本發(fā)明中的元件和組件，數(shù)量既可以單個的形式存在，也可以多個的形式存在，本發(fā)明并不對此進(jìn)行限定。本發(fā)明中的步驟雖然用標(biāo)號進(jìn)行了排列，但并不用于限定步驟的先后次序，除非明確說明了步驟的次序或者某步驟的執(zhí)行需要其他步驟作為基礎(chǔ)，否則步驟的相對次序是可以調(diào)整的?？梢岳斫?，本文中所使用的術(shù)語“和/或”涉及且涵蓋相關(guān)聯(lián)的所列項目中的一者或一者以上的任何和所有可能的組合。

請同時參閱圖1和圖2，本發(fā)明實施例提供的基于海量實時互聯(lián)網(wǎng)dpi數(shù)據(jù)的流式處理方法100包括如下步驟：

s1、接口協(xié)議層接收海量實時互聯(lián)網(wǎng)dpi數(shù)據(jù)，并對所述dpi數(shù)據(jù)進(jìn)行清洗過濾。

具體地，在步驟s1中，對所述dpi數(shù)據(jù)進(jìn)行清洗過濾步驟包括如下步驟：

過濾清洗所述dpi數(shù)據(jù)中的httppost流量，只保留httpget流量；

過濾清洗httpget流量中非用戶點擊行為的流量；

在源數(shù)據(jù)中僅保留與業(yè)務(wù)相關(guān)聯(lián)的字段，并清洗其他剩余的字段，且對保留的字段的進(jìn)行重新排列；

對關(guān)鍵字段imei進(jìn)行md5不可逆加密，保障數(shù)據(jù)的隱私安全。

需要說明的是，所述dpi數(shù)據(jù)包括固網(wǎng)dpi數(shù)據(jù)和3g/4gdpi數(shù)據(jù)。

s2、kafka集群接收來自所述接口協(xié)議層的dpi數(shù)據(jù)，并存放在對應(yīng)topics的具體分區(qū)中。

具體地，在步驟s2中，所述步驟二中，將過步驟一中濾清洗后的dpi數(shù)據(jù)分別傳輸?shù)絢afka集群對應(yīng)的topic中，即每過濾清洗產(chǎn)生一條有用的dpi數(shù)據(jù)記錄就傳輸?shù)絢afka對應(yīng)隊列中。

s3、storm集群間隔設(shè)定的時間去所述kafka集群的topics中去獲取所述dpi數(shù)據(jù)，且對應(yīng)的處理單元topology對這些數(shù)據(jù)進(jìn)行相應(yīng)的預(yù)處理，并將預(yù)處理后的結(jié)果數(shù)據(jù)輸出到所述kafka集群對應(yīng)的topics中。

具體地，在步驟s3中，所述預(yù)處理步驟包括：清洗ad/mdn字段為空的記錄和清洗url字段中帶password信息的記錄。

s4、sparkstreaming集群間隔設(shè)定的時間去所述kafka集群的topics中獲取經(jīng)所述strom集群預(yù)處理后的dpi數(shù)據(jù)，對所述預(yù)處理后的dpi數(shù)據(jù)進(jìn)行復(fù)制和分發(fā)，并將最終的處理結(jié)果以<key，value>的形式存入kv數(shù)據(jù)庫集群的數(shù)據(jù)庫中。

s5、業(yè)務(wù)平臺系統(tǒng)通過所述kv數(shù)據(jù)庫集群獲取權(quán)限范圍內(nèi)的數(shù)據(jù)，并根據(jù)注冊時使用的用戶名與密碼，以及隨機(jī)生成的apikey獲取訪問令牌token，使得后續(xù)的數(shù)據(jù)請求均帶上所述令牌token。

具體地，在所述步驟s5中，所述令牌token每12個小時會進(jìn)行一次更新。

需要說明的是，在本實施例中，從步驟s1到步驟s5的整個處理流程所產(chǎn)生的時延在秒數(shù)量級。

請參閱圖3，一種根據(jù)圖1所示基于海量實時互聯(lián)網(wǎng)dpi數(shù)據(jù)的流式處理方法的系統(tǒng)包括：接口協(xié)議層10、kafka集群20、storm集群30、sparkstreaming集群40和kv集群50。

其中，所述接口協(xié)議層10用于接收海量實時互聯(lián)網(wǎng)dpi數(shù)據(jù)，并對所述dpi數(shù)據(jù)進(jìn)行清洗過濾。

而且，對所述接口協(xié)議層10進(jìn)行配置，包括數(shù)據(jù)源的注冊和采集客戶端的配置。其中數(shù)據(jù)源的注冊主要對數(shù)據(jù)的元數(shù)據(jù)進(jìn)行管理，包括設(shè)置分割符及定義每個數(shù)據(jù)字段，以便后續(xù)解析處理。采集客戶端采用flume框架來處理源數(shù)據(jù)采集任務(wù)，并自動采集數(shù)據(jù)，每個數(shù)據(jù)源對應(yīng)一個采集客戶端。

所述kafka集群20用于接收來自所述接口協(xié)議層的dpi數(shù)據(jù)，并存放在對應(yīng)topics的具體分區(qū)中。

而且，對所述kafka集群20進(jìn)行配置包括：

1、配置kafka的主題(topic)，每種源數(shù)據(jù)對應(yīng)一個主題，一個主題可以有多個訂閱者(consumer)。訂閱者訂閱該主題之后，需要提供訂閱的模塊信息、需求描述、訂閱地址、訂閱超時設(shè)置等信息，訂閱完成后kafka會自動復(fù)制一份數(shù)據(jù)給訂閱者；

2、需要配置kafka隊列策略，主要依據(jù)集群的節(jié)點數(shù)以及每個節(jié)點的能力來配置，每一個訂閱者對應(yīng)的隊列數(shù)也是可以配置的，根據(jù)數(shù)據(jù)源的大小以及實時性要求來配置，同時kafka也會根據(jù)每個節(jié)點的運(yùn)行情況，動態(tài)實時地分配隊列到性能消耗最少的節(jié)點上；

3、配置每個topic的分區(qū)(partition)數(shù)量與大小以及備份的數(shù)量，主要依據(jù)源數(shù)據(jù)量的大小來配置。

所述storm集群30用于間隔設(shè)定時間去所述kafka集群20的topics中去獲取所述dpi數(shù)據(jù)，且對應(yīng)的處理單元topology對這些數(shù)據(jù)進(jìn)行相應(yīng)的預(yù)處理，并將預(yù)處理后的結(jié)果數(shù)據(jù)輸出到所述kafka集群20對應(yīng)的topics中。

而且，對所述storm集群30進(jìn)行配置包括：

1、配置strom本身的調(diào)度引擎，依據(jù)集群的規(guī)模調(diào)試相關(guān)參數(shù)(總bolt的數(shù)量、bolt的cpu和內(nèi)存、任務(wù)調(diào)度緩存、超時設(shè)置等)至一個最佳的調(diào)度參數(shù)；

2、針對不同的數(shù)據(jù)源開發(fā)對應(yīng)的處理邏輯topology，topology的編寫可以通過封裝公共組件(條件過濾組件、正則表達(dá)式組件、字符串操作組件)或編寫私有的處理邏輯，并加載至框架中，由框架進(jìn)行調(diào)度和運(yùn)行。

所述sparkstreaming集群40間隔設(shè)定的時間去所述kafka集群20的topics中獲取經(jīng)所述strom集群30預(yù)處理后的dpi數(shù)據(jù)，對所述預(yù)處理后的dpi數(shù)據(jù)進(jìn)行復(fù)制和分發(fā)，并將最終的處理結(jié)果以<key，value>的形式存入所述kv數(shù)據(jù)庫集群的數(shù)據(jù)庫中。

而且，對所述sparkstreaming集群40進(jìn)行配置包括：

1、將sparkstreaming的資源及任務(wù)管理方式(本地模式、standalone模式、mesoes模式、yarn模式)配置為yarn任務(wù)管理模式；

2、基于上層業(yè)務(wù)需求編寫具體的任務(wù)模塊(目前支持的任務(wù)類型有scala、java和python，scala和java通過api的方式直接嵌入發(fā)布，python則通過腳本的方式直接發(fā)布)，任務(wù)發(fā)布完畢后會立即生效。

在所述kv數(shù)據(jù)庫集群50中，業(yè)務(wù)平臺系統(tǒng)通過所述kv數(shù)據(jù)庫集50群獲取權(quán)限范圍內(nèi)的數(shù)據(jù)，并根據(jù)注冊時使用的用戶名與密碼，以及隨機(jī)生成的apikey獲取訪問令牌token，使得后續(xù)的數(shù)據(jù)請求均帶上所述令牌token。

而且，對所述kv數(shù)據(jù)庫集群50進(jìn)行配置，對于已經(jīng)授權(quán)訪問服務(wù)的用戶，獲取和使用token的總體流程包括：

1、用戶憑借kv數(shù)據(jù)庫集群的賬戶向集群申請和獲取token；

2、攜帶已獲取的token來查詢具有權(quán)限的數(shù)據(jù)標(biāo)簽。

即，基于所述kv數(shù)據(jù)庫集群50的元數(shù)據(jù)管理，可以增加用戶對元數(shù)據(jù)的權(quán)限信息，查詢訪問的時候首先進(jìn)行用戶識別，然后根據(jù)用戶的元數(shù)據(jù)權(quán)限信息進(jìn)行訪問控制。并且對一些訪問熱度較高的數(shù)據(jù)或表通過緩存的方式可以提高查詢響應(yīng)效率。

可選擇的，所述系統(tǒng)還包括hadoop集群60，所述hadoop集群60也可以從所述kafka集群20的topics中去獲取所述dpi數(shù)據(jù)，并將處理后的數(shù)據(jù)發(fā)送至所述kv數(shù)據(jù)庫集群50。

如圖4所示，是本發(fā)明的硬件網(wǎng)絡(luò)拓?fù)鋱D，主要硬件網(wǎng)絡(luò)的規(guī)模與配置如下：

硬件規(guī)模與配置：

1、接口協(xié)議層：20臺采集清洗服務(wù)器，配置：2*8corecpu、128g內(nèi)存、2*300gsas硬盤+10*3tsata硬盤，當(dāng)前接口協(xié)議層可以處理的實時數(shù)據(jù)流量約為6000mb/s；

2、kafka集群：10臺kafka節(jié)點，配置：2*8corecpu、256g內(nèi)存、2*300gsas硬盤+10*3tsata硬盤，當(dāng)前kafka集群可以處理的實時數(shù)據(jù)流量約為200mb/s；

3、storm集群：10臺storm節(jié)點，配置：2*8corecpu、256g內(nèi)存、2*300gsas硬盤+10*3tsata硬盤，當(dāng)前storm集群可以處理的實時數(shù)據(jù)流量約為200mb/s；

4、sparkstreaming集群：33臺spark節(jié)點(其中兩臺為名稱節(jié)點)，配置：2*8corecpu、256g內(nèi)存、2*300gsas硬盤+10*3tsata硬盤；

5、kv數(shù)據(jù)庫集群：7臺kv數(shù)據(jù)庫節(jié)點，配置：2*8corecpu、512g內(nèi)存、2*300gsas硬盤+10*3tsata硬盤；2臺kv接口機(jī)，配置：2*8corecpu、128g內(nèi)存、2*300gsas硬盤+10*3tsata硬盤，當(dāng)前kv數(shù)據(jù)庫集群的qps(每秒查詢數(shù))可到達(dá)120000次/秒。

網(wǎng)絡(luò)拓?fù)洌涸磾?shù)據(jù)通過網(wǎng)絡(luò)匯聚設(shè)備分發(fā)到接口協(xié)議層的20臺采集清洗服務(wù)器中，經(jīng)處理后通過兩臺核心交換機(jī)傳輸?shù)絢afka集群，strom集群與sparkstreaming集群均通過核心交換機(jī)從kafka集群獲取數(shù)據(jù)進(jìn)行對應(yīng)的處理，最后結(jié)果數(shù)據(jù)會輸出到kv數(shù)據(jù)庫集群，kv接口機(jī)連接公網(wǎng)，公網(wǎng)中的其他上層平臺系統(tǒng)通過kv接口機(jī)獲取對應(yīng)的結(jié)果數(shù)據(jù)進(jìn)行后續(xù)處理、分析與展示。

本發(fā)明的工作原理及工作過程如下：

將海量實時互聯(lián)網(wǎng)dpi數(shù)據(jù)，此處以固網(wǎng)dpi數(shù)據(jù)(簡寫為gdpi數(shù)據(jù))為例，目前固網(wǎng)dpi數(shù)據(jù)的原始接入量約為1.5gbps-2.0gbps,接入系統(tǒng)的接口協(xié)議層，對gdpi數(shù)據(jù)進(jìn)行清洗過濾，主要包含兩方面，一方面過濾清洗gdpi流量中的非用戶點擊行為的流量(主要包括圖片流量、廣告流量等)，另一方面對源數(shù)據(jù)中不需要的字段信息進(jìn)行去除，一般保留ad、srcip、dstip、ts、url、ref、ua等字段信息，清洗后留存的數(shù)據(jù)量約為原始數(shù)據(jù)的10％左右，最后將清洗并統(tǒng)一字段后的gdpi數(shù)據(jù)傳輸?shù)絢afka集群的對應(yīng)的topic中，此處topicid設(shè)為t(g1)。

kafka集群接收來自接口協(xié)議層的gdpi數(shù)據(jù)，并存放在topicid為t(g1)的分片中并備份；

storm集群中每隔5秒，從kafka集群t(g1)的分片中獲取gdpi數(shù)據(jù)，其對應(yīng)的處理單元topology會對這些數(shù)據(jù)進(jìn)行相應(yīng)的處理：1、清洗ad字段為空的記錄；2、清洗url字段中帶password信息的記錄。處理完成后storm集群將結(jié)果數(shù)據(jù)輸出到kafka集群的對應(yīng)的topic中，此處topicid為t(g2)，。

sparkstreaming集群每隔5秒，從kafka集群t(g2)的分片中獲取經(jīng)strom預(yù)處理后的gdpi數(shù)據(jù),并提供給多個上層數(shù)據(jù)分析應(yīng)用。最終的處理結(jié)果通過kafka集群以<key,value>的形式存入kv數(shù)據(jù)庫集群的數(shù)據(jù)庫中，上層的平臺系統(tǒng)通過kv數(shù)據(jù)庫集群接口調(diào)用獲取最終的結(jié)果數(shù)據(jù)。

相較于現(xiàn)有技術(shù)，本發(fā)明實施例具有如下有益效果：

1、目前hadoop集群對于實時數(shù)據(jù)的處理只能將實時數(shù)據(jù)先按照一定時間段(一般為一個小時)進(jìn)行采集落地，然后將這一時間段的數(shù)據(jù)進(jìn)行集中的入庫(加載到hadoop集群)，以60分鐘時間段為例，其產(chǎn)生的平均時延達(dá)到了30分鐘，而本發(fā)明解決了hadoop集群只能處理離線數(shù)據(jù)的不足，通過接口協(xié)議層、kafka數(shù)據(jù)分發(fā)集群、storm流式預(yù)處理集群、sparkstreaming流式分析集群以及kv數(shù)據(jù)庫輸出集群這一整個處理流程，可以達(dá)到秒這個數(shù)量級，極大的降低了數(shù)據(jù)處理的時延，從而實現(xiàn)實時分析與統(tǒng)計；

2、hadoop集群采用文件形式的數(shù)據(jù)集中入庫方式，會使用到磁盤的讀寫，很容易產(chǎn)生數(shù)據(jù)入庫的速率瓶頸，導(dǎo)致數(shù)據(jù)擁塞，而本發(fā)明通過引入kafka數(shù)據(jù)分發(fā)集群，支持從接口協(xié)議層到kafka消息隊列的基于內(nèi)存的數(shù)據(jù)傳輸方式，跳過了磁盤的讀寫，極大的提高了數(shù)據(jù)的吞吐率，從而可以接入更大的源數(shù)據(jù)流量，更好的支撐大數(shù)據(jù)的挖掘分析；

3、目前流式的大數(shù)據(jù)處理系統(tǒng)還是對源數(shù)據(jù)為文件的形式進(jìn)行處理，數(shù)據(jù)采集后需存入hdfs文件系統(tǒng)才分發(fā)到各個spark模塊進(jìn)行處理，數(shù)據(jù)的采集、落地及分發(fā)上需要耗費(fèi)大量的時間，整個處理存在較大的時延，無法做到真正的實時處理；本發(fā)明的系統(tǒng)從數(shù)據(jù)源開始均為實時的流式數(shù)據(jù)，后續(xù)對數(shù)據(jù)的分片處理均為秒級的數(shù)量級，整個處理與輸出過程僅需幾秒的時間即可完成；

4、采用高速低時延的kv數(shù)據(jù)庫集群，可以實現(xiàn)對結(jié)果數(shù)據(jù)進(jìn)行實時高并發(fā)量的查詢調(diào)用，而且可以實現(xiàn)對出口數(shù)據(jù)內(nèi)容的安全審核與統(tǒng)計，保障出口位置的安全與管控。

對于本領(lǐng)域技術(shù)人員而言，顯然本發(fā)明不限于上述示范性實施例的細(xì)節(jié)，而且在不背離本發(fā)明的精神或基本特征的情況下，能夠以其他的具體形式實現(xiàn)本發(fā)明。因此，無論從哪一點來看，均應(yīng)將實施例看作是示范性的，而且是非限制性的，本發(fā)明的范圍由所附權(quán)利要求而不是上述說明限定，因此旨在將落在權(quán)利要求的等同要件的含義和范圍內(nèi)的所有變化囊括在本發(fā)明內(nèi)。不應(yīng)將權(quán)利要求中的任何附圖標(biāo)記視為限制所涉及的權(quán)利要求。

此外，應(yīng)當(dāng)理解，雖然本說明書按照實施方式加以描述，但并非每個實施方式僅包含一個獨立的技術(shù)方案，說明書的這種敘述方式僅僅是為清楚起見，本領(lǐng)域技術(shù)人員應(yīng)當(dāng)將說明書作為一個整體，各實施例中的技術(shù)方案也可以經(jīng)適當(dāng)組合，形成本領(lǐng)域技術(shù)人員可以理解的其他實施方式。