張洪豪 姚欣 王勁松 姚世春

摘 ?要： 隨著接入設(shè)備的激增，網(wǎng)絡(luò)應(yīng)用及協(xié)議的不斷涌現(xiàn)和互聯(lián)網(wǎng)流量的爆發(fā)式增長(zhǎng)，給數(shù)據(jù)分析與處理帶來(lái)了極大的挑戰(zhàn)。大數(shù)據(jù)環(huán)境中數(shù)據(jù)處理應(yīng)用所呈現(xiàn)出的趨勢(shì)是實(shí)時(shí)在線計(jì)算、離線批式計(jì)算以及動(dòng)態(tài)響應(yīng)式計(jì)算相互結(jié)合、相互影響，這就要求底層計(jì)算資源具備同時(shí)提供實(shí)時(shí)計(jì)算、批式計(jì)算及響應(yīng)式計(jì)算的能力，然而傳統(tǒng)的系統(tǒng)架構(gòu)和編程模型已經(jīng)無(wú)法滿足這種混合計(jì)算需求。文中設(shè)計(jì)并實(shí)現(xiàn)一種構(gòu)建在流式數(shù)據(jù)處理過程IStream之上的混合計(jì)算中間件（General?purpose Hybrid Computing Middleware，GHCM），它以統(tǒng)一、靈活的高層抽象將相互依賴的高并發(fā)實(shí)時(shí)處理業(yè)務(wù)邏輯、批處理業(yè)務(wù)邏輯和跨層次動(dòng)態(tài)調(diào)用無(wú)縫融合起來(lái)。實(shí)驗(yàn)數(shù)據(jù)表明，GHCM在解決混合計(jì)算問題上具有良好的性能，在大幅縮短開發(fā)時(shí)間的同時(shí)為用戶提供了可重用和易擴(kuò)展等支持。

關(guān)鍵詞： 混合計(jì)算中間件; IStream模型設(shè)計(jì); 數(shù)據(jù)處理; 程序無(wú)縫融合; 系統(tǒng)實(shí)現(xiàn); 性能分析

中圖分類號(hào)： TN911.2?34; TP302 ? ? ? ? ? ? ? ? 文獻(xiàn)標(biāo)識(shí)碼： A ? ? ? ? ? ? ? ? ? ? ?文章編號(hào)： 1004?373X（2020）12?0055?06

Abstract： The sharp increase of access devices， the continuous emergence of network applications and protocols， and the explosive growth of Internet traffic bring a great challenge to data analysis and processing. The trend presented by the data processing applications in the big data environment is the mutual integration and mutual interaction of real?time online computing， offline batch computing and dynamic responsive computing， which requires that the underlying computing resources have the ability to simultaneously provide real?time computing， batch computing and responsive computing， but the traditional system architecture and programming model is unable to meet the needs of this kind of hybrid computing. A general?purpose hybrid computing middleware （GHCM） based on the streaming data treating process IStream is designed and implemented， which integrates the interdependent high concurrent real?time processing business logic， batching business logic and cross level dynamic call seamlessly with a unified and flexible high?level abstraction. The experimental data show that GHCM has good performance in solving the hybrid computing difficulty， and provides users with reusable and easily extensible support while significantly reducing development time.

Keywords： GHCM; IStream model design; data processing; procedure seamless integration; system implementation; performance analysis

0 ?引 ?言

當(dāng)前，大數(shù)據(jù)計(jì)算引擎及相應(yīng)的編程模型已經(jīng)成為云計(jì)算領(lǐng)域發(fā)展速度最快的技術(shù)之一，Hadoop[1]作為典型代表，以其新穎的構(gòu)思和出色的大規(guī)模數(shù)據(jù)處理能力一度成為首選的大數(shù)據(jù)分析和計(jì)算平臺(tái)。然而，在研究和實(shí)際應(yīng)用中人們已經(jīng)意識(shí)到Hadoop在面對(duì)低延遲和具有復(fù)雜數(shù)據(jù)關(guān)系的大數(shù)據(jù)問題時(shí)具有很大的不適應(yīng)性[2?3]。隨著不同應(yīng)用場(chǎng)景的出現(xiàn)，Hadoop在大數(shù)據(jù)處理領(lǐng)域的霸主地位被逐漸撼動(dòng)，一大批新型計(jì)算引擎相繼問世，Spark[4]和Storm就是其中的優(yōu)秀代表，前者為海量數(shù)據(jù)批處理提供了高效的解決方案，后者則被視為高并發(fā)實(shí)時(shí)計(jì)算領(lǐng)域的新標(biāo)準(zhǔn)。

2018年中國(guó)大數(shù)據(jù)技術(shù)與產(chǎn)業(yè)發(fā)展白皮書[5]指出，企業(yè)必須根據(jù)不同的場(chǎng)景靈活使用合適的技術(shù)，復(fù)雜場(chǎng)景中的大數(shù)據(jù)應(yīng)用可能同時(shí)包含不同特征的源數(shù)據(jù)和計(jì)算需求，單一的計(jì)算模式已無(wú)法滿足整個(gè)應(yīng)用的需求。分布式網(wǎng)絡(luò)安全軟件在監(jiān)測(cè)網(wǎng)絡(luò)流量時(shí)需要同時(shí)完成如下工作：

1） 快速處理實(shí)時(shí)注入系統(tǒng)的數(shù)據(jù)流;

2） 將實(shí)時(shí)計(jì)算所累積的信息與其他靜態(tài)數(shù)據(jù)結(jié)合起來(lái)由離線計(jì)算模塊分析處理;

3） 分析產(chǎn)生的結(jié)果在用戶發(fā)出動(dòng)態(tài)請(qǐng)求時(shí)被渲染成圖形界面并返回給用戶。

為實(shí)現(xiàn)上述類型的應(yīng)用程序，用戶通常需要同時(shí)管理兩套計(jì)算框架來(lái)分別完成實(shí)時(shí)處理任務(wù)與批處理任務(wù)。前者給用戶帶來(lái)較大的開發(fā)、協(xié)調(diào)和維護(hù)困難并且系統(tǒng)性能無(wú)法得到保證;后者則是低效的系統(tǒng)設(shè)計(jì)方案，程序性能會(huì)受到底層計(jì)算引擎的嚴(yán)重制約。

鑒于此，本文提出一種具有通用性的編程模型，它以抽象過程IStream和發(fā)布/訂閱機(jī)制為核心，將實(shí)時(shí)計(jì)算、批式計(jì)算和動(dòng)態(tài)響應(yīng)式計(jì)算無(wú)縫融入一套應(yīng)用程序中，并且為應(yīng)用程序帶來(lái)跨層次的可重用性和可擴(kuò)展性。系統(tǒng)底層實(shí)現(xiàn)細(xì)節(jié)都被編程模型所隱藏，取而代之的是簡(jiǎn)單的高層抽象概念和接口。本文所提出的通用混合計(jì)算中間件（General?purpose Hybrid Computing Middleware，GHCM）被實(shí)現(xiàn)在Spark和Storm計(jì)算引擎之上，經(jīng)GHCM優(yōu)化（任務(wù)壓縮、提前聚合等技術(shù)）之后的用戶程序借助Spark提供的快速批量計(jì)算模型和Storm提供的快速持續(xù)計(jì)算模型可以獲得相較于傳統(tǒng)架構(gòu)更快的數(shù)據(jù)處理速度。

1 ?相關(guān)工作

MapReduce[6]是Google公司開發(fā)出的一種高效、可擴(kuò)展的并行計(jì)算框架，其所提供的編程模型可以將用戶程序分解為3個(gè)相互關(guān)聯(lián)的處理步驟：Map，Shuffle和Reduce。這種編程模型具有較好的通用性，能夠?qū)崿F(xiàn)大多數(shù)計(jì)算需求。但MapReduce過于依賴文件系統(tǒng)，運(yùn)行過程中頻繁訪問磁盤所產(chǎn)生的時(shí)間開銷較大，也不能對(duì)多階段的流水線式處理過程提供很好的支持。Hadoop是MapReduce框架的開源實(shí)現(xiàn)，具有與MapReduce相似的作業(yè)調(diào)度器和分布式文件系統(tǒng)。在實(shí)際應(yīng)用中，Hadoop表現(xiàn)出的局限性與MapReduce也十分相似。FlumeJava[7]構(gòu)建在MapReduce之上，彌補(bǔ)了MapReduce模型無(wú)法實(shí)現(xiàn)流水線處理過程的缺憾。FlumeJava提供的高層API具有較強(qiáng)的表達(dá)能力，可以被用來(lái)編寫運(yùn)行在MapReduce之上的多階段處理程序。FlumeJava的不足之處在于不具備跨階段優(yōu)化能力，而且無(wú)法識(shí)別并刪除代碼中的冗余接口調(diào)用。Apache Crunch是FlumeJava的開源實(shí)現(xiàn)，它在Hadoop上實(shí)現(xiàn)了與FlumeJava類似的功能，且已經(jīng)添加了對(duì)Spark框架的支持。Dryad[8]是微軟公司提出并實(shí)現(xiàn)的分布式計(jì)算框架。Dryad用執(zhí)行計(jì)劃圖描述用戶程序，圖中的節(jié)點(diǎn)代表數(shù)據(jù)計(jì)算單元，連接不同節(jié)點(diǎn)的有向邊代表數(shù)據(jù)傳輸通道。與Hadoop相似，Dryad使所有底層實(shí)現(xiàn)細(xì)節(jié)透明化，用戶只需調(diào)用Dryad提供的API就能得到分布式數(shù)據(jù)計(jì)算服務(wù)，但在通用性方面有所欠缺。

2 ?基于IStream的發(fā)布/訂閱模型

GHCM的核心是IStream的數(shù)據(jù)計(jì)算單元和建立其上的發(fā)布/訂閱模型。IStream發(fā)布/訂閱模型[9]是一種分布式計(jì)算環(huán)境下的近同步通信模型，它以交互協(xié)議為基礎(chǔ)，以數(shù)指分離機(jī)制為核心，提供了一種面向多層實(shí)體、具有可重用性和可擴(kuò)展性的計(jì)算單元?jiǎng)討B(tài)調(diào)用服務(wù)。

2.1 ?IStream發(fā)布/訂閱模型的設(shè)計(jì)

與傳統(tǒng)的發(fā)布/訂閱模型不同，IStream發(fā)布/訂閱模型采用了指令與數(shù)據(jù)相互分離的設(shè)計(jì)方案，發(fā)布指令與傳遞數(shù)據(jù)是兩個(gè)獨(dú)立的互不干擾的過程，如圖1所示。圖中：msg cache是專注于收發(fā)調(diào)用指令和反饋信息的系統(tǒng)部件，常用的消息中間件都可以作為msg cache的底層實(shí)現(xiàn)，如Kafka和ActiveMQ;sink可以是集群內(nèi)的文件系統(tǒng)、數(shù)據(jù)庫(kù)、隊(duì)列中間件或其他存儲(chǔ)結(jié)構(gòu)，主要被用來(lái)承載或傳遞計(jì)算實(shí)體在各個(gè)階段產(chǎn)生的計(jì)算結(jié)果。

2.2 ?IStream發(fā)布/訂閱模型的動(dòng)態(tài)交互性

IStream發(fā)布/訂閱模型會(huì)將集群內(nèi)所有正在運(yùn)行的計(jì)算單元?jiǎng)澐譃閮深悾悍琼憫?yīng)式計(jì)算單元和響應(yīng)式計(jì)算單元。IStream發(fā)布/訂閱模型借助數(shù)指分離策略消除了計(jì)算單元之間的強(qiáng)關(guān)聯(lián)，把所有響應(yīng)式計(jì)算單元視作可以向外提供服務(wù)的獨(dú)立實(shí)體，并且通過集群內(nèi)部的消息中間件接收并響應(yīng)調(diào)用請(qǐng)求。這種動(dòng)態(tài)調(diào)用過程不僅可以出現(xiàn)在GHCM程序內(nèi)的IStream之間，其他外部程序也可以作為發(fā)布者參與其中。GHCM運(yùn)行時(shí)系統(tǒng)會(huì)為Supervisor進(jìn)程指定一個(gè)端口，外部程序發(fā)出的調(diào)用請(qǐng)求正是通過這個(gè)端口傳遞給Supervisor的。在這種跨層次動(dòng)態(tài)交互過程中，用戶程序只需關(guān)注高層業(yè)務(wù)流程的設(shè)計(jì)，并在必要的時(shí)候調(diào)用GHCM系統(tǒng)對(duì)外開放的計(jì)算資源，Supervisor進(jìn)程作為響應(yīng)式計(jì)算單元的外部代理，已將所有底層細(xì)節(jié)屏蔽掉，呈現(xiàn)給外部程序的只是一套簡(jiǎn)潔的調(diào)用和反饋接口。

2.3 ?IStream發(fā)布/訂閱模型的可重用性和擴(kuò)展性

IStream發(fā)布/訂閱模型為GHCM程序和外部程序帶來(lái)的另一個(gè)好處是提高組件的可重用性和可擴(kuò)展性。在圖2中，GHCM程序1原本只包含IStream 1和IStream 2。

隨著新計(jì)算需求的提出，開發(fā)者為這個(gè)GHCM程序編寫了第3個(gè)計(jì)算單元IStream 3。為了使IStream 3承接并處理IStream 2產(chǎn)生的數(shù)據(jù)，開發(fā)者只需少量修改IStream 2的程序代碼：聲明一種指令發(fā)布策略，并指向IStream 3所監(jiān)聽的消息緩存msg cache 2。重新編譯并運(yùn)行GHCM程序1之后，新添加的計(jì)算單元已然能夠無(wú)縫融入原有的處理流程中?？梢钥闯觯@種低耦合的結(jié)構(gòu)能被很容易地?cái)U(kuò)展成更大、更復(fù)雜的系統(tǒng)。GHCM程序由3個(gè)計(jì)算單元組成，IStream 1作為非響應(yīng)式計(jì)算單元不接受來(lái)自其他實(shí)體的動(dòng)態(tài)調(diào)度，而IStream 2和IStream 3都是系統(tǒng)內(nèi)的響應(yīng)式計(jì)算單元。

始終處于運(yùn)行狀態(tài)的IStream 1作為系統(tǒng)唯一的入口單元，能使該GHCM程序不間斷地執(zhí)行數(shù)據(jù)處理任務(wù)而無(wú)需等待外部調(diào)用。當(dāng)用戶1發(fā)出操作請(qǐng)求后，應(yīng)用程序1會(huì)直接從sink 1中讀取數(shù)據(jù)，然后把數(shù)據(jù)交付給用戶。而對(duì)應(yīng)用程序2，每當(dāng)用戶2提交操作請(qǐng)求，通過Host上的Supervisor進(jìn)程動(dòng)態(tài)調(diào)用IStream 2，并在收到Supervior發(fā)送的反饋信息后從sink 2中取出所需的計(jì)算結(jié)果。

3 ?GHCM系統(tǒng)實(shí)現(xiàn)與性能分析

GHCM運(yùn)行時(shí)系統(tǒng)會(huì)根據(jù)用戶程序中的IStream操作序列構(gòu)造出一幅初始的流處理圖（Stream Processing Graph，SPG）。SPG經(jīng)過任務(wù)壓縮、任務(wù)擴(kuò)展和提前聚合等優(yōu)化處理，最終會(huì)被系統(tǒng)分割、編譯并提交到底層計(jì)算引擎上執(zhí)行。將IStream編程模型作為通用混合計(jì)算中間件實(shí)現(xiàn)在Spark和Storm計(jì)算框架之上。

3.1 ?系統(tǒng)架構(gòu)及工作流程

GHCM系統(tǒng)架構(gòu)如圖3所示。

開發(fā)者編寫的應(yīng)用程序處于系統(tǒng)最高抽象層，用戶應(yīng)用程序之下分別是GHCM類庫(kù)和運(yùn)行時(shí)系統(tǒng)。GHCM類庫(kù)定義了用戶需要遵循的語(yǔ)法規(guī)則，即以抽象計(jì)算單元IStream為核心的編程模型。運(yùn)行時(shí)系統(tǒng)是GHCM的核心，該層主要由SPG Builder，SPG Optimizer，Code Generator，Task Compiler，Task Submission，Task Tracker和Supervisor七部分組成，它們所實(shí)現(xiàn)的功能分別是：

1） SPG Builder：構(gòu)建與用戶代碼相對(duì)應(yīng)的流處理圖。

2） SPG Optimizer：利用相關(guān)技術(shù)對(duì)初始SPG進(jìn)行優(yōu)化處理。

3） Code Generator：將優(yōu)化之后的SPG以IStream為單位分解開，再把DIStream和SIStream分別翻譯成符合Storm和Spark編程規(guī)范的獨(dú)立程序。

4） Task Compiler：編譯需要提交到Storm和Spark上執(zhí)行的作業(yè)。

5） Task Submission：向計(jì)算集群提交作業(yè)。

6） Task Track：追蹤計(jì)算引擎產(chǎn)生的日志及性能參數(shù)并及時(shí)向上反饋。

7） Supervisor：IStream的代理，監(jiān)聽并轉(zhuǎn)發(fā)來(lái)自外部程序的動(dòng)態(tài)調(diào)用請(qǐng)求。

3.2 ?SPG優(yōu)化相關(guān)技術(shù)

SPG的優(yōu)化技術(shù)可從任務(wù)壓縮、提前聚合以及任務(wù)擴(kuò)展等多途徑提高資源利用率并且提升程序運(yùn)行速度。在很多情況下，許多操作能被串聯(lián)起來(lái)以流水線的形式在同一個(gè)計(jì)算節(jié)點(diǎn)中處理完成，而不必將每一步處理任務(wù)分別派發(fā)到不同的計(jì)算節(jié)點(diǎn)中執(zhí)行。例如，SPG中相鄰的filter操作和map操作可以被壓縮到同一個(gè)任務(wù)中，這對(duì)數(shù)據(jù)集中的每一個(gè)原組先判斷其是否滿足過濾條件，若滿足條件則立刻進(jìn)行map變換，然后將結(jié)果傳遞出去，不滿足篩選標(biāo)準(zhǔn)的原組會(huì)被直接丟棄。

在底層實(shí)現(xiàn)時(shí)，同樣存在許多能被壓縮執(zhí)行的操作。這些操作具有的共同特點(diǎn)是有限依賴性，即“父操作”發(fā)出的任意一個(gè)數(shù)據(jù)原組只被“子操作”至多引用一次，且“父操作”向“子操作”傳遞數(shù)據(jù)時(shí)不需要重新分組，具有這種簡(jiǎn)單線性依賴的操作序列能在不改變計(jì)算結(jié)果的前提下被合并執(zhí)行。當(dāng)用戶程序中存在大量連續(xù)的有限依賴運(yùn)算時(shí)，這種優(yōu)化手段帶來(lái)的性能提升將十分顯著。

任務(wù)壓縮除了能優(yōu)化有限依賴運(yùn)算，還能夠去除冗余接口調(diào)用。例如：用戶在進(jìn)行map操作后又調(diào)用了功能相似的mapToPair（）接口，這種情況下第一個(gè)map（）調(diào)用將被刪除，其操作代碼會(huì)被融合到mapToPair處理過程中。

在編程模型提供的API中包含多個(gè)針對(duì)形式數(shù)據(jù)的聚合操作接口，如reduceByKey（）和groupByKey（），該類型操作的實(shí)現(xiàn)建立在正確的數(shù)據(jù)分類基礎(chǔ)之上。為了在集群中實(shí)現(xiàn)這兩種運(yùn)算，通常采用的方式是先將“父操作”產(chǎn)生的所有數(shù)據(jù)記錄按照散列值重新分組，再將各組數(shù)據(jù)分別引導(dǎo)至不同計(jì)算節(jié)點(diǎn)或不同計(jì)算進(jìn)程中，之后才能開始進(jìn)行數(shù)據(jù)聚合。對(duì)于那些同時(shí)滿足交換律和結(jié)合律的聚合操作來(lái)說(shuō)，這種處理方式無(wú)疑是低效的，因?yàn)橐徊糠謹(jǐn)?shù)據(jù)之間的聚合操作不必被推遲并等待下游節(jié)點(diǎn)完成。所以，更快速的處理方式是先在父節(jié)點(diǎn)中進(jìn)行一次局部數(shù)據(jù)聚合操作，再對(duì)數(shù)據(jù)分組并交給下游節(jié)點(diǎn)進(jìn)行全局聚合處理。這種提前聚合模型帶來(lái)的好處是：實(shí)現(xiàn)更快的處理速度以及網(wǎng)絡(luò)帶寬的高效利用。經(jīng)過上游節(jié)點(diǎn)的局部聚合，需要傳輸?shù)臄?shù)據(jù)量會(huì)大幅減少，因而傳輸延遲也會(huì)大幅降低。

在圖1中的DIStream 2需要同時(shí)監(jiān)聽并處理分別來(lái)自4個(gè)不同數(shù)據(jù)源的數(shù)據(jù)，如果它處理數(shù)據(jù)的速度低于數(shù)據(jù)注入的速度，那么數(shù)據(jù)將會(huì)在DIStream 2中持續(xù)堆積并最終造成系統(tǒng)性能的大幅度降低。任務(wù)擴(kuò)展是一種旨在提高任務(wù)并發(fā)性的優(yōu)化方案，通過增加工作節(jié)點(diǎn)和工作進(jìn)程來(lái)充分利用系統(tǒng)計(jì)算能力，從而加快任務(wù)處理速度。

3.3 ?實(shí)例優(yōu)化

首先，任務(wù)壓縮優(yōu)化技術(shù)將對(duì)原始SPG進(jìn)行處理。DIStream 2中的連續(xù)有限依賴操作union，flatMap和mapToPair被集成到同一步操作中，SIStream 1中的有限依賴操作以流水線的形式被裝配起來(lái)。另外，SIStream 1包含的冗余函數(shù)調(diào)用groupByKey（）和reduceByKey（）會(huì)在當(dāng)前優(yōu)化過程中被剔除。系統(tǒng)對(duì)DIStream 2進(jìn)行擴(kuò)展優(yōu)化引入一個(gè)新的處理流程，以并發(fā)處理的方式分擔(dān)計(jì)算壓力。針對(duì)SIStream 1中的reduceByKey（）調(diào)用，系統(tǒng)通過對(duì)上游操作進(jìn)行修改，使得數(shù)據(jù)聚合操作被提前至union（）處理過程中。這種局部聚合操作能大幅度減少中間結(jié)果傳輸量，并最終提升系統(tǒng)處理速度。

其次，編譯期間GHCM會(huì)對(duì)SPG進(jìn)行動(dòng)態(tài)優(yōu)化，SPG Optimizer通過合并有限依賴操作、提高程序并發(fā)性和充分利用數(shù)據(jù)局部性原理，重構(gòu)能與經(jīng)驗(yàn)豐富的程序員手動(dòng)優(yōu)化相媲美的程序。任務(wù)壓縮優(yōu)化技術(shù)以合并連續(xù)數(shù)據(jù)操作的方式提高程序運(yùn)行速度，優(yōu)化前后SPG中接口調(diào)用次數(shù)的改變能夠直觀地反映出這種技術(shù)的優(yōu)化效果，對(duì)GHCM的優(yōu)化模塊進(jìn)行改進(jìn)，使它在處理結(jié)束時(shí)記錄下重構(gòu)之后的SPG。在對(duì)5個(gè)不同規(guī)模的示例程序進(jìn)行任務(wù)壓縮優(yōu)化之后，統(tǒng)計(jì)得到的接口調(diào)用次數(shù)變化情況如表1所示。

在這5個(gè)測(cè)試程序中，最小接口調(diào)用次數(shù)為4，最大為24，經(jīng)過壓縮處理之后，原始程序被不同程度地精簡(jiǎn)。圖4用任務(wù)壓縮率的變化情況重新表述了本次測(cè)試得到的結(jié)果。

為了驗(yàn)證任務(wù)擴(kuò)展和提前聚合的有效性，分別以兩個(gè)計(jì)算單元DIStream 2和SIStream 1為測(cè)試目標(biāo)，記錄下優(yōu)化前后程序性能的改變。在驗(yàn)證過程中任務(wù)壓縮功能一直處于激活狀態(tài)，任務(wù)擴(kuò)展功能和提前聚合功能則根據(jù)測(cè)試需求被手動(dòng)激活或禁用。

針對(duì)任務(wù)擴(kuò)展優(yōu)化技術(shù)，設(shè)計(jì)了5個(gè)對(duì)比測(cè)試場(chǎng)景，分別為DIStream 2提供了1，2，4，8和16個(gè)并發(fā)數(shù)據(jù)源，每個(gè)數(shù)據(jù)源包含了一份大小為11 GB的樣本數(shù)據(jù)（約300萬(wàn)條記錄），實(shí)驗(yàn)結(jié)果如圖5所示。

當(dāng)數(shù)據(jù)源個(gè)數(shù)為1時(shí)，DIStream 2所花費(fèi)的時(shí)間約為33 s，因?yàn)镺ptimizer只會(huì)在應(yīng)對(duì)多數(shù)據(jù)源時(shí)才會(huì)擴(kuò)展用戶程序，所以此時(shí)優(yōu)化器對(duì)DIStream 2的運(yùn)行時(shí)間影響甚微。隨著并發(fā)數(shù)據(jù)源個(gè)數(shù)的增加，原始DIStream 2的運(yùn)行時(shí)間經(jīng)過相對(duì)平緩的爬升（數(shù)據(jù)源個(gè)數(shù)小于等于4）之后陡然增加。造成這種波動(dòng)的原因是，初期，程序可以利用工作節(jié)點(diǎn)本身的處理能力應(yīng)對(duì)多條并發(fā)數(shù)據(jù)流，但當(dāng)并發(fā)量超出節(jié)點(diǎn)所能承載的范圍后數(shù)據(jù)將會(huì)持續(xù)堆積，系統(tǒng)吞吐量隨之大幅度下降。與之對(duì)應(yīng)的，擴(kuò)展后的程序運(yùn)行時(shí)間不會(huì)隨著數(shù)據(jù)并發(fā)量的提高而顯著增加，工作節(jié)點(diǎn)間因交換數(shù)據(jù)而產(chǎn)生的時(shí)間開銷遠(yuǎn)遠(yuǎn)低于數(shù)據(jù)堆積對(duì)系統(tǒng)性能造成的影響。

對(duì)SIStream 1的測(cè)試結(jié)果建立在一份4.11 GB的樣本數(shù)據(jù)之上。結(jié)果顯示，將reduceByKey（）接口所要求的聚合操作提前至union（）階段后，SIStream 1獲得了近22%的速度提升，分析表明因局部聚合而減少的網(wǎng)絡(luò)數(shù)據(jù)傳輸開銷對(duì)系統(tǒng)提速貢獻(xiàn)最大。

3.4 ?GHCM系統(tǒng)性能分析

除了編程模型的通用性、靈活性和簡(jiǎn)潔性，提高系統(tǒng)性能也尤為重要。在應(yīng)用程序?qū)用?，?jīng)過SPG Optimizer優(yōu)化之后的用戶程序可以與經(jīng)驗(yàn)豐富的程序員手動(dòng)調(diào)優(yōu)的程序相媲美。而在系統(tǒng)底層，通過高性能計(jì)算引擎Spark和Storm來(lái)提高系統(tǒng)處理速度。

通過造出一組包含4個(gè)程序的測(cè)試集（包含基準(zhǔn)程序，即root program）來(lái)評(píng)價(jià)GHCM的性能。其中，所選取的基準(zhǔn)程序主要用于對(duì)網(wǎng)絡(luò)流量進(jìn)行實(shí)時(shí)分析，當(dāng)它檢測(cè)到異常流量時(shí)就會(huì)立即發(fā)出告警信息并通過關(guān)聯(lián)分析算法進(jìn)行攻擊場(chǎng)景重建。此外，該程序可以在用戶發(fā)出請(qǐng)求時(shí)將各項(xiàng)統(tǒng)計(jì)信息繪制成動(dòng)態(tài)圖像。在線模塊主要用于統(tǒng)計(jì)實(shí)時(shí)流量的狀態(tài)信息，例如：網(wǎng)絡(luò)瞬時(shí)流量、協(xié)議所占比例情況、關(guān)鍵節(jié)點(diǎn)服務(wù)器狀態(tài)等。離線模塊將IDS告警日志作為關(guān)聯(lián)規(guī)則的數(shù)據(jù)源，對(duì)每一條獨(dú)立的入侵檢測(cè)數(shù)據(jù)通過IP進(jìn)行攻擊溯源，經(jīng)過告警關(guān)聯(lián)判斷，告警決策樹生成，對(duì)整個(gè)攻擊流程進(jìn)行關(guān)聯(lián)分析，還原攻擊者對(duì)目標(biāo)機(jī)器攻擊的整個(gè)場(chǎng)景。該流量分析系統(tǒng)是混合計(jì)算模式在實(shí)際應(yīng)用場(chǎng)景中的一個(gè)典型案例：系統(tǒng)的流量監(jiān)測(cè)、分析功能對(duì)應(yīng)于實(shí)時(shí)計(jì)算模式;攻擊場(chǎng)景重建涉及到對(duì)大量數(shù)據(jù)的迭代運(yùn)算，所以這項(xiàng)功能對(duì)應(yīng)于批式計(jì)算模式;而接收用戶請(qǐng)求并動(dòng)態(tài)繪圖的功能屬于響應(yīng)式計(jì)算模式。嘗試以三種方式重新實(shí)現(xiàn)該流量分析程序：程序A將全部業(yè)務(wù)邏輯移植到Hadoop框架上;程序B分解原程序的業(yè)務(wù)邏輯，把實(shí)時(shí)任務(wù)移植到Storm框架上，把批處理任務(wù)移植到Spark框架上;程序C分解原程序的業(yè)務(wù)邏輯，把實(shí)時(shí)任務(wù)移植到Storm框架上，把批處理任務(wù)移植到Spark框架上，并對(duì)實(shí)時(shí)任務(wù)和批處理任務(wù)進(jìn)行手動(dòng)優(yōu)化。

由表2可以看出：程序A無(wú)法滿足對(duì)實(shí)時(shí)流量的分析需求以及動(dòng)態(tài)繪圖需求，只能在離線模式下實(shí)現(xiàn)攻擊場(chǎng)景重建功能，但在實(shí)際應(yīng)用場(chǎng)合，脫離了異常流量實(shí)時(shí)分析的攻擊場(chǎng)景重建是沒有意義的。程序B依托于底層的Storm計(jì)算引擎和Spark計(jì)算引擎，可承擔(dān)實(shí)時(shí)計(jì)算任務(wù)和批處理計(jì)算任務(wù)，但無(wú)法提供跨層次動(dòng)態(tài)調(diào)用服務(wù)，缺乏可重用性和易擴(kuò)展性。程序C是在程序B的基礎(chǔ)上進(jìn)行手動(dòng)優(yōu)化所生成的測(cè)試程序，二者所能提供的計(jì)算服務(wù)完全一致。

為比較上述4個(gè)程序的性能，分別以實(shí)時(shí)處理速度和批處理速度為指標(biāo)考察各待測(cè)程序。離線處理模塊使用的測(cè)試數(shù)據(jù)是天津理工大學(xué)IDS系統(tǒng)所產(chǎn)生的告警日志（512 240條記錄），在測(cè)試實(shí)時(shí)處理模塊時(shí)，將路由器產(chǎn)生的鏡像流量以700 MB/min的速度注入系統(tǒng)并將其作為源數(shù)據(jù)。實(shí)驗(yàn)過程中，提交作業(yè)、分發(fā)作業(yè)等時(shí)間開銷沒有被納入統(tǒng)計(jì)范圍，所關(guān)注的是待測(cè)功能模塊的“凈處理時(shí)間”，而且對(duì)于每個(gè)程序取其3次測(cè)試結(jié)果的平均值作為最終性能參數(shù)，實(shí)驗(yàn)結(jié)果如圖6和圖7所示。運(yùn)行在Hadoop平臺(tái)上的攻擊場(chǎng)景重建程序所耗費(fèi)的處理時(shí)間比運(yùn)行在Spark平臺(tái)上的相同程序多出近1倍，到達(dá)11 635 s。主要原因是，攻擊場(chǎng)景重建程序涉及大量迭代運(yùn)算，Hadoop在處理過程中需要多次訪問磁盤（讀寫中間計(jì)算結(jié)果），而Spark會(huì)將中間結(jié)果暫存在主存之中，使得在后續(xù)迭代過程中盡可能避免磁盤I/O代價(jià)。

觀察測(cè)試結(jié)果可以發(fā)現(xiàn)，手動(dòng)優(yōu)化之后的程序C相較于未調(diào)優(yōu)的原始程序B無(wú)論是在實(shí)時(shí)模塊吞吐量還是離線模塊處理速度方面都有較大幅度的提高，而且GHCM程序所實(shí)現(xiàn)的處理能力十分接近于手動(dòng)優(yōu)化之后的水平。

4 ?結(jié) ?語(yǔ)

針對(duì)高并發(fā)實(shí)時(shí)計(jì)算、大批量數(shù)據(jù)離線計(jì)算和動(dòng)態(tài)響應(yīng)式計(jì)算相結(jié)合的應(yīng)用需求，提出一種基于抽象計(jì)算單元IStream的通用編程模型，在實(shí)現(xiàn)混合計(jì)算模式的同時(shí)提供了跨層次的可重用性和易擴(kuò)展性。借助SPG優(yōu)化技術(shù)和底層計(jì)算引擎帶來(lái)的強(qiáng)大計(jì)算能力，GHCM中間件系統(tǒng)的性能可以得到足夠的保障。對(duì)于開發(fā)者而言，系統(tǒng)底層繁雜的實(shí)現(xiàn)細(xì)節(jié)完全被GHCM簡(jiǎn)單的高層抽象所取代，只需把所有精力投入到上層業(yè)務(wù)邏輯的設(shè)計(jì)過程中即可。此外，系統(tǒng)內(nèi)部中間計(jì)算結(jié)果的傳遞效率和跨層次交互優(yōu)化是未來(lái)工作中需要著力解決的關(guān)鍵問題。