Scheduling in YARN

In an ideal world, the requests that a YARN application makes would be

granted immediately. In the real world, however, resources are limited, and on a
busy cluster, an application will often need to wait to have some of its requests
fulfilled. It is the job of the YARN scheduler to allocate resources to
applications according to some defined policy. Scheduling in general is a
difficult problem and there is no one “best” policy, which is why YARN
provides a choice of schedulers and configurable policies. We look at these
next.

Scheduler Options

Three schedulers are available in YARN: the FIFO, Capacity, and Fair
Schedulers. The FIFO Scheduler places applications in a queue and runs them
in the order of submission (first in, first out). Requests for the first application in
the queue are allocated first; once its requests have been satisfied, the next
application in the queue is served, and so on.

The FIFO Scheduler has the merit of being simple to understand and not
needing any configuration, but it’s not suitable for shared clusters. Large
applications will use all the resources in a cluster, so each application has to
wait its turn. On a shared cluster it is better to use the Capacity Scheduler or the
Fair Scheduler. Both of these allow long-running jobs to complete in a timely
manner, while still allowing users who are running concurrent smaller ad hoc
queries to get results back in a reasonable time.

The difference between schedulers is illustrated in Figure , which shows that

under the FIFO Scheduler (i) the small job is blocked until the large job
completes.
With the Capacity Scheduler (ii in Figure ), a separate dedicated queue allows
the small job to start as soon as it is submitted, although this is at the cost of
overall cluster utilization since the queue capacity is reserved for jobs in that
queue. This means that the large job finishes later than when using the FIFO
Scheduler.
With the Fair Scheduler (iii in Figure ), there is no need to reserve a set
amount of capacity, since it will dynamically balance resources between all
running jobs. Just after the first (large) job starts, it is the only job running, so it
gets all the resources in the cluster. When the second (small) job starts, it is
allocated half of the cluster resources so that each job is using its fair share of
resources.

Note that there is a lag between the time the second job starts and when it
receives its fair share, since it has to wait for resources to free up as containers
used by the first job complete. After the small job completes and no longer
requires resources, the large job goes back to using the full cluster capacity
again. The overall effect is both high cluster utilization and timely small job
completion.

Figure 1. Cluster utilization over time when running a large job and a small
job under the FIFO Scheduler (i), Capacity Scheduler (ii), and Fair Scheduler
(iii)

Capacity Scheduler Configuration

The Capacity Scheduler allows sharing of a Hadoop cluster along organizational
lines, whereby each organization is allocated a certain capacity of the overall
cluster. Each organization is set up with a dedicated queue that is configured to
use a given fraction of the cluster capacity. Queues may be further divided in
hierarchical fashion, allowing each organization to share its cluster allowance
between different groups of users within the organization. Within a queue,
applications are scheduled using FIFO scheduling.

a single job does not use more resources than its queue’s capacity. However, if
there is more than one job in the queue and there are idle resources available,
then the Capacity Scheduler may allocate the spare resources to jobs in the
queue, even if that causes the queue’s capacity to be exceeded. This behavior is
known as queue elasticity.
In normal operation, the Capacity Scheduler does not preempt containers by
forcibly killing them, so if a queue is under capacity due to lack of demand, and
then demand increases, the queue will only return to capacity as resources are
released from other queues as containers complete. It is possible to mitigate this
by configuring queues with a maximum capacity so that they don’t eat into
other queues’ capacities too much. This is at the cost of queue elasticity, of
course, so a reasonable trade-off should be found by trial and error.

Imagine a queue hierarchy that looks like this:

root

├── prod

└── dev

├── eng

└── science

The Example shows a sample Capacity Scheduler configuration file,

called [Link], for this hierarchy. It defines two queues under
the root queue, prod and dev, which have 40% and 60% of the capacity,
respectively. Notice that a particular queue is configured by setting
configuration properties of the form [Link].<queue-
path>.<sub-property>, where <queue-path> is the hierarchical (dotted) path of
the queue, such as [Link].
Example 4-1. A basic configuration file for the Capacity Scheduler

<?xml version="1.0"?>
<configuration>
<property>
<name>[Link]</name>
<value>prod,dev</value>
</property>
<property>
<name>[Link]</name>
<value>eng,science</value>
</property>
<property>
<name>[Link]</name>
<value>40</value>
</property>
<property>
<name>[Link]</name>
<value>60</value>
</property>
<property>
<name>[Link]-capacity</name>
<value>75</value>
</property>
<property>
<name>[Link]</name>
<value>50</value>
</property>
<property>
<name>[Link]</name>
<value>50</value>
</property>
</configuration>

the dev queue is further divided into eng and science queues of equal capacity.
So that the dev queue does not use up all the cluster resources when
the prod queue is idle, it has its maximum capacity set to 75%. In other words,
the prod queue always has 25% of the cluster available for immediate use. Since
no maximum capacities have been set for other queues, it’s possible for jobs in
the eng or science queues to use all of the dev queue’s capacity (up to 75% of
the cluster), or indeed for the prod queue to use the entire cluster.
Beyond configuring queue hierarchies and capacities, there are settings to
control the maximum number of resources a single user or application can be
allocated, how many applications can be running at any one time, and ACLs on
queues. See the reference page for details.

Queue placement
The way that you specify which queue an application is placed in is specific to
the application. For example, in MapReduce, you set the
property [Link] to the name of the queue you want to use. If
the queue does not exist, then you’ll get an error at submission time. If no queue
is specified, applications will be placed in a queue called default.

Preemption
When a job is submitted to an empty queue on a busy cluster, the job cannot
start until resources free up from jobs that are already running on the cluster. To
make the time taken for a job to start more predictable, the Fair Scheduler
supports pre-emption
Preemption allows the scheduler to kill containers for queues that are running
with more than their fair share of resources so that the resources can be
allocated to a queue that is under its fair share. preemption reduces overall
cluster efficiency, since the terminated containers need to be reexecuted.
Preemption is enabled globally by setting [Link] to true.
There are two relevant preemption timeout settings: one for minimum share and
one for fair share, both specified in seconds.
By default, the timeouts are not set, so you need to set at least one to allow
containers to be preempted. If a queue waits for as long as its minimum share
preemption timeout without receiving its minimum guaranteed share, then the
scheduler may preempt other containers.
The default timeout is set for all queues via the default MinShare Preemption
Timeout toplevel element in the allocation file, and on a per-queue basis by
setting the minShare Preemption Timeout element for a queue. Likewise, if a
queue remains below half of its fair share for as long as the fair share
preemption timeout, then the scheduler may preempt other containers. The
default timeout is set for all queues via the default FairShare Preemption
Timeout top-level element in the allocation file, and on a per-queue basis by
setting fair Share Preemption Timeout on a queue. The threshold may also be
changed from its default of 0.5 by setting default FairShare Preemption
Threshold and fairSharePreemptionThres hold (per-queue).

Delay Scheduling All the YARN schedulers try to honor locality requests. On a
busy cluster, if an appli‐ cation requests a particular node, there is a good chance
that other containers are run‐ ning on it at the time of the request. The obvious
course of action is to immediately loosen the locality requirement and allocate a
container on the same rack. However, it has been observed in practice that
waiting a short time (no more than a few seconds) can dramatically increase the
chances of being allocated a container on the requested node, and therefore
increase the efficiency of the cluster. This feature is called delay scheduling,
and it is supported by both the Capacity Scheduler and the Fair Scheduler.
Every node manager in a YARN cluster periodically sends a heartbeat request to
the resource manager—by default, one per second. Heartbeats carry information
about the node manager’s running containers and the resources available for
new containers, so each heartbeat is a potential scheduling opportunity for an
application to run a container. When using delay scheduling, the scheduler
doesn’t simply use the first scheduling opportunity it receives, but waits for up
to a given maximum number of scheduling opportunities to occur before
loosening the locality constraint and taking the next scheduling opportunity.

Dominant Resource Fairness:

For the Capacity Scheduler, delay scheduling is configured by setting
[Link]-locality-delay to a positive integer representing the
number of scheduling opportunities that it is prepared to miss before loosening
the node constraint to match any node in the same rack. The Fair Scheduler also
uses the number of scheduling opportunities to determine the delay, although it
is expressed as a proportion of the cluster size. For example, setting
[Link] to 0.5 means that the scheduler
should wait until half of the nodes in the cluster have presented scheduling
opportunities before accepting another node in the same rack. There is a
corresponding property, [Link], for setting
the threshold before another rack is accepted instead of the one requested.
Dominant Resource Fairness When there is only a single resource type being
scheduled, such as memory, then the concept of capacity or fairness is easy to
determine. If two users are running applications, you can measure the amount of
memory that each is using to compare the two applications. However, when
there are multiple resource types in play, things get more com ‐ plicated. If one
user’s application requires lots of CPU but little memory and the other’s
requires little CPU and lots of memory, how are these two applications
compared? The way that the schedulers in YARN address this problem is to
look at each user’s dominant resource and use it as a measure of the cluster
usage. This approach is called Dominant Resource Fairness, or DRF for short.9
The idea is best illustrated with a simple example. Imagine a cluster with a total
of 100 CPUs and 10 TB of memory. Application A requests containers of (2
CPUs, 300 GB), and application B requests containers of (6 CPUs, 100 GB). A’s
request is (2%, 3%) of the cluster, so memory is dominant since its proportion
(3%) is larger than CPU’s (2%). B’s request is (6%, 1%), so CPU is dominant.
Since B’s container requests are twice as big in the dominant resource (6%
versus 3%), it will be allocated half as many containers under fair sharing. By
default DRF is not used, so during resource calculations, only memory is
considered and CPU is ignored. The Capacity Scheduler can be configured to
use DRF by setting [Link]-calculator to
[Link] .[Link] in capacity-
[Link]. For the Fair Scheduler, DRF can be enabled by setting the top-
level element default QueueSchedulingPolicy in the allocation file to drf.