【MR】YARN 运行机制

【MR】YARN 运行机制

熟悉了YARN的整体框架。就看看YARN的运行机制

YARN的运行过程、



1，作业提交

该过程与MR1的很相似。步骤1使用的API以及过程与MR1的相同，让后从Resource Manager中获取新的ID，这是一个应用程序的ID（步骤2）。接着客户端检查作业的输出分片，计算输入分片并将作业资源复制到HDFS中。最后，调用Resource Manager调用submitApplication()提交作业。

2，作业初始化

(1)首先，Resource Manager里的Application Manager会为每一个application(比如一个用户提交的MapReduce Job)在NodeManager里面申请一个container，schedule则在NodeManager里面分配申请的container。然后在该container里面启动一个Application Master(步骤5a，5b)。

(2)Application Master的主类是MRAppMaster。其通过创造一些bookkeeping对象来监控作业的进度, 得到任务的进度和完成报告(步骤6). 然后其通过分布式文件系统得到由客户端计算好的输入分片(split)(步骤7). 然后为每个输入分片创建一个map任务, 根据mapreduce.job.reduces创建reduce任务对象。

(3)Application Master决定如何运行构成整个作业的任务. 如果作业很小, Application Master会选择在其自己的JVM中运行任务, 这种作业称作是被unerized, 或者是以uber模式的方式运行。

(4)在任务运行之前, 作业的setup方法被调用来创建输出路径，在YARN中是由Application Master调用的。

3，任务分配

如果不是小作业, 那么应用管理器向资源管理器请求container来运行所有的map任务和reduce任务(步骤8)，每个任务对应一个container，且只能在该container上运行。这些请求是通过心跳来传输的, 包括每个map任务的数据位置, 比如存放输入分片的主机名和机架(rack). 调度器利用这些信息来调度任务, 尽量将任务分配给存储数据的节点, 或者退而分配给和存放输入分片的节点相同机架的节点。

请求也包括了任务的内存需求, 默认情况下map和reduce任务的内存需求都是1024MB，可以通过mapreduce.map.memory.mb和mapreduce.reduce.memory.mb来配置。

分配内存的方式和MR1中不一样, MR1中每个tasktracker有固定数量的任务槽, 任务槽是在集群配置是设置的, 每个任务运行在一个任务槽中, 每个任务槽都有最大内存限制, 这也是整个集群固定的，这种方式很不灵活。而在YARN中, 资源划分的粒度更细，应用的内存需求可以介于最小内存和最大内存之间, 并且必须是最小内存的倍数。

4，任务执行

当一个任务由Resource Manager的调度器分配给一个container后, Application Master通过节点管理器来启动container(步骤9a，步骤9b)。任务有一个主类为YarnChild的Java应用执行，在运行任务之前首先本地化任务需要的资源, 比如作业配置, JAR文件, 以及分布式缓存的所有文件(步骤10)。最后, 运行map或reduce任务(步骤11)。

5，进度和状态更新

YARN中的任务将其进度和状态(包括counter)返回给Application Master,作为作业的汇聚视图。这和MR1不太一样,后者的进度流从tasktracker到jobtracker。

客户端每秒(通过mapreduce.client.progressmonitor.pollinterval设置)向Application Master请求进度更新, 展示给用户。

6，作业完成

除了向Application Master请求作业进度外, 客户端每5分钟都会通过调用waitForCompletion()来检查作业是否完成，时间间隔可以通过mapreduce.client.completion.pollinterval来设置。作业完成之后, 应用管理器和container会清理工作状态, OutputCommiter的作业清理方法也会被调用，作业的信息会被作业历史服务器存储以备之后用户核查。