handoop job工作运行的机制与原理详解

声明:本博文的图片来自于董西城《hadoop技术内幕》;HDFS原理以及MapReduce的简单原理请移步我之前的博客,也欢迎关注我的大数据专栏,这是我入门学习大数据的完整历程,欢迎提出建议以及知识交流。

handoop job工作运行的机制与原理详解

上图是hadoop MapReduce的作业生命周期图。
或者看一个更简单的图,下图是MapReduce的架构图
handoop job工作运行的机制与原理详解
大致分为几个步骤:
第一个阶段:作业提交与初始化
用户通过client提交MapReduce作业给JobTracker,这个client可以理解实现一般的客户端的功能就是用来让用户和内部架构进行互动,不仅可以提交作业,还有可以client提供的一些借口进行查询作业的运行状况。其实用户并不是直接将作业提交给JobTracker。在提交给JobTracker前,用户提交作业压缩包jar,hadoop中Jobclient类根据内部的jar命令将作业通过Runjar中的main函数将压缩包解压,并配置环境,将其中的参数传递给MapReduce程序。除准备环*,作业提交过程还需要获取作业ID,创建HDFS目录,上传作业文件到HDFS,生成split文件等。(用户编写的MapReduce程序中已经配置了,Mapper类,Reducer类以及Reduce Task个数等)。经过以上步骤才将作业提交给JobTracker。第一张图中已经写出jobclient是通过RPC来通知JobTracker的。hadoop RPC框架—-remote procedure call远程过程调用是一种分布式网络通信协议,它实现了一台计算机上的程序可以调用另一台计算机上的子程序,同时将网络的细节部分封装隐藏起来,用户不需要再进行编程开发。(随后会总结一下RPC的原理)。JobTracker就像名字所写的那样,就是负责资源监控和作业调度的。举个例子,就是哪个节点资源空闲,资源使用情况,哪个作业健康有问题更换节点,作业的状态和进度等,都归它管,作业调度是由hadoop内部的调度器来配合完成的。JobTracker收到作业后,会对作业进行初始化,根据输入数据的量和作业的配置参数分解若干个Map Task 和Reduce Task。但事实上JobTracker收到作业也没有立即初始化,这是为了更好的利用资源以及更合适的分配任务,初始化是调度器TaskScheduler完成的,初始化后的作业才可以被调度。在初始化之前,JobTracker要尽职的各项参数是否符合,并为作业创建JobInProgress来完成监管任务。

第二阶段 任务调度与监控
第一阶段也提到了JobTracker的任务的调度与监控作用,具体实现过程是这样的:如上图展示的那样,TaskTracker通过heartbeat周期性的向JobTracker汇报本节点的资源使用情况。这里的heartbeat涉及的通信模式叫做心跳接收和应答,它实际仍然是一个RPC函数,TaskTracker通过调用此函数来汇报各节点的资源利用情况以及任务的状态。JobTracker与TaskTracker之间采用了pull模式,就是说JobTracker从来不主动发布命令,而是通过TaskTracker的心跳应答来分配任务的。因此心跳的作用是向JobTracker证明TaskTracker还活着,周期性让JobTracker获取信息,领取TaskTracker的任务。另一方面,心跳应答就是下达任务和下达汇报下次心跳的时间间隔。下达给TaskTracker的命令有重新初始化,运行新任务,杀死作业,提交任务。从下达的命令可以看出TaskTracker是有不错的容错机制的,主要包括超时机制,建立灰名单和黑名单。超时机制某个TaskTracker没有在一定时间内汇报心跳(时间可以自己设置)就会因为超时被移除,但移除并不是简单的删除还有一个回收机制,这里不仔细说了。灰名单就是被加入的TaskTracker还有机会被放出继续执行任务,而进入黑名单则没有机会复活。
第三阶段:任务环境准备
这里的环境准备是更宏观的环境,与第一阶段的初始化前的环境准备不是一个层次。这里由TaskTracker来实现,准备的是Java虚拟机JVM,每个Task都有单独的一个JVM,避免不同的JVM在运行时互相影响,同时也实现了资源隔离防止TaskTracker滥用资源。至于TaskTracker的运行就是第二阶段描述的镜像。
第四阶段:任务执行
这个阶段就是上篇博文中简单描述的MapReduce的过程,当然这也里面穿插着了TaskTracker不断向JobTracker汇报情况的过程,直到所有的任务完成,将结果保存在HDFS中。