Abstract
在数据流管理系统（DSMS）中，用户注册连续查询，并在数据到达和到期时接收结果更新。 我们专注于具有实时约束的应用程序，其中用户必须在更新发生后的给定时间段内接收每个结果更新。 为了处理快速数据，DSMS通常位于云基础架构之上。 由于实时流速到达等流属性可能无法预测地波动，因此必须动态配置和调度云资源以确保实时响应。 对于现有系统或未来发展而言，必须具备根据当前工作负载动态调度资源的能力，以避免浪费资源，或者无法按时提供正确的结果。
受此启发，我们提出了一种新颖的动态资源DRS基于云的DSMS的调度程序。DRS克服了三个基础心理挑战：（a）如何建模之间的关系配置资源和查询响应时间（b）在哪里最好地放置资源; （c）如何测量系统负荷最小的开销。特别是，DRS包括准确的基于Jackson开放排队理论的绩效模型网络，能够处理任意operator拓扑，可能有循环，拆分和连接。广泛的实验实际数据证实DRS能够近距离实现实时响应最佳的资源消耗。
1. Introduction
在许多应用中，例如微博，视频输入和传感器读数的分析，数据记录不是预先可用的，而是以流的形式逐渐地和连续地到达。 数据流管理系统（DSMS）处理此类流，并向用户回答长时间连续的查询。 这种查询的结果以更新流的形式提供。 通常，用户对实时执行流分析感兴趣，这意味着每个结果更新必须在更新发生之后的给定时间段内到达用户，即，可以产生它的最早可能时间。 例如，考虑DSMS监控医院病房中的监控视频流。 应及时发现患者跌倒等事件，及时向医生和护士报警。
为了处理快速，高容量的流和严格的实时响应要求，将DSMS放在云基础架构之上越来越普遍，云基础架构可根据需要提供几乎无限的计算资源。 由于数据流的关键属性（包括其数量，到达率，价值分布等）可能以不可预测的方式波动，因此DSMS应理想地为每个应用程序动态配置云资源，以满足实时约束。 最低资源消耗。 同时，在应用程序内部，需要将资源精心安排到不同的组件以确保最佳利用率。 错放资源可能不仅导致资源利用率低，而且整个系统也不稳定。
图1示出了具有两个运算符A（其从输入视频帧中提取特征）和B（其从提取的特征中识别对象）的示例视频流处理应用，其中A的输出被馈送到B作为输入。 A和B的记录到达率分别为λA和λB，其中λA取决于输入，例如，每秒24帧，而λB取决于A的输出速率，即，提取的特征的数量。单位时间。在每个运算符内部，首先将输入缓冲到输入队列（即A中的q A和B中的q B），然后由其中一个并行处理器（A 1，...，A，A，B 1）处理，...，B）B）。假设云提供相同的处理单元，A中的每个处理器（分别在B中）可以在单位时间内处理μA（μB）输入。显然，Operator必须拥有足够的处理器来跟上其输入速率;否则，输入开始填充其输入队列，导致等待时延迟增加，最终导致队列达到其大小限制时出现错误。由于每个处理器的数据到达率和处理速率是不可控制的，因此主要资源调度问题是确定每个运算符中的处理器数量，在我们的示例中为n和m。
调度资源的一种简单方法是监视每个Operator的工作负载，并相应地调整处理器数量。这种方法在多Operator应用中是不够的。例如，考虑在某些时候，许多可识别的对象出现在视频流中的情况。然后，尽管输入中每秒的帧数（即λA）保持稳定，但每帧现在包含更多可提取的特征，需要在运算符A处进行更多的工作。因此，μA减小，从而使运算符A超载，从而导致输入在队列中等待更长时间q A，减慢查询响应速度。现在，如果我们天真地将处理器添加到A以冲洗q A，则Operator A然后突然产生大量输出，导致运算符B的输入速率λB突然，使后者过载。当应用程序涉及复杂的运营商网络时，这个问题会更加严重。图2显示了这样一个例子，其中包括分裂（A到B，C），连接（C，D到E）和反馈环（E到A）。这些Topology特征是某些应用程序的关键特征，例如，循环允许基于当前查询结果在输入处减少数据，如我们在第V节中的示例所示。
正如我们在第II节中所述，现有系统在很大程度上忽略了动态资源调度的问题。 因此，为了满足实时约束，它们要么需要在运行时手动调整（这对于动态流是不可行的），过度配置每个操作员的资源（浪费资源），要么减载（导致不正确的结果）。 受此启发，我们设计并实现了DRS，一种动态资源调度模块。 DRS通常适用于基于Operator的DSMS，并允许Operator形成任意拓扑，可能具有分裂，连接和循环，如图2所示。特别是，对循环的支持可以是某些应用的关键推动因素，尤其是那些涉及迭代，正如我们在第五节中的示例所示。同时，从语义的角度来看，允许任意拓扑比Muppet [1]中的两步MapUpdate和TimeStream [2]中的DAG模型更通用。
我们的主要贡献包括有效和高效地解决动态资源调度中的三个基本问题：（a）需要多少资源，（b）最佳放置分配资源以最小化响应时间，以及（c）如何实施资源调度 在实际系统中，开销最小。 特别是，我们对前两个问题的解决方案基于扩展的Jackson网络理论，该网络提供了对系统性能的有根据的估计。
本文的其余部分安排如下。 第二节调查相关工作。 第三节介绍了我们的性能模型和优化算法。 第IV节描述了DRS的实现。 第五部分包含一系列实际数据的实验。 第六节总结了未来工作的方向。
2. RELATED WORK
请注意，Dhalion产生的诊断可能是错误的，因此执行的错误操作最终不会解决问题。例如，Dhalion可能会认为背压是由于分配给某个阶段任务的资源有限造成的，而实际上是由于任务缓慢造成的。例如，当任务没有比同行慢得多时，就会发生这种情况，因此Dhalion没有将其归类为异常值。在这种情况下，系统将错误地扩展拓扑资源。因此，在执行每个操作后，Dhalion会评估操作是否能够解决问题或使系统进入更健康的状态。如果一个动作没有产生预期的结果，那么它被列入黑名单并且不会再次重复。这种机制非常强大，因为它允许系统避免重复错误的动作。在没有黑名单机制的情况下，系统可能会陷入不健康的境地，并陷入反复调用无效（甚至可能适得其反）行动的陷阱。
A. Resource Scheduling in Cloud Systems
云由大量互连的商用服务器组成。 云的一个关键特性是可以根据需要为应用程序配置其CPU核心，内存，磁盘空间和网络带宽等资源。 事实上，如今大多数云基础设施提供商都提供资源使用的即用即付选项。 因此，系统有效使用云的基本要求是弹性，这意味着系统必须能够根据当前工作负载动态分配和释放云资源。 然而，许多传统的并行和分布式系统预先假定可用的固定资源量，使得它们不适合在云平台中应用。 因此，在过去十年中出现了许多新颖的基于弹性云的范例和系统。
第一波基于云的系统是为离线运行一批（通常很慢）的作业而构建的。 值得注意的是，MapReduce [3]是一个批处理框架，它隐藏了云基础架构的复杂性，并为用户提供了一个简单的编程接口，包括两个功能：map（例如，用于数据过滤和转换）和reduce（用于聚合和连接））。 近年来已经提出了大量的MapReduce系统，改进，技术和优化，我们将读者引用到全面的调查[4]。
资源调度一直是Map-Reduce系统中的核心问题，并且已经开发并在生产中使用了大量的调度程序，例如Fair Scheduler [5]，Capacity Schedular [6]。 由于在没有相关数据的节点上运行的任务会导致代价高昂的网络传输，因此延迟调度[7]通过强制节点等待直到本地任务出现或者指定的时间段已经过去来减少这种非本地任务。 但是，这些调度策略不适用于我们的问题，因为它们设计用于（半）静态数据的离线批处理，其目标是最小化总作业完成时间; 相反，我们专注于流数据的实时处理，其中每个单独的结果更新必须按时交付。
最近，很多注意力转移到大数据分析的实时交互系统，如Dremel [8]，Impala，Presto [9]，OceanRT [10]，[11]，C-Cube [12]，SADA [ 13]和更新版本的Hive [14]。 这样的系统处理静态数据而不是流数据; 同时，这里的术语“实时”具有不同的含义：每个查询都足够快地执行，以便用户可以在线等待其结果。 因此，这些系统中的资源调度类似于离线系统，并且由于类似的原因，它们的技术不适用于我们的问题。 基于云的系统研究中最近的另一个热门话题是基于云的流处理，这与此工作最相关。 我们在第II-C节中对它们进行了审查。
最后，存在用于供应竞争云资源的多个应用的通用调度解决方案。 诸如Mesos [15]，YARN [16]等系统就是一个突出的例子。 Abacus [17]通过揭露真相的拍卖来分配资源，从而优化了总效用。 这些方法通常假设应用程序已经知道它需要的资源量，以及如何在内部分配这些资源，这是本文解决的问题。 因此，它们可以与提出的解决方案结合使用。
B. Traditional DSMSs(数据流管理系统)
流处理一直是学术界和工业界的重要研究课题。 早期的工作主要集中在集中设置中的DSMS，类似于传统的集中式数据库管理系统。 例如，STREAM [18]为流上的查询建立了形式语义[19]，并提出了有效的查询处理算法，例如[20]。 类似的系统包括Aurora [21]，Gigascope [22]，TelegraphCQ [23]和System S [24]。 在这种集中式系统中进行调度意味着决定操作员执行的最佳顺序（通过中央处理器），例如，以便最小化存储器消耗[25]。 因此，[25]这些系统中的调度策略不适用于我们的基于云的设置，其中运营商由多个节点并行执行，并且计算资源是按需动态配置的。
同样，为传统并行设置而构建的DSMS，特别是Borealis [26]，也与基于云的DSMS不同，前者假设预先提供固定数量的计算资源，而不是动态分配。 因此，据我们所知，沿着这一研究线的调度技术并不适用于我们的问题。 接下来，我们将回顾基于云的DSMS。
C. Cloud-Based Stream Processing
在云中处理流有两种通用方法：使用基于Operator的DSMS，并将流输入离散化为小批量[27]。 前者源自第II-B节中描述的传统DSMS，而后者则将流处理减少为批量执行，如第II-A节所述。 通常，小批次流处理系统针对吞吐量进行了优化，代价是增加了查询响应时间，因为每个输入必须等到形成完整批次。 尽管通过极小的批次可以最大限度地减少这种额外的延迟，但这样做会导致高开销，从而无法实现目的。 我们专注于基于Operator的DSMS，因为我们的目标应用程序具有实时约束，其中响应时间是关键。
两个流行的基于开源操作符的DSMS是Storm [28]和S4 [29]。 它们的主要区别在于Storm保证其结果的正确性（例如，通过其Trident组件），而S4则不然。 两个系统都依赖于手动配置来进行资源调度。 因此，为了避免由于Operator负载过高导致的慢响应，用户必须向每个Operator过度提供资源，这是浪费的，或者不断地调整系统，这对于动态流是不可行的。
提出了许多基于Operator的DSMS的研究原型，例如具有高效故障恢复功能的TimeStream [2]和Samza [30]。 但是，这些系统都没有解决资源调度问题。 在下文中，我们介绍了DRS，这是基于云的Operator DSMS的第一个有效资源调度程序。
3. DYNAMIC RESOURCE SCHEDULING
第III-A节阐明了DRS中的假设。 第III-B节给出了DRS性能模型，该模型在给定资源分配方案的情况下估计查询响应时间。 第III-C节描述了DRS动态资源调度算法。 表I总结了本文中经常使用的符号。
A. Assumptions
我们专注于流分析应用程序，这些应用程序通常基于内存和计算密集型。对于此类应用程序，处理器是主要的资源类型，每个资源都包含一个CPU（或其中一个内核）和一定数量的RAM。磁盘空间并不重要，因为流输入是实时计算的。虽然网络延迟也会影响查询延迟，但我们没有明确地对其进行建模，因为（a）它通常与计算成本相关，并且（b）它可能受到不可控因素的影响，例如同一服务器上的其他传输繁重的应用程序或者在同一个子网中。此外，如今的数据中心越来越多地配备下一代网络硬件，提供更高的带宽和更低的延迟，例如10G以太网和InfiniBand，其价格一直在快速下降。相比之下，CPU时钟速率和RAM延迟方面的处理器速度在过去几年中停滞不前。因此，我们假设处理器是系统的瓶颈，而不是网络带宽。
为了便于呈现，我们进一步假设云中的所有处理器具有相同的计算能力。 尽管如此，所提出的模型和算法也可以支持异构处理器的设置，并且我们将在必要时解释如何执行此操作。 同时，我们假设在每个操作员中实现负载平衡，即，同一操作员内的每个处理器执行大致相等的工作量。 如何实现负载均衡是一个正交的主题，并且正在积极研究中，例如，[31]。在这些假设下，Operator的处理速度主要取决于其中的处理器数量。
DRS的目标是实时完全处理应用程序的每个输入。 具体地，应用程序的输入元组（例如，图1中的视频帧）可以导致多个中间结果，例如，由运算符A提取的特征，以及由运算符B识别的对象。我们说输入元组t被完全处理， 当且仅当从t导出的每个中间结果已由其相应的运算符处理。 我们使用术语总的逗留时间来指代从第一次到达系统的时间到完全处理t的时间。 我们的目标是确保每个输入t的预期总停留时间不超过用户指定的持续时间，用T max表示。
B. Performance Model
给定应用程序的Operator网络，例如图2中的那个，当前资源分配和流数据的特征，DRS性能模型估计应用程序的平均输入的总停留时间，在最后一小节的末尾解释。 当前资源分配由分配给每个Operator的处理器数量表示。 形式上，我们将N定义为应用程序中的Operator数量，资源分配由向量k =（k 1，k 2，...，k N）建模，其中ki（1≤i≤N）对应于分配给第i个Operator的处理器数量。
关于数据特征，重要的变量是元组到达每个Operator的速率，以及一个处理器可以处理它们的速度。网络延迟没有在我们的模型中明确表达，我们将在本小节的最后进一步讨论这个问题。请注意，我们的模型既不确定元组到达率也不假定处理时间;换句话说，瞬时到达率和处理时间可能会波动。另一方面，为了使问题易于处理，我们假设系统在DRS执行建模和资源调度的跨度期间保持相对稳定的状态。这意味着每个Operator的平均元组到达率和处理时间保持稳定，我们通过系统的测量模块获得这些量，如第IV节所述。具体来说，对于第i个运算符（1≤i≤N），我们使用λi来表示其输入的平均到达率，并且μi表示其每个处理器的平均处理率。例如，k i = 3，λi= 10和μi= 3的情况意味着平均来说，10个元组在单位时间内到达第i个运算符，并且其3个处理器中的每一个在单位时间内处理3个元组。对于具有多个输入流的运算符，即连接运算符，λi是其所有输入流的总到达率，并且μi是运算符的平均处理率，而不管元组来自哪个输入流。
此外，我们将λ0定义为从外部流入应用程序Operator网络的输入的平均到达率。 当Operator网络中有明确的“Source” Operator，其输入完全来自网络外部时，λ0就是这些来源的总到达率。 然而，一般情况下，λ0和λi的集合之间可能没有简单的关系，1≤i≤N。例如，在图2中，λ0是来自外部的元组的到达率 系统）给Operator A; 另一方面，A的输入到达率λA是由Operator E产生的λ0和A的其他输入流的到达率之和。
我们使用随机变量T来表示应用程序输入的总停留时间。我们的目标是估计E [T]，即T的预期值。估计E [T]的基本思想是将系统建模为开放排队网络（OQN）[32]，并将已知结果应用于排队理论。在OQN中，输入元组t的总逗留时间是通过总计其总服务时间（即，处理t所花费的总时间和从t导出的中间结果）和总排队延迟（t及其派生元组的总时间）来计算的。在运营商队列中等待）。这与我们的设置非常匹配。然而，挑战在于排队文献中有许多OQN模型，选择合适的模型并非易事。一方面，复杂的排队网络模型通常没有已知的解决方案;在其中，大多数只有数值解（而不是分析解），这使得有效优化变得困难;另一方面，过度简化的模型可能依赖于强有力的假设，例如确定性元组到达率，这在我们的设置中并不成立。在比较各种选项并通过实验测试之后，我们选择基于Erlang的模型之一[33]和Jackson网络[32]，[34]的组合来构建我们的模型。前者可以对每个Operator进行有效分析，后者有助于汇总这些分析，以估算整个网络的E [T]。我们的模型有一个分析解决方案，它只涉及轻微的限制，我们将在稍后讨论。
我们首先关注单个Operator，比如说i-th。 我们使用T i来表示Operator输入到达与Operator完成处理之间的时间。 我们将Operator建模为M / M / ki系统[33]，其中k i是运营商i的处理器数量。 根据Erlang公式[33]，E [T i]的计算公式为：
直观地，由于新元组以平均速率λi到达，并且每个处理器以平均速率μi处理元组，当ki≤λi/μi时，处理器无法跟上输入速率的元组。 因此，Operator队列中的元组数量随时间增加，导致无限的排队延迟。 当ki>λi/μi时，预期元组的处理速度比它们到达的速度快。 然而，由于到达和处理速率的随机性，当到达率暂时高于处理速率时，队列可能仍然增长。 显然，每个元组的预期服务时间是1/μi。 预期的排队延迟由等式（1）中的复杂项捕获。 接下来，我们聚合所有E [T i]以获得整个运营商网络的E [T]估计值。 根据Jackson网络[32]，[34]的理论，E [T]由E [T i]的加权平均值计算：
这样就完成了DRS性能模型。由于我们的模型依赖于Erlang的公式和Jackson开放排队网络，因此它继承了两个限制。首先，该模型隐含地假设外部元组（来自系统外部）的到达间隔时间和运算符的服务时间都是i.i.d.来自指数分布后的随机变量的样本。其次，Jackson网络没有明确地模拟不同Operator之间的流水线。因此，当服务时间或元组到达分布明显偏离预期的指数分布时，或者当流水线操作显着影响总处理时间时，我们的模型可能给出不准确的E [T]估计。同时，我们的模型没有明确考虑网络成本，因为测量两个节点之间的网络延迟需要复杂的节点间协议，例如，用于时钟同步，这在实时应用中可能过于昂贵。因此，当网络延迟成为平均输入的总逗留时间的主导因素时，我们的模型往往会低估真实结果。然而，正如我们在实验中所表明的那样，当底层应用是计算密集型时，我们模型预测的E [T]值足够准确，这是第III-A节中的一个重要假设。此外，即使预测不准确，它仍然与E [T]的确切值强烈相关，这意味着DRS仍然能够识别具有预测值的最佳资源分配。在本节的其余部分，我们将展示DRS如何根据性能模型调度资源。
C. Scheduling Algorithm
简而言之，DRS（a）监控系统的当前性能（第IV节中的更多细节），（b）检查性能是否在实时约束下降（或即将下降），或者系统何时可以 用更少的资源来满足约束，并且（c）在（b）返回肯定结果时重新安排资源。 主要挑战在于（b），它需要回答两个问题，包括满足实时要求需要多少处理器，以及将它们放置在Operator网络中的哪个位置。 我们首先关注后一个问题。 具体而言，给定一个（例如，K max）处理器，我们将找到这些处理器的最佳分配给应用程序的Operator，该Operator获得最小的预期总停留时间。 问题可以在数学上形式化如下：
上述优化问题的一个简单解决方案是将其视为整数程序，并应用标准求解器。 然而，当前的整数编程求解器非常低，特别是考虑到DRS本身必须实时运行。 在下文中，我们描述了一种新算法，该算法以可忽略的成本解决了程序（4）。
在所提出的算法中使用的关键属性是在等式（1）中定义的E [T i]（k i）是k i的凸函数，k i是分配给第i个Operator的处理器的数量。 该属性已在[32]中得到证实。 由此得出E [T i]（k i）的凸性意味着当k i变大时，递增k i的边际效益单调下降。我们有：
现在从等式（3）观察到E [T]是E [T i]的加权和，并且每个权重λi独立于k i的值。 因此，E [T]也是k i s的凸函数，意味着递增每个ki也相对于E [T]具有递减的边际收益。 基于这一观察，我们设计了算法1中列出的贪婪算法。想法是从每个ki的最小可能值（第1-4行）开始，并迭代地向操作员添加一个处理器，导致最大的减少。 E [T]（第8-15行）。 根据等式（1），每个k i必须大于λi/μi，否则，E [T i]（k i）变得无限大，导致E [T]上的无穷大。
由于E [T]是凸的，上面的贪心算法总能找到最优解，类似于服务器重新分配问题[35]。 重述如下：
定理1：算法1总是向程序4返回精确的最优解。
证据在[36]中给出。
接下来，我们关注如何确定预期实现实时处理的最小处理器数量的问题，即预期的总停留时间E [T]不大于用户定义的阈值T max。 这可以使用以下优化问题建模。
与程序（4）类似，程序（6）的约束和目标在k方面都是凸的。 因此，我们使用类似于算法1的贪婪策略来解决程序（6）。具体来说，我们首先以最小的要求初始化每个ki，如算法1的第1-4行。算法重复地向操作员添加一个处理器。 最大边际收益，如算法1的第8-15行，直到E [T]不大于T max。 我们省略了该算法的正确性证明，因为它几乎与算法1的算法完全相同。
实际上，由于两个原因，程序（6）的解决方案可能无法始终为我们提供满足实时要求所需的精确数量的资源。 首先，每个输入的总逗留时间可以不同，E [T]仅仅是其预期值。 其次，第III-B节中描述的性能模型仅输出E [T]的估计值，而不是其精确值。 为了解决这个问题，DRS从程序（6）的解决方案建议的处理器数量开始，监视实际的总逗留时间E [T]，并根据E [T]的测量值连续调整处理器的数量。 在下一节中，我们将讨论DRS的系统设计和实现问题。
4. SYSTEM DESGIN
图3中给出了系统架构的概述，其通常由两层组成，即DRS层和CSP（基于云的流处理）层。 具体地，DRS层负责性能测量，资源调度和资源分配控制，而CSP层包含原始流处理逻辑，例如， 运行Storm [28]和S4 [29]的实例，以及基于云的资源池服务，例如 YARN [16]和亚马逊EC2。
虽然DRS层的核心负责基于前一节中导出的模型优化资源调度，但支持此类功能的系统并不是那么容易构建的。 鉴于异构的底层基础架构和在CSP层上运行的复杂流处理应用程序，从基础架构收集准确的指标，汇总统计数据，做出在线决策以及以有效的方式控制资源分配至关重要。
为了无缝地结合优化模型和具体的流处理系统，我们构建了许多独立的功能模块，这些模块弥合了物理基础设施和抽象性能模型之间的差距。 如图3所示，在优化器组件的输入端，我们有测量器模块和配置读取器模块，它们根据来自CSP层的数据/控制流生成优化器所需的统计数据。 在工作流程图的输出端，调度程序模块和资源协商程序模块将优化程序的决策转换为可执行命令，以用于不同的流处理平台和资源池。 这些模块的技术细节和主要特征在[36]中讨论。
5. EMPIRICAL STUDIES
为了测试DRS的有效性，我们实现了它并将其集成到Storm [28]中，后者提供了底层的CSP层。 在[36]中提供了Storm的重要概念和架构方面的概述，以及我们如何在Storm中实现DRS的Measurement，Scheduler和Resource negotiator模块的描述。
A. Testing Applications
我们实施了两个实时流分析应用程序：视频徽标检测（VLD）和来自不同域的频繁模式检测（FPD）。
Logo Detection from a Video Stream. 给定一组查询徽标图像，徽标检测应用程序从输入视频流中识别这些图像。 虽然已经做了很多工作来提高VLD的准确性和效率，但由于计算复杂度高，实时执行它仍然是一项重大挑战。
图4显示了实时VLD应用程序的拓扑结构，它是一个包含spout，特征提取器，功能匹配器和聚合器的运算符链。Spout从原始视频流中提取帧。由于生成算法和原始视频内容，帧的输出速率可能随时间变化。我们采用尺度不变特征变换（SIFT）[37]算法从每个帧中提取特征。该步骤耗时，涉及二维图像空间上的卷积。此外，结果SIFT特征的数量可能在不同的帧上发生显着变化，从而导致计算开销随时间的显着变化。特征匹配器测量其输入SIFT特征与那些预先生成的徽标特征之间的L 2距离，并输出距离低于预定阈值的匹配对。最后，聚合器通过聚合所有输入匹配特征对来判断徽标是否出现在视频帧中，即，如果视频帧中匹配特征的数量超过阈值，则认为徽标出现在帧中。
Frequent Pattern Detection over a Microblog Stream. 该应用程序在来自Twitter的微博流上的滑动窗口上维护频繁模式[38]。 对于每个输入句子，我们附加一个附加标签“+/-”，表示它正在进入/离开专用窗口。 给定滑动窗口中的一组输入项组和阈值，我们将最大频繁模式（MFP）定义为满足以下条件的项集：（a）包含此项集的项组的数量，称为其出现次数，高于阈值; 及（b）其任何超集的发生次数低于该阈值。
图5说明了Operator Topology。 有两个spout，它们分别在itemset进入/离开当前处理窗口时生成一个事件元组。 模式生成器生成候选模式，即项集。 这些候选者包括指数数量的可能的非空项目组合。 因此，根据最近交易中的项目数量，其计算会有所不同。
检测器维护状态记录，其包含（a）所有候选i temsets的出现次数和（b）MFP指示符。 当某些项目集发生状态改变时，例如，从MFP到非MFP，检测器通过回送链路向报告者输出通知，并且还向其自身输出通知。 由于（a）探测器中的每个处理器仅保留一部分状态记录; （b）状态改变可以影响存储在不同处理器的其他项目集的状态，该循环确保将状态改变通知发送到所有实例。 最后，报告者向用户呈现检测结果的更新。 在我们的实现中，报告者只需将其输入写入HDFS文件。
B. Experiment Setup
实验在由LAN交换机互连的6台Ubuntu Linux机器的集群上运行。每台机器都配备了一个3.4GHz的Intel四核CPU和8GB的RAM。遵循Storm的常见配置，我们分配了一台机器来托管Nimbus和Zookeeper Server;其余5台机器为实验应用程序提供执行程序。我们还配置了这5台机器中的每台机器，这样一台机器最多可以容纳5台执行器。此约束的主要目的是减轻由在同一台计算机上运行的其他执行程序引起的干扰，以及由于在单个计算机上执行程序的过度分配而导致的资源争用。结果，共有25名遗嘱执行人。
对于这两种应用，即视频徽标检测（VLD）和频繁模式检测（FPD），我们分配了两个执行器作为spouts，一个执行器用于DRS。剩余的25-3 = 22个执行器用作Bolt，即K max = 22.对于VLD，输入数据是足球比赛的一系列视频剪辑，我们选择16个徽标作为检测目标。帧速率模拟典型的互联网视频体验，其在区间[1,25]中均匀分布，平均为13帧/秒。对于FPD，我们使用包含来自2006年10月至2009年11月收集的2,168,939个用户的28,688,584条推文的真实数据集。我们将滑动窗口设置为50,000条推文，并在泊松过程之后模拟推文到达拓扑的平均到达时间每秒320条推文的速度。
C. Experiment Results
对于这两个应用程序，我们运行两组实验：（a）重新平衡禁用，即我们保持DRS被动运行，这意味着它继续监视系统性能并推荐新的（如果更好）资源分配配置，但 不执行重新调度; （b）在开始时禁用重新平衡，然后在以后启用。 这些实验旨在测试性能模型的质量并评估DRS资源调度算法的有效性。
禁用重新平衡的实验。 在该组中，每个实验持续10分钟。 图6显示了每种应用在6种不同分配下的总逗留时间的平均值和标准差。 x轴（x 1：x 2：x 3）表示资源配置（部分顺序为x 1，x 2，x 3），其中x 1，x 2，x 3是分配给的执行程序的数量 图4中的运算符SIFT特征提取器，特征匹配器和匹配聚合器，或图5中的模式生成器，检测器和报告器。两个配置带有“*”，（10：11：1）用于VLD和（6： 13：3）FPD是被动运行的DRS推荐的分配。
从图6中，我们进行了以下观察。 VLD的资源配置（10：11：1）和FPD的（6：13：3），根据测量的平均逗留时间实现最佳性能。 这证明与被动运行的DRS提供的建议一致，这证实了我们的DRS性能模型和资源调度算法的准确性和有效性。
特别是，这两种配置不仅获得最小的平均逗留时间，而且获得最小标准偏差，这意味着这两种分配导致最小的性能振荡。 不同的配置，包括5个最接近的L 1距离（即实验中的剩余5个）到VLD的最佳配置（10：11：1）和FPD的（6：13：3），所有 表现出相当差的表现。 这些结果表明，找到最佳资源分配并不是一件容易的事情，特别是当应用程序拓扑结构变得更复杂时（例如，超过三个Bolt运算符），并因此揭示了DRS的重要性和实用性。
为了仔细研究DRS如何正确提供资源配置建议，图7显示了测量的平均逗留时间与估计的平均逗留时间之间的关系，该时间由第III-B节中描述的性能模型得出。 VLD和FPD的资源分配配置，禁用重新平衡。
如图7所示，表示测量和估计的平均逗留时间的点显示严格单调性，这表示性能模型能够建议最佳资源分配配置。 此外，性能模型输出VLD的准确估计值; 但是，由于我们的模型不考虑网络开销，因此与预期的测量值相比有一些轻微的低估。 值得注意的是，即使杰克逊网络理论和Erlang模型不满足基本条件，估计也是准确的。 例如，帧速率是均匀的（而不是指数所需的）分布式。 同时，Operator输入队列不遵循严格的FIFO规则; 相反，元组被处理器散列。 不同的运算符也并行运行，这导致流水线操作。 该模型对于这些条件的变化显然是稳健的。
对于FPD，估计的逗留时间显示出与测量的偏差更大的偏差。 这主要是因为该模型没有考虑网络传输成本，这占该特定应用中总查询延迟的主要部分。 换句话说，FPD事实上是数据密集型的类型，而不是我们关注的计算密集型应用程序。 然而，我们的模型仍然正确地指示了不同资源分配配置的性能的相对顺序。 同时，由于估计值与真实值强烈相关，因此可以直接使用多项式回归来精确预测给定估计值的真实等待时间值。
为了进一步验证上述解释，我们使用简单的三个运算符链对合成拓扑进行了单独的实验。 每个运算符简单地执行一些具有变化的负载（例如，循环次数）的计算（例如空的for循环）。 我们使用了在6台物理机器上运行的30个执行器，它们连接在同一个子网中。 结果报告在图8中。
如图8所示，我们在三个Bolt的总CPU时间（不包括排队时间）方面尝试了6种不同的工作负载，从0.567毫秒到309.1毫秒（x轴，对数刻度），以及y轴 显示测量的平均逗留时间与估计值的比率。 随着三个Bolt的总CPU时间增加，它显示出低估程度（测量值与估计平均逗留时间的比率）的明显下降趋势。
7. CONCLUSIONS
本文提出了DRS，一种用于基于云的DSMS中的实时流分析的新型动态资源调度器。 DRS克服了几个基本挑战，包括估计满足实时要求所需的必要资源，有效和高效的资源供应和调度，以及在基于云的DSMS中有效实施这样的调度程序。 DRS的性能模型基于严格的排队理论，即使理论的基本条件未得到充分满足，也表现出强大的性能。 此外，我们已将DRS集成到流行的Storm系统中，并通过基于实际应用和数据集的大量实验对其进行评估。
关于未来的工作，我们计划研究将系统从当前资源配置迁移到DRS推荐的新策略的有效策略。 此步骤应最大程度地减少迁移期间的额外开销和结果延迟，以及迁移持续时间（例如，[39]）。 未来工作的另一个有趣方向是研究使用更复杂的排队理论提高性能模型准确性的可能性。
951
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
