白话hadoop yarn的调度过程以mapreduce程序为例
2017-01-25 11:54
316 查看
今天上完班,终于可以回去了,现在在公司没什么事干,就用白话来总结下mapreduce的执行流程吧,如果有错误的地方大家尽管指出。
首先在hadoop 1.x中和hadoop 2.x中,mapreduce的执行流程也不一样(完全不一样),在hadoop1.x中 mapreduce的 资源管理与分配和任务监控都是集中在 jobtracker 上,这样会造成jobtracker的负担非常大,而且在hadoop 1.x中没有jobtracker的HA机制,从而会让集群的健壮性很差。
这里只大概介绍下hadoop1.x mapreduce的执行流程:
client端提交job给jobtracker,jobtracker会给这个job分配资源,在tasktracker上启动task任务,而且还要监控task任务的状况,如果task挂了,jobtracker还得重新分配新的资源给挂了的task任务,当task执行完成后,jobtracker会为reduce任务分配资源,然后监控reduce的执行流程,最后执行完成输出。
hadoop 2.x 用yarn框架,使资源的调度和监控分开,并且实现了resourcemanager的HA(通过zkfc进程和zookeeper管理实现)。
看似上面的hadoop 2.x和1.x的架构差不了多少,但是他们的执行流程却完全不一样:
yarn调度流程:
client端会调用resourcemanager,申请执行一个job
resourcemanager会给客户端返回一个hdfs的目录以及一个application_id号。
client端会将切片信息、job的配置信息以及jar包上传到上一步收到的hdfs目录下(三个文件分别是:job.split、job.xml、jar包)
client请求resourcemanager启动mrappmaster
resourcemanager将client请求初始化成一个task任务,放到执行队列里面(默认FIFO),当执行到这个task的时候会给该job分配资源。
resourcemanager会找空闲的nodemanager创建一个container容器,并启动mrappmaster
当mrappmaster启动之后会先将client提交hdfs的资源(job.split、job.xml、jar包)下载到本地
mrappmaster根据资源信息的情况请求resourcemanager启动maptask
resourcemanager会为上面的请求找空闲的nodemanager并创建maptask的container
mrappmaster将资源发送给各个nodemanager并且启动上面相应的maptask程序,监控maptask的运行情况(如果maptask挂掉之后,由mrappmaster去处理)。
当maptask执行完成后,mrappmaster又会向resourcemanager申请reducetask的资源
resourcemanager又会为上面的请求找空闲的nodemanager并创建reducetask的container
mrappmaster然后又启动reducetask任务,并且监控reducetask任务的执行状况。
直到mapreduce的程序执行完成
当mrappmaster挂掉之后,resourcemanager会重新找其他的nodemanager并重新启动一个新的mrappmaster,所以mrappmaster不存在点单故障问题。
首先在hadoop 1.x中和hadoop 2.x中,mapreduce的执行流程也不一样(完全不一样),在hadoop1.x中 mapreduce的 资源管理与分配和任务监控都是集中在 jobtracker 上,这样会造成jobtracker的负担非常大,而且在hadoop 1.x中没有jobtracker的HA机制,从而会让集群的健壮性很差。
这里只大概介绍下hadoop1.x mapreduce的执行流程:
client端提交job给jobtracker,jobtracker会给这个job分配资源,在tasktracker上启动task任务,而且还要监控task任务的状况,如果task挂了,jobtracker还得重新分配新的资源给挂了的task任务,当task执行完成后,jobtracker会为reduce任务分配资源,然后监控reduce的执行流程,最后执行完成输出。
hadoop 2.x 用yarn框架,使资源的调度和监控分开,并且实现了resourcemanager的HA(通过zkfc进程和zookeeper管理实现)。
看似上面的hadoop 2.x和1.x的架构差不了多少,但是他们的执行流程却完全不一样:
yarn调度流程:
client端会调用resourcemanager,申请执行一个job
resourcemanager会给客户端返回一个hdfs的目录以及一个application_id号。
client端会将切片信息、job的配置信息以及jar包上传到上一步收到的hdfs目录下(三个文件分别是:job.split、job.xml、jar包)
client请求resourcemanager启动mrappmaster
resourcemanager将client请求初始化成一个task任务,放到执行队列里面(默认FIFO),当执行到这个task的时候会给该job分配资源。
resourcemanager会找空闲的nodemanager创建一个container容器,并启动mrappmaster
当mrappmaster启动之后会先将client提交hdfs的资源(job.split、job.xml、jar包)下载到本地
mrappmaster根据资源信息的情况请求resourcemanager启动maptask
resourcemanager会为上面的请求找空闲的nodemanager并创建maptask的container
mrappmaster将资源发送给各个nodemanager并且启动上面相应的maptask程序,监控maptask的运行情况(如果maptask挂掉之后,由mrappmaster去处理)。
当maptask执行完成后,mrappmaster又会向resourcemanager申请reducetask的资源
resourcemanager又会为上面的请求找空闲的nodemanager并创建reducetask的container
mrappmaster然后又启动reducetask任务,并且监控reducetask任务的执行状况。
直到mapreduce的程序执行完成
当mrappmaster挂掉之后,resourcemanager会重新找其他的nodemanager并重新启动一个新的mrappmaster,所以mrappmaster不存在点单故障问题。
相关文章推荐
- hadoop 0.23 YARN分布式程序的编写 (Hadoop MapReduce Next Generation - Writing YARN Applications)
- Hadoop 调试第一个MapReduce程序过程详细记录总结
- Hadoop 调试第一个mapreduce程序过程详细记录总结以及权限问题 Permission denied: user=dr.who
- hadoop2提交到Yarn: Mapreduce执行过程reduce分析3
- Hadoop 调试第一个mapreduce程序过程详细记录总结
- hadoop2 作业执行过程之yarn调度执行
- Hadoop 2.x环境搭建之三配置部署启动YARN及在YARN上运行MapReduce程序
- hadoop2提交到Yarn: Mapreduce执行过程分析2
- Hadoop环境搭建三之配置部署启动YARN以及在YARN上运行MapReduce程序
- hadoop2提交到Yarn: Mapreduce执行过程分析
- Hadoop MapReduce 程序执行过程
- hadoop 0.23 YARN分布式程序的编写 (Hadoop MapReduce Next Generation - Writing YARN Applications)
- hadoop2提交到Yarn: Mapreduce执行过程分析1
- Hadoop v2(Yarn) 调度分析 (1) JobClient 的提交过程
- hadoop2提交到Yarn: Mapreduce执行过程分析
- hadoop2提交到Yarn: Mapreduce执行过程分析2
- hadoop2提交到Yarn: Mapreduce执行过程reduce分析3
- Hadoop2 使用 YARN 运行 MapReduce 的过程源码分析
- hadoop2提交到Yarn: Mapreduce执行过程分析2
- Hadoop详解(三)——MapReduce原理和执行过程,远程Debug,Writable序列化接口,MapReduce程序编写