一周一论文（翻译）——[VLDB 18] Chi:分布式流处理系统下可扩展的、可编程的控制计划模块
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）顯示了我們集群中隨機流子集每分鐘生成的標準化元組數的熱圖。 這顯示了兩個重要的現象。 首先，通過水平線上的不同顏色模式證明，每個流呈現出獨特的工作負荷特征（空間變異性）。 其次，雖然一些流在大多數時間內是暗的（高容量），但是幾個流表現出突發性（時間變化），如同色水平線的色點所示。
?
日志事件中存在這種可變性的主要原因有三個：
為了量化可變性程度，在圖1（b）中，我們顯示了一個盒子和胡須圖，其中Y軸表示在輸入數據流子集上每分鐘事件計數的增量。 框的高度顯示第25和第75百分位數之間的計數差異。 除了每個流的行為的顯著差異之外，值得注意的是在相同流中觀察到的高變化范圍，由大量異常值（圖中的藍點）表示。 例如，對于某些事件流，事件計數可在一分鐘內增加高達數千萬，表明及時響應對于保持負載峰值至關重要。
數據多樣性。確定最佳查詢計劃和資源分配的另一個關鍵因素是數據分布。 為了分析其動態，我們關注key selectivity，定義為落入特定存儲桶的元組數。 為了分析這個參數的動態，在圖1（c）中我們繪制了各種分組key隨時間的選擇性，而在1（d）中我們繪制了多個分組密鑰隨時間的選擇性。 在兩個圖中觀察到的選擇性的寬偏差表明，一次性或基于每個key的一次性查詢計劃（例如，基于傳統基數的優化器）可能隨時間推移是次優的。
多租戶控制策略：在我們的生產環境中，許多團隊使用相同的流處理系統。 因此，來自不同團隊的查詢或甚至來自同一團隊的不同查詢的SLO存在大量差異，導致需要同時激活多個控制策略。 例如，我們有許多客戶有興趣消費詳細，信息和錯誤日志。 雖然詳細和錯誤日志用于調試，但信息日志通常用于計算重要指標（例如，計費指標）。 我們的開發人員提出的一個流行請求是為信息日志和較弱的傳遞語義（例如，盡力而為，至少一次）提供更強的傳遞語義（例如，恰好一次）用于詳細/錯誤日志。 這突出了在每個流級別或每個租戶級別上支持多個控制策略的重要性。
?????? 多租戶還在系統管理和優化方面引入了新的機會。 在我們的生產跟蹤中，我們觀察到在數據源和運算符方面共享重要重疊的查詢（例如，用戶以相同的方式解析日志）。 因此，控制策略可以考慮跨用戶共享計算或者對中間數據進行物化以供以后重用。 此外，通過對數據流和工作負載的洞察，可以使用控制策略來自動且透明地選擇可以提高執行效率的新數據布局（例如，利用分區）和存儲引擎（例如，存儲器內，數據庫）。 雖然所有這些優化都被孤立地理解[33,34,40,32]，但以集成方式應用它們來優化流式工作負載需要控制平面的靈活性和可擴展性。
目標：我們的跟蹤分析揭示了我們工作負載的幾個有趣的特征 - 高容量（10 / PB /天），低延遲要求（SLO秒），廣泛多樣化（100s數據流）和動態（由于 生產這些日志的服務的性質）。 基于此，我們可以得出以下控制平面要求列表：
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來增加吞吐量的情況。
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對生產工作負載的實施和驗證不僅提供了驗證設計選擇的見解，而且提供了有價值的工程經驗，這對于這種云規模控制平面的成功至關重要。
總結
以上是生活随笔為你收集整理的一周一论文（翻译）——[VLDB 18] Chi:分布式流处理系统下可扩展的、可编程的控制计划模块的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 云计算的三种服务模式：IaaS，PaaS
- 下一篇： 一周一论文（翻译）——[PVLDB 17