调度对于不同的受众意味着不同的事物。对于许多商界人士来说，调度是工作流管理的同义词。工作流管理是为了业务工作流而协调执行一系列脚本或程序，并在 WYSIWYG 编辑器中内置了监控、日志记录和执行保证。诸如 Platform Process Manager 这样的工具可以作为例子。对于其他人来说，调度是关于进程或网络调度。在分布式计算领域，调度意味着作业调度，或者更准确地说，是工作负载管理。

工作负载管理不仅关乎特定的工作单元如何提交、打包和调度，还关乎它如何运行、处理故障和返回结果。HPC 的定义与 Hadoop 的调度定义非常接近。HPC 调度和资源管理交叉的一个有趣方式是在 Hadoop on Demand 项目中。Torque 资源管理器和 Maui Meta Scheduler 都曾在 Hadoop 在 Yahoo 早期阶段的 Hadoop on Demand 项目中用于调度。

本文比较和对比了历史悠久且稳健的 HPC 工作负载管理领域与当今 Hadoop 中快速发展的作业调度领域。

HPC 和 Hadoop 都可以称为分布式计算，但它们的架构却迅速分化。HPC 是一种典型的共享一切架构，计算节点共享通用存储。在这种情况下，每个作业的数据都必须通过共享存储系统移动到节点。共享存储层使编写作业脚本更容易一些，但也引入了对更昂贵的存储技术的需求。共享一切范式也随着规模的扩大而对网络提出了越来越高的要求。HPC 中心很快意识到他们必须转向更高速的网络技术来支持大规模的并行工作负载。

另一方面，Hadoop 在一种无共享架构中运行，这意味着数据存储在使用本地磁盘的各个节点上。Hadoop 将工作移动到数据，并尽可能多地利用廉价且快速的本地存储 (JBOD)。本地存储架构几乎呈线性扩展，因为 CPU、磁盘和 I/O 容量随着节点数量的增加而成比例增加。光纤网络对于 Hadoop 来说是一个不错的选择，但在许多情况下，两个绑定的 1GbE 接口或一个 10GbE 接口就足够快了。使用最慢的实用网络技术可以为项目预算节省净成本。

从 Hadoop 的理念来看，资金实际上应该分配给额外的数据节点。CPU、内存和驱动器本身也是如此。添加节点使整个集群在运行上更并行，也更具抗故障能力。使用中档组件，也称为商品硬件，使其价格合理。

直到最近，Hadoop 本身还是一种主要局限于 MapReduce 的范式。用户试图扩展 MapReduce 模型，以适应远远超出其最初用途的不断扩展的用例列表。Hadoop 的作者通过将 MapReduce 内置的资源管理功能与 MapReduce 的编程模型分离，解决了 Hadoop 在架构上超越 MapReduce 增长的需求。

新的资源管理器被称为 YARN。YARN 代表 Yet Another Resource Negotiator（另一种资源协商器），并在 ASF JIRA MAPREDUCE-279 中引入。基于 YARN 的 Hadoop 2 架构允许在 Hadoop 中使用替代的编程范式。该架构使用一个名为 Resource Manager 的主节点守护进程，它由两部分组成：调度器和 Application Manager。

调度器通常被称为纯调度器，因为它仅管理来自数据节点上的节点管理器的资源可用性。它还强制执行在配置文件中定义的调度策略。调度器的功能是调度容器，容器是可以自定义的资源集合。

Application Master 本身就是一个容器，尽管是一个特殊的容器，有时称为容器 0。Application Master 负责根据作业的需要启动后续容器。Resource Manager 的第二部分称为 Application Manager，它接收作业提交并管理 Application Master 的启动。Application Manager 处理 Application Master 的故障，而 Application Master 处理作业容器的故障。因此，Application Master 实际上是一个应用程序特定的容器，负责管理运行作业实际任务的容器。

图 1. Hadoop 2 的基于 YARN 的架构

从 MapReduce 编程模型中重构资源管理使 Hadoop 集群更通用。在 YARN 下，MapReduce 是在 YARN 容器中运行的一种可用应用程序类型。现在可以通用地编写其他类型的应用程序以在 YARN 上运行，包括 HBase、Storm 甚至 MPI 应用程序等知名应用程序。MPI 支持的进展可以在 Hamster 项目和 GitHub 上提供的名为 mpich2-yarn 的项目中看到。然后，YARN 从调度器转变为 Hadoop 的操作系统，在分布式架构上支持多个应用程序。

在架构上，HPC 工作负载管理与 Hadoop 工作负载管理有许多相似之处。根据所使用的 HPC 工作负载管理技术，存在一组主节点，其中包含用于接受和调度作业的集群控制守护进程。在许多情况下，主节点包含特殊配置，包括通过网络存储共享重要的集群数据，以消除主服务的 SPOF。在工作节点方面，存在一个或多个守护进程正在运行，以接受作业并将资源可用性报告给主节点守护进程。来自 HPC 的技术，如 Platform LSF 和 PBS Professional 以及其他开源变体，如 SLURM 和 Torque，在 HPC 中很常见。

这些技术比 Hadoop 更古老，并且在调度策略方面，它们更成熟。它们倾向于共享 Hadoop 社区正在解决或已经解决的一些基本调度策略原则。

表 1. 调度选项的比较

策略或功能	HPC	Hadoop
FIFO	可用	可用
公平共享	可用	可用
基于时间的策略	可用	技术差距
抢占	可用	可用
独占放置	可用	技术差距
自定义算法	可用	可用
基于 SLA 或 QoS	可用	技术差距
轮询	可用	技术差距
静态和动态资源	可用	可用
节点标签	可用	即将推出
自定义资源	可用	技术差距

先进先出调度

很多时候，这是首次安装工作负载管理器时使用的默认策略。顾名思义，FIFO 的运行方式类似于电影院的队伍或队列。

公平共享

公平共享是一种调度策略，它尝试根据每个用户或组的固定份额数量，将集群资源公平地分配给作业。公平共享的实现方式因所使用的确切集群资源管理软件而异，但大多数系统都具有对作业进行排序以运行的概念，以便平均所有用户的资源使用量。特定的排序可以基于固定数量的份额或资源容量的百分比，以及单个队列或队列层次结构的策略。

基于时间的策略

基于时间的策略有几种不同的类型。队列级基于时间的策略可用于根据一天中的时间更改队列的配置，包括允许提交（入队）但不分派到节点的作业。基于时间的策略实现了诸如在工作时间内将集群用于特定工作负载，并在夜间用于备用工作负载之类的概念。其他基于时间的策略包括在一段时间内将整个集群或集群的一部分专用于特定用途。此外，耗尽集群中提交的作业以进行维护窗口也很常见。

抢占

抢占是指某些作业可以取代当前正在运行的其他作业的想法。抢占通常基于作业本身的优先级。被抢占的作业可能只是被杀死、暂停或可能只是重新排队。所有这些选项都有优点和缺点。总的来说，抢占往往会引起许多内部政治挑战，但没有哪一个能像杀死式抢占那样多。将提交的高优先级工作简单地设置为在资源可用时要运行的下一个作业，这倾向于平衡高优先级工作的需求，而不会因杀死式抢占模型可能造成的破坏。另一种选择是自动化抢占作业的重新排队，而不是杀死它们。执行抢占的最佳方式与工作负载配置文件密切相关。

独占作业放置

将作业独占地放置到节点上是一项重要的作业放置策略。将作业独占地放置在节点上意味着一旦将作业分配给节点，就不能将后续作业放置在该节点上。当用户想要确保在所选节点内与其他作业绝对没有资源争用时，独占放置非常重要。当用户渲染视频或图形时，可能会请求这种类型的放置，其中内存是总挂钟时间的速率限制因素。

通过将作业资源请求与整个单个节点匹配，可以在大多数系统上启用独占放置。为此，提交用户必须知道集群中节点的特定硬件详细信息，并且此方法还假设节点同质性。在许多情况下，用户不知道节点的具体配置，或者集群中节点之间可能存在某种程度的异构性。使用资源管理器和一种用于作业提交的语言，其中包括客户端资源请求标志以允许独占放置作业是非常理想的。

自定义算法

高级集群用户最终会发现，创建自己的算法来进行自定义作业放置是必需的。在实践中，这些算法往往是高度机密的，并且绑定到所有者垂直业务线的某些专有流程。自定义算法的示例可能包括根据组织目标或特定项目为特定作业分配即时高优先级。

基于 SLA 或 QoS 的策略

很多时候，很难保证作业会在所需的时间窗口内完成。大多数工作负载管理系统都有直接或间接的方式来配置调度策略，以便保证作业在给定的时间约束内完成。或者，可能有一些方法来定义用于构建调度策略的自定义质量。

轮询放置

轮询放置将按照特定顺序从每个队列中获取作业，通常在单个调度周期内。队列在大多数系统中按优先级排序，但确切的行为可能很棘手，具体取决于所使用的其他选项（例如，PBS Professional 中的严格排序）。

HPC 工作负载管理器资源类型

工作负载管理器使用资源请求语言来帮助调度器将工作放置在节点上。许多作业放置场景包括静态或内置资源的规范，以及使用脚本定义自定义样式资源的能力。资源类型倾向于反映编程原语，如布尔值、数值和字符串，以及静态和动态等属性，以反映值的性质。其中一些资源类型专门分配给主机，而另一些则与集群中的共享资源有关，如软件许可证或分配管理（集群使用积分或收费）。这些资源在多租户分布式计算环境中都很重要。

Hadoop 调度策略

Hadoop 目前主要使用 CPU 和内存。在指定容器请求时，还可以进行其他选择标准。Application Master 可以指定主机名、机架放置信息和优先级。随着时间的推移，Hadoop 将受益于类似于 HPC 的更成熟的资源规范设计。一个这样的用例是布尔主机资源，用于指定将容器放置到具有特定硬件（例如，GPU）的节点上。即使可以在 Application Master 的 Java 代码中完成非常强大的容器放置，资源请求可能也需要更通用，并在更高的级别（即，在提交时通过通用客户端）可用。YARN 允许来自提交客户端的所谓静态资源和 Application Master 在运行时定义的动态资源。

目前 Hadoop 有两种内置调度策略（不包括 FIFO），但调度与 Hadoop 中的大多数事物一样，是可插拔的。在 yarn-site.xml 配置文件中将 yarn.resourcemanager.scheduler.class 设置为所需的类可以更改所使用的特定调度类型。自定义调度策略类也可以在此处定义。

可以通过 Web 浏览器轻松访问 Hadoop 集群的调度策略。只需使用 Resource Manager 主机名或 IP 和正在使用的 Hadoop 发行版的正确端口，导航到 http://ResourceManager:port/cluster/scheduler 即可。

图 2. Resource Manager Web 接口的调度器页面，显示队列配置和正在运行的应用程序的数据。

FIFO

这是人们可能期望的作为默认调度选项的标准先进先出方法。它的运行方式是接受作业并按接收顺序分派它们。

Capacity Scheduler（容量调度器）

Hadoop 的 Capacity Scheduler（容量调度器）旨在为同一集群上的多个用户（又名多租户）提供最低级别的资源可用性。Hadoop 的部分强大之处在于拥有许多节点。单个集群中提供的工作节点越多，它对故障的弹性就越强。在具有独立预算的大型组织中，各个部门负责人可能认为最好设置单独的集群以获得资源隔离。可以使用 Capacity Scheduler（容量调度器）在逻辑上完成多租户。这种设计的好处不仅在于更好的集群利用率，还在于系统稳定性的提高。通过分散数据以及增加集群数据和计算能力，使用更多节点降低了任何一个节点在节点丢失场景中的重要性。

Capacity Scheduler（容量调度器）通过一系列队列运行。这包括分层队列，每个队列都具有与指导资源共享相关的属性。目前的主要资源包括内存和 CPU。在编写 Application Master 时，容器请求可以包括资源请求，例如节点资源（内存和 CPU）、特定主机名、特定机架和优先级。

capacity-scheduler.xml 文件包含队列及其属性的定义。此文件中的设置包括容量和百分比最大值，以及一次允许运行的作业总数。在多租户环境中，可以在根队列下创建多个子队列。每个队列配置都包含要由自身消耗或与其子队列共享的资源份额。

也常见到使用队列用户的访问控制列表。在这种情况下，每个队列都将接收调度器保证的最小容量。当其他队列低于其容量时，另一个队列可以使用额外的资源，直到达到其配置的最大值（硬限制）。

在 Hadoop 2.1 中，通过 ASF JIRA YARN-569 为容量调度器添加了可配置的抢占。另一方面，完全隔离资源，以便没有一个作业（AM 或其容器）妨碍另一个作业的进度，这是以操作系统相关的方式完成的。是的，Hadoop 已经成熟到可以在 Windows 上运行。对于 Linux，资源隔离是通过 cgroups（控制组）完成的，而在 Windows 上则使用作业控制。未来的增强功能甚至可能包括使用虚拟化技术，如 XEN 和 KVM，来进行资源隔离。

Fair Scheduler（公平调度器）

Fair Scheduler（公平调度器）是 YARN 下 Hadoop 的另一个可插拔调度功能。Capacity Scheduler（容量调度器）和 Fair Scheduler（公平调度器）的运行方式非常相似，尽管它们的命名法不同。这两个系统都按内存和 CPU 进行调度；这两个系统都使用队列（以前称为池），并尝试提供一个框架来共享通用资源集合。Fair Scheduler（公平调度器）使用最少份额的概念来强制执行最少的资源可用性，而多余的资源与其他队列共享。它们有很多相似之处，但也有一些不错的独特功能。调度策略本身可以通过队列自定义，并且可以包括三个选项，包括 FIFO、Fair Share（按内存）和 Dominant Resource Fairness（同时使用 CPU 和内存），后者尽力平衡不同工作负载随时间推移的需求。

yarn-site.xml 文件可以包含许多 Fair Scheduler（公平调度器）设置，包括默认队列。一个独特的设置包括一个选项，用于打开以前是杀死式抢占的抢占，现在包括节省工作量的抢占选项。yarn-site.xml 中最重要的选项之一包括分配文件位置。分配文件详细说明了队列、资源分配以及 XML 中的队列特定调度算法。

YARN 调度器负载模拟器

应该如何在可用的两个主要选项之间进行选择？更重要的是，如何调整配置以获得最佳性能？YARN 调度器负载模拟器是一个方便的工具，用于通过 Hadoop 可用的选项来研究调度选项。模拟器与真实的 Resource Manager 一起工作，但模拟 Node Manager 和 Application Master，因此不需要完全分布式的集群来分析调度策略。新的配置最佳实践之一应该是在最初设置新的 Hadoop 集群时，可以包括调度器调整的时间。之后可以定期进行调度策略分析，以进行持续优化。无论选择哪种类型的调度或如何配置，现在都有一个工具可以帮助每个组确定最适合其需求的方法。

图 3. YARN 调度器模拟器输出，显示队列的内存和 vcore。

调度器模拟是一个非常技术性的研究领域，商业 HPC 工作负载产品多年来一直迫切需要它。很高兴看到分析 Hadoop 工作负载的具体方法，特别是考虑到分布式系统上吞吐量和利用率的微小变化可能产生的影响。

结论

Hadoop 工作负载调度与 Hadoop 的其余部分非常相似，正在突飞猛进地发展。随着每个版本的发布，都会有更多资源类型和调度功能可用，并且很高兴看到互联网规模的分布式计算与已经存在多年的 HPC 领域的融合。有人可能会说 Hadoop 需要 HPC 工作负载管理中的某些功能。例如，基于 SLA 的调度和基于时间的策略是管理员期望的重要操作策略示例。从资源的角度来看，还需要额外的资源类型。开源模型创新的步伐肯定会很快弥合差距。多个群体和贡献者参与基于精英管理的系统，不仅推动了创新步伐，也提高了质量。

资源

原始 YARN JIRA: https://issues.apache.org/jira/browse/MAPREDUCE-279

Hamster 项目: https://issues.apache.org/jira/browse/MAPREDUCE-2911

mpich2-yarn: https://github.com/clarkyzl/mpich2-yarn

Apache Capacity Scheduler 站点: https://hadoop.apache.ac.cn/docs/r2.2.0/hadoop-yarn/hadoop-yarn-site/CapacityScheduler.html

Capacity Scheduler 抢占: https://issues.apache.org/jira/browse/YARN-569

Apache Fair Scheduler 站点: https://hadoop.apache.ac.cn/docs/r2.2.0/hadoop-yarn/hadoop-yarn-site/FairScheduler.html

节省工作量的抢占: https://issues.apache.org/jira/browse/YARN-568

YARN 调度器负载模拟器: https://issues.apache.org/jira/browse/YARN-1021

YARN 调度器负载模拟器演示: http://youtu.be/6thLi8q0qLE