Hadooop1.0时代
由于Hadoop1.0良好特性，比如说bat，Facebook，雅虎等都在大数据处理系统中用了Hadoop，但是随着Hadoop1.0使用的日益丰富，用的越来越多了，那么原来的Hadoop1.0中存在的问题逐渐暴露出来。主要体现在四个方面。
SPOF
第一个方面单点故障。因为Hadoop1.0时候NameNode和JobTracker设计成单一结点。JobTracker是提交任务的管理者，但是它是单节点，一旦该节点出现故障对整个系统产生致命性影响。因为NameNode和JobTracker放在了一起，这严重制约了Hadoop的可可展性和可靠性。因为我们是在生产环境中使用，如果不能做到高可靠，我们的生产系统很难做到大规模推广。随着我们的业务越来越多，所部署的大数据系统不可能就放一个业务，而是有一个任务队列，在任务队列中也有许多的任务，随着JobTracker的业务增长，处理任务也随着增长同时内存消耗过大也会产生一些任务失败的情况，那么单节点就将大规模的应用给堵死了。
Only MR
第二个方面是仅仅支持MapReduce。这个计算模式比较单一。然而在现实业务中存在很多的需求，比如，对实时业务及时处理就产生了Storm和Spark。需要图的处理，图是计算机里非常重要的数据结构抽象，也需要这种处理模式。这些就不仅仅是MapReduce可以解决的处理框架。那么怎么样整合这些处理框架，数据在Hadoop中，不能将计算搬移到数据所在的节点上，那么框架的应用会受到很大的限制。
MR Slot
第三个方面是MapReduce框架不够灵活。因为Map和Reduce绑得太死，先进行Map再进行Reduce中间有个Shuffle，这个作为整个Map和Reduce的耦合点之一。因为Map和Reduce作为一个整体给用户使用的，但是，并不是每个业务都需要同时操作，有时只需要其中之一。但是Hadoop1.0中TaskTracker将任务分解为Map Tracker Slot和Reduce Tracker Slot。Slot在大数据的理解为分配的资源词，从硬件的Slot抽象到软件的Slot。如果，当前节点只存在Map或者只存在Reduce这种任务，需要同时分配两个插槽也就是两个Slot，这样就会造成资源浪费，因为只有单一的Map和单一的Reduce。
RM
最后一个方面是资源管理不灵活，因为采用的是静态Slot分配措施，就是在任务提交分析完之后，Slot已经分配了，而且在每个节点启动前为每个节点配置好Slot总数，一旦启动后就不能动态更改，并且Map Slot和Reduce Slot不允许交换。
YARN架构
Yarn有三个组件，分别为Resource Manager、Node Manager和Application Master。Resource Manager是管理器的核心组件，采用的是主从结构，负责所有资源的监控、分配和管理。Application Master负责每个应用程序的调度和协调。Node Manager负责本节点资源的维护。因为所有的程序都要跑在每一个节点上，做底层工作的是Node Manager，因为Node Manager上有很多的Container去跑计算机任务。
Resource Manager需要获取Node Manager的情况，Container需要向Application Master汇报情况。
Flink运行在Yarn上
可以将Flink理解为某个计算任务。首先向Flink计算框架提交任务，在Flink框架里有YARN的客户端，Flink将其他的资源打包成Uberjar先提交给HDFS，HDFS是整个集群所能共享的相当于一个缓存。然后，向YARN Resource Manager申请am，am是处理层的管理者。申请一个项目协调小组，由一个总的Container控制，下分许多单个Container。将任务的执行文件也就是Uberjar拷贝到本地执行，执行完之后，或者执行的过程中，向总的Container汇报情况。由此可见，YARN将任务协调交给了应用程序的本身。
详细学习内容可观看Spark快速大数据处理扫一扫~~~或者引擎搜索Spark余海峰
