Yarn我的简单理解就是一个资源分配和协调器，可以参看下面这张官方的图解，既然是一个资源管理框架，就不仅仅局限用在Hadoop里面，像Spark里面好像也可以用，具体还没研究过。
Client提交一个Job，这个时候Job就需要向ResourceManager请求资源，
ResourceManger(RM) 包含2部分：
- ApplicationsManager
- Scheduler
ApplicationsManager(ASM)负责接收job提交请求，协调ApplicationMaster, 重启失败的ApplicationMaster container。
Scheduler负责分配资源给运行的application， 是一个纯调度器，具体的调度规则还可以插件化。
App Mstr(AM) 上图中的App Mstr其实应该 叫pre-application ApplicationMaster（个人觉得跟上面的RM里面的ApplicationMaster一样），这个是基于应用的ApplicationMaster，主要负责从RM获取合适的containers，监控这些containers。
NodeManager(NM)负责Container的管理， 监控他们的资源使用情况（CPU，内存，磁盘，网络），然后报告给ResourceManager的Scheduler
总结：
全局的ResourceManager（RM）和与每个应用相关的ApplicationMaster（AM）。这里的“应用”指一个单独的MapReduce作业或者DAG作业。
ResourceManager（RM）和与NodeManager（NM，每个节点一个）共同组成整个数据计算框架。
为了更加直观一点，下面是一张Yarn的web监控界面（http://apc-lgdcdevl201:8088/cluster）
Yarn在最新的hadoop版本里面才有，下面是别人总结的好处：
- 这个设计大大减小了 JobTracker（也就是现在的 ResourceManager）的资源消耗，并且让监测每一个 Job 子任务 (tasks) 状态的程序分布式化了，更安全、更优美。
- 在新的 Yarn 中，ApplicationMaster 是一个可变更的部分，用户可以对不同的编程模型写自己的 AppMst，让更多类型的编程模型能够跑在 Hadoop 集群中，可以参考 hadoop Yarn 官方配置模板中的 mapred-site.xml 配置。
- 对于资源的表示以内存为单位 ( 在目前版本的 Yarn 中，没有考虑 cpu 的占用 )，比之前以剩余 slot 数目更合理。
- 老的框架中，JobTracker 一个很大的负担就是监控 job 下的 tasks 的运行状况，现在，这个部分就扔给 ApplicationMaster 做了，而 ResourceManager 中有一个模块叫做 ApplicationsMasters( 注意不是 ApplicationMaster)，它是监测 ApplicationMaster 的运行状况，如果出问题，会将其在其他机器上重启。
- Container 是 Yarn 为了将来作资源隔离而提出的一个框架。这一点应该借鉴了 Mesos 的工作，目前是一个框架，仅仅提供 java 虚拟机内存的隔离 ,hadoop 团队的设计思路应该后续能支持更多的资源调度和控制 , 既然资源表示成内存量，那就没有了之前的 map slot/reduce slot 分开造成集群资源闲置的尴尬情况。
参考文章：
http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/YARN.html
http://www.ibm.com/developerworks/cn/opensource/os-cn-hadoop-yarn/