前言
在经典MR架构中,JobTracker担负资源分配、任务管理等工作,当集群规模越来越大时,JobTracker将不堪重负。例如在Yahoo的集群规模达到4000个节点时,就无法再增长,严重影响了hadoop分布式处理的可伸缩性。因此在hadoop2.x版本,推出了YARN架构来解决这个问题。
YARN将JobTracker中的资源分配和任务管理工作分离开来,分为ResourceManger(资源管理器)、ApplicationMaster(应用管理器,用来管理任务进度等)、NodeManager(节点管理器,用来运行任务)。
应用运行流程
1.client向ResourceManager申请一个新的ApplicationID(这里Application相当于Job)。
2.client计算出MR作业输入分片信息(可设置为集群计算分片)。
3.client提交作业到ResourceManager节点。
4.ResourceManager节点找到可用NodeManager节点列表,调度器在可用NodeManager节点中创建容器(包含内存、cpu等资源)运行ApplicationMaster。
5.ApplicationMaster根据client计算出的输入分片,为每一个分片创建一个Map任务对象,创建一定数量的reduce任务对象。
6.如果作业规模较小(默认是10个map和1个reduce,可配置),将作为uber任务运行(uber组件用于jvm重用),在单个容器中并发运行整个作业。
7.对于不能作为uber任务运行的作业,ApplicationMaster将会向ResourceManager申请一个容器,并且调度器按照策略分配给NodeManager。NodeManager中不像TaskTracker那样设置固定数量的槽,槽的最大内存限制是固定的,而是动态设置内存限制,可动态分配。
8.ApplicationMaster通过与NodeManager通信启动容器,容器启动时创建JVM虚拟机,并且将任务所需资源本地化,最后运行任务。
9.任务每3秒钟向ApplicationMaster更新任务进度和状态,如果任务因异常(内存溢出等)失败,ApplicationMaster可重新申请容器启动任务。ApplicationMaster因异常结束时,ResourceManager会重新启动AppliactionMaster。
10.Map任务中运行完成后,中间输出将会存放到本地文件中,在此之前会进行Shuffle对输出内容进行按键排序。Map任务设置有任务输出内存缓冲区,默认大小100M,当数据量超出缓冲区一定百分比(默认80%)后,将会向磁盘中写入。排序完成之后,将数据写入磁盘,并且传递给reduce。这时候如果在数据量大的情况下,带宽就将严重影响效率。有两种做法可减少磁盘数据存储量和传输量,可缓解这样的问题。一种是本地reduce任务方式(称作Combiner),在本地对map输出数据进行初步整合;另一种是对输出数据进行压缩处理;两者可同时采用。
11.reduce任务拿到map传过来的数据之后,将对数据进行合并,将数据按键合并,而后进行reduce操作。reduce任务如果不是全局的操作,可根据分区设置多个。
推测执行
在MR任务执行过程中,可能会有部分任务会执行地非常慢(可能因为机器老旧或者其他原因)。在任务执行时,会对任务计算出一个平均执行时间,如果预期时间内未能执行完成,那么启动一个副本执行,两个同时执行。这时候如果其中一个先执行完成,那么另一个将中止。