Hadoop1.0采用的是MRv1版本的MapReduce编程模型
对于MRv1
运行时环境：JobTracker和TaskTracker
编程模型：MapReduce
数据处理引擎：Map任务和Reduce任务
这一版本的瓶颈和缺陷：
1、JobTracker既负责资源管理又负责任务调度，如果集群繁忙，JobTracker本身就会成为可扩展性的瓶颈，大大制约计算能力。
2、在这一版本中，TaskTracker将节点的CPU和内存量等量划分为slot，每个slot代表一个计算单元，分为Map slot和Reduce slot，供MapTask和ReduceTask使用。这会造成什么问题？
- 有些任务用不了整个slot的能力，有些任务使用的slot能力不够用，这就造成了资源使用效率不高。
- 任务启动之初，MapTask在运行，ReduceTask未调度运行，这个时候Reduce slot被闲置。
3、单节点的Master，没有备用Master和选举操作，这导致了一旦Master失败，集群将不可用。
4、只能使用自身的MapReduce计算框架，无法通过热插拔方式使用其他（如Spark等）计算框架。
5、这一版本的核心是MapReduce，只能跑MapReduce任务。
基于以上的问题和局限，MRv2诞生，对应Hadoop2.0
对于MRv2
运行时环境：ResourceManager（负责通用资源调度）和ApplicationMaster（负责任务调度）
编程模型：MapReduce
数据处理引擎：Map任务和Reduce任务
在这一版本中，核心是YARN，MapReduce是可插拔的，完全可以使用其他的计算框架替代，如Spark、Storm等。
可以看到，在这一版本中JobTracker被替换成了ResourceManager和ApplicationMaster，分别负责对资源的统一调度，和对各计算框架的任务调度。这样一来的好处有：
1、提高了可扩展性，相比于JobTracker本身可能的瓶颈，这里不存在。
2、计算框架可插拔，不管是本身的Hadoop MapReduce、Spark、Storm等都可以，因为任务调度交给了ApplicationMaster，计算框架的任务只需到向ResourceManager申请的资源中去运行即可。
3、资源的使用单位由slot变成container，应用可根据自身需要申请，提高了集群资源的分配和使用效率。
仍然存在的局限：由HDFS的频繁读写导致的磁盘IO决定了其只适合于离线计算。
