一種通用混合計算中間件的設(shè)計與實現(xiàn)

張洪豪 姚欣 王勁松 姚世春

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

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

中圖分類號： TN911.2?34; TP302 ? ? ? ? ? ? ? ? 文獻標識碼： A ? ? ? ? ? ? ? ? ? ? ?文章編號： 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 ?引 ?言

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

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

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

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

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

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

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

1 ?相關(guān)工作

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.3 ?實例優(yōu)化

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

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

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

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

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

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

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

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

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

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

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

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

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

4 ?結(jié) ?語

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