Abstract
流處理工作負載和現代共享集羣環境表現出高度的可變性和不可預測性。 結合大量參數空間和各種用戶SLO，這使得現代流處理系統非常難以靜態配置和調整。 爲了解決這些問題，在本文中，我們研究了一種新穎的控制平面設計Chi，它支持連續監測和反饋，並支持動態重新配置。 Chi利用在數據平面通道中嵌入控制平面消息，爲流處理系統實現低延遲和靈活的控制平面。
Chi引入了新的反應式編程模型和設計機制，以異步執行控制策略，從而避免全局同步。 我們展示瞭如何使我們能夠輕鬆實現針對生產中觀察到的不同用例的各種控制策略。 使用來自雲提供商的生產工作負載的大規模實驗證明了我們方法的靈活性和效率。
1. Introduction
亞馬遜，Facebook，谷歌和微軟等大型互聯網服務提供商每秒產生數千萬個數據事件[5]。 爲了處理如此高的吞吐量，他們傳統上採用離線批處理系統[21,13,4]。 然而，最近，使用流媒體系統[3,10,27,31]以確保及時處理並避免離線批處理系統通常產生的延遲的趨勢越來越明顯。
然而，完全實現這些在線實時系統所承諾的好處尤其具有挑戰性。首先，流處理工作負載表現出較高的時間和空間可變性，與平均負載相比可達到一個數量級[27,31]。其次，大型共享集羣表現出高硬件異構性和不可預測的連接使用率。第三，現代流媒體系統暴露出大的參數空間，即使對於經驗最豐富的工程師來說也很難調整。此外，不同的用戶和作業具有不同的服務級別目標（SLO），導致不同的配置設置。解決這些問題需要將持續的監控和反饋以及動態重新配置引入流系統的各個方面，從查詢規劃和資源分配/調度到參數調整。我們將負責這種控制機制的系統層稱爲控制平面，以將其與數據平面（負責數據處理的層）區分開來。
通過我們與產品團隊和雲運營商的互動，我們確定了控制平面應滿足的以下要求。 首先，應該可以定義新的自定義控制操作，以適應不同的場景[24]。 其次，這應該通過開發人員的最小努力以及通過簡單直觀的API來實現，以最小化錯誤的可能性，這在分佈式環境中檢測尤其具有挑戰性。 最後，即使存在高事件吞吐量和大型計算圖，控制開銷也應保持最小。 在今天的情況下，這一點尤其重要，因爲不同的雲提供商難以爲其客戶提供最好的SLO。 理想情況下，控制平面應與數據平面SLO匹配（通常爲秒或更小）。
不幸的是，據我們所知，現有的流處理系統都不能滿足所有這些要求。 Heron [27]和Flink [10]擁有一個單片控制平面，僅支持一組有限的預定義控制策略（例如，動態縮放和背壓），並且缺少乾淨的API，這使得用戶很難定義自定義策略。 Spark Streaming [41]採用批量同步並行（BSP）模型[38]，其中一組事件被緩衝並作爲批處理。 雖然這允許系統修改批次之間的數據流，但是由於硬批量邊界而導致靈活性有限，並且由於所需的同步和調度操作而導致高開銷。
爲了克服當今系統的缺點並滿足上述要求，我們探索了一種用於流處理系統的新型控制平面設計。 受到用於數據Operator的想法[37]的啓發，我們建議將控制平面消息嵌入到數據流中。 通過利用現有的數據管道，控制消息可以低延遲和可擴展的方式進行流式傳輸，而無需任何特殊的機制（第7.2節）。 然而，這種看似簡單的方法需要底層流式基礎架構的支持，以一致性要求執行分佈式控制操作，同時最小化同步開銷並啓用可擴展控制編程模型。
在本文中，我們描述了Chi，一種基於這種在數據流中嵌入控制消息以執行低延遲控制操作的想法的控制平面。我們引入了一個用於處理控制消息的反應式編程模型，允許用戶編碼許多複雜的控制策略。這隱藏了底層系統的複雜分佈式特性，併爲開發人員提供了一個直觀的模型來理解應用控制事件的數據事件的邊界。然後，我們設計了一種機制，以便在每個操作員以異步方式執行這些控制策略，從而避免同步和複雜運行時開銷。我們通過使用我們的編程模型和執行機制表明，我們可以有效地實施一系列控制策略，從檢查點和重放等基本功能到具有強大全局一致性要求的高級功能，如連續監控，計劃重新優化和參數調整（§5）。最後，我們還討論瞭如何通過在每個操作中使用單獨的控制迴路來輕鬆並行化我們的控制平面基礎架構，從而使控制平面可擴展。
爲了驗證我們的聲明並評估新控制平面設計的運行時性能，我們在Flare之上實現了Chi，Flare是我們集羣中使用的內部流處理系統之一。 Flare建立在Orleans [7]之上，這是一個高效的分佈式actor框架，並使用Trill [16]作爲底層流處理引擎。雖然我們選擇在Flare之上展示我們的方法，以便在我們的內部集羣上輕鬆實現和部署，但我們的設計並不依賴於特定平臺，並且通過一些額外的工程工作，它可以應用於現有實時流處理系統，包括Heron和Flink。我們基於生產工作負載和行業標準基準測試的實驗評估表明，Chi能夠在32個服務器羣集上在5.8秒內對大型有狀態數據流進行重新配置。實際使用案例進一步顯示了Chi在幫助開發人員自動調整關鍵系統參數和減少61％的延遲方面的有效性，從而減少了運行時的工作負載偏差。
總之，本文做出以下貢獻：
•通過從200,000多臺生產服務器收集的日誌對當今的流處理工作負載進行廣泛研究。
•可擴展且高效的控制平面，允許流媒體系統有效地適應工作負載或環境的變化。
•靈活的控制平面API，使開發人員能夠輕鬆實現自定義控制操作。
•使用來自雲服務提供商的生產工作負載以及大量控制操作（包括動態擴展，故障恢復，自動調整和數據傾斜管理）評估我們在32服務器Azure VM羣集上的原型實施。
2. MOTIVATION
我們通過分析現在流行的雲提供商的數據分析集羣的200,000多臺服務器生成的日誌，進行了廣泛的測量研究。 這些集羣生成大量日誌數據（10s PB /天），開發人員執行對此數據的查詢以進行調試，監控等。鑑於數據大小，我們需要具有足夠網絡和計算資源的大型集羣實時處理數據。 我們的設置與最近對Google生產日誌的分析一致[19]。
我們首先總結分析的主要結果，並討論出現的機會。
工作負載不可預測性：服務器提取日誌事件的負載變化很大。 圖1（a）顯示了我們集羣中隨機流子集每分鐘生成的標準化元組數的熱圖。 這顯示了兩個重要的現象。 首先，通過水平線上的不同顏色模式證明，每個流呈現出獨特的工作負荷特徵（空間變異性）。 其次，雖然一些流在大多數時間內是暗的（高容量），但是幾個流表現出突發性（時間變化），如同色水平線的色點所示。
日誌事件中存在這種可變性的主要原因有三個：
- 異構工作負載：生成這些日誌的集羣處理各種工作負載，範圍從典型的大數據作業（例如，過濾，轉換，連接）到代表數百個團隊的迭代機器學習工作負載。
- 故障和調試：故障在大規模中很常見。 這些故障（例如，網絡問題，電源問題等）會產生大量錯誤日誌，從而導致流量突發。 此外，當攝取數據不足時，開發人員會暫時激活更詳細的日誌以執行深入調試，從而產生更高的流量。
- 不同的流語義：我們攝取的日誌具有不同的語義（例如，信息，詳細，調試，錯誤等），服務中的各種組件具有不同的特徵。 最低級別的服務（例如，存儲層）自然地產生最多的日誌，因爲大多數請求涉及商店I / O事務。
爲了量化可變性程度，在圖1（b）中，我們顯示了一個盒子和鬍鬚圖，其中Y軸表示在輸入數據流子集上每分鐘事件計數的增量。 框的高度顯示第25和第75百分位數之間的計數差異。 除了每個流的行爲的顯着差異之外，值得注意的是在相同流中觀察到的高變化範圍，由大量異常值（圖中的藍點）表示。 例如，對於某些事件流，事件計數可在一分鐘內增加高達數千萬，表明及時響應對於保持負載峯值至關重要。
數據多樣性。確定最佳查詢計劃和資源分配的另一個關鍵因素是數據分佈。 爲了分析其動態，我們關注key selectivity，定義爲落入特定存儲桶的元組數。 爲了分析這個參數的動態，在圖1（c）中我們繪製了各種分組key隨時間的選擇性，而在1（d）中我們繪製了多個分組密鑰隨時間的選擇性。 在兩個圖中觀察到的選擇性的寬偏差表明，一次性或基於每個key的一次性查詢計劃（例如，基於傳統基數的優化器）可能隨時間推移是次優的。
多租戶控制策略：在我們的生產環境中，許多團隊使用相同的流處理系統。 因此，來自不同團隊的查詢或甚至來自同一團隊的不同查詢的SLO存在大量差異，導致需要同時激活多個控制策略。 例如，我們有許多客戶有興趣消費詳細，信息和錯誤日誌。 雖然詳細和錯誤日誌用於調試，但信息日誌通常用於計算重要指標（例如，計費指標）。 我們的開發人員提出的一個流行請求是爲信息日誌和較弱的傳遞語義（例如，盡力而爲，至少一次）提供更強的傳遞語義（例如，恰好一次）用於詳細/錯誤日誌。 這突出了在每個流級別或每個租戶級別上支持多個控制策略的重要性。
多租戶還在系統管理和優化方面引入了新的機會。 在我們的生產跟蹤中，我們觀察到在數據源和運算符方面共享重要重疊的查詢（例如，用戶以相同的方式解析日誌）。 因此，控制策略可以考慮跨用戶共享計算或者對中間數據進行物化以供以後重用。 此外，通過對數據流和工作負載的洞察，可以使用控制策略來自動且透明地選擇可以提高執行效率的新數據佈局（例如，利用分區）和存儲引擎（例如，存儲器內，數據庫）。 雖然所有這些優化都被孤立地理解[33,34,40,32]，但以集成方式應用它們來優化流式工作負載需要控制平面的靈活性和可擴展性。
目標：我們的跟蹤分析揭示了我們工作負載的幾個有趣的特徵 - 高容量（10 / PB /天），低延遲要求（SLO秒），廣泛多樣化（100s數據流）和動態（由於 生產這些日誌的服務的性質）。 基於此，我們可以得出以下控制平面要求列表：
- 高效且可擴展的反饋迴路控制：由於我們的工作負載的多樣性，允許用戶或應用程序對其數據處理邏輯做出靈活的後期綁定決策以優化性能非常重要。 從可擴展性的角度來看，應該可以與專用組件集成（例如，Dhalion [24]等策略控制器）。
- 易於控制的界面：由於我們希望應用程序開發人員使用控制平面，因此具有更簡單的編程接口對於其採用至關重要。
- 對數據平面的最小影響：控制平面應該對數據平面的延遲和吞吐量有限或沒有影響，它應該能夠無縫地處理高控制頻率和大數據流圖。
3. BACKGROUND
Chi主要設計用於基於流數據流計算模型的流系統。 在本節中，我們爲讀者提供了有關流數據流計算模型的必要背景知識。許多現有的流處理系統，如Naiad [30]，Stream-Scope [28]和Apache Flink [10]採用流數據流計算模型。 在此模型中，計算作業表示爲有狀態運算符的有向無環圖（DAG），其中每個運算符沿着指定的邊發送和接收邏輯上帶時間戳的事件。 每個Operator都維持可變的本地狀態。 接收到事件後，Operator更新其本地狀態，生成新事件，並將其發送給下游運營商。 沒有Input通道的Operator是Source; 那些沒有Output通道的Operator是Sink。
例如，考慮一個例子，其中用戶有興趣將句子標記爲單詞，並以數據並行方式計算所有句子中每個單詞的加窗口累加計數（例如，每小時）。 此查詢可以用LINQ樣式語言表示，如下所示：
示例1的數據流圖的實例在圖2的階段I中示出。注意，運算符{R1，R2}將字的累積計數保持爲其可變的本地狀態。 這些狀態覆蓋了一組不相交的密鑰，並共同代表整個密鑰子空間，例如，R1保持所有單詞的累計計數，起始字母在['a' - 'l']範圍內，而R2保留了 範圍['m' - 'z']。
數據流計算模型：形式上，數據流計算表示爲DAG G（V，E），其中V表示操作符集，E表示連接運算符的邊集，u→v表示有向邊運算符u到v。我們使用{·→v}來表示v的輸入邊，而{v→·}來自v的輸出邊。一個Operator v∈V由三元組（sv，fv，pv）描述，其中sv是v的狀態; fv定義了一個捕獲在v上運行的計算的函數，即f：sv，mei∈{·→v} - →sV，{M eo∈{v→·}}，意思是函數從輸入邊ei獲取單個輸入消息m，並且基於當前狀態sv，它將v的狀態修改爲新的狀態sv，並在一組out-上生成一條或多條出邊{m eo∈{V→·}}。沒有輸入邊的Operator稱爲Source，沒有輸出邊的Operator稱爲Sink。一般來說，我們將與v不相關的屬性表示爲pv的狀態，例如，pv可以定義v使用的最大內存。邊e不具有任何狀態但可以保持屬性pe，例如，窗口的token大小用於觸發背壓條件。
4. DESGIN
將控制平面嵌入數據平面背後的直覺是，這使得能夠重新使用現有的，高效的數據平面基礎設施，併爲開發人員提供熟悉的API來編寫控制操作，即用於處理數據事件的操作。 此外，讓控制消息直接跟蹤數據事件提供了一種在事件序列之間創建自定義邊界的自然方式。 這使得實現異步控制操作變得容易，因爲控制消息可用於捕獲因果依賴性，而無需昂貴的全局同步操作。
在本節中，我們將展示如何將這些原理融入我們的控制平面設計中，並提供幾個示例來描述我們如何輕鬆地在頂部構建不同的控制操作。 我們通過描述我們設計的一些更高級的功能並討論如何使Chi適應支持BSP風格的計算來結束本節。
4.1 Overview
Chi依賴於以下三個功能。 首先，Operator之間的Channel通道支持exactly-once和FIFO傳送消息。 當下遊Operator的緩衝區填滿時，背壓用於停止消息的發送。 其次，Operator一次一個地處理消息，並按照接收消息的順序處理消息。 最後，底層引擎提供基本的Operator生命週期管理功能。 具體來說，它允許我們啓動，停止和殺死一個Operator。 我們的內部流媒體系統Flare已經支持這些功能，但它們也可以在其他現有系統中找到[10,27,39,41]。
我們的系統設計使用數據流控制器，負責監控數據流行爲和外部環境變化，並在需要時觸發控制操作。 用戶可以定義控制操作，並將其提交給控制器。
通過控制迴路執行控制操作，該控制迴路包括數據流控制器和數據流拓撲本身。通常，控制迴路由三個階段組成:(階段I）控制器做出控制決策並使用唯一標識符實例化控制操作。控制操作通過實現反應式API（第4.2.2節）來定義，並且具有每個Operator的控制配置（例如，用於擴展數據流的新拓撲）。控制操作被序列化爲控制消息（第§6節）。 （階段II）控制消息由控制器擴展到數據流的所有Source操作符。然後，控制消息通過數據流傳播，與正常數據消息交織。在傳播期間，在接收到控制消息時，每個Operator觸發相應的控制動作 - 其可以可選地將附加數據（例如，重新分區狀態）附加到控制消息 - 並將控制消息廣播到所有下游Operator。有關更多實現細節，請參見第4.2.2節和第6節。 （階段III）最後，the sink Operator將控制消息傳播回控制器，並且控制器執行後續處理。
我們使用圖2來說明這個過程。 我們考慮控制器希望通過修改拓撲並添加新的reducer來增加吞吐量的情況。
- 在剛剛開始時，有兩個Map Operator {M1，M2}和兩個Reducer Operator {R1，R2}，它們爲攝取的句子計算單詞計數。 這些Operator是有狀態的。 例如，{R1，R2}保持所有單詞的累計計數，其中R1保持以['a' - 'l']開頭的所有單詞的計數，R2保持['m' - 'z的計數“]。 控制器C負責監視所有Operator的內存使用情況，並在需要時重新配置並行性。 爲了簡化，我們省略了收集內存使用情況的控制消息，並在以下討論中關注並行性重新配置過程。
- 一旦控制器C檢測到Reducer的聚合內存使用率使用超過閾值，它就做出重新配置決定以啓動新的Reducer R3以增加內存的供應。 在新拓撲中，{R1，R2，R3}的狀態應該重新分區，以便R1保持範圍['a' - 'h']的字數，R2代表['i' - 'p']， 和['q' - 'z']的R3。 這種重新配置需要保持狀態的一致性。 首先將帶有新拓撲配置的控制消息廣播到所有源節點（→{M1，M2}）
- 當Source（Mapper M1或M2）接收到該控制消息時，映射器在處理消息時立即阻塞輸入信道，用新拓撲更新其路由表並向下遊廣播消息（→{R1，R2，R3}）。
- 當reducer R1（或R2）收到控制消息時，它會阻止接收消息的輸入通道。 當收到來自所有輸入通道的控制消息時，它會更新其路由表並檢查其狀態。 接下來，它將狀態分爲兩部分：範圍['a' - 'h']的累積字數和範圍['i' - 'l']（或範圍['m' - 'p']和['q' - 'z']）並且處理需要由R3處理的狀態，即['i' - 'l']的字數（或對於['m '-'p']）到控制消息並沿所有輸出通道廣播（→{R3，C}）。
- 當R3收到控制消息時，它會阻止該輸入通道。 如果控制消息源自R1（或R2），它將從控制消息中記錄狀態。 當它接收來自所有輸入通道的控制消息時，它繼續合併所有接收的狀態，生成範圍['i' - 'p']的累計字數的新狀態，並安裝一個新函數（來自 控制消息）使用新狀態。 最後，它在輸出通道上廣播（→C）。
- 當C從所有預期匯聚節點{R1，R2，R3}接收控制消息時，完成橫向擴展操作。 然後，控制器在新拓撲中持續監視這些運營商的內存使用情況，並且可以根據需要決定Scale In/Scale Up。 這形成了反饋迴路控制。
4.2 Control Mechanism
接下來，我們將描述支持Chi的核心機制。 我們首先正式定義數據流計算模型，並解釋圖形轉換是如何發生的。 然後，我們討論控制器和運算符API並提供示例控制操作實現。 我們在§4.2.3中提供了正確性證明。
4.2.1 Graph Transitions through Meta Topology
形式上，用戶控制操作C可以被建模爲將數據流執行圖G（V，E）轉換爲新圖G *（V *，E *）的變換。 對於運算符v，這種變換可以改變三元組中的一個或多個條目（S，f，P）。 對於邊e，這種變換可以可選地改變pe。 特別地，由於Operator狀態S可以捕獲在長時間段內累積的狀態，因此需要特別小心以在重新配置期間捕獲狀態的變換（即，G→G *）。 也就是說，對於v *∈V*，Sv *由一個或多個節點{v}⊆V上的變換函數T定義，即T（{Sv}）= Sv *。 在沒有歧義的情況下，我們放鬆符號並使用T-1（v *）來表示狀態Sv *所依賴的集合{v}⊆V。
大多數現有系統（例如[10,39]）採用freeze-the-world方法來執行轉換，即通過適當的檢查點機制停止G，啓動G *，將G上的舊檢查點狀態遷移到G *並恢復數據流。但是，這可能會觸發反壓，導致延遲增加和吞吐量損失，進而限制數據流重新配置的執行頻率和表現。因此，在Chi的設計中，我們選擇了異步替代方案：我們不是直接影響轉換（即G→G *），而是引入一箇中間元拓撲G 1,控制操作可以暫時利用它來完成異步轉換。也就是說，在傳播控制消息期間，每個Operator根據G1向其下游廣播消息。在 G1 -G * 子圖下的Operator處理完控制消息後，將關閉;而G1 -G * 子圖下的Operator僅在完成控制消息處理後纔開始處理數據消息。當控制消息傳播完成時，產生的拓撲將等同於G *。
我們推導出元拓撲G* 對於控制操作C如下。 在最一般的情況下，我們設置G*=G∪G*∪EV，V *，其中EV，V * = {（v，v *）|∀v*∈V*，∀v∈T-1（v *）}。 換句話說，C的傳播圖包含來自新舊執行圖的所有運算符和通道，以及捕獲舊操作符和新運算符的狀態之間的依賴關係的通道。 雖然這種方法可以在重新配置期間將數據流執行圖的大小加倍，但實際上，我們可以通過適當的修剪來顯着減少傳播拓撲。 例如：
狀態不變性。 如果控制操作沒有改變節點v的狀態Sv，我們可以用v∈G摺疊相應的新節點v *∈G*，併合並與v相鄰的輸入和輸出通道。例如，在圖3（a）中 ，M * 1（M * 2）可以分別與M1（M2）合併。
非循環不變性。 只要我們能夠保證圖形的共生性，就可以積極地合併新舊拓撲。 例如，在圖3（a）中，我們可以用R1（R2）進一步摺疊R1（R2），而不破壞環狀。 這是通過（i）確保初始數據流拓撲是非循環的功能查詢接口以及（ii）修剪算法來保證的，該算法確保在優化元拓撲期間不引入循環。 例如，對於橫向擴展/重新配置，修剪算法使用一致散列作爲狀態分配方案，以避免在重新分區狀態時引入循環。
通過在圖3（a）中重複應用上述修剪規則，我們獲得了圖2中階段（IV）所示的圖形。
4.2.2 Control API
接下來，我們將介紹控制API的功能，使開發人員能夠實現複雜的控制操作。 Chi的API允許在以下維度上表達不同的行爲：（1）空間，例如{M1，M2}的行爲不同於{R1，R2，R3}，以及（2）時間，例如R3在接收時的行爲 第一個控制消息與圖2中的最後一個消息。
爲了實現這種靈活性，我們抽象控制操作並向用戶提供以下功能：
Configuration injection：我們允許相同的控制操作爲不同的Operator提供不同的配置。 配置指示Operator採取不同的控制操作。 配置被注入控制消息中（參見圖6以實現）。 運行時通過每個Operator的正確配置適當地實例化控制操作。 在圖2所示的向外擴展示例中，注入的配置需要指示（1）映射器重新連接輸出通道，（2）減速器R1和R2以遷移狀態，以及（3）新的減速器R3到 接受遷移的國家。 如算法1（L1-11）所示，R1注入SplitState（L6）和LoadFunc（L9）指令，R3注入MergeState（L8）和LoadFunc指令。
Reactive execution：Chi公開了一個被動（事件驅動）的編程接口，用戶可以利用該接口來定義控制操作。控制操作包括兩組事件處理程序：在控制器{OnInitAtController，OnBeginAtController，OnNextAtController，OnCompleteAtController，OnDis- poseAtController}執行的事件處理程序，以及在運算符{OnBegi- nAtOperator，OnNextAtOperator，OnCompleteAtOperator，OnDis- poseAtOperator}執行的事件處理程序。 。這些事件處理程序爲用戶提供了極大的靈活性，可在控制器和操作員收到第一個，下一個和最後一個控制消息時收集指標或修改配置。初始化控件操作時調用OnInitAtController，並允許用戶將配置注入控件消息。處理控件操作時將調用OnDisposeAtController和OnDisposeAtOperator。它們通常用於釋放資源。運行時處理這些處理程序的正確調用和狀態轉換，如圖3（b）所示，從而支持以安全的方式表達複雜的控制邏輯。
Blocking behavior：在圖2的示例中，運算符在從其接收到控制消息時總是阻塞輸入通道。我們發現這在許多控制場景中是一種相當普遍的模式，例如使用Checkpoint的放大/縮小操作。爲了簡化複雜控制的實現，我們提供了一個抽象層，允許用戶以阻塞和非阻塞的方式實現其控制操作。我們通過將控制消息分爲兩類來實現這一點：（1）阻塞：Operator阻止接收控制消息的相應信道，並且只有當該操作符上的所有控制操作都完成時才解除阻塞， （2）非阻塞：Operator不阻塞輸入通道並繼續接收該通道上的其他數據/控制消息。我們相信這種抽象對於用戶表達更高級的控制操作非常有用。例如，阻塞控制消息通常對影響狀態的控制有用，而非阻塞控制消息對於其他情況（例如監視）是有用的。
Example：我們使用圖2中所示的示例演示控制API的用法，其中我們要從G縮小爲G *到G（如圖3（b）所示）。算法1示出了數據流重新配置控制操作的僞實現。完成重新配置決策後，開發人員會創建阻止控制消息。在OnInitAtController中，創建阻塞控制消息並注入配置，以便在不同的操作員處觸發控制操作。具體來說，如§4.2.1中所述，邊（v，v *）∈EV，V *描述了v *和v的狀態之間的依賴關係，運算符v需要被配置爲拆分其狀態並運送相應的部分狀態爲v *，而操作符v *需要配置爲加載和合並接收狀態（L5-8）。例如，如圖2所示，R1需要分割狀態並將範圍['i' - 'l']的累計計數運送到R3。一旦拓撲或狀態改變，操作員需要重置相關的計算功能（L9）。這樣的控制消息被廣播給源操作員。它首先初始化保存遷移狀態的會話變量，並在OnBeginAtOperator函數中控制動作（L15-16）。遷移狀態逐漸累積，直到OnNextAtOperator（L18-19）接收到狀態的所有部分。一旦接收到所有消息，操作員（在OnCompleteAtOperator函數中顯示）執行控制動作，包括根據新的狀態鍵範圍（L23-25）移除不再保持的狀態，合併其他人給出的狀態（L26-27） ，並重置功能（L28-29）。一旦控制器從接收器操作員接收到控制消息，控制操作就會在OnCompleteAtController（L12）中標記爲已完成。
4.2.3 Correctness Properties
Chi提供正確性屬性，可以幫助用戶證明其控制操作的正確性。
THEOREM 1. Consider a control operation that changes a graph from G to G∗ using a control message and a state transformation function T. The control operation has the following properties:
1. The control operation will terminate in finite time.
2. If a pair of operators v,v? satisfies (a) v → v? is an edge in G or G∗, or (b) v ∈ T−1(Sv?), then v will always invoke OnCompleteAtOperator before v?.
此外，我們引入了安全阻塞控制操作 - 一種特殊類型的阻塞控制操作，其每個操作員的控制操作僅在OnCompleteAtOperator中讀/寫相應的操作員狀態。 安全阻塞控制操作具有更強的屬性 - 安全阻塞控制操作的語義等同於凍結世界方法 - 這可以幫助用戶理解其定製控制操作的語義和正確性。 有關定理1的詳細說明和證明以及安全阻塞控制操作的屬性，請參閱技術報告1。
4.3 Advanced Functionalities
我們討論了Chi的高級功能，這些功能是應對生產工作負載所必需的。
Multiple Controllers。到目前爲止，我們的描述假設一個數據流控制器強制執行控制操作。 我們的設計能夠通過允許單個數據流的多個電流控制器自然地擴展控制器。 例如，用戶可以每個所需功能具有一個控制器，例如，一個控制器負責監視數據流執行的健康狀況，另一個控制器負責監視運行狀態，而另一個負責重新配置數據流執行圖以防萬一激增的工作量負載。 只要保證不同控制操作的控制消息的可串行性，多個控制器就可以同時工作。 爲了執行跨數據流控制操作，例如，協調跨多個數據流的資源分配，我們可以引入可以與每個數據流的控制器交互的全局控制器。
Broadcast/aggregation trees. 在實踐中，數據流圖通常具有大量Source Operator（有時還有Sink Operator）。 在這種拓撲結構中，由於大的fan in/fan out，控制器很快就會成爲瓶頸。 爲了緩解這種情況，我們利用一種簡單的技術，例如在Source（Sink）Operator之前（之後）插入跨越Broadcast（Aggregation）Tree。
Dealing with congestion/deadlock. 當出現擁塞時，例如，由於網絡或CPU瓶頸，我們的反壓機制被觸發，所有消息（包括控制消息）都被延遲。 如果這些消息是緩解擁塞的控制操作的一部分，則這可能尤其重要。 一種選擇可能是擁有兩個單獨的隊列並使控制消息具有更高的優先級，以便在擁塞時首先交付它們。 然而，這會破壞控制和數據消息的順序，從而難以保持一致性。 因此，我們等待處理消息。 這類似於其他系統採用的方法，如Flink [10]和Spark Streaming [41]。
Fault tolerance。 集成控制和數據平面的主要好處之一是控制平面中的故障的處理方式與數據平面中的故障相同。 更具體地說，如果控制消息丟失，則底層數據信道負責重傳它們，直到它們被另一端確認爲止。 在網絡分區的情況下，控制器最終會超時並將重新啓動控制操作。
Chi允許開發人員實施各種策略來處理操作員故障。 爲了便於採用，我們在Chi之上實施了一個檢查點重放策略，以便在默認情況下處理操作員故障。 此策略將首先將數據流流回滾到最後一個檢查點，然後它將重新插入丟失的控制消息。 控制器中的故障通過將其自身狀態檢查到持久存儲中並在啓動故障控制器的新實例（通常由監視器處理）時恢復狀態來處理。
4.4 Compare Chi with Existing Models
接下來我們將Chi與流處理系統的現有控制模型進行比較（表1總結了比較）。 正在開發各種控制模型，針對不同的計算範例進行定製，即基於BSP的微批處理與一次記錄。 我們根據一致性，易用性，開銷和可擴展性來比較不同的模型。
Consistency. 許多有用的控制操作，例如縮小，狀態重新分區和檢查點，確實需要一致性。 通過在並行計算（稱爲同步全局控制）之間使用同步障礙，可以在BSP系統中輕鬆實現一致性。 Chi也可以使用阻塞控制消息來實現這種一致性，阻塞控制消息充當在數據流內異步移動的屏障。 如果需要，Chi可以複製BSP模型。 具體地，控制器可以用作如圖4（a）所示的屏障節點。 當一個階段開始時，它產生（1）一個阻塞控制消息（用S表示），它在操作員處安裝任務，然後是（2）描述輸入數據的數據消息（用D表示），以及（3）a 阻止控制消息（由E降級），標誌着一個階段的完成。 當接收到所有完成消息時，控制器通過重複相同的消息序列來啓動下一階段。
通過在重新配置期間凍結整個數據流，也可以在一次記錄系統中實現一致性。然而，這需要系統停止（如BSP），從而激勵像SEEP [11]這樣的系統異步重新配置工作程序（命名爲異步本地控制）;但犧牲了障礙的語義。異步本地控制也可以使用Chi的非阻塞控制消息來實現。缺少障礙使得很難實現許多有用的控制操作。考慮將過濾器應用於具有x和y字段的流的數據流（如圖4（b）所示），其中由於隱私調節，過濾器參數存儲在兩個數據存儲中。因此，必須複製流以並行過濾。最後將過濾結果連接起來。在僅提供異步本地控制的系統中，它無法支持請求簡單併發重新配置的控制請求，例如將過濾器選擇性從x <A和y <B更改爲x <C和y <D。這是因爲每個複製的元組必須同時處理所有新配置，而不是它們的混合。爲了確保一致性，如SEEP [11]中的算法3所示，數據流必須阻止攝取，恢復操作員檢查點，應用新配置，重放自上次檢查點以來複制操作符的輸出，以及取消阻塞攝取。
Easy-of-Use 除了一致性保證外，Chi還提供靈活的控制平面接口，並提供全面的自動化支持。 用戶以被動方式聲明控制邏輯，並依賴運行時自動管理控制操作的狀態，處理故障並異步執行操作。 相比之下，現有的控制模型缺乏可編程性和運行時支持。 例如，Flink實現了一種分佈式檢查點算法，該算法無法支持一般控制操作，例如，需要更改狀態。 最近，Dhalion研究了控制政策的高級代表性，特別關注識別檢測到的異常的症狀和療法。 它依賴於底層系統，即Heron，來提供實際的重新配置能力。 因此，Dhalion不具有作爲Chi的控制平面運行時間，其可以應用於一般的一次記錄流式傳輸系統。
Overhead. 重新配置BSP系統時，將停止整個數據流。這對於在線流處理系統尤其不利，並且會影響延遲和吞吐量。此外，BSP障礙嚴重限制了控制操作的頻率和時間。爲了分攤調度和通信成本，BSP屏障間隔通常設置爲不小於秒[39]。如上所述，重新配置一次記錄系統需要像在Flink中那樣freeze-the-world（第§7節），或者像在SEEP中那樣通過數據重放進行重新計算。一方面，freeze-the-world會產生與同步全球屏障相似的開銷。另一方面，儘管重新配置的Operator通常已經缺乏資源，但重放數據在生產中是昂貴的。我們的跟蹤顯示，緩衝所有中間輸出以準備重放需要大量內存，比操作員計算狀態消耗的內存大幾個數量級。重放如此大的緩衝區狀態不僅消耗大量帶寬，而且還會長時間阻塞運營商。
在Chi中，更改應用於異步全局障礙。無需凍結世界或數據重播。阻止行爲是每個運營商的本地行爲。沒有全局阻塞凍結整個數據流，從而減少了數據平面開銷。
Scalability. 現有的流處理系統通常具有單獨的控制平面。 這重複了控制平面的資源，以處理典型的分佈式系統問題，例如容錯和可伸縮性。 然而，Chi將控制平面嵌入數據平面。 由於數據平面針對處理大量數據進行了優化，因此Chi受益於相同的優化，例如，零拷貝數據移動和Broadcast/aggregation trees，用於數據流中的大量扇入/輸出。 此外，現有系統大多采用集中控制器。 重新配置需要大量控制消息，因此會導致單點故障和性能瓶頸。 相反，Chi可以自然地在控制器上分區工作負載。 數據流由並行控制器管理。 數據流控制器進一步拆分以並行操作控制操作。 所有這些控制器都在多個服務器上運行，並在分佈式存儲上保持狀態，這意味着需要高規模的體系結構。
5. APPLICATION EXAMPLES
爲了展示我們方法的靈活性，我們演示了使用Chi實現的三個控制應用程序。
Continuous Monitoring. 由於我們工作負載的不可預測性，與傳統的批處理系統不同，傳統的批處理系統可以離線調整作業以實現最佳性能，因此必須持續監控流量管道並按需優化，以實現高性能和穩健性。 我們展示了使用Chi來持續收集所有Operator的測量數據的示例，這是用於檢測和處理系統有趣特徵的基礎模塊，例如overload/underload，數據分佈中的skew/drift，間歇性的環境相關瓶頸和緩解散亂的人。 由於頁面限制，監視控制操作實現在技術報告中顯示。
請注意，控制器不再需要單獨ping每個運算符以收集統計信息。 相反，度量標準以可伸縮的樹形方式收集和聚合。 §7顯示了使用監視控件收集每個連接密鑰基數的評估，該基數有助於識別連接空間中的偏度（然後可以用於減少散亂圖）。
Dataflow Reconfiguration. 數據流重新配置對於幾個有趣的用例非常重要，例如從給定查詢添加/刪除運算符，增加運算符的並行度以及利用計算重用。
除了放大/縮小外，還可以執行更復雜的重新配置，包括更改查詢計劃。例如，圖5（a）演示了當我們在流連接查詢中發現偏差時，我們如何將查詢計劃更改爲異常的離散器。原來，流A和B使用shuffle join [26]連接，其中Reducer分別從A和B讀取數據，並根據連接key
將數據分區並路由到相應的reducer;減少接收數據時，使用相同的key加入元組。由於key空間偏斜，reducer R1接收的數據遠多於R2。此時，我們可以通過添加reducers {R3，R4}來更改查詢計劃，以共享R1的負載。我們的想法是讓A（假設A的工作量明顯高於B）將R1的負載分配到{R1，R3，R4}; B將R1的負載廣播到{R1，R3，R4}。這種重新配置要求R1將其內部維護的數據哈希表從B複製到R3和R4，同時將數據哈希表從A分配並重新分配到R3和R4。
自動參數調整。 大數據系統有許多參數，即使對於經驗豐富的工程師也很難調整。 通過在緊密控制迴路中對監控和數據流重新配置進行槓桿化，可以將Chi用於自動參數調整，以模擬單個查詢的多個實例的A / B測試。 例如，許多現有的流處理系統使用微批處理來在延遲和吞吐量之間進行權衡。 雖然大批量提供了良好的吞吐量，但它會增加延遲。 調整正確的批量大小是一個棘手的問題。 通過Chi的一個解決方案是持續監控數據平面的延遲並在我們看到觀察到的延遲相當大的波動時調整批量大小，直到我們獲得具有所需延遲的最大吞吐量。
6. IMPLEMENTATION & DISCUSSION
Distributed runtime.爲了展示Chi的性能和靈活性，我們在Flare上實現了它，這是我們團隊內部使用的流處理系統。 Flare建立在Orleans [7] - 虛擬角色框架之上 - 作爲運行時和Trill [16]作爲運營商級流處理引擎。 通過利用Orleans，Flare實現了分散的可擴展性，特別是：（1）節點可以在不通知主節點的情況下加入/離開集羣;（2）演員的生命週期由平臺自動管理，超越了內存的生命週期 實例化和特定服務器。
Chi中的Operator具有嵌入到Flare操作符中的堆疊體系結構，該操作符是單線程環境，如圖5（b）所示。 （i）通信層準確地提供FIFO，一旦數據通信信道具有模擬TCP的背壓。 （ii）消息調度器/多路複用器根據消息類型調用相應的處理模塊，並將它們的輸出多路複用到通信層。 （iii）數據處理器將Trill管道應用於數據消息。 （iv）控制處理器根據接收到的控制消息調用一系列本地控制動作。 它加載相應的控制配置，管理狀態機，並相應地調用用戶定義的控制操作。
Flare進一步提供了以下功能來簡化控制操作：（i）用戶友好的狀態管理功能，它將Operator狀態建模爲Key-Value映射，並可以使用用戶定義的分區方案自動分割和合並狀態。 關鍵，（ii）一個查詢編譯器（可自定義優化規則擴展）類似於Spark的催化劑[4]，它將LINQ查詢轉換爲分佈式數據流，以及（iii）文件服務器，允許運行時可擴展性，用戶可以上傳新的控制操作 依賴項並在運行時加載它們。
Custom serialization. 控制消息可以carry/propagate大的有效載荷，包括配置和狀態/度量/等來自每個Operator。由於每個Operator的序列化和反序列化可能會帶來不必要的開銷，因此我們實現了零複製操作，允許我們從字節緩衝區中提取必要的部分（例如，配置，感興趣的有效負載），而不會對整個消息進行去除。
圖6顯示了控制消息的結構。每條消息包括三個基本組件：1。元數據字段，用於確保FIFO準確一次傳送; 2.配置有效載荷字段以存儲不同Operator的配置; 3.Operator插入任何控制專用數據的數據有效載荷，例如，在縮小時重新分區狀態。控制消息由控制器生成（在控制指令應用於任何操作符之前）或由Operator生成（在控制操作已觸發之後但在控制消息傳播到後續操作符之前）。
Portability. 雖然我們在Flare之上實現了我們的方法，以便在我們的內部集羣中實現/部署，但我們的設計並不依賴於特定平臺。 Chi可以應用於其他系統，只要系統提供至少一次或一次性交付語義的FIFO，以及有序消息處理。 這些適度的要求由大多數現代流媒體系統提供，如Flink [10]和SEEP [11]。 典型的移植計劃包括：（1）如果底層系統不提供FIFO準確的一次消息傳送，（2）移植消息調度器/多路複用器和控制處理器，以及（3）重用 現有數據處理器。
7. EVALUATION
在本節中，我們使用許多微基準和兩個真實基準來評估Chi的性能。 第一個真實世界的基準測試側重於動態擴展/輸出資源，而第二個評估Chi的處理控制和數據故障的能力。 這些結果表明，即使在高數據/控制負載和大型數據流圖表下，Chi也會產生可忽略的開銷，並且能夠快速響應工作負載或故障的變化。 爲了展示我們方法的靈活性，我們還通過兩個更高級的案例研究報告了實驗，即處理傾斜的密鑰分發和自動調整以滿足SLO。
7.1 Experimental Setup
我們的實驗羣集包含Azure中的32個DS12v2實例。 每個虛擬機具有4個vCPU，28 GB RAM和10 Gbps網絡連接。 我們考慮一個公共工作負載，Yahoo！ 流式基準測試（YSB）[42]和一個基於生產跟蹤的私有工作負載IPQ1，它由具有複雜窗口聚合和流連接的多階段查詢組成。 YSB在數據處理（字節/事件）方面相當輕量級，而IPQ1在計算上更重（KB /事件）。 正如§6中所解釋的，我們在Flare之上實現了Chi，這是一個基於.NET CLR構建的流引擎，由我們的團隊在內部使用。 在需要時，我們將比較Drizzle [39]，一個Apache Spark v2.0.0（一個BSP風格的引擎）的分支，它帶有一個用於流媒體場景的優化調度程序，以及Apache Flink v1.3.2 [10]（一個連續的數據流引擎）。 對於我們的所有實驗，我們在測量折扣自舉效果之前預熱JVM和CLR。
Flare performance。爲了幫助理解我們用於Chi的底層引擎是否與現有系統競爭，我們將Flare與Flink和Drizzle的基本性能進行比較。在圖7中，我們顯示了使用YSB和IPQ1時三個系統的吞吐量和延遲的結果。對於吞吐量實驗（圖7（a）），我們將延遲SLO設置爲350毫秒並最大化吞吐量，而對於延遲實驗，我們將輸入速率固定爲2000萬 tuples/秒並最小化延遲。按照慣例[39]，我們將延遲定義爲窗口結束後處理窗口中所有事件所需的時間。例如，如果窗口在時間a結束並且在時間b處理來自窗口的最後一個事件，則該窗口的處理等待時間計算爲b-a。 Flink和Drizzle的結果與之前在文獻[39,25]中報道的結果一致，並證實Flare的性能與這些系統相當。
7.2 Micro-benchmarks
在本小節中，我們研究了控制平面和數據平面之間的相互作用。 具體來說，我們對Chi的操作開銷和可伸縮性方面感興趣。 爲此，我們在三種不同的CPU方案（分別爲50％，75％和90％）下改變數據平面負載，並相應地設置兩個工作負載YSB和IPQ1的攝取率。 對於計算量大的IPQ1，這導致20,40和60百萬個事件/秒（對應於我們的32個服務器集羣中平均CPU的56％，73％和94％），而對於通信量大的YSB，這導致 140,180和220萬個事件/秒（分別爲51％，74％和89％的平均CPU）。 對於控制負載，我們使用阻塞（B-Control）和非阻塞（NB-Control）消息來考慮控制消息的兩個實例。 爲了準確地隔離Chi的影響並避免使用自定義控制邏輯（例如，CPU密集型用戶代碼）偏置結果，我們在實驗中僅使用NoOp控制消息。
Does control plane affect the data plane? 我們現在評估Chi引入的開銷。在圖8（a）和8（b）中，我們顯示了當從一個控制消息改變控制平面負載時兩個工作負載的延遲相對增加（代表數據流管理任務，例如，檢查點和重新配置） - 例如，縮放/縮小）到100個控制消息/ s（代表監視任務）。該範圍涵蓋了我們在生產中觀察到的所有控制方案，我們認爲絕大多數用例都應該如此。
這些結果表明非阻塞和阻塞控制都具有低開銷。這是因爲這些控件都不需要全局同步 - 控制事件像數據事件一樣以異步方式傳播和處理。例如，在計算密集型IPQ1工作負載（6000萬事件/秒）的最高負載下，即使對於高控制負載（100條消息/秒），Chi也會對數據平面造成低於20％的延遲損失。這很重要，因爲平均CPU利用率已經達到了94％（通過向外擴展可以進一步降低延遲）。正如所料，阻塞控制消息比非阻塞消息更昂貴。這是因爲阻塞控制消息需要本地同步，這會暫時阻塞輸入通道。
Does a busy data plane limit the control plane? 接下來，我們研究數據平面負載對控制消息完成時間的影響。關注的是，通過合併控制和數據事件，高數據平面負載可能會對控制消息的性能產生負面影響。爲了驗證這一點，我們重複實驗，並測量阻塞和非阻塞消息的完成時間（見圖8（c）和8（d））。作爲參考點，我們還顯示了數據平面的延遲（圖中的“數據延遲”條）。消息等待時間定義爲進入系統的消息M的時間戳與M觸發的最後一條消息離開系統的時間戳之間的差異。除了排隊延遲之外，數據（相應控制）消息的完成時間還取決於實際數據處理的複雜性（分別是控制邏輯）。因此，如果沒有積壓並且在接收時立即處理消息，則控制消息可以比數據消息更快地完成。
在大多數情況下，與數據消息傳遞相比，控制消息的完成速度相對較快。此外，當控制負載較低（一個或十個控制消息/ s）時，完成時間相對不受數據平面負載增加的影響。然而，我們觀察到，在最高負載（對於YSB分別爲2.2億個事件/秒和對於IPQ1爲6000萬個事件/秒），控制消息的完成時間與數據延遲相似或更高。這對於阻止消息尤其明顯。原因是後者在每個操作員處引入了本地同步，並且在高負載下，數據流中不同路徑上的延遲存在較高的可變性（例如，由於工作不平衡）。然而，正如§4.2.2中所討論的，我們觀察到阻塞和非阻塞控制消息在語義上是等效的，儘管它們的實現和執行模型都不同。因此，爲了減少完成時間，開發人員總是可以將阻塞控制消息轉換爲非阻塞版本。
Is the control plane scalable? 如第6節所述，Chi可以通過使用廣播（聚合）樹在控制器和運營商之間交換控制事件來擴展到具有大量源（接收器）的大型數據流。 爲了評估其效果，在圖9中，我們顯示了控制消息的完成時間，因爲我們增加了源的數量。 結果表明，即使對於非常大的數據流圖（8,192個源），完成時間也會以對數方式增加並且仍然遠低於100 ms。
7.3 Adaptivity and Fault-Tolerance
前面的部分已經表明，Chi會產生較低的開銷和完成時間，並且可以擴展到大型數據流圖。 在此之後，我們將研究Chi如何利用這些屬性來改善使用YSB工作負載對數據平面的工作負載變化（動態彈性）和故障（故障恢復）的適應性。
Dynamic Elasticity. 我們將32服務器羣集的輸入速率設置爲30M元組/秒。 在時間t = 40秒時，我們將輸入速率加倍以模擬工作負載峯值。 同時，我們使用各自的策略在所有三個流引擎上啓動橫向擴展流程。 例如，在Apache Flink中，當橫向擴展過程開始時，我們立即調用Savepoint [23]操作。 它外部存儲一個獨立的檢查點，可用於Flink程序的停止和恢復，並使用更大的拓撲重新啓動數據流。 我們將結果繪製在圖10（a）中：
CHI。 在橫向擴展時間（t = 40s），吞吐量沒有明顯下降，而延遲暫時達到5.8s。 但是，系統會在6秒內快速恢復到穩定狀態。
APACHE FLINK。 在t = 40s時，吞吐量降至零（由於Savepoints啓動的凍結世界）持續五秒。 相反，處理延遲最高可達35.6秒，重啓後需要31秒才能恢復穩定狀態。
DRIZZLE。 在t = 40s時，吞吐量沒有明顯下降，因爲Drizzle使用BSP模型，因此不可能連續測量吞吐量。 與Flink類似，處理延遲時間達到6.1秒，並且在穩定之前需要額外的10秒。 值得注意的是，Drizzle在5秒後開始對工作負載峯值作出反應。 這是因爲工作負載峯值發生在調度組[39]的中間，系統無法調整數據流拓撲 - 調度組大小越大，它對工作負載變化的反應就越慢。
Fault Tolerance：接下來，我們將檢查在Chi之上實現的默認故障恢復操作（第§4.3節）。 與之前的實驗一樣，我們將攝取率設置爲30M元組/秒。 我們還每隔10秒啓用所有三個流處理系統的檢查點。 在最後一個檢查點後5秒的時間t = 40s，我們殺死虛擬機以模擬數據流中的故障，並且我們在所有三個流引擎上開始恢復過程（參見圖10（b））：
CHI在失敗時（t = 40s），吞吐量沒有明顯下降，而延遲暫時達到4.3秒。 但是，系統會在5秒內迅速恢復到穩定狀態。
APACHE FLINK在t = 40s時，吞吐量降至零5秒（系統停機時間），因爲Flink的恢復機制使用最後完成的檢查點重新部署整個分佈式數據流[22]。 處理延遲達到17.7秒。 然後重新啓動後需要13秒才能恢復穩定狀態。
DRIZZLE在t = 40s時，由於橫向擴展實驗中描述的原因，我們觀察到吞吐量沒有下降。 處理延遲時間達到9.1秒，恢復穩定狀態需要11秒。 由於Spark需要重新運行失敗批次的線路，因此Spark的恢復機制導致吞吐量下降（在恢復期間）在t = 50s左右。
7.4 Chi in Action
我們通過使用兩個真實的複雜控制操作來展示Chi的性能來結束我們的評估，一個側重於參數自動調整，另一個側重於由於key值的數據傾斜導致的工作負載skew。
Auto-Tuning for SLOs：流處理系統包括許多用於調整系統行爲的參數。 這爲用戶提供了極大的靈活性，但同時由於參數空間的大尺寸而使其任務大大複雜化。 作爲一個代表性的例子，我們將注意力集中在輸入數據批量大小上。 流處理系統使用批處理來分攤每元組處理成本。 批次大小直接影響系統性能。 正確識別最優值通常是一項非常重要的任務，如圖11（a）所示，其中我們繪製了IPQ1工作負載的延遲和批量大小之間的關係。
爲了說明Chi如何幫助正確調整批量大小，我們實現了一個控制操作，包括一個監控任務，它收集延遲信息，再加上一個重新配置任務，更新批量大小以滿足之間的期望權衡。 潛伏。 爲了說明這是如何工作的，我們展示了一個運行於11（b）的示例，其中我們設置控制操作以優化批量大小，給定輸入速率爲6,000萬個事件/秒，並且上限延遲爲500毫秒。 控制器每30秒收集一次延遲樣本，更新處理延遲的移動平均值，並在需要時執行優化步驟。
最初（階段I），控制器選擇保守批次大小爲40K事件，同時測量延遲和吞吐量。 它很快意識到這個批量大小不足以滿足輸入速率 - 它壓倒了系統導致頻繁的背壓，這從圖中的吞吐量波動中可以清楚地看出。 然後，從30秒標記（階段II）開始，控制器將批量大小加倍至80K，這導致更穩定的吞吐量，將處理延遲減少到≈500ms。 在60秒標記（階段III），控制器通過將批量大小加倍到160K來嘗試第二個優化步驟，但很快就會檢測到這樣做，它將無法滿足延遲SLO（500毫秒）。 最後它將批量大小恢復爲80K（第四階段）。
Detecting and Adapting to Workload Skew: 如圖1（c）和圖1（d）中對生產工作負載的分析所示，對Key進行Join在數據分佈中表現出高時間和空間偏差。 這種差異可能導致不平衡，導致落後者，並最終違反SLO。 爲了顯示這種影響，我們使用了另一種生產工作量IPQ2，它表現出高度的偏斜。 此工作負載是一種流連接查詢，可在極大且高吞吐量的實時用戶活動日誌上進行自聯接。 自連接的存在放大了關鍵偏斜。
與前面的示例一樣，我們實現了一個由監視任務和重新配置組成的控制操作，其行爲如圖5（a）所示。 圖11（d）和圖11（e）分別顯示了重新配置之前和之後的Key分組的分佈。 在重新配置之前，一些任務處理大部分Key空間（如分佈中的峯值所示），而在重新配置之後，Key空間在任務之間均勻分佈。 這對延遲和吞吐量有直接的好處：在重新配置之後，吞吐量增加了26％，而延遲下降了61％（圖11（c））。
8. RELATEDWORK
在單節點[16,1,30]和分佈式設置[41,14,36,10,39,31,28,3]中已經對流處理進行了充分研究。 在高層次上，我們可以將這些系統的基礎分爲三類：continuous operator model模型[30,16,28,10,17,36,27]和BSP模型[41,14,3]。 儘管在這兩種方法[16,6,5,11]中都在努力改進數據平面，但在改進控制平面方面的工作卻相對較少[9,11,10]。 控制平面仍然需要處理分佈式系統實現中遇到的常見問題，例如容錯，可伸縮性和自適應性。 相反，在Chi中，通過利用數據平面傳遞控制消息，控制操作可以利用爲數據平面引入的相同優化。
現有工作主要集中在基於持續Operator模型的流處理系統中控制平面的特定方面，例如異步檢查點算法[9]。 Apache Flink [10]使用freeze-the-world的方法通過保存點和數據流重啓來改變階段的並行性。 Apache Storm [36]提供了非常有限的數據流重新平衡功能 - 由於系統不提供狀態Operator支持，因此用戶必須手動管理和遷移Operator狀態。 這使得用戶很難正確地重新平衡有狀態的應用程序。
關於控制平面編程的工作量有限。 SEEP [11]提出了一種運算符API，它集成了動態擴展和故障恢復的實現。 SEEP API專注於管理並行性，是Chi在功能方面提供的一個子集。 Chi允許更靈活的控制操作，例如，解決數據偏差和連續監控。 此外，由於廣泛的一致性模型，Chi支持一般控制操作。 相反，SEEP僅提供有限的操作集，因爲其控制信號不同步。 此外，Chi通過自動執行復雜任務簡化了控制平面編程。 必須在SEEP中手動實施和管理這些任務。 最近，Dhalion [24]提出了一種控制策略抽象，描述了檢測到的異常的症狀和解決方案。 如第§4.4節所述，Dhalion的政策可以在Chi之上實施。
流處理系統廣泛採用分割符號。它們被引入用於分割連續流[37]以支持具有無約束狀態的查詢，例如分組和連接。標點符號缺少同步機制，這對於支持需要全局一致性保證的任何高級控制操作至關重要。 Aurora / Medusa [18]和繼承人Borealis [8]是開創性的工作，探索分佈式流處理中的查詢自適應。 Borealis使用控制線來修改流查詢，但是它們的同步需要由開發人員小心處理，這在分佈式設置中是一項非常重要的任務。此外，控制線僅限於修改查詢參數。 Esmaili等。 [35]使用非同步標點來修改連續查詢，因此僅支持單輸入和輸出流。最近的流媒體系統，如Flink [10]，MillWheel [2]和GigaScope [20]，主要採用標點符號來檢查維護任務，如檢查點障礙，沖洗早期結果和檢查心跳。他們的標點符號機制不能支持Chi的一般控制操作。
BSP流處理系統[38]很自然地在同步Barrier下重新配置數據流。 但是，由於對延遲和吞吐量的負面影響，Barrier的概念可能對流式工作負載不利。 因此，已經提出了幾種技術來減輕BSP中同步引入的開銷[41,39]。 例如，Drizzle [39]研究了基於快速適應性BSP的流媒體系統的調度方法，如何使用羣組調度和預調度來減少延遲，但仍然爲突然的環境變化提供合理的適應性。 由於Chi主要關注的是將控制嵌入到數據平面中，因此我們的工作是對這些工作的補充。
離線數據系統在運行時期間對重新配置也有很強的要求。 Chandramouli等。 [15]研究了檢查點和恢復連續數據庫查詢的最佳執行計劃。 最近，S-Store [12]在事務數據庫之上添加了流語義。 可以在交易之間應用控制; 但是，系統遭受與BSP系統類似的同步開銷。 爲了支持新興的強化學習算法，Project
Ray [29]爲大型動態數據流開發了一個任務調度框架。 在Chi中，任務調度框架由Orans提供，Chi負責提供用於定製控制操作和分佈式執行機制的API。 一個可能的未來方向是將Chi移植到Ray上。 這將增強Ray的人工智能和流處理系統作業的持續監控和重新配置功能。
9. Conclusion
Chi採用原則性方法來控制數據流。 Chi不是使用單獨的控制平面通道，而是在數據平面上傳播控制消息和數據消息。 這樣可以支持重要的處理系統要求，例如零系統停機時間和頻繁的重新配置，而不會影響易用性。 Chi對生產工作負載的實施和驗證不僅提供了驗證設計選擇的見解，而且提供了有價值的工程經驗，這對於這種雲規模控制平面的成功至關重要。