4.关于YARNYARN是Hadoop集群资源管理系统。YARN被引入Hadoop2，最初是为了改善mapreduce的

YARN是Hadoop集群资源管理系统。YARN被引入Hadoop2，最初是为了改善mapreduce的实现，但它有足够的通用性，同样可以支持其他的分布式计算模式。
剖析YARN运行机制
1. 为了在YARN上运行一个应用，首先，客户端联系resource manager，要求它运行一个application master进程。然后resource manager找到一个能够在容器中启动application master的node manager。
2. 资源请求：YARN有一个灵活的资源请求模型。当请求多个容器时，可以指定每个容器需要的计算机资源数量（内存和CPU），还可以指定对容器的本地限制。通常情况下，当启动一个容器用于处理HDFS数据块时，应用会向这样的节点申请容器：存储该数据块三个复本的节点，或是存储这些复本的机架中的一个节点。如果都申请失败，则申请集群中的任意节点。YARN应用可以在运行中的任意时刻提出资源申请以满足不断变化的应用的需求。
3. 应用生命期：
  1. 第一种：一个用户作业对应一个应用，mapreduce采用这种模型。
  2. 第二种：作业的每个工作流或每个用户对话对应一个应用。这种方法比第一种效率要高，因为容器可以在作业之间重用，并且有可能缓存作业之间的中间数据。spark采用这种模型。
  3. 第三种：多个用户共享一个长期运行的应用。这种应用通常是作为一种协调者的角色在运行。如apache slider有一个长期运行的application master，主要用于启动集群上的其他应用。由于避免了启动新的application master带来的开销，一个always on的application master意味着用户将获得非常低延迟的查询响应。
YARN与MapReduce1相比
1. MapReduce1：MapReduce1中，有两类守护进程控制着作业过程：一个jobtracker及一个或多个tasktracker。jobtracker通过调度tasktracker上运行的任务来协调所有运行在系统上的应用。tasktracker在运行任务的同时将任务进度报告给jobtracker。如果其中一个任务失败，jobtracker可以在另一个tasktracker节点上重新调度该任务。jobtracker同时负责作业调度（将任务与tasktracker匹配）和任务监控（跟踪任务、重启失败或迟缓的任务；记录任务流水，如维护计数器的计数）。
2. 可扩展性：与MpaReduce1相比，YARN可以在更大规模的集群上运行。MapReduce1在集群节点数达到4000，任务数达到40000时会遇到瓶颈，瓶颈源于jobtracker必须同时管理任务和作业这样一个事实。YARN利用其resource manager和applicaiton master分离的架构克服了这个局限性，可以扩展到面向将近10000个节点和100000个任务。
3. 可用性：当服务守护进程失败时，通过为另一个守护进程复制接管工作所需的状态以便其继续提供服务，从而获得高可用性。然而，jobtracker内存中存在大量快速变化的复杂状态使得改进jobtracker服务获得高可用性非常困难。由于YARN中jobtracker在resource manager和application master之间进行了职责划分，高可用的服务随之成为一个分而治之问题：先为resource manager提供高可用性，再为YARN应用提供高可用性。
4. 利用率：MapReduce1中，每个tasktracker都配置有若干固定长度的slot，这些slot是静态分配的，在配置时就被划分为map slot和reduce slot。一个map slot只能运行一个map任务，reduce slot亦然。YARN中，一个node manager管理一个资源池，而不是固定数目的slot。不会出现由于集群中仅有map slot可用而导致reduce任务无法执行的情况。更进一步，YARN中的资源是精细化管理的，应用能够按照需求申请资源，避免了因为slot太大/太小造成的资源浪费/失败。
YARN中的调度
1. 调度选项：YARN中有三种调度器可用：FIFO调度器、容量调度器和公平调度器。
2. FIFO调度器
  1. FIFO调度器将应用放在一个队列中，然后按照提交的顺序运行应用。首先为队列中的第一个应用的请求分配资源，第一个应用的请求被满足后，再依次服务下一个应用。
  2. FIFO的优点是简单易懂，不需要任何配置，但是不适合共享集群。因为大的应用可能会占领集群中的所有资源，导致其他应用必须等待较长时间。
3. 容量调度器(capacity scheduler)
  1. 使用容量调度器时，一个专门的独立队列保证小作业一提交就可以启动，由于队列容量是为那么队列中的作业所保留的，因此这种策略是以牺牲整个集群的利用率为代价的。这意味着与FIFO调度器相比，同样的大作业在容量调度器中会执行更长的时间。
  2. 容量调度器允许多个组织共享一个Hadoop集群。每个组织被配置一个专门的队列，对应一定的集群资源。队列可以进一步划分，这样每个组织内的不同用户能够共享该组织队列所分配的资源。在一个队列内，使用FIFO调度策略对应用进行调度。
  3. 弹性队列：单个作业使用的资源资源不会超过其队列容量。然而，如果队列中有多个作业，且队列资源不够用了呢？这时如果仍有可用的空闲资源，那么容量调度器可能会将空余的资源分配给队列中的作业，哪怕这会超出队列的容量。
  4. 正常操作时，容量调度器不会通过强行中止来抢占容器。但应该为队列设置一个最大容量限制，这样这个队列就不会过多侵占其他队列的资源了，但这是以牺牲队列弹性为代价的，需要找到一个平衡点。
4. 公平调度器(fair scheduler)
  1. 使用公平调度器时，不一定要预留一定量的资源，因为调度器会在所有运行的作业之间动态平衡资源。当第一个（大）作业启动时，它会获得集群的所有资源。当第二个（小）作业启动时，它会被分配集群一半的资源。注意，从第二个作业启动到获得公平共享资源之间会有时间滞后，因为它必须等待第一个作业使用的容器用完并释放资源。当小作业不再申请资源后，大作业将回去再次使用所有资源。这样即得到了较高的集群利用率，又能保证小作业及时完成。
  2. 抢占：在一个繁忙的集群中，当作业被提交给一个空队列时，作业不会立刻启动，知道集群上已经运行的作业释放了资源。为了使作业从提交到执行所需的时间可预测，公平调度器支持抢占功能。
    1. 概念：所谓抢占，就是允许调度器终止那些占用资源超过了其公平共享份额的队列的容器，这些容器资源释放后可以分配给资源数量低于赢得份额的队列。注意，抢占会降低整个集群的效率，因为被终止的容器需要重新执行。
5. 延迟调度：所有YARN调度器都试图以本地请求为重。在一个繁忙的集群，如果一个应用请求某个节点，那么极有可能此时有其他容器正在该节点运行。显而易见的处理是，立刻放宽本地性需求，在同一机架中分配一个容器。然而，通过实践发现，此时如果等待一小段时间（不超过几秒），能够戏剧性地增加在所请求的节点上分配到一个容器的机会，从而可以提高集群的效率，这个特性被称为延迟调度。
6. 主导资源公平性(DRF)：当有多种资源类型需要调度，例如一个应用对CPU的需求很大，内存的需求很小；而另一个应用对CPU需求很小，对内存需求很大，YARN如何比较这两个应用来确定公平性呢？答案是，YARN会观察每个用户的主导资源，并将其作为对集群资源使用的一个度量。这个方法被成为“主导资源公平性”。