在经典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任务执行过程中，可能会有部分任务会执行地非常慢（可能因为机器老旧或者其他原因）。在任务执行时，会对任务计算出一个平均执行时间，如果预期时间内未能执行完成，那么启动一个副本执行，两个同时执行。这时候如果其中一个先执行完成，那么另一个将中止。
