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的两种任务模式