王春凱，莊福振，史忠植

（1.中國再保險(xiǎn)(集團(tuán))股份有限公司 博士后科研工作站，北京 100033; 2.中國科學(xué)院 計(jì)算技術(shù)研究所，北京 100190）

日前，許多應(yīng)用需要大規(guī)模的連續(xù)查詢和分析，如：社會(huì)網(wǎng)絡(luò)中的微博分析、金融領(lǐng)域中的高頻交易監(jiān)控，以及電子商務(wù)中的實(shí)時(shí)推薦等[1-3]。這些應(yīng)用往往需要快速響應(yīng)用戶提交的查詢請求，要求大規(guī)模數(shù)據(jù)流管理系統(tǒng)對數(shù)據(jù)流的查詢處理具有較高的吞吐率和較低的處理延遲。這往往需要用戶預(yù)先設(shè)置相關(guān)的系統(tǒng)參數(shù)，如查詢算子的并行度、查詢進(jìn)程的內(nèi)存使用率等。然而，由于數(shù)據(jù)流的易變性和查詢?nèi)蝿?wù)的不同，為確保實(shí)時(shí)處理查詢請求的同時(shí)盡量減少資源使用情況是一個(gè)非常有挑戰(zhàn)性的問題。接下來舉例說明該問題的普遍性。

我們以交通監(jiān)控系統(tǒng)實(shí)時(shí)分析路況為例，使用流處理系統(tǒng)Storm[4]和軌跡數(shù)據(jù)集GeoLife[5]實(shí)現(xiàn)如下查詢?nèi)蝿?wù)。查詢包含一個(gè)映射處理邏輯，用于接收由GPS 設(shè)備采集的軌跡數(shù)據(jù)，并通過函數(shù)映射找到使用該GPS 設(shè)備的對象所在的道路信息。此外，包括一個(gè)測速處理邏輯接收來自映射處理邏輯發(fā)送的數(shù)據(jù)，并實(shí)時(shí)計(jì)算出不同道路上的各GPS 設(shè)備對象的平均行駛速度。

然而，配置查詢?nèi)蝿?wù)的參數(shù)不能動(dòng)態(tài)感知數(shù)據(jù)流的變化，導(dǎo)致了查詢延遲的增加和系統(tǒng)資源的浪費(fèi)。為應(yīng)對此問題，文獻(xiàn)[6-7]已進(jìn)行了相關(guān)研究。但是，文獻(xiàn)[6]需要重啟查詢?nèi)蝿?wù)，數(shù)據(jù)阻塞和查詢延遲的問題較為突出；文獻(xiàn)[7]通過保存狀態(tài)信息避免了查詢?nèi)蝿?wù)的重啟操作。然而，針對流速頻繁改變的易變數(shù)據(jù)流，文獻(xiàn)[6-7]均會(huì)導(dǎo)致系統(tǒng)延遲的緩慢增加，以至于超過用戶自定義的查詢延遲閾值。為此，本文提出了應(yīng)對易變數(shù)據(jù)流的系統(tǒng)資源動(dòng)態(tài)配置方法OrientStream+。與文獻(xiàn)[6-7] 提出的OrientStream 相比，Orient-Stream+可較好解決易變數(shù)據(jù)流的資源配置問題，進(jìn)一步降低流處理系統(tǒng)的查詢延遲并提高系統(tǒng)的吞吐率。

針對系統(tǒng)資源動(dòng)態(tài)配置的相關(guān)工作可總結(jié)為如下3 個(gè)方面：

1) 動(dòng)態(tài)加載調(diào)度策略。Aeolus[8]是柏林洪堡大學(xué)和惠普實(shí)驗(yàn)室聯(lián)合研發(fā)的Storm 優(yōu)化器，用于動(dòng)態(tài)設(shè)置算子的并行度和節(jié)點(diǎn)內(nèi)部數(shù)據(jù)的批量大小。Aeolus 定義了處理單條元組所需時(shí)間的代價(jià)模型，其中包括元組的傳輸時(shí)間、等待時(shí)間、計(jì)劃處理時(shí)間和實(shí)際處理時(shí)間。依據(jù)該模型，針對不同的查詢請求和數(shù)據(jù)流特征(如數(shù)據(jù)流速、數(shù)據(jù)分布情況等)，Aeolus 可計(jì)算出算子并行度和數(shù)據(jù)批量傳輸大小的最佳配置樣式。為避免資源浪費(fèi)或無法實(shí)時(shí)獲取正確的查詢結(jié)果，F(xiàn)U 等[9]設(shè)計(jì)了基于云環(huán)境的大規(guī)模數(shù)據(jù)流管理系統(tǒng)的動(dòng)態(tài)資源調(diào)度器。該調(diào)度器借助開放排隊(duì)網(wǎng)絡(luò)[10]理論來度量已使用資源和查詢響應(yīng)時(shí)間的關(guān)系、制定最佳資源配置方案以及使用最小開銷測量系統(tǒng)的負(fù)載等。Aniello 等[11]針對Storm 平臺(tái)，利用基于拓?fù)涞牟呗院突诹髁康膭?dòng)態(tài)調(diào)度策略設(shè)計(jì)了兩個(gè)調(diào)度算法，以降低元組處理的延遲時(shí)間和減少多個(gè)拓?fù)涔?jié)點(diǎn)間的傳輸流量。然而，Aeolus 和DRS 需要明確每個(gè)算子的具體處理時(shí)間，并且僅用于固定的查詢應(yīng)用場景。文獻(xiàn)[11]僅考慮傳輸延遲，而未關(guān)注資源使用的情況，并且不能對算子的并行度做動(dòng)態(tài)調(diào)整。

2) 機(jī)器學(xué)習(xí)技術(shù)。文獻(xiàn)[12]提出了一種基于混合密度網(wǎng)絡(luò)[13]的模型來評估數(shù)據(jù)流處理任務(wù)的資源使用情況。該模型可幫助用戶判斷是否向流處理系統(tǒng)提交新的查詢?nèi)蝿?wù)。ALOJA 項(xiàng)目[14]針對Hadoop[15]的執(zhí)行情況開發(fā)了開源平臺(tái)用于預(yù)測查詢?nèi)蝿?wù)的執(zhí)行時(shí)間和異常監(jiān)控。ALOJA是基于ALOJA-ML[16]設(shè)計(jì)的框架，ALOJA-ML 利用機(jī)器學(xué)習(xí)技術(shù)分析了運(yùn)行在Hadoop 上的不同查詢?nèi)蝿?wù)的基準(zhǔn)性能數(shù)據(jù)，并以此支持查詢?nèi)蝿?wù)的性能調(diào)優(yōu)。Jamshidi 等[17]設(shè)計(jì)了一種自動(dòng)優(yōu)化流處理系統(tǒng)參數(shù)配置的貝葉斯優(yōu)化算法BO4-CO。以MySQL 和Postgres 為實(shí)驗(yàn)平臺(tái)，Otter-Tune[18]利用經(jīng)驗(yàn)數(shù)據(jù)的監(jiān)督學(xué)習(xí)方法和新搜集信息的非監(jiān)督學(xué)習(xí)方法，針對不同查詢請求選擇出對系統(tǒng)性能影響最大的參數(shù)，并通過歷史查詢?nèi)蝿?wù)對新的查詢?nèi)蝿?wù)進(jìn)行預(yù)測，利用深度學(xué)習(xí)框架TensorFlow[19]向用戶推薦最佳參數(shù)配置。然而，文獻(xiàn)[12]不能動(dòng)態(tài)改變流處理系統(tǒng)的調(diào)度策略和各個(gè)算子的并行度，且不可以預(yù)測系統(tǒng)資源的使用情況。ALOJA-ML 框架僅可預(yù)測Hadoop的處理平臺(tái)，OtterTune 系統(tǒng)僅可預(yù)測數(shù)據(jù)庫管理系統(tǒng)，均不能用于數(shù)據(jù)流的查詢場景。BO4CO 只能以流處理系統(tǒng)的歷史數(shù)據(jù)作為訓(xùn)練集，不能對新收集的性能數(shù)據(jù)作增量分析。

3) 針對關(guān)系查詢系統(tǒng)的資源預(yù)測。正如我們所知，關(guān)系查詢系統(tǒng)往往具有類SQL 的查詢接口。因此，有些研究也致力于檢測SQL 查詢的資源消耗。針對微軟的SQL Server 數(shù)據(jù)庫的不同查詢請求，Li 等[20]設(shè)計(jì)了兩種特征抽取的機(jī)制用于預(yù)測SQL 查詢的資源消耗情況。兩種特征包括粗粒度的全局特征和細(xì)粒度的算子特征。Akdere 等[21]為預(yù)測不同查詢計(jì)劃的查詢性能，構(gòu)建了3 種層次模型：查詢計(jì)劃層模型、算子層模型和針對嵌套查詢的混合模型。然而，模型[20-21]僅考慮了靜態(tài)特征的選擇過程，不能對系統(tǒng)進(jìn)行動(dòng)態(tài)監(jiān)控，并且沒有考慮位于關(guān)系查詢系統(tǒng)下面的數(shù)據(jù)處理系統(tǒng)的有關(guān)特征。

本文提出的OrientStream+框架不同于以上工作。OrientStream+構(gòu)建了以延遲閾值為間隔片段的微批量樣式(mini-batch scheme)的數(shù)據(jù)流傳輸機(jī)制，利用多級(jí)別管道緩存計(jì)算出精準(zhǔn)查詢結(jié)果，并提出異常檢測的增量學(xué)習(xí)模型ODRegression (outerlier detection regression)，可較好解決易變數(shù)據(jù)流的資源配置問題。

1 基本概念與問題描述

1.1 概念描述

OrientStream+需要實(shí)時(shí)監(jiān)控大規(guī)模數(shù)據(jù)流管理系統(tǒng)的查詢執(zhí)行情況，并基于不同的數(shù)據(jù)流速和參數(shù)配置搜集訓(xùn)練數(shù)據(jù)集。接下來，我們給出形式化的定義。

由于數(shù)據(jù)流無限的特性，本文采集訓(xùn)練數(shù)據(jù)集的過程使用窗口模型(見定義1)。

定義1窗口模型。將無限的數(shù)據(jù)流切分成若干有限子數(shù)據(jù)流，每次的查詢處理僅針對當(dāng)前窗口內(nèi)的子數(shù)據(jù)流。一般可根據(jù)用戶設(shè)定的時(shí)間間隔或窗口內(nèi)元組數(shù)量設(shè)置窗口大小，并在多查詢場景下使用翻轉(zhuǎn)窗口或滑動(dòng)窗口的語義信息。

在OrientStream+框架中，我們使用基于時(shí)間間隔的窗口模型獲取訓(xùn)練集。每個(gè)具有不同時(shí)間間隔的窗口作為一條訓(xùn)練數(shù)據(jù)。訓(xùn)練樣本搜集過程中，時(shí)間窗口的下限是30 s，上限是120 s。首先，以初始的參數(shù)配置啟動(dòng)查詢請求，當(dāng)窗口大小達(dá)到時(shí)間間隔約束時(shí)，我們采集一條訓(xùn)練數(shù)據(jù)。接下來，以新的窗口大小和新的參數(shù)配置重啟查詢請求，用于獲取下一條訓(xùn)練數(shù)據(jù)。最后，通過迭代操作，我們可采集到不同窗口大小和配置信息的訓(xùn)練數(shù)據(jù)集。

定義2算子并行度。構(gòu)建在分布式集群上的流處理系統(tǒng)往往可同時(shí)執(zhí)行由不同類型算子構(gòu)成的若干拓?fù)淙蝿?wù)。每個(gè)算子可根據(jù)不用的查詢請求設(shè)置不同的并行度，一般以多線程的形式實(shí)現(xiàn)。以本文使用的Storm 系統(tǒng)為例，可動(dòng)態(tài)設(shè)置數(shù)據(jù)源部件spout 和查詢處理部件bolt 的單元實(shí)例task 的并行度。

定義3系統(tǒng)處理延遲。每個(gè)數(shù)據(jù)流元組

被各個(gè)查詢算子處理延遲的總和。數(shù)據(jù)源i的處理延遲表示為每個(gè)單元實(shí)例處理延遲的平均值，形式化定義為

式中：m是數(shù)據(jù)源(source)節(jié)點(diǎn)的并行度。然而，由于查詢請求往往涉及到多個(gè)數(shù)據(jù)流，因此，大規(guī)模數(shù)據(jù)流管理系統(tǒng)的處理延遲需要按照每個(gè)數(shù)據(jù)源的最大處理延遲來定義，形式化定義為

式中n是查詢請求中涉及到的數(shù)據(jù)源個(gè)數(shù)。

定義4參數(shù)配置。向流處理系統(tǒng)提交查詢?nèi)蝿?wù)時(shí)，需提前定義進(jìn)程的內(nèi)存大小、不同算子的并行度等參數(shù)信息。該過程稱為系統(tǒng)資源的參數(shù)配置。

1.2 問題定義

向大規(guī)模數(shù)據(jù)流管理系統(tǒng)提交查詢請求時(shí)，往往需要憑借用戶的經(jīng)驗(yàn)和平臺(tái)的硬件情況動(dòng)態(tài)配置不同的參數(shù)。參數(shù)配置是否合理將直接影響系統(tǒng)的吞吐率和處理延遲，以及平臺(tái)的資源使用情況。隨著數(shù)據(jù)流的變化情況，我們需要?jiǎng)討B(tài)調(diào)整參數(shù)配置以滿足用戶對處理延遲和系統(tǒng)吞吐率閾值的要求。但是，流處理系統(tǒng)往往不允許任意調(diào)整配置參數(shù)。比如，Storm 的“re-balance”機(jī)制，僅可降低處理單元的并行度，不能超越用戶設(shè)定的最大處理單元實(shí)例值。

我們需要對任意的參數(shù)配置預(yù)測資源使用情況、處理延遲和系統(tǒng)吞吐率。根據(jù)預(yù)測結(jié)果，從中選取最優(yōu)配置。即，在保證處理延遲和系統(tǒng)吞吐率滿足用戶設(shè)定閾值的前提下，盡量減少CPU和內(nèi)存的資源使用率。該問題可形式化表示為資源使用最優(yōu)化的問題，定義如下。

令N=(n1,n2,···) 為集群的各個(gè)節(jié)點(diǎn)集合，每個(gè)節(jié)點(diǎn)ni關(guān)于CPU 使用情況Ucpu和內(nèi)存使用情況Umemory可用式(3)表示。

式中：α和β分別是CPU 和內(nèi)存使用率的權(quán)重。本文中，α和β均設(shè)置為50%。

接下來，令C=(c1,c2,···) 為用戶提供的候選配置集合。對整個(gè)集群來講，我們需要預(yù)測出最佳的配置copt以實(shí)現(xiàn)式(4)的優(yōu)化目標(biāo)。

式中：R(latency)和R(throughput)是查詢請求的處理延遲和吞吐率；T(latency)和T(throughput)是用戶設(shè)置的對應(yīng)閾值。

2 系統(tǒng)設(shè)計(jì)

2.1 OrientStream+概述

如圖1 所示，給出了OrientStream+系統(tǒng)的架構(gòu)圖。該系統(tǒng)主要分為3 個(gè)部分：左部是層次性的特征抽取機(jī)制，從下向上主要分為3 個(gè)部分即硬件集群層特征集、流處理系統(tǒng)算子層特征集，以及流查詢系統(tǒng)的查詢計(jì)劃層特征集；中部是對n個(gè)數(shù)據(jù)流以微批量的處理方式，通過模型預(yù)測獲取m個(gè)參數(shù)配置，并將相同參數(shù)配置的子數(shù)據(jù)流存放至同一個(gè)Kafka[22]消息隊(duì)列中。右部是查詢監(jiān)視器(query monitor)，主要負(fù)責(zé)采集特征數(shù)據(jù)并通過增量學(xué)習(xí)模型預(yù)測系統(tǒng)資源的使用情況，可從候選配置項(xiàng)集中預(yù)測出最佳配置和異常警告。

圖1 OrientStream+系統(tǒng)架構(gòu)圖Fig.1 OrientStream+ architecture

2.2 微批量數(shù)據(jù)樣式傳輸

由于頻繁設(shè)置系統(tǒng)的參數(shù)配置會(huì)導(dǎo)致處理延遲的不斷增加，所以引入Sax 等在文獻(xiàn)[23]中提出的批量層次策略，以用戶設(shè)置的查詢延遲閾值為滑動(dòng)窗口大小，在Storm 系統(tǒng)上使用該策略實(shí)現(xiàn)窗格內(nèi)數(shù)據(jù)的微批量處理。

2.3 資源配置策略

2.3.1 多管道數(shù)據(jù)緩存

根據(jù)微批量數(shù)據(jù)傳輸模式，我們以用戶定義的延遲閾值為微批量傳輸?shù)拇翱诖笮?。如圖1 中間部分所示，窗口內(nèi)的微批量數(shù)據(jù)首先通過增量學(xué)習(xí)的模型進(jìn)行參數(shù)配置的預(yù)測，依次記錄需要調(diào)整配置的次數(shù)c1、c2、···、cn。針對不同類型的查詢請求，現(xiàn)場調(diào)整機(jī)制下,以文獻(xiàn)[7]的實(shí)驗(yàn)結(jié)果所示，拓?fù)淙蝿?wù)的調(diào)整延遲在100～300 ms 之間。本文中，我們以上限300 ms 當(dāng)作單次調(diào)整的延遲，設(shè)計(jì)了多管道數(shù)據(jù)緩存算法MPDC(multiple pipeline data cache)，如算法1 所示。

算法1MPDC 算法

輸入用戶自定義閾值Tthreshold；單次調(diào)整延遲閾值Lthreshold；

輸出多個(gè)子管道m(xù)。

1)nprediction= 模型預(yù)測需要調(diào)整配置的次數(shù)；

2)nmax=Tthreshold/Lthreshold；

3) if(nprediction>nmax)

4)ndiff= 統(tǒng)計(jì)不同的參數(shù)配置個(gè)數(shù)；

5) if(ndiff

6)m=ndiff；

7) else

8)m=nmax；

9) 選取并行度最高的nmax個(gè)配置；

10) 隨機(jī)向m個(gè)子管道分發(fā)并行度低的ndiff?nmax個(gè)子數(shù)據(jù)流；

11) end if

12) end if

算法1 首先以用戶定義的延遲閾值作為微批量傳輸?shù)拇翱诖笮。诖翱趦?nèi)使用增量學(xué)習(xí)模型預(yù)測出需要調(diào)整參數(shù)配置的次數(shù)nprediction(行1)，根據(jù)用戶定義的延遲閾值和單次調(diào)整拓?fù)浣Y(jié)構(gòu)的最大閾值，我們可計(jì)算出數(shù)據(jù)傳輸子管道的最大值nmax(行2)。在調(diào)整次數(shù)nprediction大于子管道最大值nmax的情況下，需要統(tǒng)計(jì)出nprediction個(gè)調(diào)整次數(shù)中不同的參數(shù)配置個(gè)數(shù)ndiff(行4)。如果參數(shù)配置個(gè)數(shù)ndiff小于子管道最大值nmax，則根據(jù)不同的配置參數(shù)，將數(shù)據(jù)流劃分至ndiff個(gè)子數(shù)據(jù)流進(jìn)行處理(行5～6)。如果參數(shù)配置個(gè)數(shù)ndiff大于子管道最大值nmax，則首選選取并行度最高的nmax個(gè)配置參數(shù)，并將余下的ndiff?nmax個(gè)子數(shù)據(jù)流隨機(jī)向nmax個(gè)子管道中發(fā)送并進(jìn)行處理(行7～10)。此時(shí)，按照并行度高的參數(shù)配置策略，在消耗部分過多系統(tǒng)資源的情況下，可滿足用戶定義的延遲閾值。

2.3.2 精準(zhǔn)查詢處理

由于我們使用子管道的數(shù)據(jù)處理方式，數(shù)據(jù)流通過MPDC 算法后，各個(gè)子管道內(nèi)的數(shù)據(jù)流并非按照時(shí)間順序排序。因此，我們需要完成原始數(shù)據(jù)流的精準(zhǔn)查詢處理。如圖2 所示，我們在流處理系統(tǒng)之上構(gòu)筑基于元組時(shí)間戳的映射函數(shù)，將不同子管道數(shù)據(jù)流的處理過程通過哈希映射后，確保輸出精準(zhǔn)的查詢結(jié)果。

圖2 映射過程Fig.2 Mapping process

2.3.3 增量學(xué)習(xí)模型

利用預(yù)測精度最高的4 個(gè)模型(貝葉斯模型[24]、Hoeffding 樹模型[25]、在線裝袋模型[26]和最近鄰模型[27])，文獻(xiàn)[7] 給出了集成學(xué)習(xí)方法EDKRegression。但是，在增量學(xué)習(xí)過程中，由于訓(xùn)練數(shù)據(jù)的動(dòng)態(tài)變化和分布的不均衡性，導(dǎo)致個(gè)別模型的預(yù)測精度和實(shí)際值偏差較大。為此，本文在EDKRegression 算法的基礎(chǔ)上，提出了異常檢測回歸模型ODRegression (如算法2 所示)。

算法2ODRegression 算法

輸入4 個(gè)學(xué)習(xí)模型對樣本n的預(yù)測值P1、

P2、P3、P4；

輸出樣本n的預(yù)測值

1)E= 模型預(yù)測值的均值；

2)δ= 模型預(yù)測值的方差；

3) for (i=1;i=

4) if(|Pi-E|>δ)

5) 移除第i個(gè)預(yù)測模型；

6) end if

7) end for

8) 調(diào)用EDKRegression[5]算法計(jì)算預(yù)測值；

首先，根據(jù)4 個(gè)預(yù)測模型對樣本n的預(yù)測值P1、P2、P3、P4，算法計(jì)算出預(yù)測值的均值E和方差δ(行1～2)。然后，如果模型預(yù)測值Pi與均值E相差的絕對值大于方差δ時(shí)，利用行4 的公式移除偏移較大的預(yù)測模型。最后，針對過濾后的預(yù)測模型，調(diào)用集成回歸模型EDKRegression 算法，計(jì)算出樣本n的最終回歸預(yù)測值。通過回歸模型的異常檢測，可進(jìn)一步提高集成學(xué)習(xí)模型的預(yù)測精度。

3 實(shí)驗(yàn)與結(jié)果分析

3.1 實(shí)驗(yàn)準(zhǔn)備

1) 實(shí)驗(yàn)環(huán)境。本文實(shí)驗(yàn)平臺(tái)用1 GB 網(wǎng)絡(luò)連通14 個(gè)物理節(jié)點(diǎn)，其中5 個(gè)是使用Kafka 的數(shù)據(jù)發(fā)送節(jié)點(diǎn)，1 個(gè)是Storm 的nimbus 節(jié)點(diǎn)，其余8 個(gè)是Storm 的supervisor 節(jié)點(diǎn)。數(shù)據(jù)發(fā)送與nimbus各節(jié)點(diǎn)配置如下：CPU 為Intel E5-2620 2.00 GHz，Memory 為4 GB。supervisor 各節(jié)點(diǎn)配置如下：CPU 為兩顆Intel E5-2620 2.00 GHz，Memory 為64 GB；操作系統(tǒng)為Ubuntu-14.04.3；Storm 版本0.9.5。

2) 查詢?nèi)蝿?wù)。我們依據(jù)不同的查詢特征，分別選取了3 個(gè)查詢?nèi)蝿?wù)。

① 交通監(jiān)控(traffic monitoring，TM)。此查詢?nèi)蝿?wù)的細(xì)節(jié)請參見第1 節(jié)相關(guān)內(nèi)容。

② 單詞計(jì)數(shù)(word count，WC)。統(tǒng)計(jì)不同語句中各個(gè)單詞的出現(xiàn)頻率。該查詢?nèi)蝿?wù)包含一個(gè)將句子切分成單詞的處理邏輯，和一個(gè)使用哈希映射來統(tǒng)計(jì)單詞出現(xiàn)頻率的處理邏輯。我們使用HiBench[28]提供的單詞計(jì)數(shù)數(shù)據(jù)集，共涉及300 萬個(gè)句子和超過3 000 萬個(gè)單詞。

③ TPC-H(Q3)。TPC-H[29]是一個(gè)決策支持基準(zhǔn)，其包含的查詢和數(shù)據(jù)具有廣泛的行業(yè)相關(guān)性。為驗(yàn)證多個(gè)數(shù)據(jù)流的查詢處理過程，選擇Q3 作為第3 個(gè)查詢?nèi)蝿?wù)。Q3 共包括3 個(gè)過濾數(shù)據(jù)源的處理邏輯，兩個(gè)做等值連接的處理邏輯，一個(gè)對連接結(jié)果做分組的處理邏輯，以及一個(gè)對分組結(jié)果進(jìn)行排序的處理邏輯。在查詢?nèi)蝿?wù)的執(zhí)行過程中，對每個(gè)數(shù)據(jù)源各取1 500 萬個(gè)元組。

3) 數(shù)據(jù)規(guī)模。為保證模型預(yù)測的準(zhǔn)確性，針對每個(gè)訓(xùn)練樣本，計(jì)算窗口時(shí)間內(nèi)CPU 使用率、內(nèi)存使用率、處理延遲和吞吐率的平均值。對于每個(gè)查詢?nèi)蝿?wù)，通過隨機(jī)設(shè)置數(shù)據(jù)速率和30～120 s內(nèi)的動(dòng)態(tài)窗口大小，分別采集3 000 個(gè)訓(xùn)練樣本。

3.2 延遲與吞吐率

通過利用微批次的處理方式，OrientStream+應(yīng)對易變數(shù)據(jù)流的效果顯著，處理數(shù)據(jù)的延遲和吞吐率情況均優(yōu)于Storm 和OrientStream。

這里使用3 個(gè)不同類型的查詢?nèi)蝿?wù)，對比了OrientStream+和OrientStream 的延遲與吞吐率。如圖3 所示，隨著數(shù)據(jù)流速的頻繁變化，由于頻繁調(diào)整系統(tǒng)的參數(shù)配置，OrientStream 的查詢延遲不斷增加，超過了用戶自定義閾值。OrientStream+利用多管道數(shù)據(jù)緩存的策略確保了查詢?nèi)蝿?wù)的延遲低于用戶自定義閾值。同時(shí)，如圖4 所示，OrientStream+的系統(tǒng)吞吐率在滿足用戶定義閾值的前提下，均高于OrientStream 的系統(tǒng)吞吐率。

3.3 在線資源預(yù)測

關(guān)于資源使用的回歸模型預(yù)測，我們使用EDKRegression[7]和ODRegression 兩個(gè)模型。針對不同的查詢?nèi)蝿?wù)，表1 和表2 分別給出了使用不同模型的測試結(jié)果，包括平均絕對誤差值(mean absolute error, MAE)和相對絕對誤差值(relative absolute error, RAE)。

圖3 不同查詢?nèi)蝿?wù)的延遲Fig.3 The latency of different workloads

圖4 不同查詢?nèi)蝿?wù)的吞吐率Fig.4 The throughput of different workloads

表1 預(yù)測CPU 使用情況的MAE 和RAE 值Table 1 Mean and relative absolute error per method for CPU usage prediction

表2 預(yù)測內(nèi)存使用情況的MAE 和RAE 值Table 2 Mean and relative absolute error per method for memory usage prediction

根據(jù)該實(shí)驗(yàn)結(jié)果，可以得出如下結(jié)論：

1)預(yù)測內(nèi)存使用情況的相對絕對誤差(RAE)的平均值比預(yù)測CPU 使用率的略低，這是因?yàn)閮?nèi)存使用率的波動(dòng)幅度沒有CPU 使用率的波動(dòng)幅度大。

2)在不同查詢?nèi)蝿?wù)下預(yù)測CPU 的使用情況，ODRegression 模型優(yōu)于EDKRegression，其中，平均絕對誤差值(MAE)可降低0.3～0.37，相對絕對誤差值(RAE)可降低4.4%～5.8%。在預(yù)測內(nèi)存使用情況方面，ODRegression 模型也優(yōu)于EDKRegression，其中，平均絕對誤差值(MAE) 可降低0.2 9 ～0.3 3，相對絕對誤差值(R A E) 可降低2.5%～5.6%。

3.4 動(dòng)態(tài)資源配置

根據(jù)增量學(xué)習(xí)模型的預(yù)測結(jié)果和在線參數(shù)配置策略，我們監(jiān)控了3 個(gè)查詢?nèi)蝿?wù)的整體執(zhí)行過程。如圖5 和圖6 所示，相對于固定參數(shù)配置的查詢過程而言，ORDegression 算法分別可節(jié)省10%～16%的CPU 使用率和32%～45%的內(nèi)存使用率。相對于使用EDKRegression 算法的參數(shù)配置策略而言，ORDegression 算法分別可節(jié)省1.6%～4.3%的CPU 使用率和4.5%～8%的內(nèi)存使用率。

圖5 CPU 使用率Fig.5 The usage of CPU

圖6 內(nèi)存使用率Fig.6 The usage of memory

4 結(jié)束語

為應(yīng)對易變數(shù)據(jù)流的查詢請求，頻繁改變資源配置會(huì)導(dǎo)致系統(tǒng)處理的延遲增加，降低系統(tǒng)性能。針對此問題，本文提出了OrientStream+框架。根據(jù)用戶自定義數(shù)據(jù)處理的延遲閾值，設(shè)定以閾值為間隔片段的微批量樣式的數(shù)據(jù)流傳輸機(jī)制；并利用多級(jí)別管道緩存，對相同配置的數(shù)據(jù)流進(jìn)行批量處理，再按照數(shù)據(jù)流的時(shí)間戳，獲取精準(zhǔn)查詢結(jié)果；根據(jù)訓(xùn)練數(shù)據(jù)的持續(xù)增長和動(dòng)態(tài)變化的特性，引入具有異常檢測功能的增量學(xué)習(xí)模型，用于進(jìn)一步提高OrientStream+的預(yù)測精度。最后，我們在Storm 上實(shí)現(xiàn)了上述資源配置框架，并進(jìn)行了大量的實(shí)驗(yàn)。實(shí)驗(yàn)結(jié)果表明，本文所提出的OrientStream+框架可在顯著降低系統(tǒng)資源使用的情況下，進(jìn)一步降低系統(tǒng)的處理延遲并提高系統(tǒng)的吞吐率。

針對窗口內(nèi)的易變數(shù)據(jù)流，文本利用多級(jí)緩存和增量學(xué)習(xí)的方法以獲取較優(yōu)解。接下來，根據(jù)速率無重復(fù)波動(dòng)的頻繁變化問題，我們需要設(shè)計(jì)更加高效的數(shù)據(jù)緩存策略,使系統(tǒng)更加穩(wěn)定和健壯。