在Hadoop Yarn中有5个独立的实体
- 客户端：用来提交MapReduce作业(Job)的
- Yarn ResourcesManager：用来管理协调分配集群中的资源
- Yarn NodeManager：用来启动和监控本地计算机资源单位Container的利用情况
- MapReduce Application Master：用来协调MapReduce Job下的Task的运行。它和MapReduce Task 都运行在 Container中，这个Container由RM(ResourcesManager)调度并有NM(NodeManager)管理
- HDFS：用来在其他实体之间共享作业文件
整体如下：
A.作业的提交
Job提交相似于MapReduce1.0.当在配置文件中设置mapreduce.framework.name为yarn时候，MapReduce2.0继承接口ClientProtocol的模式就激活了，RM生成新的Job ID(从Yarn的角度看是Application ID---步骤2)，接着Job客户端计算输入分片，拷贝资源(包括Job JAR文件、配置文件，分片信息)到HDFS(步骤3)，最后用submitApplication函数提交Job给RM(步骤4)
B.作业的初始化
RM接受到由上面的A提交过来的调用，将其请求给调度器处理，调度器分配Container，同时RM在NM上启动Application Master进程(步骤5a和5b)，AM主函数MRAppMatser会初始化一定数量的记录对象(bookkeeping)来跟踪Job的运行进度，并收取task的进度和完成情况(步骤6)，接着MRAppMaster收集计算后的输入分片
之后与MapReduce1.0又有所不同，此时Application Master会决定如何组织运行MapReduce Job，如果Job很小，能在同一个JVM，同一个Node运行的话，则用uber模式运行(参见源码)
C.任务的分配
如果不在uber模式下运行，则Application Master会为所有的map和reducer task向RM请求Container，所有的请求都通过heartbeat(心跳)传递，心跳也传递其他信息，例如关于map数据本地化的信息，分片所在的主机和机架地址信息，这信息帮主调度器来做出调度的决策，调度器尽可能遵循数据本地化或者机架本地化的原则分配Container
在Yarn中，不像MapReduce1.0中那样限制map或者reduce的slot个数，这样就限制了资源是利用率，Yarn中非配资源更具有灵活性，可以在配置文件中设置最大分配资源和最小分配资源，例如，用yarn.scheduler.capacity.minimum-allocation-mb设置最小申请资源1G，用yarn.scheduler.capacity.maximum-allocation-mb设置最大可申请资源10G 这样一个Task申请的资源内存可以灵活的在1G~10G范围内
D.任务的执行
分配给Task任务Container后，NM上的Application Master就联系NM启动(starts)Container，Task最后被一个叫YarnChild的main类执行，不过在此之前各个资源文件已经从分布式缓存拷贝下来，这样才能开始运行map Task或者reduce Task。PS：YarnChild是一个(dedicated)的JVM
Streaming 和 Pipes 运行机制与MapReduce1.0一样
E.进程和状态的更新
当Yarn运行同时，Task和Container会报告它的进度和状态给Application Master，客户端会每秒轮询检测Application Master，这样就随时收到更新信息，这些信息也可通过Web UI来查看
F.作业的完成
客户端每5秒轮询检查Job是否完成，期间需要调用函数Job类下waitForCompletion()方法,Job结束后该方法返回。轮询时间间隔可以用配置文件的属性mapreduce.client.completion.pollinterval来设置
