欢迎关注Hadoop、Spark、Flink、Hive、Hbase、Flume等大数据资料分享微信公共账号:iteblog_hadoop
  1. 文章总数:961
  2. 浏览总数:11,480,158
  3. 评论:3873
  4. 分类目录:103 个
  5. 注册用户数:5841
  6. 最后更新:2018年10月17日
过往记忆博客公众号iteblog_hadoop
欢迎关注微信公众号:
iteblog_hadoop
大数据技术博客公众号bigdata_ai
大数据猿:
bigdata_ai

Hadoop YARN公平调度(FairScheduler)介绍

一、介绍

  FairScheduler是一个资源分配方式,在整个时间线上,所有的applications平均的获取资源。Hadoop NextGen能够调度多种类型的资源。默认情况下,FairScheduler只是对内存资源做公平的调度(分配)。当集群中只有一个application运行时,那么此application占用这个集群资源。当其他的applications提交后,那些释放的资源将会被分配给新的applications,所以每个applicaiton最终都能获取几乎一样多的资源。不像Hadoop默认的Scheduler(CapacityScheduler),CapacityScheduler将applications以queue的方式组成,它可以让short applications在何时的时间内完成,而不会starving那些长期运行的applications,它也是一个合理的方式在多个用户之间共享集群。最终,Fair共享也可以与application priorities一起工作-----“priorities”作为权重来使用,以决定每个application需要获取资源的量。

  Scheduler将applications以queues的方式组织,在这些queues之间公平的共享资源。默认,所有的users共享一个queue,名称为“default”。如果application在请求资源时指定了queue,那么请求将会被提交到指定的queue中;仍然可以通过配置,根据请求中包含的user名称来分配queue。在每个queue内部,调度策略是在运行中的applicaitons之间共享资源。默认是基于内存的公平共享,不过FIFO和multi-resource with Dominant Resource Fairness也能够配置。Queues可以分级来划分资源,配置权重以特定的比例共享集群资源。

  FairScheduler允许为queues分配担保性的最小的共享资源量,这对保证某些用户、groups或者applications总能获取充足的资源是有帮助的。当一个queue中包含applications时,它至少能够获取最小量的共享资源,当queue不在需要时,那些过剩的资源将会被拆分给其他的运行中的application。这就让Scheduler在有效利用资源是,保证了queue的capacity。

  FairScheudler在默认情况下允许所有的application运行,但是这也可以通过配置文件来限制每个用户下和每个queue下运行applications的个数。这对限制一个用户一次提交大量applications是有用的,或者通过限制running applications个数来提升性能,因为大量的running applicaiton会导致创建大量的中间数据或者过多的上下文切换。限制applications不会导致随后的提交失败,只是在Scheduler queue中等待,直到先前的application结束。

二、Hierarchical queues

  FairScheduler支持分层的queues。所有的queues继承自“root” queue。有效的资源在root子节点中,以典型的公平调度的方式分布;子节点再将分配给自己的资源以相同的方式分配给自己的子节点。applications只能在queue的叶子节点上调度。可以通过FairScheduler相关的配置文件,Queues可以被指定作为其他queues的子节点。

  Queue的名字,以其父节点path作为开始,以“.”作为分割符。比如名称为“queue1”的queue作为root的子节点,那么应该表示为“root.queue1”,名称为“queue2”的queue为“parent1”的子节点,那么应该表示为“root.parent1.queue2”。当指明一个queue时,root部分是可选的,比如“queue1”就是指queue1,而queue2指“parent1.queue2”。

  此外,FairScheduler允许为每个queue指定不同的policy,每个queue都可以根据用户希望的方式共享queue的资源。这些自定义的Policy可以通过实现“org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.SchedulingPolicy”来构建;FifoPolicy,FairSharePolicy(默认),以及DominantResouceFairnessPolicy都是内置的,可以直接使用。

三、Installation

  为了使用FairScheduler,首先需要在yarn-site.xml配置:
Java代码 收藏代码

<property>
    <name>yarn.resourcemanager.scheduler.class</name>
    <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value>
</property>
 

四、配置

  定制FairScheduler涉及到2个文件。首先,scheduler有关的选项可以在yarn-site.xml中配置。此外,多数情况,用户需要创建一个“allocation”文件来列举存在的queues和它们相应的weights和capacities。这个“allocation”文件每隔10秒钟加载一次,更新的配置可以更快的生效。

1、yarn-site.xml中的配置

  yarn.scheduler.fair.allocation.file: “allocation”文件的位置,“allocation”文件是一个用来描述queue以及它们的属性的配置文件。这个文件必须为格式严格的xml文件。如果为相对路径,那么将会在classpath下查找此文件(conf目录下)。默认值为“fair-scheduler.xml”。
  yarn.scheduler.fair.user-as-default-queue:是否将与allocation有关的username作为默认的queue name,当queue name没有指定的时候。如果设置成false(且没有指定queue name) 或者没有设定,所有的jobs将共享“default” queue。默认值为true。
  yarn.scheduler.fair.preemption:是否使用“preemption”(优先权,抢占),默认为fasle,在此版本中此功能为测试性的。
  yarn.scheduler.fair.assignmultiple:是在允许在一个心跳中,发送多个container分配信息。默认值为false。
  yarn.scheduler.fair.max.assign:如果assignmultuple为true,那么在一次心跳中,最多发送分配container的个数。默认为-1,无限制。
  yarn.scheduler.fair.locality.threshold.node:一个float值,在0~1之间,表示在等待获取满足node-local条件的containers时,最多放弃不满足node-local的container的机会次数,放弃的nodes个数为集群的大小的比例。默认值为-1.0表示不放弃任何调度的机会。
  yarn.scheduler.fair.locality.threashod.rack:同上,满足rack-local。
  yarn.scheduler.fair.sizebaseweight:是否根据application的大小(job的个数)作为权重。默认为false,如果为true,那么复杂的application将获取更多的资源。

2、一个例子

<?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>
本博客文章除特别声明,全部都是原创!
转载本文请加上:转载自过往记忆(https://www.iteblog.com/)
本文链接: 【Hadoop YARN公平调度(FairScheduler)介绍】(https://www.iteblog.com/archives/1540.html)
喜欢 (13)
分享 (0)
发表我的评论
取消评论

表情
本博客评论系统带有自动识别垃圾评论功能,请写一些有意义的评论,谢谢!
(12)个小伙伴在吐槽
  1. FairScheduler允许为queues分配担保性的最小的共享资源量,这对保证某些用户、groups或者applications总能获取充足的资源是有帮助的。请问博主, 这里的用户是怎么定义的?是client系统上的用户还是?
    spoofer2016-03-03 22:01 回复
    • 当然是Hadoop队列上的用户。
      w3970907702016-03-04 08:28 回复
      • 问题来了, 这queue上的用户是哪里来的?谁产生的?
        spoofer2016-03-04 12:23 回复
        • Hadoop队列上的用户需要和各个Client上用户对应,然后你才可以使用这个用户。。
          w3970907702016-03-04 13:29 回复
          • 那就是运行client的系统上的用户囖 😐 ,那有个问题, 如果两台不同的机器提交作业的client的用户名字都一样, 那队列里的这两个用户应该一样吗?
            spoofer2016-03-05 08:22
    • 肯定一样啊。
      w3970907702016-03-05 13:46 回复
  2. 过往记忆你好,经常浏览你的博客,收获不少。我现在正从事hadoop相关的工作,遇到一个调优的问题,想请教你一下。我们的集群有两种机器(共7台),8核的CPU(5台)和12核的CPU(2台),内存都是64G的。Hadoop版本是CDH5(对应于Apache2.6.0),现在的问题是当作业提交后,并行Mapper的数量始终徘徊在55个左右,其他的Mapper都处于pending状态,yarn.nodemanager.resource.memory-mb已经给到40G了,但还是不能使并行Mapper的数量有所增加,期待你的回答。
    天天向上2015-12-07 16:29 回复
    • 你这种情况应该不是你内存不够导致的,你集群总共就 8*5+12*2=64个核,再减去Hadoop守护进程占用的,也就55左右,你应该把核增加。
      w3970907702015-12-08 13:46 回复
      • 明白了,感谢您的回答。
        天天向上2015-12-08 18:06 回复
        • 比较好奇工作核能达到55个吗?默认情况下一个daemon process一个核心,64-55=9,其中resource manager一个,namenode一个,每个工作节点datanode一个,nodemanager一个(就算5个工作节点,计10个),就算不配置secondary namenode,WebAppProxy,MR job history等,也达不到55个。你说的7台机器是不是全是工作机?如果不是的话,只能认为是有些几点不是HDFS节点了。
          Yohan2015-12-15 14:52 回复
          • 忘了说,namenode的核也不会分配给node manager使用,所以会更少。默认情况下,一个mapper一个核,reducer也一样。十分好奇这个55核是怎么来的
            Yohan2015-12-15 14:58
          • 你说的很对,大部分时候是在50左右徘徊,但峰值确实有过55的时候。因为机器内存足够,所以我的配置是在所有节点都运行NodeManager和DataNode,包括运行ResourceManager和NameNode的节点,另外还运行了一个JobHistory和HBase的相关进程。
            天天向上2015-12-15 15:59