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 CPU@2.40GHz和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对其他类别的大数据引擎的适用性，例如批处理和机器学习系统。
1194
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
