Abstract
在數據流管理系統（DSMS）中，用戶註冊連續查詢，並在數據到達和到期時接收結果更新。 我們專注於具有實時約束的應用程序，其中用戶必須在更新發生後的給定時間段內接收每個結果更新。 爲了處理快速數據，DSMS通常位於雲基礎架構之上。 由於實時流速到達等流屬性可能無法預測地波動，因此必須動態配置和調度雲資源以確保實時響應。 對於現有系統或未來發展而言，必須具備根據當前工作負載動態調度資源的能力，以避免浪費資源，或者無法按時提供正確的結果。
受此啓發，我們提出了一種新穎的動態資源DRS基於雲的DSMS的調度程序。DRS克服了三個基礎心理挑戰：（a）如何建模之間的關係配置資源和查詢響應時間（b）在哪裏最好地放置資源; （c）如何測量系統負荷最小的開銷。特別是，DRS包括準確的基於Jackson開放排隊理論的績效模型網絡，能夠處理任意operator拓撲，可能有循環，拆分和連接。廣泛的實驗實際數據證實DRS能夠近距離實現實時響應最佳的資源消耗。
1. Introduction
在許多應用中，例如微博，視頻輸入和傳感器讀數的分析，數據記錄不是預先可用的，而是以流的形式逐漸地和連續地到達。 數據流管理系統（DSMS）處理此類流，並向用戶回答長時間連續的查詢。 這種查詢的結果以更新流的形式提供。 通常，用戶對實時執行流分析感興趣，這意味着每個結果更新必須在更新發生之後的給定時間段內到達用戶，即，可以產生它的最早可能時間。 例如，考慮DSMS監控醫院病房中的監控視頻流。 應及時發現患者跌倒等事件，及時向醫生和護士報警。
爲了處理快速，高容量的流和嚴格的實時響應要求，將DSMS放在雲基礎架構之上越來越普遍，雲基礎架構可根據需要提供幾乎無限的計算資源。 由於數據流的關鍵屬性（包括其數量，到達率，價值分佈等）可能以不可預測的方式波動，因此DSMS應理想地爲每個應用程序動態配置雲資源，以滿足實時約束。 最低資源消耗。 同時，在應用程序內部，需要將資源精心安排到不同的組件以確保最佳利用率。 錯放資源可能不僅導致資源利用率低，而且整個系統也不穩定。
圖1示出了具有兩個運算符A（其從輸入視頻幀中提取特徵）和B（其從提取的特徵中識別對象）的示例視頻流處理應用，其中A的輸出被饋送到B作爲輸入。 A和B的記錄到達率分別爲λA和λB，其中λA取決於輸入，例如，每秒24幀，而λB取決於A的輸出速率，即，提取的特徵的數量。單位時間。在每個運算符內部，首先將輸入緩衝到輸入隊列（即A中的q A和B中的q B），然後由其中一個並行處理器（A 1，...，A，A，B 1）處理，...，B）B）。假設雲提供相同的處理單元，A中的每個處理器（分別在B中）可以在單位時間內處理μA（μB）輸入。顯然，Operator必須擁有足夠的處理器來跟上其輸入速率;否則，輸入開始填充其輸入隊列，導致等待時延遲增加，最終導致隊列達到其大小限制時出現錯誤。由於每個處理器的數據到達率和處理速率是不可控制的，因此主要資源調度問題是確定每個運算符中的處理器數量，在我們的示例中爲n和m。
調度資源的一種簡單方法是監視每個Operator的工作負載，並相應地調整處理器數量。這種方法在多Operator應用中是不夠的。例如，考慮在某些時候，許多可識別的對象出現在視頻流中的情況。然後，儘管輸入中每秒的幀數（即λA）保持穩定，但每幀現在包含更多可提取的特徵，需要在運算符A處進行更多的工作。因此，μA減小，從而使運算符A超載，從而導致輸入在隊列中等待更長時間q A，減慢查詢響應速度。現在，如果我們天真地將處理器添加到A以沖洗q A，則Operator A然後突然產生大量輸出，導致運算符B的輸入速率λB突然，使後者過載。當應用程序涉及複雜的運營商網絡時，這個問題會更加嚴重。圖2顯示了這樣一個例子，其中包括分裂（A到B，C），連接（C，D到E）和反饋環（E到A）。這些Topology特徵是某些應用程序的關鍵特徵，例如，循環允許基於當前查詢結果在輸入處減少數據，如我們在第V節中的示例所示。
正如我們在第II節中所述，現有系統在很大程度上忽略了動態資源調度的問題。 因此，爲了滿足實時約束，它們要麼需要在運行時手動調整（這對於動態流是不可行的），過度配置每個操作員的資源（浪費資源），要麼減載（導致不正確的結果）。 受此啓發，我們設計並實現了DRS，一種動態資源調度模塊。 DRS通常適用於基於Operator的DSMS，並允許Operator形成任意拓撲，可能具有分裂，連接和循環，如圖2所示。特別是，對循環的支持可以是某些應用的關鍵推動因素，尤其是那些涉及迭代，正如我們在第五節中的示例所示。同時，從語義的角度來看，允許任意拓撲比Muppet [1]中的兩步MapUpdate和TimeStream [2]中的DAG模型更通用。
我們的主要貢獻包括有效和高效地解決動態資源調度中的三個基本問題：（a）需要多少資源，（b）最佳放置分配資源以最小化響應時間，以及（c）如何實施資源調度 在實際系統中，開銷最小。 特別是，我們對前兩個問題的解決方案基於擴展的Jackson網絡理論，該網絡提供了對系統性能的有根據的估計。
本文的其餘部分安排如下。 第二節調查相關工作。 第三節介紹了我們的性能模型和優化算法。 第IV節描述了DRS的實現。 第五部分包含一系列實際數據的實驗。 第六節總結了未來工作的方向。
2. RELATED WORK
請注意，Dhalion產生的診斷可能是錯誤的，因此執行的錯誤操作最終不會解決問題。例如，Dhalion可能會認爲背壓是由於分配給某個階段任務的資源有限造成的，而實際上是由於任務緩慢造成的。例如，當任務沒有比同行慢得多時，就會發生這種情況，因此Dhalion沒有將其歸類爲異常值。在這種情況下，系統將錯誤地擴展拓撲資源。因此，在執行每個操作後，Dhalion會評估操作是否能夠解決問題或使系統進入更健康的狀態。如果一個動作沒有產生預期的結果，那麼它被列入黑名單並且不會再次重複。這種機制非常強大，因爲它允許系統避免重複錯誤的動作。在沒有黑名單機制的情況下，系統可能會陷入不健康的境地，並陷入反覆調用無效（甚至可能適得其反）行動的陷阱。
A. Resource Scheduling in Cloud Systems
雲由大量互連的商用服務器組成。 雲的一個關鍵特性是可以根據需要爲應用程序配置其CPU核心，內存，磁盤空間和網絡帶寬等資源。 事實上，如今大多數雲基礎設施提供商都提供資源使用的即用即付選項。 因此，系統有效使用雲的基本要求是彈性，這意味着系統必須能夠根據當前工作負載動態分配和釋放雲資源。 然而，許多傳統的並行和分佈式系統預先假定可用的固定資源量，使得它們不適合在雲平臺中應用。 因此，在過去十年中出現了許多新穎的基於彈性雲的範例和系統。
第一波基於雲的系統是爲離線運行一批（通常很慢）的作業而構建的。 值得注意的是，MapReduce [3]是一個批處理框架，它隱藏了雲基礎架構的複雜性，併爲用戶提供了一個簡單的編程接口，包括兩個功能：map（例如，用於數據過濾和轉換）和reduce（用於聚合和連接））。 近年來已經提出了大量的MapReduce系統，改進，技術和優化，我們將讀者引用到全面的調查[4]。
資源調度一直是Map-Reduce系統中的核心問題，並且已經開發並在生產中使用了大量的調度程序，例如Fair Scheduler [5]，Capacity Schedular [6]。 由於在沒有相關數據的節點上運行的任務會導致代價高昂的網絡傳輸，因此延遲調度[7]通過強制節點等待直到本地任務出現或者指定的時間段已經過去來減少這種非本地任務。 但是，這些調度策略不適用於我們的問題，因爲它們設計用於（半）靜態數據的離線批處理，其目標是最小化總作業完成時間; 相反，我們專注於流數據的實時處理，其中每個單獨的結果更新必須按時交付。
最近，很多注意力轉移到大數據分析的實時交互系統，如Dremel [8]，Impala，Presto [9]，OceanRT [10]，[11]，C-Cube [12]，SADA [ 13]和更新版本的Hive [14]。 這樣的系統處理靜態數據而不是流數據; 同時，這裏的術語“實時”具有不同的含義：每個查詢都足夠快地執行，以便用戶可以在線等待其結果。 因此，這些系統中的資源調度類似於離線系統，並且由於類似的原因，它們的技術不適用於我們的問題。 基於雲的系統研究中最近的另一個熱門話題是基於雲的流處理，這與此工作最相關。 我們在第II-C節中對它們進行了審查。
最後，存在用於供應競爭雲資源的多個應用的通用調度解決方案。 諸如Mesos [15]，YARN [16]等系統就是一個突出的例子。 Abacus [17]通過揭露真相的拍賣來分配資源，從而優化了總效用。 這些方法通常假設應用程序已經知道它需要的資源量，以及如何在內部分配這些資源，這是本文解決的問題。 因此，它們可以與提出的解決方案結合使用。
B. Traditional DSMSs(數據流管理系統)
流處理一直是學術界和工業界的重要研究課題。 早期的工作主要集中在集中設置中的DSMS，類似於傳統的集中式數據庫管理系統。 例如，STREAM [18]爲流上的查詢建立了形式語義[19]，並提出了有效的查詢處理算法，例如[20]。 類似的系統包括Aurora [21]，Gigascope [22]，TelegraphCQ [23]和System S [24]。 在這種集中式系統中進行調度意味着決定操作員執行的最佳順序（通過中央處理器），例如，以便最小化存儲器消耗[25]。 因此，[25]這些系統中的調度策略不適用於我們的基於雲的設置，其中運營商由多個節點並行執行，並且計算資源是按需動態配置的。
同樣，爲傳統並行設置而構建的DSMS，特別是Borealis [26]，也與基於雲的DSMS不同，前者假設預先提供固定數量的計算資源，而不是動態分配。 因此，據我們所知，沿着這一研究線的調度技術並不適用於我們的問題。 接下來，我們將回顧基於雲的DSMS。
C. Cloud-Based Stream Processing
在雲中處理流有兩種通用方法：使用基於Operator的DSMS，並將流輸入離散化爲小批量[27]。 前者源自第II-B節中描述的傳統DSMS，而後者則將流處理減少爲批量執行，如第II-A節所述。 通常，小批次流處理系統針對吞吐量進行了優化，代價是增加了查詢響應時間，因爲每個輸入必須等到形成完整批次。 儘管通過極小的批次可以最大限度地減少這種額外的延遲，但這樣做會導致高開銷，從而無法實現目的。 我們專注於基於Operator的DSMS，因爲我們的目標應用程序具有實時約束，其中響應時間是關鍵。
兩個流行的基於開源操作符的DSMS是Storm [28]和S4 [29]。 它們的主要區別在於Storm保證其結果的正確性（例如，通過其Trident組件），而S4則不然。 兩個系統都依賴於手動配置來進行資源調度。 因此，爲了避免由於Operator負載過高導致的慢響應，用戶必須向每個Operator過度提供資源，這是浪費的，或者不斷地調整系統，這對於動態流是不可行的。
提出了許多基於Operator的DSMS的研究原型，例如具有高效故障恢復功能的TimeStream [2]和Samza [30]。 但是，這些系統都沒有解決資源調度問題。 在下文中，我們介紹了DRS，這是基於雲的Operator DSMS的第一個有效資源調度程序。
3. DYNAMIC RESOURCE SCHEDULING
第III-A節闡明瞭DRS中的假設。 第III-B節給出了DRS性能模型，該模型在給定資源分配方案的情況下估計查詢響應時間。 第III-C節描述了DRS動態資源調度算法。 表I總結了本文中經常使用的符號。
A. Assumptions
我們專注於流分析應用程序，這些應用程序通常基於內存和計算密集型。對於此類應用程序，處理器是主要的資源類型，每個資源都包含一個CPU（或其中一個內核）和一定數量的RAM。磁盤空間並不重要，因爲流輸入是實時計算的。雖然網絡延遲也會影響查詢延遲，但我們沒有明確地對其進行建模，因爲（a）它通常與計算成本相關，並且（b）它可能受到不可控因素的影響，例如同一服務器上的其他傳輸繁重的應用程序或者在同一個子網中。此外，如今的數據中心越來越多地配備下一代網絡硬件，提供更高的帶寬和更低的延遲，例如10G以太網和InfiniBand，其價格一直在快速下降。相比之下，CPU時鐘速率和RAM延遲方面的處理器速度在過去幾年中停滯不前。因此，我們假設處理器是系統的瓶頸，而不是網絡帶寬。
爲了便於呈現，我們進一步假設雲中的所有處理器具有相同的計算能力。 儘管如此，所提出的模型和算法也可以支持異構處理器的設置，並且我們將在必要時解釋如何執行此操作。 同時，我們假設在每個操作員中實現負載平衡，即，同一操作員內的每個處理器執行大致相等的工作量。 如何實現負載均衡是一個正交的主題，並且正在積極研究中，例如，[31]。在這些假設下，Operator的處理速度主要取決於其中的處理器數量。
DRS的目標是實時完全處理應用程序的每個輸入。 具體地，應用程序的輸入元組（例如，圖1中的視頻幀）可以導致多箇中間結果，例如，由運算符A提取的特徵，以及由運算符B識別的對象。我們說輸入元組t被完全處理， 當且僅當從t導出的每個中間結果已由其相應的運算符處理。 我們使用術語總的逗留時間來指代從第一次到達系統的時間到完全處理t的時間。 我們的目標是確保每個輸入t的預期總停留時間不超過用戶指定的持續時間，用T max表示。
B. Performance Model
給定應用程序的Operator網絡，例如圖2中的那個，當前資源分配和流數據的特徵，DRS性能模型估計應用程序的平均輸入的總停留時間，在最後一小節的末尾解釋。 當前資源分配由分配給每個Operator的處理器數量表示。 形式上，我們將N定義爲應用程序中的Operator數量，資源分配由向量k =（k 1，k 2，...，k N）建模，其中ki（1≤i≤N）對應於分配給第i個Operator的處理器數量。
關於數據特徵，重要的變量是元組到達每個Operator的速率，以及一個處理器可以處理它們的速度。網絡延遲沒有在我們的模型中明確表達，我們將在本小節的最後進一步討論這個問題。請注意，我們的模型既不確定元組到達率也不假定處理時間;換句話說，瞬時到達率和處理時間可能會波動。另一方面，爲了使問題易於處理，我們假設系統在DRS執行建模和資源調度的跨度期間保持相對穩定的狀態。這意味着每個Operator的平均元組到達率和處理時間保持穩定，我們通過系統的測量模塊獲得這些量，如第IV節所述。具體來說，對於第i個運算符（1≤i≤N），我們使用λi來表示其輸入的平均到達率，並且μi表示其每個處理器的平均處理率。例如，k i = 3，λi= 10和μi= 3的情況意味着平均來說，10個元組在單位時間內到達第i個運算符，並且其3個處理器中的每一個在單位時間內處理3個元組。對於具有多個輸入流的運算符，即連接運算符，λi是其所有輸入流的總到達率，並且μi是運算符的平均處理率，而不管元組來自哪個輸入流。
此外，我們將λ0定義爲從外部流入應用程序Operator網絡的輸入的平均到達率。 當Operator網絡中有明確的“Source” Operator，其輸入完全來自網絡外部時，λ0就是這些來源的總到達率。 然而，一般情況下，λ0和λi的集合之間可能沒有簡單的關係，1≤i≤N。例如，在圖2中，λ0是來自外部的元組的到達率 系統）給Operator A; 另一方面，A的輸入到達率λA是由Operator E產生的λ0和A的其他輸入流的到達率之和。
我們使用隨機變量T來表示應用程序輸入的總停留時間。我們的目標是估計E [T]，即T的預期值。估計E [T]的基本思想是將系統建模爲開放排隊網絡（OQN）[32]，並將已知結果應用於排隊理論。在OQN中，輸入元組t的總逗留時間是通過總計其總服務時間（即，處理t所花費的總時間和從t導出的中間結果）和總排隊延遲（t及其派生元組的總時間）來計算的。在運營商隊列中等待）。這與我們的設置非常匹配。然而，挑戰在於排隊文獻中有許多OQN模型，選擇合適的模型並非易事。一方面，複雜的排隊網絡模型通常沒有已知的解決方案;在其中，大多數只有數值解（而不是分析解），這使得有效優化變得困難;另一方面，過度簡化的模型可能依賴於強有力的假設，例如確定性元組到達率，這在我們的設置中並不成立。在比較各種選項並通過實驗測試之後，我們選擇基於Erlang的模型之一[33]和Jackson網絡[32]，[34]的組合來構建我們的模型。前者可以對每個Operator進行有效分析，後者有助於彙總這些分析，以估算整個網絡的E [T]。我們的模型有一個分析解決方案，它只涉及輕微的限制，我們將在稍後討論。
我們首先關注單個Operator，比如說i-th。 我們使用T i來表示Operator輸入到達與Operator完成處理之間的時間。 我們將Operator建模爲M / M / ki系統[33]，其中k i是運營商i的處理器數量。 根據Erlang公式[33]，E [T i]的計算公式爲：
直觀地，由於新元組以平均速率λi到達，並且每個處理器以平均速率μi處理元組，當ki≤λi/μi時，處理器無法跟上輸入速率的元組。 因此，Operator隊列中的元組數量隨時間增加，導致無限的排隊延遲。 當ki>λi/μi時，預期元組的處理速度比它們到達的速度快。 然而，由於到達和處理速率的隨機性，當到達率暫時高於處理速率時，隊列可能仍然增長。 顯然，每個元組的預期服務時間是1/μi。 預期的排隊延遲由等式（1）中的複雜項捕獲。 接下來，我們聚合所有E [T i]以獲得整個運營商網絡的E [T]估計值。 根據Jackson網絡[32]，[34]的理論，E [T]由E [T i]的加權平均值計算：
這樣就完成了DRS性能模型。由於我們的模型依賴於Erlang的公式和Jackson開放排隊網絡，因此它繼承了兩個限制。首先，該模型隱含地假設外部元組（來自系統外部）的到達間隔時間和運算符的服務時間都是i.i.d.來自指數分佈後的隨機變量的樣本。其次，Jackson網絡沒有明確地模擬不同Operator之間的流水線。因此，當服務時間或元組到達分佈明顯偏離預期的指數分佈時，或者當流水線操作顯着影響總處理時間時，我們的模型可能給出不準確的E [T]估計。同時，我們的模型沒有明確考慮網絡成本，因爲測量兩個節點之間的網絡延遲需要複雜的節點間協議，例如，用於時鐘同步，這在實時應用中可能過於昂貴。因此，當網絡延遲成爲平均輸入的總逗留時間的主導因素時，我們的模型往往會低估真實結果。然而，正如我們在實驗中所表明的那樣，當底層應用是計算密集型時，我們模型預測的E [T]值足夠準確，這是第III-A節中的一個重要假設。此外，即使預測不準確，它仍然與E [T]的確切值強烈相關，這意味着DRS仍然能夠識別具有預測值的最佳資源分配。在本節的其餘部分，我們將展示DRS如何根據性能模型調度資源。
C. Scheduling Algorithm
簡而言之，DRS（a）監控系統的當前性能（第IV節中的更多細節），（b）檢查性能是否在實時約束下降（或即將下降），或者系統何時可以 用更少的資源來滿足約束，並且（c）在（b）返回肯定結果時重新安排資源。 主要挑戰在於（b），它需要回答兩個問題，包括滿足實時要求需要多少處理器，以及將它們放置在Operator網絡中的哪個位置。 我們首先關注後一個問題。 具體而言，給定一個（例如，K max）處理器，我們將找到這些處理器的最佳分配給應用程序的Operator，該Operator獲得最小的預期總停留時間。 問題可以在數學上形式化如下：
上述優化問題的一個簡單解決方案是將其視爲整數程序，並應用標準求解器。 然而，當前的整數編程求解器非常低，特別是考慮到DRS本身必須實時運行。 在下文中，我們描述了一種新算法，該算法以可忽略的成本解決了程序（4）。
在所提出的算法中使用的關鍵屬性是在等式（1）中定義的E [T i]（k i）是k i的凸函數，k i是分配給第i個Operator的處理器的數量。 該屬性已在[32]中得到證實。 由此得出E [T i]（k i）的凸性意味着當k i變大時，遞增k i的邊際效益單調下降。我們有：
現在從等式（3）觀察到E [T]是E [T i]的加權和，並且每個權重λi獨立於k i的值。 因此，E [T]也是k i s的凸函數，意味着遞增每個ki也相對於E [T]具有遞減的邊際收益。 基於這一觀察，我們設計了算法1中列出的貪婪算法。想法是從每個ki的最小可能值（第1-4行）開始，並迭代地向操作員添加一個處理器，導致最大的減少。 E [T]（第8-15行）。 根據等式（1），每個k i必須大於λi/μi，否則，E [T i]（k i）變得無限大，導致E [T]上的無窮大。
由於E [T]是凸的，上面的貪心算法總能找到最優解，類似於服務器重新分配問題[35]。 重述如下：
定理1：算法1總是向程序4返回精確的最優解。
證據在[36]中給出。
接下來，我們關注如何確定預期實現實時處理的最小處理器數量的問題，即預期的總停留時間E [T]不大於用戶定義的閾值T max。 這可以使用以下優化問題建模。
與程序（4）類似，程序（6）的約束和目標在k方面都是凸的。 因此，我們使用類似於算法1的貪婪策略來解決程序（6）。具體來說，我們首先以最小的要求初始化每個ki，如算法1的第1-4行。算法重複地向操作員添加一個處理器。 最大邊際收益，如算法1的第8-15行，直到E [T]不大於T max。 我們省略了該算法的正確性證明，因爲它幾乎與算法1的算法完全相同。
實際上，由於兩個原因，程序（6）的解決方案可能無法始終爲我們提供滿足實時要求所需的精確數量的資源。 首先，每個輸入的總逗留時間可以不同，E [T]僅僅是其預期值。 其次，第III-B節中描述的性能模型僅輸出E [T]的估計值，而不是其精確值。 爲了解決這個問題，DRS從程序（6）的解決方案建議的處理器數量開始，監視實際的總逗留時間E [T]，並根據E [T]的測量值連續調整處理器的數量。 在下一節中，我們將討論DRS的系統設計和實現問題。
4. SYSTEM DESGIN
圖3中給出了系統架構的概述，其通常由兩層組成，即DRS層和CSP（基於雲的流處理）層。 具體地，DRS層負責性能測量，資源調度和資源分配控制，而CSP層包含原始流處理邏輯，例如， 運行Storm [28]和S4 [29]的實例，以及基於雲的資源池服務，例如 YARN [16]和亞馬遜EC2。
雖然DRS層的核心負責基於前一節中導出的模型優化資源調度，但支持此類功能的系統並不是那麼容易構建的。 鑑於異構的底層基礎架構和在CSP層上運行的複雜流處理應用程序，從基礎架構收集準確的指標，彙總統計數據，做出在線決策以及以有效的方式控制資源分配至關重要。
爲了無縫地結合優化模型和具體的流處理系統，我們構建了許多獨立的功能模塊，這些模塊彌合了物理基礎設施和抽象性能模型之間的差距。 如圖3所示，在優化器組件的輸入端，我們有測量器模塊和配置讀取器模塊，它們根據來自CSP層的數據/控制流生成優化器所需的統計數據。 在工作流程圖的輸出端，調度程序模塊和資源協商程序模塊將優化程序的決策轉換爲可執行命令，以用於不同的流處理平臺和資源池。 這些模塊的技術細節和主要特徵在[36]中討論。
5. EMPIRICAL STUDIES
爲了測試DRS的有效性，我們實現了它並將其集成到Storm [28]中，後者提供了底層的CSP層。 在[36]中提供了Storm的重要概念和架構方面的概述，以及我們如何在Storm中實現DRS的Measurement，Scheduler和Resource negotiator模塊的描述。
A. Testing Applications
我們實施了兩個實時流分析應用程序：視頻徽標檢測（VLD）和來自不同域的頻繁模式檢測（FPD）。
Logo Detection from a Video Stream. 給定一組查詢徽標圖像，徽標檢測應用程序從輸入視頻流中識別這些圖像。 雖然已經做了很多工作來提高VLD的準確性和效率，但由於計算複雜度高，實時執行它仍然是一項重大挑戰。
圖4顯示了實時VLD應用程序的拓撲結構，它是一個包含spout，特徵提取器，功能匹配器和聚合器的運算符鏈。Spout從原始視頻流中提取幀。由於生成算法和原始視頻內容，幀的輸出速率可能隨時間變化。我們採用尺度不變特徵變換（SIFT）[37]算法從每個幀中提取特徵。該步驟耗時，涉及二維圖像空間上的卷積。此外，結果SIFT特徵的數量可能在不同的幀上發生顯着變化，從而導致計算開銷隨時間的顯着變化。特徵匹配器測量其輸入SIFT特徵與那些預先生成的徽標特徵之間的L 2距離，並輸出距離低於預定閾值的匹配對。最後，聚合器通過聚合所有輸入匹配特徵對來判斷徽標是否出現在視頻幀中，即，如果視頻幀中匹配特徵的數量超過閾值，則認爲徽標出現在幀中。
Frequent Pattern Detection over a Microblog Stream. 該應用程序在來自Twitter的微博流上的滑動窗口上維護頻繁模式[38]。 對於每個輸入句子，我們附加一個附加標籤“+/-”，表示它正在進入/離開專用窗口。 給定滑動窗口中的一組輸入項組和閾值，我們將最大頻繁模式（MFP）定義爲滿足以下條件的項集：（a）包含此項集的項組的數量，稱爲其出現次數，高於閾值; 及（b）其任何超集的發生次數低於該閾值。
圖5說明了Operator Topology。 有兩個spout，它們分別在itemset進入/離開當前處理窗口時生成一個事件元組。 模式生成器生成候選模式，即項集。 這些候選者包括指數數量的可能的非空項目組合。 因此，根據最近交易中的項目數量，其計算會有所不同。
檢測器維護狀態記錄，其包含（a）所有候選i temsets的出現次數和（b）MFP指示符。 當某些項目集發生狀態改變時，例如，從MFP到非MFP，檢測器通過回送鏈路向報告者輸出通知，並且還向其自身輸出通知。 由於（a）探測器中的每個處理器僅保留一部分狀態記錄; （b）狀態改變可以影響存儲在不同處理器的其他項目集的狀態，該循環確保將狀態改變通知發送到所有實例。 最後，報告者向用戶呈現檢測結果的更新。 在我們的實現中，報告者只需將其輸入寫入HDFS文件。
B. Experiment Setup
實驗在由LAN交換機互連的6臺Ubuntu Linux機器的集羣上運行。每臺機器都配備了一個3.4GHz的Intel四核CPU和8GB的RAM。遵循Storm的常見配置，我們分配了一臺機器來託管Nimbus和Zookeeper Server;其餘5臺機器爲實驗應用程序提供執行程序。我們還配置了這5臺機器中的每臺機器，這樣一臺機器最多可以容納5臺執行器。此約束的主要目的是減輕由在同一臺計算機上運行的其他執行程序引起的干擾，以及由於在單個計算機上執行程序的過度分配而導致的資源爭用。結果，共有25名遺囑執行人。
對於這兩種應用，即視頻徽標檢測（VLD）和頻繁模式檢測（FPD），我們分配了兩個執行器作爲spouts，一個執行器用於DRS。剩餘的25-3 = 22個執行器用作Bolt，即K max = 22.對於VLD，輸入數據是足球比賽的一系列視頻剪輯，我們選擇16個徽標作爲檢測目標。幀速率模擬典型的互聯網視頻體驗，其在區間[1,25]中均勻分佈，平均爲13幀/秒。對於FPD，我們使用包含來自2006年10月至2009年11月收集的2,168,939個用戶的28,688,584條推文的真實數據集。我們將滑動窗口設置爲50,000條推文，並在泊松過程之後模擬推文到達拓撲的平均到達時間每秒320條推文的速度。
C. Experiment Results
對於這兩個應用程序，我們運行兩組實驗：（a）重新平衡禁用，即我們保持DRS被動運行，這意味着它繼續監視系統性能並推薦新的（如果更好）資源分配配置，但 不執行重新調度; （b）在開始時禁用重新平衡，然後在以後啓用。 這些實驗旨在測試性能模型的質量並評估DRS資源調度算法的有效性。
禁用重新平衡的實驗。 在該組中，每個實驗持續10分鐘。 圖6顯示了每種應用在6種不同分配下的總逗留時間的平均值和標準差。 x軸（x 1：x 2：x 3）表示資源配置（部分順序爲x 1，x 2，x 3），其中x 1，x 2，x 3是分配給的執行程序的數量 圖4中的運算符SIFT特徵提取器，特徵匹配器和匹配聚合器，或圖5中的模式生成器，檢測器和報告器。兩個配置帶有“*”，（10：11：1）用於VLD和（6： 13：3）FPD是被動運行的DRS推薦的分配。
從圖6中，我們進行了以下觀察。 VLD的資源配置（10：11：1）和FPD的（6：13：3），根據測量的平均逗留時間實現最佳性能。 這證明與被動運行的DRS提供的建議一致，這證實了我們的DRS性能模型和資源調度算法的準確性和有效性。
特別是，這兩種配置不僅獲得最小的平均逗留時間，而且獲得最小標準偏差，這意味着這兩種分配導致最小的性能振盪。 不同的配置，包括5個最接近的L 1距離（即實驗中的剩餘5個）到VLD的最佳配置（10：11：1）和FPD的（6：13：3），所有 表現出相當差的表現。 這些結果表明，找到最佳資源分配並不是一件容易的事情，特別是當應用程序拓撲結構變得更復雜時（例如，超過三個Bolt運算符），並因此揭示了DRS的重要性和實用性。
爲了仔細研究DRS如何正確提供資源配置建議，圖7顯示了測量的平均逗留時間與估計的平均逗留時間之間的關係，該時間由第III-B節中描述的性能模型得出。 VLD和FPD的資源分配配置，禁用重新平衡。
如圖7所示，表示測量和估計的平均逗留時間的點顯示嚴格單調性，這表示性能模型能夠建議最佳資源分配配置。 此外，性能模型輸出VLD的準確估計值; 但是，由於我們的模型不考慮網絡開銷，因此與預期的測量值相比有一些輕微的低估。 值得注意的是，即使傑克遜網絡理論和Erlang模型不滿足基本條件，估計也是準確的。 例如，幀速率是均勻的（而不是指數所需的）分佈式。 同時，Operator輸入隊列不遵循嚴格的FIFO規則; 相反，元組被處理器散列。 不同的運算符也並行運行，這導致流水線操作。 該模型對於這些條件的變化顯然是穩健的。
對於FPD，估計的逗留時間顯示出與測量的偏差更大的偏差。 這主要是因爲該模型沒有考慮網絡傳輸成本，這佔該特定應用中總查詢延遲的主要部分。 換句話說，FPD事實上是數據密集型的類型，而不是我們關注的計算密集型應用程序。 然而，我們的模型仍然正確地指示了不同資源分配配置的性能的相對順序。 同時，由於估計值與真實值強烈相關，因此可以直接使用多項式迴歸來精確預測給定估計值的真實等待時間值。
爲了進一步驗證上述解釋，我們使用簡單的三個運算符鏈對合成拓撲進行了單獨的實驗。 每個運算符簡單地執行一些具有變化的負載（例如，循環次數）的計算（例如空的for循環）。 我們使用了在6臺物理機器上運行的30個執行器，它們連接在同一個子網中。 結果報告在圖8中。
如圖8所示，我們在三個Bolt的總CPU時間（不包括排隊時間）方面嘗試了6種不同的工作負載，從0.567毫秒到309.1毫秒（x軸，對數刻度），以及y軸 顯示測量的平均逗留時間與估計值的比率。 隨着三個Bolt的總CPU時間增加，它顯示出低估程度（測量值與估計平均逗留時間的比率）的明顯下降趨勢。
7. CONCLUSIONS
本文提出了DRS，一種用於基於雲的DSMS中的實時流分析的新型動態資源調度器。 DRS克服了幾個基本挑戰，包括估計滿足實時要求所需的必要資源，有效和高效的資源供應和調度，以及在基於雲的DSMS中有效實施這樣的調度程序。 DRS的性能模型基於嚴格的排隊理論，即使理論的基本條件未得到充分滿足，也表現出強大的性能。 此外，我們已將DRS集成到流行的Storm系統中，並通過基於實際應用和數據集的大量實驗對其進行評估。
關於未來的工作，我們計劃研究將系統從當前資源配置遷移到DRS推薦的新策略的有效策略。 此步驟應最大程度地減少遷移期間的額外開銷和結果延遲，以及遷移持續時間（例如，[39]）。 未來工作的另一個有趣方向是研究使用更復雜的排隊理論提高性能模型準確性的可能性。