这里转载一篇写的好博文，供大家参考和学习
http://blog.csdn.net/yangjjuan/article/details/74530255?ref=myread
一，新旧MapReduce API比较
（1）新的API倾向于使用抽象类，而不是接口，因为这更容易扩展。如在新的API中，Mapper 和Reducer现在都是抽象类。接口只有方法声明而没有方法实现，且要求所有实现类（不包括抽象类）必须实现接口中的每一个方法。接口的最大优点是允许一个类实现多个接口，进而实现类似C++中的“多重继承”。抽象类则是一种较宽松，它可为某些方法提供默认实现。而继承类则可选择是否重新实现这些方法。正是因为这一点，抽象类在类衍化方面更有优势，也就是说，抽象类具有良好的向后兼容性，当需要为抽象类添加新的方法时，只要新添加的方法提供了默认实现，用户之前的代码就不必修改了。
（2）新的API是在org.apache.Hadoop.mapreduce包(和子包)中的。之前版本的API则是放在org.apache.hadoop.mapred中的。
（3）新的API广泛使用context object(上下文对象)，并允许用户代码与MapReduce系统进行通信。例如，MapContext基本上充当着JobConf的OutputCollector和Reporter的角色。
（4）新的API统一了配置。旧的API有一个特殊的JobConf对象用于作业配置，这是一个对于Hadoop通常的Configuration对象的扩展。在新的API中，这种区别没有了，所以作业配置通过Configuration来完成。作业控制的执行由Job类来负责，而不是JobClient，它在新的API中已经荡然无存。
二，新旧MapReduce 框架比较
两个框架最大的区别在于原来框架中的JobTracker和TaskTracker不
见了，取而代之的是ResourceManager、NodeManager和Application Master三个。
（1）ResourceManager起到了JobTracker的资源分配的作用，它做的关于作业调度的就只有启动、监控每个作业所属的Application Master，并重启故障的 Application Master。不再负责原来框架中JobTracker的监控、重启每个Task。使得单点故障的影响变得小，恢复更加容易。NodeManager 功能比较专一，就是负责 Container 状态的维护，并向 RM 保持心跳。Application Master 负责一个 Job 生命周期内的所有工作，类似老的框架中 JobTracker。但注意每一个 Job(不是每一种)都有一个 Application Master，它可以运行在 ResourceManager 以外的机器上。
（2）新框架将JobTracker的分 离，减少了它的资源消耗，使系统更容易从单点故障中恢复，并且监测每个作业子任务状态的程序分布式化了，更安全。
（3）在新框架中，Application Master是可变的，可以为不同的计算框架编写自己的Application Master，使得更多的计算框架可以运行在Hadoop集群上。
（4）老的框架中，JobTracker一个很大的负担就是监控job下的tasks的运行状况，现在，这个部分就扔给Application Master做了，而ResourceManager中有一个模块叫ApplicationsManager，它是监测Application Master的运行状况，如果出问题，会将其在其他机器上重启。
（5）Container很好地起到了资源隔离的作用，让资源更好地被利用起来。