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對其他類別的大數據引擎的適用性，例如批處理和機器學習系統。