MRv1存在的主要问题是：在运行时，JobTracker既负责资源管理又负责任务调度，这导致了它的扩展性、资源利用率低等问题。之所以存在这样的问题，是与其最初的设计有关，如下图：
从上图可以看到，MRv1是围绕着MapReduce进行，并没有过多地考虑以后出现的其它数据处理方式 。按着上图的设计思路，我们每开发一种数据处理方式（例如spark），都要重复实现相应的集群资源管理和数据处理。因此，Yarn就很自然的被开发出来了.
Yarn对MRv1的最大改进就是将资源管理与任务调度分离，使得各种数据处理方式能够共享资源管理，如
下图所示：
从上图我们可以看到，Yarn是一种统一资源管理方式，是从MRv1中的JobTracker分离出来的。这样的好处显而易见：资源共享，扩展性好等。
MRv1与Yarn的主要区别：在MRv1中，由JobTracker负责资源管理和作业控制，而Yarn中，JobTracker被分为两部分：ResourceManager（RM）和ApplicationMaster（AM）。如下图所示：
从上图中，我们可以清晰的看到 ，对于MRv1无论是资源管理里还是任务调度都是有JobTracker来完成得。这导致了，JobTracker负荷太大不便于管理和扩展而对于Yarn，我们看可以清晰地看到资源管理和任务调度被分为了两个部分：RM和AM。
Yarn与MRv1的差异对编程的影响：我们知道，MRv1主要由三部分组成：编程模型(API)、数据处理引擎(MapTask和ReduceTask)和运行环境(JobTracker和TaskTracker);Yarn继承了MRv1的编程模型和数据处理，改变的只是运行环境，所以对编程没有什么影响。
为了更好 的说明Yarn的资源管理，首先来看下Yarn的框架，如下图所示：
从上图可以看到 ，当客户向RM提交 作业时，由AM负责向RM提出资源申请，和向NameManager（NM）提出task执行 。也就是说 在这个过程中，RM负责资源调度，AM 负责任务调度。几点重要说明：RM负责整个集群的资源管理与调度；Nodemanager(NM)负责单个节点的资源管理与调度；NM定时的通过心跳的形式与RM进行通信，报告节点的健康状态与内存使用情况；AM通过与RM交互获取资源，然后然后通过与NM交互，启动计算任务。
下面对上面的内容通过内存资源配置进行详细说明：
RM的内存资源配置，主要是通过下面的两个参数进行的（这两个值是Yarn平台特性，应在yarn-sit.xml中配置好）：
yarn.scheduler.minimum-allocation-mb
yarn.scheduler.maximum-allocation-mb
说明：单个容器可申请的最小与最大内存，应用在运行申请内存时不能超过最大值，小于最小值则分配最小值，从这个角度看，最小值有点想操作系统中的页。最小值还有另外一种用途，计算一个节点的最大container数目注：这两个值一经设定不能动态改变(此处所说的动态改变是指应用运行时)。
NM的内存资源配置，主要是通过下面两个参数进行的（这两个值是Yarn平台特性，应在yarn-sit.xml中配置） ：
yarn.nodemanager.resource.memory-mb
yarn.nodemanager.vmem-pmem-ratio
说明：每个节点可用的最大内存，RM中的两个值不应该超过此值。此数值可以用于计算container最大数目，即：用此值除以RM中的最小容器内存。虚拟内存率，是占task所用内存的百分比，默认值为2.1倍;注意：第一个参数是不可修改的，一旦设置，整个运行过程中不可动态修改，且该值的默认大小是8G，即使计算机内存不足8G也会按着8G内存来使用。
AM内存配置相关参数，此处以MapReduce为例进行说明（这两个值是AM特性，应在mapred-site.xml中配置），如下：
mapreduce.map.memory.mb
mapreduce.reduce.memory.mb
说明：这两个参数指定用于MapReduce的两个任务（Map and Reduce task）的内存大小，其值应该在RM中的最大最小container之间。如果没有配置则通过如下简单公式获得：
max(MIN_CONTAINER_SIZE, (Total Available RAM) / containers))
一般的reduce应该是map的2倍。注：这两个值可以在应用启动时通过参数改变；
AM中其它与内存相关的参数，还有JVM相关的参数，这些参数可以通过，如下选项配置：
mapreduce.map.java.opts
mapreduce.reduce.java.opts
说明：这两个参主要是为需要运行JVM程序（java、scala等）准备的，通过这两个设置可以向JVM中传递参数的，与内存有关的是，-Xmx，-Xms等选项。此数值大小，应该在AM中的map.mb和reduce.mb之间。
-------------------------------------------------------------------------------------------
下面通过一个具体错误实例，进行内存相关说明，错误如下：
Container[pid=41884,containerID=container_1405950053048_0016_01_000284] is running beyond virtual memory limits. Current usage: 314.6 MB of 2.9 GB physical memory used; 8.7 GB of 6.2 GB virtual memory used. Killing container.
配置如下：
<property> <name>yarn.nodemanager.resource.memory-mb</name> <value>100000</value> </property> <property> <name>yarn.scheduler.maximum-allocation-mb</name> <value>10000</value> </property> <property> <name>yarn.scheduler.minimum-allocation-mb</name> <value>3000</value> </property> <property> <name>mapreduce.reduce.memory.mb</name> <value>2000</value> </property>
通过配置我们看到，容器的最小内存和最大内存分别为：3000m和10000m，而reduce设置的默认值小于2000m，map没有设置，所以两个值均为3000m，也就是log中的“2.9 GB physicalmemory used”。而由于使用了默认虚拟内存率(也就是2.1倍)，所以对于Map Task和Reduce Task总的虚拟内存为都为3000*2.1=6.2G。而应用的虚拟内存超过了这个数值，故报错 。解决办法：在启动Yarn是调节虚拟内存率或者应用运行时调节内存大小。
-------------------------------------------------------------------------------------------
在上Yarn的框架管理中，无论是AM从RM申请资源，还是NM管理自己所在节点的资源，都是通过container进行的。Container是Yarn的资源抽象，此处的资源包括内存和cup等。下面对container，进行比较详细的介绍。为了是大家对container有个比较形象的认识，首先看下图：
从上图中我们可以看到，首先AM通过请求包ResourceRequest从RM申请资源，当获取到资源后，AM对其进行封装，封装成ContainerLaunchContext对象，通过这个对象，AM与NM进行通讯，以便启动该任务.