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

MapReduce作业的map task和reduce task调度参数

  MapReduce作业可以细分为map task和reduce task,而MRAppMaster又将map task和reduce task分为四种状态:

  1、pending:刚启动但尚未向resourcemanager发送资源请求;

  2、scheduled:已经向resourceManager发送资源请求,但尚未分配到资源;

  3、assigned:已经分配到了资源且正在运行;

  4、completed:已经运行完成。

  map task的生命周期为:scheduled -> assigned -> completed
  reduce task 生命周期:pending -> scheduled -> assigned -> completed。

  由于reduce task的执行需要依赖于map task的输出结果,因此,为避免reduce task过早启动造成资源利用率底下,MRAppMaster让刚启动的reduce处于pending状态,以便能够根据map task的运行情况决定是否对其进行调度。

  那么如何确定reduce task启动时机呢?因为YARN没有Hadoop 1.x里面的map slot和reduce slot概念,且ResourceManager也不知道map task和reduce task之间的依赖关系,因此MRAppMaster自己需要设计资源申请策略以防止因reduce task过早启动照成资源利用率低下和map task因分配不到资源而饿死。MRAppMaster在MRv1原有策略(map task完成数目达到一定比例后才允许启动reduce task)基础上添加了更为严格的资源控制策略和抢占策略,这里主要涉及到以下三个参数:

  mapreduce.job.reduce.slowstart.completedmaps:其英文含义是:Fraction of the number of maps in the job which should be complete before reduces are scheduled for the job。当map task完成的比例达到该值后才会为reduce task申请资源,默认是0.05。

  yarn.app.mapreduce.am.job.reduce.rampup.limit:在map task完成之前,最多启动reduce task比例,默认是0.5

  yarn.app.mapreduce.am.job.reduce.preemption.limit:当map task需要资源但暂时无法获取资源(比如reduce task运行过程中,部分map task因结果丢失需重算)时,为了保证至少一个map task可以得到资源,最多可以抢占reduce task比例,默认是0.5

  如果上面三个参数设置的不合理可能会出现提交的job出现大量的reduce被kill掉,这个问题其实是reduce 任务启动时机的问题,由于yarn中没有map slot和reduce slot的概念,且ResourceManager也不知道map task和reduce task之间的依赖关系,因此MRAppMaster自己需要设计资源申请策略以防止因reduce task过早启动照成资源利用率低下和map task因分配不到资源而饿死,然后通过抢占机制,大量reduce任务被kill掉。可以合理调节上面三个配置参数来消除这种情况。

本博客文章除特别声明,全部都是原创!
转载本文请加上:转载自过往记忆(https://www.iteblog.com/)
本文链接: 【MapReduce作业的map task和reduce task调度参数】(https://www.iteblog.com/archives/1724.html)
喜欢 (4)
分享 (0)
发表我的评论
取消评论

表情
本博客评论系统带有自动识别垃圾评论功能,请写一些有意义的评论,谢谢!