周煜敏 王 鵬 汪 衛(wèi)

(復(fù)旦大學(xué)計(jì)算機(jī)科學(xué)技術(shù)學(xué)院 上海 200433)

0 引 言

隨著云時(shí)代的到來，大數(shù)據(jù)和云計(jì)算已經(jīng)吸引了越來越多的業(yè)內(nèi)外人士的關(guān)注。在諸如金融、電信和大規(guī)模傳感器監(jiān)控等許多領(lǐng)域中，在線處理實(shí)時(shí)數(shù)據(jù)，也稱為數(shù)據(jù)流處理也得到了越來越廣泛的應(yīng)用。數(shù)據(jù)流處理應(yīng)用程序通常需要低延遲、快速處理和實(shí)時(shí)反饋。

在物聯(lián)網(wǎng)的場(chǎng)景下，一套完整的系統(tǒng)由數(shù)千個(gè)傳感器節(jié)點(diǎn)的分布式集合組成，每個(gè)傳感器節(jié)點(diǎn)能夠從環(huán)境中感測(cè)多種類型的信息并以特定頻率發(fā)送數(shù)據(jù)。這就需要非常強(qiáng)大的分布式處理能力來滿足計(jì)算的需求。

在Storm、Spark以及Flink等實(shí)時(shí)大數(shù)據(jù)計(jì)算引擎不斷發(fā)展的同時(shí)，傳感器的分析專家則難以掌握這些計(jì)算引擎的處理原語。因此需要用一套簡(jiǎn)單的自定義的語言支持，幫助分析專家能夠簡(jiǎn)單地構(gòu)建計(jì)算邏輯，這樣才能夠最快速地為這些專家提供可靠的數(shù)據(jù)結(jié)果。

本文在深入分析了傳感器計(jì)算的需求后，發(fā)現(xiàn)絕大部分的計(jì)算都是基于傳感器數(shù)據(jù)的數(shù)值計(jì)算，而且都是基于滑動(dòng)窗口的計(jì)算，將高頻的數(shù)據(jù)的統(tǒng)計(jì)量以秒、分鐘至小時(shí)級(jí)別的頻率計(jì)算，加以輔助的閾值設(shè)定和四則運(yùn)算最終呈現(xiàn)結(jié)果。

本文試圖設(shè)計(jì)一套輕量但有效的方案，以支持在大量傳感器上運(yùn)行的多個(gè)查詢計(jì)算。由于處理是實(shí)時(shí)的，傳統(tǒng)的靜態(tài)數(shù)據(jù)平臺(tái)和算法不適合傳感器的流數(shù)據(jù)。同時(shí)，由于數(shù)據(jù)的高頻率，還應(yīng)該滿足處理的高吞吐量以對(duì)應(yīng)數(shù)據(jù)的攝入速率。對(duì)于傳感器監(jiān)測(cè)分析師，他們可以將計(jì)算需求轉(zhuǎn)化為腳本，系統(tǒng)會(huì)自動(dòng)解析并轉(zhuǎn)化Storm的流處理程序，將高頻數(shù)據(jù)處理之后再源源不斷地產(chǎn)生處理結(jié)果并及時(shí)反饋給分析師。

該系統(tǒng)還會(huì)針對(duì)優(yōu)化處理在計(jì)算的過程中出現(xiàn)的重復(fù)計(jì)算，衡量所涉及的通信和計(jì)算成本并通過中間結(jié)果共享的分區(qū)算法來減少網(wǎng)絡(luò)通信已達(dá)到更好的性能。

1 相關(guān)知識(shí)

1.1 相關(guān)工作

實(shí)時(shí)計(jì)算需要一個(gè)合適的分布式平臺(tái)輔助運(yùn)行，社區(qū)已經(jīng)開發(fā)了許多系統(tǒng)，例如早期的Aurora[1]、S4以及Storm[2]和Spark Streaming[3]等來處理秒級(jí)甚至毫秒級(jí)響應(yīng)中的大量數(shù)據(jù)。Storm具有高度可擴(kuò)展性，易于使用，并且具有低延遲和有保證的數(shù)據(jù)處理能力。同時(shí)，Storm提出了拓?fù)?Topology)的計(jì)算概念[4]，相比于傳統(tǒng)大數(shù)據(jù)引擎Hadoop的MapReduce更加靈活并且適合實(shí)時(shí)場(chǎng)景。這些特性都非常契合物聯(lián)網(wǎng)數(shù)據(jù)處理應(yīng)用的需求。與Storm不同，S4等系統(tǒng)無法保證每個(gè)元組都會(huì)被處理。而Spark Streaming則提出了一個(gè)新的模型，使用微批處理的方式用來近似進(jìn)行分布式流處理[5]，但其延遲對(duì)于實(shí)時(shí)響應(yīng)來說很高，無法滿足實(shí)際的應(yīng)用需求。

為了在大數(shù)據(jù)流上進(jìn)行計(jì)算，已經(jīng)提出了許多支持復(fù)雜事件處理(CEP)的語言，包括SQL-TS[6]、Cayuga[7]等。雖然他們?cè)O(shè)計(jì)了不同的語法規(guī)則，但某些語言不適合物聯(lián)網(wǎng)大數(shù)據(jù)的應(yīng)用程序場(chǎng)景。在過去的研究中，也有相關(guān)的研究人員設(shè)計(jì)了一套實(shí)時(shí)處理應(yīng)用輔助開發(fā)框架以簡(jiǎn)化開發(fā)人員工作[9]。而本文的工作專注于數(shù)據(jù)流上的聚合和滑動(dòng)窗口計(jì)算，而上述語言和系統(tǒng)設(shè)計(jì)初衷是處理更復(fù)雜的流處理作業(yè)，因此在分布式集群上并沒有良好的兼容性，使用這些語言會(huì)在解析子句和生成作業(yè)時(shí)會(huì)產(chǎn)生額外的開銷。

為了實(shí)現(xiàn)高吞吐量，應(yīng)該充分利用分布式集群。對(duì)性能的關(guān)注需要在有限的資源下完成工作。許多先前的研究已經(jīng)解決了在Storm上開發(fā)的一部分優(yōu)化問題。TMSH-Storm[8]有效降低了Storm的處理延遲和通信開銷，然而在多查詢的環(huán)境下，該方法的優(yōu)勢(shì)則并不明顯。

之前的許多文獻(xiàn)都討論了物聯(lián)網(wǎng)環(huán)境下傳感器的實(shí)時(shí)處理算法，例如：基于微簇的橋梁監(jiān)測(cè)數(shù)據(jù)流異常識(shí)別算法[10]，主要利用主成分分析提取特征，優(yōu)化異常檢測(cè)的計(jì)算；基于復(fù)雜事件處理的用戶需求響應(yīng)性能實(shí)時(shí)監(jiān)測(cè)分析，主要在復(fù)雜事件處理上實(shí)現(xiàn)了R算法的內(nèi)嵌和可視化的仿真[11]。這些文獻(xiàn)著重解決靜態(tài)數(shù)據(jù)的上下文的處理優(yōu)化而并非流處理。此外，還有一些文獻(xiàn)作了滑動(dòng)窗口相關(guān)的優(yōu)化，例如：具有不同長(zhǎng)度和不同選擇謂詞的滑動(dòng)窗口上的聚合的多查詢優(yōu)化[12]，然而沒有利用先驗(yàn)知識(shí)達(dá)到更好的效果。

1.2 滑動(dòng)窗口

實(shí)時(shí)查詢通常適用于無界數(shù)據(jù)流，而不是靜態(tài)數(shù)據(jù)集?？紤]到內(nèi)存限制，有必要設(shè)計(jì)用于維護(hù)流歷史的摘要或概要的技術(shù)。對(duì)于大多數(shù)應(yīng)用程序，數(shù)據(jù)流的最新元素比舊的元素更重要。因此這種對(duì)最近數(shù)據(jù)的偏好產(chǎn)生了實(shí)時(shí)流數(shù)據(jù)上的滑動(dòng)窗口的表達(dá)形式。窗口的大小和滑動(dòng)間隔通常使用時(shí)間間隔(基于時(shí)間)或元組數(shù)來指定(基于元組)。

在本文中滑動(dòng)窗口使用時(shí)間間隔標(biāo)準(zhǔn)，時(shí)間滑動(dòng)窗口W定義如下。

定義1將時(shí)間長(zhǎng)度為L(zhǎng)ms，每次滑動(dòng)時(shí)間長(zhǎng)度為Sms定義為滑動(dòng)窗口，記作W(L,S)。

W(L,S)所對(duì)應(yīng)的時(shí)間窗口如圖1所示。

圖1 時(shí)間滑動(dòng)窗口示意圖

當(dāng)需要計(jì)算W(L,S)中的數(shù)據(jù)時(shí)，就需要在內(nèi)存中存儲(chǔ)時(shí)間長(zhǎng)度為L(zhǎng)的數(shù)據(jù)以供計(jì)算，并且每Sms就需要給出當(dāng)前窗口的結(jié)果反饋。

1.3 數(shù)據(jù)格式

首先介紹一下流數(shù)據(jù)和查詢的基本數(shù)據(jù)結(jié)構(gòu)。每個(gè)傳感器都有一個(gè)唯一的標(biāo)識(shí)號(hào)。傳入數(shù)據(jù)流采用(sensor_id，timestamp，data)的數(shù)據(jù)格式。它指的是在timestamp時(shí)間戳?xí)r，sensor_id對(duì)應(yīng)傳感器的值為data。

Timestamp的類型為long，使用的是Unix時(shí)間戳。

Data的類型包括布爾類型、整數(shù)數(shù)據(jù)和實(shí)數(shù)數(shù)據(jù)。系統(tǒng)會(huì)將其統(tǒng)一轉(zhuǎn)化為單精度浮點(diǎn)類型進(jìn)行存儲(chǔ)和計(jì)算。

每個(gè)傳感器將以靜態(tài)頻率發(fā)送該結(jié)構(gòu)的元組。sensor_id與其頻率之間的關(guān)系存儲(chǔ)在數(shù)據(jù)庫(kù)中，在優(yōu)化計(jì)算時(shí)該信息會(huì)被使用。

1.4 語法規(guī)則

一位分析師可以對(duì)傳感器啟動(dòng)一系列查詢，并添加一些進(jìn)一步的計(jì)算以獲得檢查所需的最終結(jié)果。這里將查詢組稱為工作流。不同的分析師希望監(jiān)控不同傳感器上的不同參數(shù)，從而導(dǎo)致許多工作流一起執(zhí)行。為了消除歧義，應(yīng)該為工作流提供明確的定義，并為分析師提供語言標(biāo)準(zhǔn)，為此本文設(shè)計(jì)了一套腳本語言。

本文將用戶的查詢劃分為以下3類：

(1) 滑動(dòng)窗口聚合功能；

(2) 流聯(lián)合函數(shù)；

(3) 基本算術(shù)計(jì)算支持。

對(duì)于第一類，我們提供四種基本聚合功能：滑動(dòng)窗口的最大值、最小值、平均值、求和運(yùn)算。這4種函數(shù)每一種都需要3個(gè)參數(shù)，包括輸入的sensor_id，窗口長(zhǎng)度L和滑動(dòng)間隔S。計(jì)算所產(chǎn)生的結(jié)果可以計(jì)為用戶定義的新的流。例如：

A1=avg("S1",1 000,1 000)

該語句即代表了傳感器“S1”在1秒鐘的滑動(dòng)窗口上的平均值，計(jì)算的結(jié)果成為一個(gè)新的流，并命名為A1。

對(duì)于第二類，本文為流提供聯(lián)合函數(shù)union，其中的每個(gè)參數(shù)都是一個(gè)不同的流id，可以使用原始數(shù)據(jù)的sensor_id或者是另一個(gè)用戶定義的流id。該函數(shù)還將生成一個(gè)帶有新用戶定義id的連接流。

對(duì)于第三類，本文提供4個(gè)算術(shù)運(yùn)算(加，減，乘，除)和4個(gè)聚合函數(shù)(最大值，最小值，平均值，求和運(yùn)算)，接收不同的流id作為運(yùn)算參數(shù)，并持續(xù)計(jì)算結(jié)果輸出。與第一類計(jì)算不同，這些運(yùn)算符給出結(jié)果的時(shí)間發(fā)生在任何輸入?yún)?shù)值發(fā)生變化的時(shí)候，而不是等待窗口時(shí)間之后更新其結(jié)果。

以下腳本是工作流的另一個(gè)示例。這意味著首先計(jì)算兩個(gè)傳感器的平均值，并在一個(gè)10分鐘的滑動(dòng)窗口中以5分鐘的滑動(dòng)間隔計(jì)算兩個(gè)傳感器的連接流，然后在同一時(shí)間計(jì)算三個(gè)輸出流的最大值和平均值窗口。

MD1Z=avg("8MD1-AZ",600 000,300 000);

UNI=union("8MD2-A","8MD3-A");

MD23=avg("UNI",600 000,300 000);

MD4Z=avg("8MD4-AZ",600 000,300 000);

UNIF=union("MD1Z","MD23","MD4Z");

out_MZ=max("UNIF",600 000,300 000);

out_AZ=avg("UNIF",600 000,300 000)。

2 系統(tǒng)架構(gòu)

本節(jié)主要講述該實(shí)時(shí)計(jì)算平臺(tái)的系統(tǒng)架構(gòu)，如圖2所示。系統(tǒng)內(nèi)部主要分為三大模塊：腳本解析模塊、實(shí)時(shí)計(jì)算代碼生成模塊和分布式實(shí)時(shí)計(jì)算模塊。

圖2 計(jì)算平臺(tái)示意圖

2.1 腳本解析模塊

腳本解析模塊負(fù)責(zé)解析腳本語言，提取出關(guān)鍵信息供后續(xù)邏輯搭建，為后續(xù)模塊的查詢優(yōu)化提供信息。

當(dāng)收到所有的腳本時(shí)，這些腳本首先通過語法分析模塊生成抽象語法樹，然后再通過腳本所攜帶的額外信息通過計(jì)算圖生成模塊進(jìn)一步生成計(jì)算圖。為了使分析計(jì)算組組之間的時(shí)間序列計(jì)算的計(jì)算能夠共享，需要將計(jì)算組中的每一個(gè)語句，也就是每個(gè)計(jì)算，當(dāng)成一個(gè)節(jié)點(diǎn)看待，而運(yùn)算符和與該運(yùn)算所用到的底層所有其他運(yùn)算之間形成有向邊，對(duì)于用戶所給出的計(jì)算組進(jìn)行一個(gè)有向圖狀的描述，從而對(duì)于相同的操作可以進(jìn)行有效的合并。

本模塊通過ANTLR的解析，能夠識(shí)別出對(duì)于相同傳感器的聚集操作，對(duì)于其中不同的窗口進(jìn)行最大公約數(shù)的合并計(jì)算，以最大限度地節(jié)省不必要的計(jì)算。由于減少了一些重復(fù)互相有交集的時(shí)間片段數(shù)據(jù)存儲(chǔ)，因此在橋梁傳感器網(wǎng)絡(luò)監(jiān)測(cè)的高頻率數(shù)據(jù)流的應(yīng)用情景下，合并切分窗口來進(jìn)行分析計(jì)算會(huì)節(jié)省不少內(nèi)存消耗。

這些信息將通過信息收集模塊將代碼所需信息存儲(chǔ)起來，以便后續(xù)使用。

在1.4節(jié)中描述的腳本語言簡(jiǎn)易的語法使得以前需要使用成千上萬行的Storm代碼才能完成的查詢邏輯，只需要幾十條語句便可以完成。當(dāng)用戶遇到查詢需求變更的時(shí)候，用戶只需要把簡(jiǎn)短的幾十條語句作輕微的修改，然后由實(shí)時(shí)計(jì)算代碼生成模塊重新生成可以執(zhí)行的Storm代碼，進(jìn)行部署和運(yùn)行。

2.2 實(shí)時(shí)計(jì)算代碼生成模塊

實(shí)時(shí)計(jì)算代碼生成模塊通過Java反射機(jī)制，根據(jù)用戶的腳本需求，將計(jì)算圖進(jìn)一步轉(zhuǎn)化為Storm的Bolt具體的處理代碼。

上一模塊產(chǎn)生的計(jì)算圖的結(jié)果，分別經(jīng)過代碼生成模塊和優(yōu)化分區(qū)結(jié)果生成模塊的解析、相應(yīng)的源代碼和分區(qū)結(jié)果。

其中代碼生成模塊主要運(yùn)用Java語言的反射機(jī)制，將計(jì)算圖的邏輯轉(zhuǎn)換成相對(duì)應(yīng)的Java函數(shù)，并配置對(duì)應(yīng)的參數(shù)。而每一種函數(shù)都對(duì)應(yīng)一段具體的Storm原語的計(jì)算邏輯。

對(duì)于優(yōu)化分區(qū)結(jié)果生成模塊而言，由于多個(gè)腳本之間存在重復(fù)的查詢語句，因此代碼生成模塊中還包含了查詢共享發(fā)現(xiàn)模塊。該模塊負(fù)責(zé)把腳本中存在的重復(fù)查詢語句組進(jìn)行合并去重，減少數(shù)據(jù)流元組在網(wǎng)絡(luò)中的重復(fù)傳輸以及在集群中的重復(fù)計(jì)算。本文采用的查詢共享模塊的算法架構(gòu)和具體實(shí)現(xiàn)如下：

對(duì)于一個(gè)分布式集群，如果所有的計(jì)算能夠相對(duì)平均的分配到每一個(gè)計(jì)算節(jié)點(diǎn)上去，那么集群的計(jì)算能力就能夠得到最大程度的發(fā)揮，計(jì)算的吞吐量也得以提升。而實(shí)際情況中，在一個(gè)工作流中通常存在對(duì)于相同的流的計(jì)算的情況，如果這些計(jì)算能夠分區(qū)在一起將會(huì)共享計(jì)算結(jié)果，減少重復(fù)的計(jì)算，從而獲得更好的性能。同時(shí)，如果兩個(gè)不同的工作流程共享同一個(gè)傳感器計(jì)算或甚至相同的窗口聚集計(jì)算，那將這兩個(gè)工作流程合并在一起也能降低通信成本，從而提高性能。

基于以上想法，采用啟發(fā)式算法進(jìn)行分區(qū)優(yōu)化見算法1。

算法1分區(qū)優(yōu)化算法

輸入：分布式工作節(jié)點(diǎn)個(gè)數(shù)n，計(jì)算圖G，數(shù)據(jù)庫(kù)中存儲(chǔ)的傳感器數(shù)據(jù)頻率Freq[]

輸出：每個(gè)傳感器的分區(qū)結(jié)果Map:Partition

for i :=1 to n

W[i] :=0

//工作節(jié)點(diǎn)負(fù)載

foreach G的子圖G’

load[G’] := 0

foreach G’中所有傳感器sensor_id

load[G’] :=load[G’]+freq[sensor_id]

Arrays.sort(load)

foreach G的子圖G’(按load從大到小)

target :=W數(shù)組中最小值下標(biāo)

foreach G’中所有傳感器sensor_id

Partition.put(sensor_id,target)

算法首先將每一個(gè)結(jié)點(diǎn)的計(jì)算復(fù)雜度作為該節(jié)點(diǎn)的權(quán)重，然后以子圖的粒度進(jìn)行權(quán)重的計(jì)算。獲取劃分算法之后，通過加權(quán)輪詢算法判斷子圖和分區(qū)的對(duì)應(yīng)關(guān)系，以達(dá)到負(fù)載均衡。

2.3 分布式實(shí)時(shí)計(jì)算框架

分布式實(shí)時(shí)計(jì)算通過分布式Storm集群實(shí)現(xiàn)，其Storm的拓?fù)浣Y(jié)構(gòu)如圖3所示。

圖3 Storm計(jì)算拓?fù)涫疽鈭D

在Storm拓?fù)渲校瑪?shù)據(jù)源模塊將持續(xù)發(fā)送原始傳感器數(shù)據(jù)的元組，在計(jì)算之前還需要一層Filter Bolt以過濾無關(guān)傳感器的流式數(shù)據(jù)。在查詢組中所設(shè)計(jì)到的要處理的數(shù)據(jù)種類是有限的，正如橋梁檢測(cè)系統(tǒng)中的原始數(shù)據(jù)通道可能有幾千個(gè)，而查詢組中涉及到的通道卻有可能只有非常少量的部分。因此本文增加了這一層過濾模塊，將不必要的傳感器數(shù)據(jù)從系統(tǒng)中過濾出去，有效減少了整個(gè)分布式系統(tǒng)的負(fù)載和計(jì)算壓力。

數(shù)據(jù)流中的元組從一個(gè)組件發(fā)往另外一個(gè)組件需要指定發(fā)送的分組方式，默認(rèn)的隨機(jī)分組并不能有效地解決大規(guī)模傳感器場(chǎng)景下數(shù)據(jù)不均衡所帶來的性能壓力。2.2節(jié)所述的分區(qū)優(yōu)化算法幫助系統(tǒng)產(chǎn)生了負(fù)載更均衡的數(shù)據(jù)分區(qū)對(duì)應(yīng)關(guān)系。我們利用了Storm系統(tǒng)提供的CustomGrouping API，將優(yōu)化算法輸出的Map優(yōu)化分區(qū)結(jié)果應(yīng)用于Storm的數(shù)據(jù)中，進(jìn)行重排分發(fā)。數(shù)據(jù)會(huì)相對(duì)均勻地交給后續(xù)Calc Bolt的每一個(gè)具體實(shí)例任務(wù)。

Calc Bolt接收代碼生成模塊傳遞的參數(shù)和代碼，能夠保證運(yùn)算嚴(yán)格按照用戶腳本所定義的窗口運(yùn)行。而上游的優(yōu)化分組策略能夠進(jìn)一步降低網(wǎng)絡(luò)傳輸?shù)拇鷥r(jià)，提升整個(gè)系統(tǒng)的計(jì)算效率。

Result Bolt和Calc Bolt的原理很類似，它會(huì)接收Calc Bolt的計(jì)算結(jié)果，以相對(duì)較低的負(fù)載完成上層結(jié)果的計(jì)算并在命令行進(jìn)行輸出。不同的是，Result Bolt的計(jì)算在接收數(shù)據(jù)的瞬間觸發(fā)而非等待窗口到達(dá)。

本系統(tǒng)結(jié)合物聯(lián)網(wǎng)傳感器計(jì)算的窗口聚合計(jì)算占比較大，計(jì)算同質(zhì)性較大等特點(diǎn)，完成了一個(gè)基于匹配的查詢優(yōu)化算法，使得對(duì)于海量流式數(shù)據(jù)在分布式系統(tǒng)中的處理更加平衡，從而節(jié)約資源，提高查詢效率和性能。

3 實(shí) 驗(yàn)

3.1 測(cè)試集群

實(shí)驗(yàn)環(huán)境使用由1個(gè)Master和4個(gè)Slave組成的Storm集群。每個(gè)節(jié)點(diǎn)都有64 GB內(nèi)存，6×2.0 GHz(Intel Xeon E5-2620)CPU和6 TB磁盤空間。所有節(jié)點(diǎn)都通過1 GB以太網(wǎng)連接。

3.2 數(shù)據(jù)集

實(shí)驗(yàn)使用真實(shí)的上海市的大橋傳感器數(shù)據(jù)，傳感器種類達(dá)21種，總數(shù)量達(dá)到了1 000，其中大多數(shù)傳感器的數(shù)據(jù)傳輸速率達(dá)到了20 Hz以上，每秒鐘傳輸?shù)臄?shù)據(jù)量約30 MB。數(shù)據(jù)通過傳感器采集系統(tǒng)的加密socket協(xié)議進(jìn)入系統(tǒng)。

工作流程由經(jīng)驗(yàn)豐富的工程師設(shè)計(jì)，因此監(jiān)控結(jié)果在實(shí)際應(yīng)用中具有重要意義。此外，工程師來自不同的領(lǐng)域，包括一些交叉領(lǐng)域。不同類型的傳感器以復(fù)雜的方式使用。本文從工程師那里收集了1 024個(gè)不同的工作流程。

3.3 實(shí)驗(yàn)結(jié)果及分析

通過套接字獲取數(shù)據(jù)源并將其放入Apache Kafka[13]作為Spout的數(shù)據(jù)生成器。作為對(duì)比實(shí)驗(yàn)，本文在sensor_id上使用fieldGrouping來對(duì)所有數(shù)據(jù)進(jìn)行分區(qū)(圖例中naive算法)，而Storm的拓?fù)浣Y(jié)構(gòu)保持不變。這樣，所有的傳感器會(huì)以隨機(jī)的方式分配到不同的計(jì)算節(jié)點(diǎn)上進(jìn)行運(yùn)算，可以有效地檢驗(yàn)本文所述優(yōu)化和算法的有效性。

本文使用兩個(gè)性能指標(biāo)：通信成本和節(jié)省的代碼行。通信成本通過每分鐘Filter Bolt與Calc Bolt任務(wù)之間傳遞的數(shù)據(jù)單元的數(shù)量來衡量。節(jié)省的代碼行是將腳本語言的行數(shù)和直接在Storm上編寫代碼執(zhí)行所有流處理邏輯的代碼行數(shù)的比較，該參數(shù)可以直觀地測(cè)量為傳感器監(jiān)測(cè)專家節(jié)省的工作量。

本文使用兩個(gè)評(píng)估參數(shù)：計(jì)算涉及傳感器的數(shù)量n和計(jì)算中共享的傳感器的數(shù)量ns。n可以反映工作量的復(fù)雜性，而ns可以反映可以共享的數(shù)據(jù)量，也就是整個(gè)計(jì)算圖的連接性。

系統(tǒng)的通信成本遠(yuǎn)低于對(duì)比方法，在各種計(jì)算量的實(shí)驗(yàn)中，平均提高了20%，并且特別在大計(jì)算量的實(shí)驗(yàn)中更顯著(見圖4)。這是因?yàn)楫?dāng)計(jì)算量更大時(shí)，會(huì)存在更多的重復(fù)計(jì)算的優(yōu)化空間，證明了分區(qū)算法的優(yōu)勢(shì)。

圖4 網(wǎng)絡(luò)傳輸量對(duì)比實(shí)驗(yàn)結(jié)果

本文使用16個(gè)相同數(shù)據(jù)發(fā)送頻率的傳感器進(jìn)行了另一組腳本實(shí)驗(yàn)，并且構(gòu)造了相同的計(jì)算邏輯。唯一的區(qū)別是本文改變不同的sensor_id以獲得不同的ns來改變數(shù)據(jù)計(jì)算的可共享性。當(dāng)ns增加時(shí)，系統(tǒng)的表現(xiàn)遠(yuǎn)遠(yuǎn)好于對(duì)比算法(參見圖5)，實(shí)驗(yàn)表明本文算法更好地利用了可利用的先驗(yàn)知識(shí)讓計(jì)算盡可能在本地進(jìn)行?？梢钥闯?，本系統(tǒng)在共享8個(gè)傳感器的計(jì)算中，達(dá)到最多20%的網(wǎng)絡(luò)傳輸減少，進(jìn)一步體現(xiàn)了本文算法的有效性。

圖5 網(wǎng)絡(luò)傳輸量和計(jì)算可共享傳感器數(shù)量關(guān)系實(shí)驗(yàn)結(jié)果

另外本文測(cè)試了直接編寫Java代碼來直接實(shí)現(xiàn)計(jì)算邏輯，并和精簡(jiǎn)的腳本語言進(jìn)行比較。實(shí)驗(yàn)發(fā)現(xiàn)：如果代碼不是由系統(tǒng)自動(dòng)生成的，將會(huì)需要完成大量的重復(fù)編碼工作。從表1中看出，尤其是當(dāng)查詢數(shù)量很大時(shí)，腳本行數(shù)相對(duì)于Java的代碼行數(shù)有了極大的減少，這說明了本文提供的腳本語言為傳感器監(jiān)控專家節(jié)省了大量的精力。

表1 腳本優(yōu)化情況比較

4 結(jié) 語

本文提出了大規(guī)模傳感器流數(shù)據(jù)中的實(shí)時(shí)聚合計(jì)算框架的方法。主要貢獻(xiàn)是提供了適合這一類計(jì)算的簡(jiǎn)單易用的腳本語言和相應(yīng)的分布式計(jì)算系統(tǒng)。腳本語言使分析人員能夠在滑動(dòng)窗口的聚合的組合中構(gòu)建自己的計(jì)算邏輯。同時(shí)，該系統(tǒng)平臺(tái)可以將腳本語言解釋為Storm拓?fù)?，使用智能?jì)算和分組方法來顯著提高性能。實(shí)驗(yàn)證明了本文所述的系統(tǒng)使得傳感器監(jiān)控專家從編碼工作中解脫，在計(jì)算大規(guī)模傳感器的應(yīng)用中降低了流處理的通信成本，從而能夠在分布式環(huán)境中處理大量的查詢。