Abstract
近年來，大規模實時分析需求激增，并且已開發出大量流處理系統來支援此類應用。 即使遇到硬體和軟體故障，這些系統也能夠繼續進行流處理。 然而，這些系統并未解決其Operator面臨的一些關鍵挑戰：手動，耗時且容易出錯的調整各種配置旋鈕以實作服務水準目标（SLO）以及SLO維護的任務。 面對突然的，不可預測的負載變化以及硬體或軟體性能下降。
在本文中，我們介紹了自适應調節流處理系統的概念以及它們必須滿足的關鍵屬性。 然後，我們介紹了Dhalion的設計和評估，Dhalion是一個為底層流處理系統提供自适應自我調節功能的系統。 我們描述了在Twitter Heron之上實作Dhalion架構，以及一些自動重新配置Heron拓撲以滿足吞吐量SLO的政策，根據需要擴充和縮減資源消耗。 我們通過實驗評估我們在雲環境中的Dhalion政策并證明其有效性。 作為Heron項目的一部分，我們正在開放我們的Dhalion政策。
1. Introduction
在一個組織被來自内部和外部資料的資料所淹沒的世界中，分析資料并對實時變化做出反應已成為關鍵的服務差異化因素。 這些需求的例子比比皆是 - 分析Twitter推文可以在幾分鐘内檢測出熱門話題，一旦釋出就會對新聞事件作出反應，并在資料中心Operators級聯之前顯示系統故障。
這些用例的普遍存在導緻近年來在資料中心規模上開發和部署了大量的分布式流處理系統（參見Apache Storm [26]，Spark Streaming [10]和Twitter的Heron [22]，LinkedIn的Samza [ 4]等）。 考慮到這些系統通常采用的規模，它們自然地設計為容忍系統故障并與同一叢集中的其他應用程式共存。
然而，在很大程度上不受研究人員和系統開發人員注意的關鍵挑戰是配置，管理和部署此類應用程式的複雜性。 與這些架構的使用者進行的交流表明，這些手動操作任務不僅繁瑣且耗時，而且容易出錯。 Operators必須仔細調整這些系統，以平衡資源使用率和性能（吞吐量或延遲）等競争目标。 同時，它們還必須在配置期間考慮大的和不可預測的負載峰值，并随時待命以對故障和服務降級做出反應。
受這些挑戰的啟發，在本文中，我們介紹了Dhalion，這是一個建立在流處理系統必須自适應自我調節的核心理念的系統。 受複雜生物和社會系統中類似概念的啟發，我們定義了三個重要的能力，使系統slef-regulate。
Self-tuning:為了支援各種應用程式和操作環境，現代流處理系統通常具有高度可配置性，可以顯示各種旋鈕，允許操作員根據自己的特定需求調整系統。 然而，這個功能既是恩惠又是禍根。 流式架構的使用者經常抱怨即使對于最簡單的任務也需要大量的手動工作，例如确定流式傳輸管道的每個階段的并行度。 由于沒有完全确定理想配置的原則方法，是以使用者通常會嘗試多種配置并選擇最符合其服務級别目标（SLO）的配置。 自我調節流處理系統應該采用流處理系統應用的規範以及定義目标的政策，并自動調整配置參數以實作所述目标。
Self-stabilizing：長期運作的流處理應用程式不可避免地面臨各種可能威脅其穩定性的外部沖擊。 例如，當全世界的使用者對地震，名人失禮或世界杯目标做出反應時，Twitter的推文處理應用程式通常會遇到比正常情況高幾倍的負載。 由于這些負載變化在很大程度上是不可預測的，是以操作員不得不為這些應用程式過度配置資源以避免SLO違規。 但是這種選擇意味着在大多數情況下，系統資源未得到充分利用，進而降低了叢集營運商的投資回報率（ROI）。 自動調節流式傳輸系統必須通過适當地重新配置自身來對外部沖擊作出反應，以始終保證穩定性（和SLO的遵守）。 它可以通過擷取額外資源并擴充負載峰值，然後放棄資源和縮減來滿足此要求。
Self-healing: 大多數流處理系統都包含各種容錯機制，可以從硬體或軟體故障中恢複。 但是，系統性能不僅會受到故障的影響，還會受到硬體和軟體的影響，進而降低服務品質。 例如，叢集中的機器可能名義上可用，同時由于硬體問題（例如慢速磁盤）或軟體問題（例如導緻交換抖動的記憶體限制）而提供極低的性能。 自我調節流處理系統必須識别此類服務降級，診斷其根源的内部故障，并執行必要的操作以從中恢複。
Dhalion是一個基本上允許流處理架構變得自我調節的系統。 Dhalion已經在Twitter Heron [22]的基礎上實作和評估，我們正在将它作為對Heron代碼庫的貢獻釋出到開源。 但是，其架構和基本抽象也适用于其他流處理系統引擎。
Dhalion位于每個Heron應用程式的頂部，并定期調用一個明确的政策。 該政策檢查流應用程式的狀态并檢測潛在的問題，例如存在緩慢的程序，缺乏資源，SLO違規等。在診斷出特定問題後，Dhalion政策試圖通過執行适當的操作來解決它。 Dhalion的一個重要方面是其可擴充和子產品化的架構。 Dhalion足夠靈活，可以合并使用者可以使用指定良好的API實作的新政策。 此外，由于政策使用多個自包含子產品，是以Dhalion使用者可以在指定自己的政策時重用現有子產品。
受到流處理系統使用者面臨的挑戰的啟發，我們設計了兩個Dhalion政策，即在存在負載變化時實作吞吐量最大化的動态資源配置，以及用于滿足吞吐量SLO的Heron應用程式的自動調整。 第一項政策為Dhalion提供了自我穩定和自我修複能力。 第二個政策另外提供自我調整功能。 據我們所知，現有的流處理系統都沒有采用這種複雜的政策，但它們主要依賴于使用者幹預配置。
在這項工作中，我們做出以下貢獻：
- 受使用者面臨的挑戰的啟發，我們引入了自調節流媒體系統的概念，并讨論了它們的主要特性。
-
我們設計了Dhalion，這是一種新穎的系統，它位于流引擎之上，并允許它們通過調用明确的Dhalion政策來自我調節（第2節）。 Dhalion具有子產品化和可擴充的架構，并已在Twitter Heron（第4節）之上實作。
我們提出了兩個重要的Dhalion政策，允許Heron在負載變化的情況下動态配置資源，并自動調整Heron應用程式，以便滿足吞吐量SLO（第5節）。
- 我們在雲環境中評估我們在Heron之上的政策并證明Dhalion的有效性（第6節）。
我們在第7節讨論相關工作。最後，我們總結了未來工作的方向（第8節）。 接下來，我們首先介紹Dhalion的進階概述，重點介紹其關鍵的抽象概念。
2. DHALION OVERVIEW
在本節中，我們将介紹Dhalion的進階概述，重點介紹其關鍵的抽象概念。 在下一節中，我們将詳細讨論Dhalion的架構。
Dhalion位于Heron等流處理系統引擎之上，通過子產品化和可擴充的架構為其提供自我調節功能。 Dhalion會定期調用一個政策來評估拓撲的狀态，識别潛在的問題并采取适當的措施來解決它們。 使用者和系統管理者可以根據其特定需求和工作負載要求定義新政策。 例如，使用者可能會建立一個政策，嘗試在不過度使用資源的情況下最大化吞吐量，或者建立一個自動提供必要資源以滿足特定服務級别目标（SLO）的政策。 圖1顯示了Dhalion政策的各個階段。 這些階段将在第4節中詳細讨論。
在Symptom Detection階段，Dhalion通過從底層流處理系統收集各種名額來觀察系統狀态。一些Example Metrics标準是在特定拓撲階段處理元組的速率或者在特定任務處理的待處理資料包的數量。根據收集的名額，Dhalion嘗試識别可能表示流處理應用程式的健康受到損害的症狀。例如，Heron執行個體使用背壓作為一種機制來通知其上遊Source無法跟上其輸入速率并要求其Source發送速度減慢。是以，Dhalion将背壓識别為一種症狀，表明流處理系統Channel目前尚未處于健康狀态。另一個症狀是處理Channel中特定階段的任務的偏差。如果給定階段的某些任務處理的元組明顯多于同一階段的其餘執行個體，那麼這種症狀值得進一步研究。
在收集各種症狀之後，在Diagnosis Generation階段，Dhalion試圖找到一個或多個解釋它們的Diagnoses。 例如，背壓的存在可歸因于各種原因，例如在特定階段資源不足，慢主機/機器或資料偏斜。 Dhalion産生所有可能的診斷，可以解釋觀察到的症狀。
一旦找到一組Diagnoses，系統就會對它們進行評估，并探讨在Resolution階段可以采取的解決問題的措施。 例如，如果Dhalion已經診斷出由于配置設定給特定階段的資源有限而導緻背壓，那麼為了解決問題，它可以擴大配置設定給該階段的資源。 同樣，如果由于一台或多台任務由于機器速度較慢而運作較慢而建立了背壓，那麼Dhalion可以通過将任務移動到新位置來解決此問題。
請注意，Dhalion産生的診斷可能是錯誤的，是以執行的錯誤操作最終不會解決問題。例如，Dhalion可能會認為背壓是由于配置設定給某個階段任務的資源有限造成的，而實際上是由于任務緩慢造成的。例如，當任務沒有比同行慢得多時，就會發生這種情況，是以Dhalion沒有将其歸類為異常值。在這種情況下，系統将錯誤地擴充拓撲資源。是以，在執行每個操作後，Dhalion會評估操作是否能夠解決問題或使系統進入更健康的狀态。如果一個動作沒有産生預期的結果，那麼它被列入黑名單并且不會再次重複。這種機制非常強大，因為它允許系統避免重複錯誤的動作。在沒有黑名單機制的情況下，系統可能會陷入不健康的境地，并陷入反複調用無效（甚至可能适得其反）行動的陷阱。
3. HERON BACKGROUND
我們通過擴充Twitter的Heron [7]系統實作了Dhalion，進而為Heron提供了自我調節功能。 在描述我們的實作之前，我們簡要概述了Heron及其速率控制機制。 關于Heron架構的廣泛讨論可以在[17,22]中找到。
3.1 Topology Architecture
HERON使用者部署拓撲結構，這些拓撲結構基本上是有針對性的Spout和Bolt。Spout是輸入資料的來源，例如Twitter流，而Bolt表示從Spout或其他Bolt接收的流的計算。 Spouts經常從隊列中讀取資料，例如Kafka [3]或Distributed Log [6]并生成元組流，而元組流又由執行流上實際計算的Bolt網絡消耗。 圖2顯示了拓撲的體系結構。 在本節中，我們将重點放在圖中的灰色元件上，它描繪了拓撲中最重要的Heron元件。 在Heron之上實作的Dhalion（藍色）将在以下部分中進行廣泛讨論。
Heron運作在諸如Aurora [1]或YARN [27]之類的排程架構之上。每個Heron Topology都部署在由這些架構管理的容器上。 Scheduler元件負責從底層排程架構請求容器。Topology Master過程負責在整個存在過程中管理Topology并占用一個Container容器。其餘的容器分别運作Stream Manager，Metrics Manager和許多名為Heron Instances的程序，這些程序運作與使用者邏輯對應的代碼。每個Spout/Bolt由一組Heron Instances表示，這些Instance獨立并行地執行與此Spout/Bolt相對應的使用者代碼。Stream Manager是系統的關鍵元件，因為它管理Heron Instance中Tuple的路由。更具體地說，每個Heron Instance都連接配接到其本地Stream Manager來發送和接收元組。拓撲中的所有流管理器在它們之間連接配接以形成n2個連接配接，其中n是拓撲的容器數。最後，Metrics Manager負責從位于同一容器中的Stream Manager和Heron Instances收集和報告各種Metrics名額。
3.2 Topology Backpressure
Heron的一個重要方面是它的速率控制機制。在不同元件可以以不同速度執行或元件的處理速度随時間變化的拓撲中，速率控制至關重要。這可能是由于各種原因造成的，例如一個或多個Toplogy階段（有限的并行性）中的Heron Instance數量有限，資料偏斜或由于機器/容器緩慢。 Heron使用Backpressure機制動态調整資料流經拓撲的速率。作為示例，考慮由于前面提到的原因之一而下遊階段緩慢的拓撲。如果上遊拓撲階段沒有降低它們發出資料的速率，則Tuple将在長隊列中累積，是以系統可能會開始丢棄元組。Heron的背壓機制減慢了上遊階段的速度，進而避免了這種情況。正如我們将在第5節中讨論的那樣，Dhalion将Topology Backpressure的存在視為系統不穩定的訓示，是以采取适當的措施使Topology結構恢複健康狀态。
Heron Stream Manager在處理和傳播拓撲階段的背壓方面發揮着重要作用。 背壓機制的工作原理如下：當容器中的一個或多個Heron執行個體比其對等端慢時，本地Stream Manager将該事件識别為保持要發送的元組的緩沖區将填滿。 然後，Stream Manager停止從本地Spout讀取資料，并向其他Stream Manager發送特殊消息，要求他們停止從本地Spout讀取資料。 一旦慢速Heron Instances趕上，本地Stream Manager就會通知其他Stream Manager，然後他們又開始從他們的本地spout中讀取資料。
4. DHALION ARCHITECTURE
在本節中，我們将較長的描述Dhalion的架構。 如圖2所示，Dhalion由三個主要元件組成，即Health Manager，Action Log和Action Blacklist。 在以下部分中，我們将詳細讨論這三個元件。
4.1 Health Manager
Health Manager是Dhalion的關鍵元件，因為它負責維護運作拓撲的運作狀況。 Health Manager是一個長期運作的程序，它定期調用一個政策來評估Topology的狀态，識别潛在的問題并采取适當的措施來解決它們。 Dhalion支援兩種政策：侵入性和非侵入性。 入侵政策采取調整拓撲配置的動作（例如，并行性變化）。 另一方面，非侵入性政策不會進行任何拓撲更改，但通常會在發生特定事件時向使用者發出警報。 Health Manager可以同時執行多個非侵入性政策，但一次隻能執行一個入侵政策。 這是因為同時執行多個侵入政策可能會導緻沖突操作，并且可能導緻系統不穩定。
正如我們将在第5節中讨論的那樣，Dhalion已經實施了各種政策。 但是，Dhalion的Health Manager通過定義政策API來支援一組可擴充的政策。 這允許使用者建立可由Health Manager訓示的新的侵入性和非侵入性政策。 圖1顯示了政策的各個階段。 如圖所示，政策評估包括我們在下面描述的三個主要階段：
Symptom Detection Phase：在此階段，Dhalion從Metrics Manager收集多個度量Metrics，并嘗試識别可能表示拓撲結構健康受損的症狀（如背壓，資料傾斜等）。症狀的識别是通過各種Symptom Detectors完成的，這些Symptom Detectors收集适當的Metrics并執行必要的Metrics評估。Symptom Detectors采用各種異常檢測技術，例如更早的檢測和資料點聚類等。一旦識别出症狀，Symptom Detectors就會生成一個症狀描述，該症狀是症狀的緊湊表示，以及用于識别此症狀的Metrics度量标準及其對應值。例如，一旦背壓檢測器檢測到背壓的存在，它就會産生一個症狀描述，指明拓撲結構中哪個Bolt引起背壓，以及與此Bolt相對應的Heron Instance暫停輸入資料的時間長短 - 灰。 Dhalion實作了各種症狀檢測器，但也提供了明确指定的API，以便使用者可以建立自己的症狀檢測器并将其合并到其政策中。
Diagnosis Generation Phase: 診斷生成階段收集症狀檢測階段産生的各種症狀，并嘗試确定這些症狀的根本原因。 這是通過各種診斷程式實作的，這些子產品旨在将一組症狀描述作為輸入，并在可能的情況下根據這些症狀進行診斷。 例如，正如我們稍後讨論的那樣，Resource Underprovisioning Diagnoser将背壓症狀描述作為輸入，并确定背壓的存在是否可歸因于拓撲的特定階段中的少量Heron執行個體（資源供應不足）。 類似地，Slow Instances Diagnoser診斷程式确定背壓的原因是否可能是一個或多個執行個體在特定拓撲階段比同類運作慢，因為一個或多個容器或機器可能很慢。
Diagnosis程式生成診斷描述，它簡潔地表示問題的根本原因以及導緻此特定診斷的症狀及其相應的Metrics值。 Dhalion中實施的目前診斷程式集做出了二進制決策，主要決定症狀是否可歸因于特定原因。 但是，使用者還可以建立診斷程式，為需要時生成的診斷配置設定置信度。 最後，類似于Symptom Detectors，Diagnosers有一個明确指定的API，允許使用者建立新的Diagnosers并将它們合并到他們的政策中。
Resolution Phase：The Resolution Phase是Dhalion政策的最後階段。其主要目标是通過采取必要的行動來解決診斷生成階段所确定的問題。此階段的基本建構塊是Resolver子產品。The Resolver将診斷描述作為輸入，并基于此，執行适當的操作以使Topology恢複到健康狀态。 Diagnosers和Resolvers之間通常有1-1的映射。例如，Scale Up Resolver可以通過增加與啟動背壓的拓撲階段相對應的Heron執行個體的數量來解決Resource Underprovisioning Diagnoser程式識别的問題。同樣，Restart Instances Resolver解析程式将Slow Instances Diagnose程式識别為慢的Heron Instance移動到新容器。在第5節中，我們将廣泛讨論這些元件的功能。與Symptom Detectors和Diagnosers類似，使用者可以靈活地使用适當的API将新的Resolvers合并到Dhalion。
The Resolution Phase包括兩個步驟。在第一步中，檢查Diagnosis Generation Phase産生的診斷，以确定必須調用的适當的Resolver。例如，如前所述，Backpressure的原因可歸因于各種原因，例如有限的并行性，慢執行個體或資料偏斜。根據各種診斷程式産生的診斷，此步驟将探索候選解析器并選擇更有可能解決背壓問題的解析器。請注意，根據特定政策，可以使用各種方法（例如基于規則或機器學習技術）執行Resolver選擇步驟。例如，給定一組診斷，可能總是選擇最有可能解決問題的解析器，或者可能決定偶爾探索解析器的空間并選擇一個替代空間。當使用者使用Dhalion API建立新政策時，它還必須實作将在此步驟中調用的政策的Resolver選擇方法。
在第二步中，将調用所選的Resolver并執行适當的拓撲更改。 請注意，主要的Topology更改（例如Scale-up和Scale-down資源或重新啟動容器）通常通過Heron Scheduler元件調用，是以如圖2所示，執行此類操作的Resolvers與Heron Scheduler通信。
除了可擴充性方面，值得注意的是Dhalion政策架構的一個主要優勢是其子產品化。 例如，我們不是建立通過評估所有症狀來生成診斷的單一診斷程式，而是決定建立多個獨立的診斷程式，每個診斷程式評估一組特定的症狀。 這種方法有兩個主要優點。 首先，它允許通過多種政策重用Diagnosers，因為更容易組合不同的Diagnosers來滿足特定政策的需求。 其次，它有助于調試和維護政策代碼，因為使用者可以輕松調試和調整特定的診斷程式，而無需了解源代碼的其他部分。 出于同樣的原因，政策體系結構和相應的API包含多個獨立的症狀檢測器和解析器。
4.2 Action Log
Action Log是一個日志，用于捕獲Health Manager在政策執行期間執行的操作。 該日志可用于調試和調整特定政策，以及向使用者或系統管理者報告有關政策操作的統計資訊。 正如我們在下一節中看到的，在評估政策的有效性時，Action Log也很有用。
日志中的每個條目都包含政策采取的操作類型。 例如，如果政策調用了Scale Up Resolver，則會向日志寫入“向上擴充”操作。 日志條目還記錄了采取行動的時間以及導緻此特定操作的診斷。 使用者可以通過配置日志清除操作來管理日志的大小。 更具體地說，他們可以選擇保留最近的n個日志條目，或者保留與最後幾個小時相對應的日志條目。
4.2 Action Blacklist
Dhalion保留了一份診斷描述和相應行動的黑名單，這些行動未産生預期的結果。在執行政策期間，對于類似的診斷，不會再次調用這些操作。特别是，在生成診斷并且政策采取相應的操作之後，Health Manager會等待一段時間以允許拓撲結構達到穩定狀态，然後通過從中擷取必要資訊來評估所采取的操作來自行動日志。定義新政策時，必須提供此特定政策的評估方法。例如，如果政策采取措施以嘗試最大化吞吐量，則政策的評估方法可以簡單地檢查操作是否導緻吞吐量增加。這可以通過将目前Topology狀态與在記錄檔條目的診斷描述中捕獲的先前狀态進行比較來實作，該記錄檔條目對應于政策采取的最後一個操作。
系統目前跟蹤特定動作對于給定診斷沒有益處的次數與由于診斷而被動作被調用的總次數的比率。當比率高于可配置門檻值時，診斷 - 動作對将被置于動作黑名單中。在政策的Resolution Phase，在調用所選的Resolver之前，Dhalion會自動檢查此操作是否已被列入黑名單以進行類似的診斷。如果操作已包含在操作黑名單中，則不會調用所選的Resovler程式。在這種情況下，使用者可以通過建立政策時定義的Resolver選擇方法來指定政策的行為。例如，使用者可能會決定調用另一個Resolver程式，或者等到運作狀況管理器再次執行該政策，可能是在新Topology狀态下執行。
最後，盡管Dhalion為Action Blacklist提供支援，但使用者可以靈活地決定是否要在執行其政策時啟用此機制。
5. DHALION USE CASES
如第4節所述，Dhalion是一個子產品化和可擴充的系統，允許使用者實施自己的政策以滿足他們的應用程式要求。 在本節中，我們介紹了Dhalion的兩個用例，并廣泛讨論了在Heron之上實施相應的Dhalion政策。 請注意，隻要采用基于Backpressure的控制速率機制，我們的政策也可以應用于其他流處理系統引擎。
5.1 Dynamic Resource Provisioning
流處理作業通常長時間運作，時間跨度為數周甚至數月。在應用程式的生命周期中，系統觀察到的資料負載會随着時間的推移而顯着變化。例如，由于預期和意外的全局事件，需要在Twitter資料中心處理的資料量可能會有很大差異。在這些事件期間，需要實時處理的Twitter數量激增。使用者和系統管理者通常過度配置配置設定給每個Topolgoy的資源，以便可以有效地處理工作負載峰值。然而，這種方法不是最理想的，因為它會顯着增加營運成本。理想情況下，資源應自動按比例放大和縮小，以有效處理負載變化，同時避免資源利用不足。出于這個原因，我們建立了一種侵入式Dhalion政策，即Dynamic Resource Provisioning Policy，它遵守系統行為并動态配置拓撲資源，以便最大化整體吞吐量，同時資源未得到充分利用。
Dynamic Resource Provisioning Policy的主要目标是根據需要擴充和縮小Topology資源，同時仍保持Topology處于未觀察到Bakpressure的穩定狀态。 這是因為Bakpressure的存在會導緻Spout停止發送資料，這反過來意味着吞吐量沒有最大化。 該政策使用各種Symptom Detectors和Diagnose診斷程式來确定Topology不穩定的原因是缺乏資源還是探索在不犧牲性能的情況下縮減資源的機會。 同樣，它使用各種Resolver來嘗試解決診斷出來的問題。 圖3顯示了政策階段的概述。 我們現在更詳細地讨論這些階段。
Symptom Detection Phase: 如圖所示，該政策采用三個症狀檢測器，即Pending Packets Detector，Backpressure Detector和Processing Rate Skew Detector。每次政策由Dhalion Health Manager提供時，症狀檢測器都會評估300秒間隔内的各種名額，并嘗試識别可能表示拓撲未處于健康狀态的症狀。待處理資料包檢測器集中在與每個Heron執行個體對應的Stream Manager隊列上。每個Stream Manager隊列臨時存儲等待相應Heron執行個體處理的資料包。此症狀檢測器檢查屬于同一個Spout的Heron執行個體隊列中的待處理資料包的數量，并訓示這些Heron執行個體是否具有相似的隊列大小或是否觀察到異常值。正如我們稍後讨論的那樣，隊列大小可以提供有關潛在系統瓶頸的見解。背壓檢測器通過評估适當的Stream Manager名額來檢查Topology是否經曆背壓。如果觀察到背壓，則背壓檢測器會生成症狀描述，其中包含作為背壓Source的特定Bolt以及在300秒測量期間輸入資料消耗暫停的時間量。如前所述，背壓的存在表明系統無法實作最大吞吐量。最後，Processing Rate Skew Detector檢查每個Heron Instance在測量期間處理的樣本數（處理速率）。然後，它确定在每個拓撲階段是否觀察到處理速率的偏差。
Diagnosis Generation Phase: 然後将症狀檢測器生成的症狀描述轉發給一組診斷程式，如圖3所示。當輸入資料負載減少時，資源過度配置診斷程式通常很有用，其主要目标是在拓撲處于健康狀态時識别縮小資源的機會。Diagnoser将Pending Packets Detector和BackPressure Detector生成的症狀描述視為輸入，并檢查拓撲是否過度配置了資源。更具體地說，資源過度配置診斷程式首先檢查拓撲中是否存在背壓。在這種情況下，它不會産生診斷，因為拓撲結構不處于健康狀态，這将允許識别撤銷資源的機會。如果未觀察到背壓，則資源過度配置診斷程式将根據待處理資料包檢測程式生成的症狀描述檢查拓撲的Heron執行個體的平均待處理資料包數。如果Bolt的每個Heron執行個體的待處理資料包的平均數幾乎為零，那麼配置設定給該Bolt的資源可能過度配置，是以撤銷某些資源可能不會對總體吞吐量産生負面影響。資源過度配置診斷程式檢查拓撲的所有Bolt，并生成診斷描述，描述哪些Bolt可能過度配置。該描述還包含有關其相應Heron執行個體的待處理資料包數量的剩餘Bolt狀态的資訊。
當輸入負載增加（工作負載峰值）時，Topology可能會遇到背壓，因為Heron執行個體可能會過載，是以必須配置更多資源以容納更多的Heron執行個體。然而，背壓的存在可能不一定歸因于資源不足。如第3節所述，工作負載中的慢速執行個體或資料偏差也可能導緻反向壓力。是以，仔細檢查背壓的根本原因至關重要，因為這有助于避免不必要的額外資源配置設定。其餘三個診斷程式在遇到背壓的拓撲上運作，并嘗試确定背壓的原因。正如他們的名字所表示的那樣，Resource Underprovisioning Diagnoser診斷程式檢查背壓是否可歸因于作為背壓源頭的Bolt的欠配置資源。Slow Instances Diagnoser診斷程式檢查一個或多個啟動背壓的Bolt的執行個體是否比同類運作慢。在這種情況下，Slow Instances執行個體可能是背壓的原因。最後，Data Skew Diagnoser檢查一個或多個Heron Instance是否因為資料偏差而接收的資料多于同類，是以它們會過載。請注意，資料偏斜或慢速執行個體的影響可能不足以啟用Heron的背壓機制，是以不會對總體吞吐量産生負面影響。我們的診斷程式無法診斷此類情況，因為它們僅在未處于健康狀态的拓撲上運作。
三個診斷程式在生成診斷時會考慮背壓檢測器BackPressure Detector，待處理資料包檢測器Pending Packets Detector和處理速率傾斜檢測器Data Skew Diagnoser産生的症狀描述。診斷程式首先檢查是否存在背壓。如果沒有觀察到背壓，則它們不會産生診斷。否則，他們首先檢查哪個Bolt啟動了背壓。然後，他們收集有關此Bolt的Heron執行個體的處理速率的資訊以及它們的相應平均未發送資料包的數量。 讓H對應于Bolt的Heron Instances集合。然後，對于每個Heron Instancehi∈H，讓ri，pi分别為其對應的處理速率和待處理分組的平均數。另外，讓B成為在測量間隔（B⊂H）期間暫停資料消耗的Heron執行個體的子集。表1描述了必須符合的條件，以便相應的診斷程式産生相應的診斷。
如表中所示，當Bolt的所有Heron執行個體具有相似的處理速率且其相應的隊列具有相似的大小時，資源欠配置診斷程式Resource Underprovisioning Diagnoser确定觀察到的症狀是由于配置設定給所考慮的Bolt的有限資源。這是因為在瓶頸是特定Topology階段的有限數量的Heron執行個體的情況下，此階段的所有Heron執行個體都将過載，是以它們将表現出類似的行為。慢執行個體診斷程式Slow Instances Diagnoser确定背壓的原因是當啟動反向壓力的Heron執行個體在以類似處理速率運作時具有比其對等其他執行個體更多的待處理資料包時，背壓的原因是存在慢速執行個體。直覺上，可以預期慢速執行個體的處理速率低于同類Heron Instance執行個體。但是，由于慢速執行個體啟動背壓，其餘執行個體以慢速執行個體的速度運作而未達到其最大容量。最後，當啟動背壓的Heron執行個體具有比同類更高的處理速率和更多的待處理資料包時，Data Skew Diagnoser将背壓的存在歸因于資料傾斜。在資料傾斜的情況下，一些Dhalion執行個體接收的資料多于同行。如果這些執行個體沒有處理輸入負載所需的處理能力，則其對應的待處理資料包的數量将高于其對等資料包的數量。此外，如果他們的同伴沒有收到足夠的資料來滿負荷運作，那麼這些Dhalion執行個體的處理速度将高于同行，因為他們在同一時間間隔内處理更多資料。
值得注意的是，隻要我們能夠準确地檢測異常值，上述技術就可以正确地對背壓相關問題進行分類。異常值檢測方法通常基于某個門檻值對資料進行分類。是以，如果未正确設定門檻值，則可能會産生錯誤的診斷。例如，當Heron Instance比同類稍慢時，異常值檢測方法可能無法檢測到問題。在這種情況下，慢執行個體診斷程式不會産生診斷，但資源不足的診斷程式将生成一個診斷。我們的政策能夠通過使用動作黑名單和适當的Resolver選擇方法來解決此類情況，我們将在後面讨論。最後，我們想指出的是，表1中列出的三個條件中隻有一個一次是真的，是以，隻有一個診斷程式會産生診斷。正如我們稍後讨論的那樣，這種觀察簡化了解析器選擇方法。
Resolution Phase: 在此階段，将檢查前一階段生成的診斷，以确定要調用的Resolver。該政策雇用了四個解決方案。 Bolt Scale Down Resolver通過減少與Bolt相對應的Heron執行個體的數量來縮減特定Bolt的資源。當Resource Overprovisioning Diagnoser生成診斷時，将調用此Resolver程式。請注意，如果此Diagnoser生成診斷，則保證其餘診斷程式不會生成診斷程式。這是因為資源過度配置診斷程式在健康的拓撲上運作，而其餘的則解決與背壓相關的問題。自動計算縮小因子是一個挑戰，因為我們無法預測拓撲的行為，因為資源被撤銷。是以，在我們目前的實作中，縮小因子是可配置的。然而請注意，如果縮小操作導緻觀察到背壓的狀态，則操作将被列入黑名單，并且政策随後将調用向上擴充操作以使拓撲恢複到健康狀态。
重新開機執行個體解決器Restart Instances Resolver，資料傾斜解決器Data Skew Resolver和Bolt擴充解決器Bolt Scale Up Resolver分别解決由慢執行個體診斷程式Slow Instances Diagnoser，資料傾斜診斷程式Data Skew Diagnoser和資源欠配置診斷程式Resource Overprovisioning Diagnoser生成的診斷。更具體地說，Restart Instances Resolver将慢速Heron執行個體移動到新容器，而Data Skew Resolver調整用于将資料配置設定給Bolt的散列函數。我們現在更詳細地解釋Bolt Scale Up Resolver，因為它通常在觀察到工作負載峰值時被調用。該Resovler負責通過自動增加屬于該Bolt的Heron執行個體的數量來擴大引發背壓的Bolt的資源。為了确定放大系數，解析器計算Heron執行個體在未觀察到背壓的時間内暫停輸入資料所花費的總時間的百分比。這個百分比基本上表示Heron Instances無法處理的輸入負載部分。例如，如果20％的時間資料消耗暫停，而80％的時間資料流正常，那麼Heron Instances無法處理1/4的輸入負載，是以增加了25％并行性是必需的。在确定了放大因子後，Resolver會調用相應的Heron API來相應地擴充拓撲資源。
值得注意的是，由于表1中隻有一個條件始終為真，是以每次觀察到背壓時，隻有一個診斷器會産生診斷。 是以，這種政策的Resolver選擇方法很簡單，因為隻有一個Resolver可以解決Backpressure問題。 請注意，如果為特定診斷将所選的Resolver列入黑名單，則Resolver選擇方法将随機選擇剩餘的兩個解析器中的一個。
5.2 Satisfying Throughput SLOs
我們觀察到，在大量流處理應用程式中，使用者花費大量時間調整Topology以滿足高于特定門檻值的吞吐量的要求。 這是因為要麼他們不知道以所需速率擷取資料所需的Spout數量，要麼他們手動重新調整螺栓的平行度以減輕背壓。 在本節中，我們将介紹解決此問題的Throughput SLO Policy。 更具體地說，想要部署拓撲的使用者可以使用此政策在spout和bolt級别自動配置Heron Instances的數量，以便滿足他們的特定吞吐量SLO.
Throughput SLO Policy将Throughput SLO作為輸入，該吞吐量SLO表示Spout應發送資料的總速率。 例如，使用者可能希望處理300萬元/分鐘的輸入負載。 該政策一直跟蹤Topology運作時觀察到的實際吞吐量，并自動調整Spout或Bolt的并行度，以滿足吞吐量SLO。 此政策可以顯着減少使用者調整Topology所花費的時間; 使用者可以簡單地送出包含由單個Heron執行個體（并行性= 1）組成的spout和bolt的拓撲，并讓政策調整各種拓撲階段的并行性，以便滿足性能目标。
Throughput SLO Policy重用動态資源調配政策的元件，因為它可能會擴充配置設定給拓撲Bolt的資源。除了這些元件之外，吞吐量SLO政策還使用了附加的症狀檢測器，診斷程式和解析程式。更具體地說，發射計數檢測器Emit Count Detector計算噴口發出資料的總速率，并将其轉發到Throughput SLO Violation Diagnoser程式。 Diagnoser首先檢查拓撲是否處于健康狀态。如果觀察到背壓，則診斷程式不會産生診斷。否則，它會檢查目前吞吐量是否滿足使用者的性能要求。如果違反了使用者的SLO，則診斷程式會生成一個診斷描述，該描述将轉發到Spout Scale Up Resolver，進而增加Spout執行個體的Spout數量。為了确定放大系數，Resolver将使用者的吞吐量要求除以目前觀察到的吞吐量。
如果政策增加了Spout并行性，則拓撲可能會由于輸入負載的增加而導緻背壓措施。 在這種情況下，Throughput SLO Policy使用動态資源調配政策使用的元件來自動調整配置設定給Bolt的資源，以使拓撲恢複到健康狀态。 在第6節中，我們實驗性地評估了吞吐量SLO政策。
6. EXPERIMENTAL EVALUATION
在本節中，我們将評估Dhalion政策并提供實驗結果分析。 我們首先評估動态資源配置政策，然後評估吞吐量SLO政策。 我們的主要成果如下：
- Dhalion适用于背壓從一級傳播到另一級的多級拓撲（見圖5,7,9,10）。
- 當負載變化發生時，系統能夠動态調整資源，同時仍然達到最大化吞吐量的穩定狀态（參見第6.2節）。
- 即使在使用者沒有花時間調整拓撲的情況下，系統也能夠自動重新配置拓撲以滿足使用者指定的吞吐量SLO（參見第6.3節）
- Dhalion的行為不受噪音和瞬态變化的影響（見第6.2節）。
- 即使出現多個問題，Dhalion也可以使拓撲結構處于健康狀态（參見第6.5節）。
- 在以下部分中，我們将描述我們的實驗設定并進一步分析我們的發現。
6.1 Experimental Setup
Hardware and Software Configuration：我們所有的實驗都是在D4類型的Azure執行個體上的Microsoft HDInsight [8]上進行的。 每個D4執行個體都有一個8核Intel Xeon E5-2673 [email protected]和28GB的RAM，并運作Ubuntu版本16.04.2。 在我們的所有實驗中，我們在YARN 2.7.3版本之上使用Heron版本0.14.5。
Heron Topology: 之前關于流處理系統的工作[22,26]使用了一個2階段字數統計拓撲來評估系統。 在我們的工作中，我們決定使用3級字數統計拓撲，該拓撲在句子級别操作而不是單個字段作為相應的2級拓撲。 通過這種方式，我們可以證明我們的Dhalion政策可以處理背壓從一個階段傳播到另一個階段的拓撲。 在我們的拓撲結構中，spout通過随機選擇一組450K英語單詞中的單詞并發出它來生成一個200個字元長的句子。 Spout以循環方式将句子配置設定到屬于拓撲的第二級Bolt（Splitter Bolt）。 Splitter Bolt将句子分成單詞，然後使用散列分區轉發到第3級Bolt（Counter Bolt）。 最後，Counter Bolt計算每個單詞遇到的次數。
Evaluation Metrics: 在我們的實驗中，我們經常将吞吐量用作評估名額。 我們注意到，噴口的吞吐量定義為噴口在一分鐘内發出的元組數。 螺栓的吞吐量定義為螺栓在一分鐘内處理的元組數。 為了跟蹤資源配置設定，我們提供了在每個拓撲階段配置的Heron執行個體的數量。
6.2 Dynamic Resource Provisioning
在本實驗中，我們分析了動态資源配置政策的行為。 我們首先使用40個Spout，11個Splitter Bolt和11個Counter Bolt部署字數統計拓撲。 在這種狀态下，拓撲結構不會出現背壓。 我們将這個初始狀态稱為S1。 然後，我們通過手動減少Spout數量來減少輸入負載20％，并觀察政策是否調用适當的縮小操作。 一段時間後，我們将輸入負載增加30％并再次觀察政策的行為。 請注意，我們有意避免引入顯着的負載變化，以證明我們的Dhalion政策能夠識别較小的負載變化并相應地調整資源。 每2分鐘調用一次政策并監視拓撲狀态。 當政策執行操作時，Health Manager會等待幾分鐘以使拓撲穩定，然後再次調用政策。
圖5顯示了在實驗執行期間每個拓撲階段的标準化吞吐量; 繪制的數字歸一化為拓撲處于狀态S1時觀察到的相應吞吐量。 圖6顯示了在實驗執行期間屬于Splitter和CounterBolt的相應Heron執行個體數。
在前10分鐘，拓撲處于穩定狀态S1。然後，我們通過将Spout數設定為32來手動減少輸入負載。此時，由于Heron在發生并行性更改時停止處理新資料，是以吞吐量暫時變為零。更改完成後，吞吐量恢複到正常水準。請注意，并行度降低後觀察到的吞吐量低于狀态S1，因為Spout發出的元組數量較少。此時，政策成功檢測到存在縮減資源的機會。特别是，它首先檢測到計數器螺栓的Heron執行個體的待處理資料包的數量幾乎為零，是以，它在第14分鐘調用Scale Down Resolver。如圖6所示，Resolver删除了兩個Heron Counter Bolt使執行個體數減少到9.請注意，在此更改之後，觀察到的吞吐量與之前相同。這清楚地表明該政策是成功的，因為它在不犧牲性能的情況下減少了整體資源。另請注意，Dhalion正确地決定縮減資源，盡管幾分鐘之前吞吐量急劇下降。這表明Dhalion不受瞬态變化或噪聲資料的影響。
執行縮小操作後，Health Manager會在再次調用政策之前等待一段時間。 在第23分鐘，調用政策并檢測到有可能縮小配置設定給Splitter Bolt的資源。 然後删除兩個Heron Instances，将執行個體數降低到9.如圖所示，吞吐量仍然保持在相同的水準，表明政策正确地調整了并行性。 在此更改之後，政策未檢測到縮小的其他機會，是以拓撲在穩定狀态S2下操作。 在這種狀态下，Splitter和Counter螺栓都包含9個Heron執行個體。
在第40分鐘，我們手動将Spout數量增加到45，進而增加了資料負載。如圖5所示，在并行度改變之後，Spout的吞吐量與Bolt的吞吐量之間存在間隙。這是因為流管理器隊列中包含待處理的資料包在Splitter螺栓處繼續累積資料包。隊列大小持續增加約5分鐘，直到達到門檻值并調用背壓。在第46分鐘，政策檢測到背壓，确定Splitter Bolt是瓶頸，并将其并行度增加1.在此更改後，拓撲結構不會出現背壓，并且Splitter Bolt的吞吐量會增加。現在Counter Bolt經曆了更高的負載，其相應的隊列開始累積更多的資料包。在第53分鐘，Counter Bolt啟動背壓。該政策檢測背壓并将其歸因于拓撲結構的最後階段有限數量的Heron執行個體。是以，它通過将并行度從9增加到14來擴充配置設定給Counter bolt的資源。拓撲在實作穩定狀态（S3）之前需要再進行兩輪縮放。更具體地說，Splitter Bolt在65分鐘和93分鐘時啟動背壓。在兩種情況下，政策都正确地将Bolt的平行度增加1，進而将為此Bolt提供的Heron執行個體的總數增加到12.在狀态S3，Splitter和Counter Bolt分别由12和14個Dhalion執行個體組成。
正如我們在第5節中提到的，該政策僅在觀察到背壓時才擴充資源。 如本實驗所示，除非至少一個Stream Manager隊列的大小超過門檻值，否則不會啟動反壓。 但是，填寫隊列的過程可能需要一些時間，在此期間我們的政策不會啟動任何擴充操作。 這在長時間運作的流處理應用程式的環境中通常是可接受的，特别是在初始配置階段，在部署生産數周甚至數月之前，拓撲被廣泛調整。 但是，作為未來工作的一部分，我們計劃通過考慮平均隊列大小變化的速率來進一步改進我們的算法。 通過這種方式，政策的反應時間可以進一步最小化。
我們的實驗表明，動态資源配置政策能夠在工作負載峰值發生時即時調整拓撲資源。 此外，該政策最終能夠達到健康狀态，其中未觀察到背壓并且總體吞吐量最大化。 最後，即使在背壓逐漸從拓撲的一個階段傳播到另一個階段的多階段拓撲中，該政策也可以正确地檢測和解決瓶頸。
6.3 Satisfying Throughput SLOs
在本實驗中，我們使用字數統計拓撲來評估吞吐量SLO政策。 我們評估使用者在部署拓撲之前不調整拓撲并行性的情況，而是提供吞吐量SLO并期望政策自動配置拓撲。 最初送出的拓撲結構是為Spout和每個Bolt配置的單個Heron執行個體（并行度= 1）。 作為政策配置的一部分，使用者指定拓撲在穩定狀态下應至少處理400萬個元組/分鐘。
圖7顯示了Spout和Bolt的吞吐量如何随時間調整。 SLO是根據Spout發出的元組數量定義的，是以一旦藍線達到所需級别且系統處于穩定狀态，吞吐量SLO政策将不再進行任何進一步調整。 請注意，Counter Bolt的吞吐量遠遠高于Splitter Bolt的吞吐量，因為後者在上面操作，而前者在這些句子中包含的單詞之上，是以，它接收更多的元組數量。 是以，Countter的吞吐量分别繪制在右側y軸上。 圖8顯示了實驗期間每個拓撲階段的相應Heron執行個體數。
如圖7所示，政策應用多個操作，直到spout的吞吐量達到所需級别。更具體地說，該政策增加了4次Spout數量。它還增加了Counter Bolt和Splitter Bolt的數量，分别增加了4倍和3倍。在實驗開始時，政策觀察到實際吞吐量遠低于期望的吞吐量，是以它決定将Spout數量增加到4.請注意，我們已配置政策以擴大噴口數量為了将負載變化逐漸傳播到拓撲的後期階段，每次最多為4倍。在增加Spout數量後，系統經曆了由Counter Bolt啟動的背壓，是以政策為此Bolt配置設定了一個額外的Heron執行個體。此時，拓撲處于健康狀态，但尚未達到所需的吞吐量。政策檢測到問題，并在第16分鐘再次将Spout數量增加到16.在平行度改變後，背壓在Splitter Bolt和Counter Bolt之間傳播，導緻從第22分鐘到第46分鐘的四次放大操作。圖8示出了在該時間間隔期間每個螺栓的Heron執行個體的數量。從第51分鐘到第71分鐘，該政策調用了另外兩個Spout擴大操作，并通過擴大啟動它的Bolt來處理背壓的存在。當觀察到的吞吐量等于或高于吞吐量SLO并且未觀察到背壓時，拓撲結構達到穩定狀态。在穩定狀态下，觀測到的吞吐量約為4.3百萬元/分鐘，拓撲由43個噴口，11個Splitter Bolt和11個Counter Bolt組成。
我們的實驗表明，吞吐量SLO政策可以成功地自動調整拓撲，進而滿足吞吐量SLO。
6.4 Evaluating the Diagnosers
之前的實驗證明了Resource Overprovisioning Diagnoser和Resource Underprovisioning Diagnoser在檢測擴充和縮小資源的機會方面的有效性。在本實驗中，我們評估了Slow Instances Diagnoser和Data Skew Diagnoser的有效性。更具體地說，我們綜合生成Word Count拓撲，這些拓撲要麼表現出資料偏差，要麼包含比其同伴慢的Heron執行個體。然後，我們評估Dhalion的動态資源供應政策的診斷程式是否能夠正确診斷背壓的原因。
為了生成具有慢速Heron執行個體的拓撲，我們改變了Splitter螺栓的一個執行個體的平均元組處理延遲，使其執行速度比同類慢。通過引入适當的睡眠操作來實作這種減速。是以，X％較慢的執行個體的峰值處理速率比其對等點低X％。為了生成具有資料傾斜的拓撲，所有的spout執行個體都被配置為增加發出的句子中特定單詞的頻率。為了合成地建立具有X％資料傾斜的拓撲，在用于形成句子的100個單詞的集合中出現X次X次。
表2列出了我們的結果。 對于所檢查的每個方案，該表的第二列顯示了啟動背壓的Dhalion執行個體的平均處理速率與剩餘Dhalion執行個體的平均處理速率之比。 如第5.1節所述，當此比率接近1時，診斷程式會産生慢速診斷。如果該比率大于1，則會産生資料偏斜診斷。 該表還包含有關由于背壓而導緻的懸浮輸入資料所花費的時間百分比的資訊。
如表中所示，慢執行個體診斷程式對具有緩慢執行個體的拓撲結構進行了成功診斷，即使執行個體僅比同類執行個體慢25％。請注意，在這些情景中觀察到的處理率比率為1，如預期的那樣。另一個有趣的觀察是背壓百分比随着執行個體變慢而增加。這種行為是預期的，因為Heron Instance越慢，它将暫停輸入資料消耗的時間越長。
除一種情況外，Data Skew Diagnoser在所有情況下都能成功診斷出來。如表中所示，觀察到的加工速率比大于1。但是，當資料偏差較小（5％）時，Diagnoser不會認為處理速率的變化足以證明資料偏斜診斷的合理性，是以慢速執行個體診斷程式會産生慢速執行個體診斷。但是，由于Dhalion采用黑名單機制，即使在這種情況下也能最終産生正确的診斷。
7. RELATEDWORK
關于流資料處理的初步工作大約在十年前開始，當時開發了STREAM [20]，Aurora [13]和Borealis [11]等流媒體引擎。 在過去幾年中，對可擴充流媒體的需求變得更加突出，因為許多業務營運依賴于實時分析。 已經建立了幾個系統[2,4,5,9,10,12,22,26]，其中許多系統，如Heron [22]，Storm [26]，Samza [4]，Spark Streaming [10]和 Flink [2]已經開源了。 這些系統大規模運作，可以容忍各種硬體和軟體故障。
然而，盡管多年來取得了重大進展，但現有的流處理系統都沒有真正的自我調節。 Dhalion通過在流處理引擎之上運作并為其提供自我調節功能來解決此問題。 請注意，盡管Dhalion已經在Heron之上實作，但是其架構和基本政策抽象可以被其他流引擎采用，隻要它們提供Metrics收集API并且可能是擴充API。
Dhalion提供了必要的抽象，以解決由于多個硬體級别（如CPU和網絡I / O）或軟體提供服務品質下降而導緻的性能差異問題[15,16,25]。 本文介紹的政策會自動調整拓撲配置，以便即使在存在慢速機器/容器的情況下也能滿足性能目标。
與我們的動态資源配置政策類似，之前已經提出了用于流應用程式的自動縮放技術[18,19]。然而，這些方法不能直接應用于采用背壓機制來執行速率控制的系統。在這種情況下，必須檢查背壓的存在是否可歸因于資源不足或其他因素。據我們所知，現有的開源流處理系統都沒有根據輸入負載執行自動縮放。 [24]中的工作提出了一種自适應負載管理器，它根據觀察到的響應時間執行減載。 Dhalion政策可以潛在地結合這種減載技術，以避免系統過載。
過去，人們對資料庫和Map Reduce系統的自我調整技術進行了廣泛的研究[14,21]。最近的工作提出了自動駕駛關系資料庫系統，可以預測未來的工作量并主動調整資料庫的實體設計[23]。這些工作主要集中在系統的自我調整方面，不讨論建立自穩定和自我的機制。治療系統。此外，這些研究中提出的技術不能直接應用于流系統，因為它們針對不同的應用場景。
8. CONCLUSIONS AND FUTUREWORK
在本文中，我們介紹了自調節流媒體系統的概念。然後，我們介紹Dhalion，這是一個子產品化和可擴充的系統，部署在流媒體系統之上，并通過執行各種Dhalion政策為其提供自我調節功能。 Dhalion為使用者提供必要的抽象，以實作他們自己的政策并将其合并到他們的流應用程式中。我們提出了一種Dhalion政策，可以根據輸入資料負載自動擴充和縮小資源，并通過配置必要的資源來自動調整拓撲，以滿足吞吐量SLO。這兩項政策都已在Heron之上實施和評估。
作為未來工作的一部分，我們計劃通過整合更多滿足各種應用程式要求的政策（例如實施延遲SLO的政策）來擴充Dhalion的功能。我們還計劃調查Dhalion的決策制定過程是否可以使用機器學習模型進一步自動化。最後，未來工作的一個有趣方向是評估Dhalion對其他類别的大資料引擎的适用性，例如批處理和機器學習系統。