1. 先进先出（FIFO）调度器
先进先出调度器是Hadoop的默认调度器。就像这个名字所隐含的那样，这种调度器就是用简单按照“先到先得”的算法来调度任务的。例如，作业A和作业B被先后提交。那么在执行作业B的任务前，作业A中的所有map任务都应该已经执行完成。
配置：调度器类型的配置是在mapred-site.xml文件中，将mapred.jobtracker.taskscheduler参数设置为我们想要使用的调度器的类名，FIFO调度器的类名是org.apache.hadoop.mapred.jobQueueTaskScheduler。当然，如果想用FIFO调度器，并不需要在配置文件中明确指定，因为默认的就是FIFO调度器。
2. 公平调度器
公平调度器，有时也叫公平共享调度器或FS调度器，是默认FIFO调度器的一种替代调度器。开发公平调度器的目的是解决FIFO调取器在大流量多用户环境中所滋生的一些问题。
公平调度是将资源分配给应用程序的方法，使所有的应用程序得到的平均值，资源随时间的相等份额。Hadoop的下一代系统能够调度多个资源类型。默认情况下，公平调度器调度仅在内存中实现公平调度。它可以被配置为内存和CPU调度，利用资源优势公平的概念。此方法有由Ghodsi等人开发的。在应用程序使用的集群中，当有一个单一的应用程序运行时。当其他应用程序提交后，即释放被分配给新的应用程序的资源，这样每个应用程序对最终得到的资源量大致相当。不同于默认Hadoop的调度，形成应用程序的队列，这让短暂的应用程序在合理的时间内完成，而不会饿死长时间运行的应用程序。它也是一种合理的方式来共享多个用户之间的集群资源。最后在公平共享的同时还能配合的应用程序优先级 作为权重来确定总的资源为每个应用程序应该得到的资源数。
调度组织进一步应用到“队列”，并在这些队列之间分享资源??。默认情况下，所有用户共享一个单一的队列，命名为“ default”。如果一个应用程序专门列出一个队列在一个容器资源请求，该请求被提交到该队列。它也可以分配基于包括通过配置请求中的用户名的队列。在每个队列调度策略用于共享运行的应用程序之间的资源。默认的是基于存储器的公平共享，但是FIFO和多资源具有优势资源公平也可以配置。队列可以被安排在一个层次结构来划分资源，并与重量配置为共享集群中的特定比例。
除了提供公平共享，公平调度器允许分配最低保证分享的队列，这是保证某些用户，组或生产应用程序总能得到足够的资源是有效的。当队列中包含的应用程序，它得到至少为其最小的份额，但是当队列并不需要它的全面保证份额，则超出部分拆分其他正在运行的应用程序之间。这让调度保障能力的同时有效地利用资源，当这些队列不包含应用程序的队列。
公平调度器让默认情况下运行的所有应用程序，但它也可以通过配置文件限制运行的每个用户和每个队列的应用程序的数量。这可能是有用的，当一个用户必须同时提交上百的应用程序，或在总体上提高性能，如果同时运行了太多的应用程序会导致创建太多的中间数据或过多的上下文切换。限制应用程序不会造成任何其后提交的应用程序失败，只能等待调度的队列中，直到一些用户的较早的应用程序完成的。
层次化队列同可插入是策略
公平调度器支持分级队列。所有队列下降从一个名为“根”的队列。可利用的资源分布在根队列中的典型公平调度的时尚子节点。然后，子节点分发分配给他们自己的子节点以同样的方式的资源。应用程序可能只被安排在队列。队列可以通过将他们作为父母的子元素中的公平调度器分配的文件被指定为其他队列中的孩子节点。
队列的名字开始与它的父母的名字，以间隔作为分隔符。因此，一个根队列在名为“队列”的队列，将被称为“root.queue1”，和一个名为“母公司1”队列在名为“队列”队列会被称为“root.parent1.queue2”。当提及队列名称的根部分是可选的，所以队列1可以被称为只是“队列1”，并且一个队列2可以被简称为“parent1.queue2”。
此外，公平调度器允许设置为每个队列不同的自定义策略，以允许共享队列的资源，任何用户想要的方式。自定义策略可以通过扩展来构建org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.SchedulingPolicy。FifoPolicy，FairSharePolicy（默认）和DominantResourceFairnessPolicy是内置的，并可以很容易地使用。
某些加载项尚不支持其存在，在原来（MR1）公平调度。其中，是使用自定义的政策管辖优先权“提升”过某些应用程序。
将应用程序自动加载到队列
公平调度器允许管理员配置策略，自动将应用程序提交到合适的队列中。放置可以依赖于提交者和应用程序通过请求队列中的用户和组。策略由一组规则按顺序应用到传入的应用程序进行分类的。每项规则会将应用程序放入一个队列，拒绝它，或者继续到下一个规则。请参考下面的配置文件格式如何配置这些策略。
安装
要使用公平调度器首先在yarn-site.xml配置相应的调度类：
<property>
<name>yarn.resourcemanager.scheduler.class</name> <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value> </property>
配置
自定义公平调度器通常需要修改两个文件。首先，调度范围的选项可以通过添加在您现有的配置目录在yarn-site.xml文件配置属性进行设置。第二，在大多数情况下，用户希望创建一个配置文件列表的队列存在，它们各自的权重和容量。配置文件被装入每10秒，允许改变要在程序进行调度方式。
可以放置在yarn-site.xml属性
- yarn.scheduler.fair.allocation.file
- 路径配置文件。分配文件是一个XML清单描述队列和它们的属性，除了某些政策的默认值。此文件必须在下一节中描述的XML格式。如果使用相对路径，则该程序文件中搜索的类路径（这通常包括Hadoop的conf目录下）。默认为公平scheduler.xml。
- yarn.scheduler.fair.user-as-default-queue
- 是否使用与分配作为默认队列名称关联的用户名，在未指定队列名称的事件。如果设置为“false”或取消，所有工作都具有共享的缺省队列，命名为“默认”。默认为true。如果队列放置策略中给出了配置文件，则忽略此属性。
- yarn.scheduler.fair.preemption
- 是否使用抢占。需要注意的是抢占实验是在当前版本中。默认为false。
- yarn.scheduler.fair.sizebasedweight
- 是否将股份分配给基于其规模的个体应用，而不是提供一个平等的份额，所有的应用程序无论大小。如果设置为true，应用程序是由一加应用程序的总内存要求的自然对数，以2。默认值的自然对数除以假加权。
- yarn.scheduler.fair.assignmultiple
- 是否允许多个容器分配在一个心跳。默认为false。
- yarn.scheduler.fair.max.assign
- 如果assignmultiple是true，容器可以在一个心跳被分配的最大金额。默认为-1，这台没有限制。
- yarn.scheduler.fair.locality.threshold.node
- 对于要求容器在特定节点上的应用程序，调度机会，因为最后一个容器分配数接受安置在另一个节点上之前的等待时间。表现为介于0和1之间的浮点数，其中，作为簇大小的一小部分，是调度机会的数量让人欲罢不能。-1.0手段的默认值不传递任何调度的机会。
- yarn.scheduler.fair.locality.threshold.rack
- 对于要求容器上特定机架的应用，调度机会，因为最后一个容器分配数接受安置在另一架前等待。表现为介于0和1之间的浮点数，其中，作为簇大小的一小部分，是调度机会的数量让人欲罢不能。-1.0手段的默认值不传递任何调度的机会。
- yarn.scheduler.fair.allow-undeclared-pools
- 如果这是true，新的队列可以在提交申请时被创建，无论是因为它们是由提交者指定为应用程序的队列中，或者因为它们是由用户的默认队列属性放在那里。如果此为假，任何时间的应用程序将被放置在一个未在该分配文件中指定一个队列，它被放置在“默认”的队列来代替。默认为true。如果队列放置策略中给出了配置文件，则忽略此属性。
-
配置文件格式
配置文件必须是XML格式。该格式包含了五种类型的元素：
- 队列中的元素，它们代表的队列。每一个都可以包含下面的属性：
- minResources：最少的资源队列有权在形式的“X MB，Y vcores”。对于单资源公平性的政策，在vcores值将被忽略。如果一个队列的最低份额不满意，将根据之前同一母公司提供可用资源的任何其他队列。当下资源的公平策略队列被认为是不满意的，如果它的内存使用量低于其最低内存份额。就失去优势资源公平性，一个队列被认为是不满意的，如果它的使用，它的相对于所述簇的容量优势资源低于它的最低份额该资源。如果多个队列不满意在这种情况下，资源进入队列有关的资源使用情况和最小值之间的最小比率。注意，有可能是一个队列，即低于其最小可能不会立即起床到最小，当它提交的申请，因为已经运行的作业可以利用这些资源。
- maxResources：最大的资源队列是允许的，在形式的“X MB，Y vcores”。对于单资源公平性的政策，在vcores值将被忽略。队列永远不会被分配一个容器，将其放在总使用量超过此限制。
- maxRunningApps：从队列限制的应用程序的数量，同时运行
- 重量：与其他队列非按比例分担集群。权值默认为1，而与体重2队列应收取约两倍的资源作为一个与默认权重队列。
- schedulingPolicy：设置任何队列的调度策略。允许的值是“先进先出”/“公平”/“DRF”或 ??扩展任何类org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.SchedulingPolicy。默认为“公平”。如果“先进先出”，应用程序与先前提交时间以偏爱的容器，但后来提交的应用程序可以同时运行，如果有剩余的空间集群在满足前面的应用程序的请求后。
- aclSubmitApps：用户和/或可以提交应用程序的队列组的列表。请参考下面的ACL部分在此列表的格式和队列是如何工作的ACL的详细信息。
- aclAdministerApps：用户和/或组可管理一个队列的列表。目前唯一的行政行为是杀一个应用程序。请参考下面的ACL部分在此列表的格式和队列是如何工作的ACL的详细信息。
- minSharePreemptionTimeout：秒数队列是根据它的最小份额的时候，才试图抢占容器，以使资源从其他队列。
- 用户元件，它代表设置管用户个性化的行为。它们可以包含一个属性：maxRunningApps上运行的应用程序对特定用户数量的限制。
- 一个userMaxAppsDefault元素，它设置默认运行的应用程序的限制是不是另有规定的限制的任何用户。
- 一个fairSharePreemptionTimeout元素，几秒钟的队列号是其公平份额下的时候，才尝试抢占容器，以使资源从其他队列。
- 一个defaultQueueSchedulingPolicy元素，它设置为队列默认的调度策略; 如果所指定的每个队列的schedulingPolicy元素覆盖。默认为“公平”。
- 一个queuePlacementPolicy元素，其中包含告诉调度程序如何进入的应用程序放置到队列规则元素的列表。规则的应用，因为它们列出的顺序。规则可能需要的参数。所有规则接受“创造”的说法，这表示规则是否可以创建一个新的队列。“创建”默认为true; 如果设置为false，该规则将放在未在配置文件中配置一个队列的应用程序，我们继续到下一个规则。最后一条规则必须是一个永远无法发出继续。有效的规则是：
- 规定：应用程序被放置到它要求队列中。如果应用程序要求没有队列，也就是说，它指定了“default”，我们继续。
- 用户：应用程序被放置到一个与谁提交它的用户的名称队列。
- primaryGroup：应用程序被放置到一个队列，谁提交它的用户的主组的名称。
- secondaryGroupExistingQueue：应用程序被放置到一个有一个与谁提交了用户的次要组名的队列。符合配置的队列中的第一次要组将被选中。
- 默认：应用程序被放置到一个名为“默认”的队列。
- 拒绝：应用程序被拒绝。
这里有一个例子配置文件中给出：
-
<?xml version="1.0"?> <allocations> <queue name="sample_queue"> <minResources>10000 mb,0vcores</minResources> <maxResources>90000 mb,0vcores</maxResources> <maxRunningApps>50</maxRunningApps> <weight>2.0</weight> <schedulingPolicy>fair</schedulingPolicy> <queue name="sample_sub_queue"> <aclSubmitApps>charlie</aclSubmitApps> <minResources>5000 mb,0vcores</minResources> </queue> </queue> <user name="sample_user"> <maxRunningApps>30</maxRunningApps> </user> <userMaxAppsDefault>5</userMaxAppsDefault> <queuePlacementPolicy> <rule name="specified" /> <rule name="primaryGroup" create="false" /> <rule name="default" /> </queuePlacementPolicy> </allocations>
请注意，为了与原来的FairScheduler兼容性，“ queue”元素可以代替其命名为“pool”的元素。
队列的访问控制列表（ACL）
队列的访问控制列表（ACL）允许管理员控制谁可以采取行动，特别是队列。它们被配置成与aclSubmitApps和aclAdministerApps特性，这可以为每个队列被设置。目前只支持行政行为被杀死的应用程序。谁可以管理一个队列中任何人也可以提交申请了。这些属性需要像“用户1，用户2组1，组2”或“组1，组2”的格式值。如果它的用户或组是在该队列的访问控制列表或任何该队列的祖先ACL在一个队列动作将被允许。所以，如果队列2是内部队列1，而user1的队列1的ACL，和user2是在队列2的ACL，那么这两个用户可以向队列2。
根队列的ACL是“*”，其中，因为ACL是传下来的默认值，也就是说，每个人都可以提出来，并从每个队列杀应用程序。要开始限制访问，修改root队列的ACL来的东西比“*”等。
管理
公平调度器提供了通过两个机制来管理支持在运行时：
- 它可以通过编辑配置文件来修改最小的股票，限制，重量，抢占超时和队列调度策略在运行时。它看到后，它被修改调度程序将重新载入该文件10-15秒。
- 当前的应用程序，队列和公平共享可以通过ResourceManager的Web界面进行审查，在http://ResourceManager URL/cluster/scheduler。
以下字段可以看出，Web界面上显示每个队列信息：
- 使用资源 - 资源分配给队列容器内的总和。
- 运行的应用程序数 - 应用程序在已收到至少一个容器队列的数目。
- 等待的应用程序数 - 在队列中的应用尚未收到任何容器的数量。
- 最小的资源 - 这是保证队列的配置最少的资源。
- 最大的资源 - 被允许的队列配置的最大资源。
- 公平共享 - 资源的队列的公平份额。队列可能当其他队列不使用它们被分配的资源超出了他们的公平份额。队列的资源消耗在于等于或低于其公平份额将永远不会有它的容器抢占。
除此之外ResourceManager中通常会显示每个应用程序的信息，Web界面，包括应用程序的公平份额。
参考链接：
Hadoop-2.2.0中文文档 MapReduce下一代 公平调度器
Hadoop的调度器总结
3. 计算能力调度器（Capacity Scheduler）
计算能力调度器是由Yahoo贡献的，主要是解决HADOOP-3421中提出的，在调度器上完成HOD（Hadoop On Demand）功能，克服已有HOD的性能低效的缺点。它适合于多用户共享集群的环境的调度器。本文解析的计算能力调度器属于Hadoop 0.20.2。
Capacity Scheduler支持以下特性：
(1) 计算能力保证。支持多个队列，某个作业可被提交到某一个队列中。每个队列会配置一定比例的计算资源，且所有提交到队列中的作业共享该队列中的资源。
(2) 灵活性。空闲资源会被分配给那些未达到资源使用上限的队列，当某个未达到资源的队列需要资源时，一旦出现空闲资源资源，便会分配给他们。
(3) 支持优先级。队列支持作业优先级调度（默认是FIFO）
(4) 多重租赁。综合考虑多种约束防止单个作业、用户或者队列独占队列或者集群中的资源。
(5) 基于资源的调度。 支持资源密集型作业，允许作业使用的资源量高于默认值，进而可容纳不同资源需求的作业。不过，当前仅支持内存资源的调度。
参考链接：