王春凱，莊福振，史忠植

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

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

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

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

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

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

2) 機器學(xué)習(xí)技術(shù)。文獻[12]提出了一種基于混合密度網(wǎng)絡(luò)[13]的模型來評估數(shù)據(jù)流處理任務(wù)的資源使用情況。該模型可幫助用戶判斷是否向流處理系統(tǒng)提交新的查詢?nèi)蝿?wù)。ALOJA 項目[14]針對Hadoop[15]的執(zhí)行情況開發(fā)了開源平臺用于預(yù)測查詢?nèi)蝿?wù)的執(zhí)行時間和異常監(jiān)控。ALOJA是基于ALOJA-ML[16]設(shè)計的框架，ALOJA-ML 利用機器學(xué)習(xí)技術(shù)分析了運行在Hadoop 上的不同查詢?nèi)蝿?wù)的基準(zhǔn)性能數(shù)據(jù)，并以此支持查詢?nèi)蝿?wù)的性能調(diào)優(yōu)。Jamshidi 等[17]設(shè)計了一種自動優(yōu)化流處理系統(tǒng)參數(shù)配置的貝葉斯優(yōu)化算法BO4-CO。以MySQL 和Postgres 為實驗平臺，Otter-Tune[18]利用經(jīng)驗數(shù)據(jù)的監(jiān)督學(xué)習(xí)方法和新搜集信息的非監(jiān)督學(xué)習(xí)方法，針對不同查詢請求選擇出對系統(tǒng)性能影響最大的參數(shù)，并通過歷史查詢?nèi)蝿?wù)對新的查詢?nèi)蝿?wù)進行預(yù)測，利用深度學(xué)習(xí)框架TensorFlow[19]向用戶推薦最佳參數(shù)配置。然而，文獻[12]不能動態(tài)改變流處理系統(tǒng)的調(diào)度策略和各個算子的并行度，且不可以預(yù)測系統(tǒng)資源的使用情況。ALOJA-ML 框架僅可預(yù)測Hadoop的處理平臺，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è)計了兩種特征抽取的機制用于預(yù)測SQL 查詢的資源消耗情況。兩種特征包括粗粒度的全局特征和細(xì)粒度的算子特征。Akdere 等[21]為預(yù)測不同查詢計劃的查詢性能，構(gòu)建了3 種層次模型：查詢計劃層模型、算子層模型和針對嵌套查詢的混合模型。然而，模型[20-21]僅考慮了靜態(tài)特征的選擇過程，不能對系統(tǒng)進行動態(tài)監(jiān)控，并且沒有考慮位于關(guān)系查詢系統(tǒng)下面的數(shù)據(jù)處理系統(tǒng)的有關(guān)特征。

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

1 基本概念與問題描述

1.1 概念描述

OrientStream+需要實時監(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è)定的時間間隔或窗口內(nèi)元組數(shù)量設(shè)置窗口大小，并在多查詢場景下使用翻轉(zhuǎn)窗口或滑動窗口的語義信息。

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

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

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

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

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

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

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

1.2 問題定義

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

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

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

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

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

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

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

2.1 OrientStream+概述

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

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

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

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

2.3 資源配置策略

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

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

算法1MPDC 算法

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

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

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

2)nmax=Tthreshold/Lthreshold；

3) if(nprediction>nmax)

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

5) if(ndiff

6)m=ndiff；

7) else

8)m=nmax；

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

10) 隨機向m個子管道分發(fā)并行度低的ndiff?nmax個子數(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)的最大閾值，我們可計算出數(shù)據(jù)傳輸子管道的最大值nmax(行2)。在調(diào)整次數(shù)nprediction大于子管道最大值nmax的情況下，需要統(tǒng)計出nprediction個調(diào)整次數(shù)中不同的參數(shù)配置個數(shù)ndiff(行4)。如果參數(shù)配置個數(shù)ndiff小于子管道最大值nmax，則根據(jù)不同的配置參數(shù)，將數(shù)據(jù)流劃分至ndiff個子數(shù)據(jù)流進行處理(行5～6)。如果參數(shù)配置個數(shù)ndiff大于子管道最大值nmax，則首選選取并行度最高的nmax個配置參數(shù)，并將余下的ndiff?nmax個子數(shù)據(jù)流隨機向nmax個子管道中發(fā)送并進行處理(行7～10)。此時，按照并行度高的參數(shù)配置策略，在消耗部分過多系統(tǒng)資源的情況下，可滿足用戶定義的延遲閾值。

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

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

圖2 映射過程Fig.2 Mapping process

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

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

算法2ODRegression 算法

輸入4 個學(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個預(yù)測模型；

6) end if

7) end for

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

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

3 實驗與結(jié)果分析

3.1 實驗準(zhǔn)備

1) 實驗環(huán)境。本文實驗平臺用1 GB 網(wǎng)絡(luò)連通14 個物理節(jié)點，其中5 個是使用Kafka 的數(shù)據(jù)發(fā)送節(jié)點，1 個是Storm 的nimbus 節(jié)點，其余8 個是Storm 的supervisor 節(jié)點。數(shù)據(jù)發(fā)送與nimbus各節(jié)點配置如下：CPU 為Intel E5-2620 2.00 GHz，Memory 為4 GB。supervisor 各節(jié)點配置如下：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 個查詢?nèi)蝿?wù)。

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

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

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

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

3.2 延遲與吞吐率

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

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

3.3 在線資源預(yù)測

關(guān)于資源使用的回歸模型預(yù)測，我們使用EDKRegression[7]和ODRegression 兩個模型。針對不同的查詢?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ù)該實驗結(jié)果，可以得出如下結(jié)論：

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

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 動態(tài)資源配置

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

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