ApplicationMaster 启动以后，对 作业（也就是 Application） 进行拆分，拆分 task 出来，这些 task 可以运行在一个或多个容器中。然后向 ResourceManager 申请要运行程序的容器，并定时向 ResourceManager 发送心跳。
申请到容器后，ApplicationMaster 会去和容器对应的 NodeManager 通信，而后将作业分发到对应的 NodeManager 中的容器去运行，这里会将拆分后的 MapReduce 进行分发，对应容器中运行的可能是 Map 任务，也可能是 Reduce 任务。
容器中运行的任务会向 ApplicationMaster 发送心跳，汇报自身情况。当程序运行完成后， ApplicationMaster 再向 ResourceManager 注销并释放容器资源。
以上就是一个作业的大体运行流程。
为什么会有 Yarn ？上面说了这么多，最后我们来聊聊为什么会有 Yarn 吧。
直接的原因呢，就是因为 Hadoop1.0 中架构的缺陷，在 MapReduce 中，jobTracker 担负起了太多的责任了，接收任务是它，资源调度是它，监控 TaskTracker 运行情况还是它。这样实现的好处是比较简单，但相对的，就容易出现一些问题，比如常见的单点故障问题。
要解决这些问题，只能将 jobTracker 进行拆分，将其中部分功能拆解出来。彼时业内已经有了一部分的资源管理框架，比如 mesos，于是照着这个思路，就开发出了 Yarn。这里多说个冷知识，其实 Spark 早期是为了推广 mesos 而产生的，这也是它名字的由来，不过后来反正是 Spark 火起来了。。。
闲话不多说，其实 Hadoop 能有今天这个地位，Yarn 可以说是功不可没。因为有了 Yarn ，更多计算框架可以接入到 Hdfs 中，而不单单是 MapReduce，到现在我们都知道，MapReduce 早已经被 Spark 等计算框架赶超，而 Hdfs 却依然屹立不倒。究其原因，正式因为 Yarn 的包容，使得其他计算框架能专注于计算性能的提升。Hdfs 可能不是最优秀的大数据存储系统，但却是应用最广泛的大数据存储系统，Yarn 功不可没。