欢迎您光临本小站。希望您在这里可以找到自己想要的信息。。。

Hadoop之MapReduce的两种任务模式

大数据云计算 water 239℃ 0评论

MapReduce按照任务大小和设置的不同,提供了两种任务模式:

老一些的版本还有一个JobTracker的实现类,即:classic。用于和MapReduce1.X兼容用的,高一些的版本已经没有这个实现类了。

一,本地模式(LocalJobRunner实现)

mapreduce.framework.name设置为local,则不会使用YARN集群来分配资源,在本地节点执行。在本地模式运行的任务,无法发挥集群的优势。注:在web UI是查看不到本地模式运行的任务。

二,Yarn模式(YARNRunner实现)

mapreduce.framework.name设置为yarn,当客户端配置mapreduce.framework.name为yarn时, 客户端会使用YARNRunner与服务端通信, 而YARNRunner真正的实现是通过ClientRMProtocol与RM交互, 包括提交Application, 查询状态等功能。但是根据任务的特性,分为两种方式执行任务:

1,uber mode:

         Uber模式是Hadoop2.0针对MR小作业的优化机制。通过mapreduce.job.ubertask.enable来设置是否开启小作业优化,默认为false。

        如果用Job足够小,则串行在的一个JVM完成该JOB,即MRAppMaster进程中,这样比为每一个任务分配Container性能更好。

        那么什么才是足够小的Job呢?下面我们看看一些的参数(mapred-site.xml):

mapreduce.job.ubertask.maxmaps 最大的map数。默认值9

mapreduce.job.ubertask.maxreduces 最大的reduce数,默认为1

mapreduce.job.ubertask.maxbytes 最大的字节数,如果没有指定,默认和dfs.block.size一样。

应用程序的其他配置也会影响到对“小”的定义,yarn.app.mapreduce.am.resource.mb必须大于mapreduce.map.memory.mb和mapreduce.reduce.memory.mb,还有yarn.app.mapreduce.am.resource.cpu-vcores必须大于mapreduce.map.cpu.vcores 和 mapreduce.reduce.cpu.vcores,以下是这个配置的说明:

yarn.app.mapreduce.am.resource.mb   MR AppMaster需要的内存数,默认为1536

mapreduce.map.memory.mb  从调度器(scheduler)为每个Map Task请求的内存数,默认1024

mapreduce.reduce.memory.mb  从调度器(scheduler)为每个Reduce Task请求的内存数,默认1024

yarn.app.mapreduce.am.resource.cpu-vcores MR AppMaster需要的虚拟CPU核数,默认为1536

mapreduce.map.cpu.vcores 从调度器(scheduler)为每个Map Task请求的虚拟CPU核数,默认1

mapreduce.reduce.cpu.vcores  为每个Map Reduce请求的虚拟CPU核数,默认1

 链式Job也不能使用Uber模式执行,即使满足了上面的情况也不能。因为链式作业会并发执行不同资源需求的map task和reduce task。链式Job是指集成了org.apache.hadoop.mapreduce.lib.chain.ChainReducer和org.apache.hadoop.mapreduce.lib.chain.ChainMapper类的用户Map或Reduce程序。

yarn.app.mapreduce.am.resource.mb和yarn.app.mapreduce.am.resource.cpu-vcores是在yarn框架的级别,其他四个关于内存和CPU的配置是和具体每个Mapreduce任务有关,如果Mapreduce所需的资源大于Yarn框架定义的资源数量,则不能当成“小”Job使用uber mode执行了。

2,Non-Uber mode:

Uber只能执行一小部门的任务,在大数据环境下,大部分任务仍然运行在Non-Uber模式下,MRAppMaster将一个作业的map task和reduce task分为四种状态:

      pending:刚启动但尚未向ResourceManager发送资源请求

      scheduled:已经向ResourceManager发送资源请求,但尚未分配到资源

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

      completed:已经运行完成。

MRAppMaster初始化之后,会产生一系列的Map Task和Reduce Task。

      Map Task的生命周期是:

      scheduled->assigned->completed

      Reduce Task的生命周期是:

 pending->scheduled->assigned->completed

上面我们可以看到,Reduce Task比Map Task多一个pending的状态,主要是因为Reduce Task需要依赖Map Task的输出,为了防止Reduce Task启动过早造成资源浪费,MRAppMaster让刚启动的Reduce Task处于pending状态,这样可以根据Map Task的运行情况和具体的配置来调整Reduce Task状态(pengding到scheduled中相互转移),以下几个参数是有来配置Reduce Task的启动时机的:

mapreduce.job.reduce.slowstart.completedmaps     map task完整了多少比率才开始为reduce task生成资源

yarn.app.mapreduce.am.job.reduce.rampup.limit     在maps task已经完成,启动reduce task的比率。默认为0.5

——————— 

作者:qianshanding0708 

来源:CSDN 

原文:https://blog.csdn.net/qianshangding0708/article/details/47702057 

版权声明:本文为博主原创文章,转载请附上博文链接!

转载请注明:学时网 » Hadoop之MapReduce的两种任务模式

喜欢 (0)or分享 (0)

您必须 登录 才能发表评论!