从hadoop发展角度彻底明白hadoop1.x与hadoop2.x的区别

问题导读

1.hadoop1.x改造如果是两个jobtraker，你认为解决了什么问题？
2.hadoop1.x改造如果是两个jobtraker，你认为未解决了什么问题？

3.你如何看待hadoop2.x的yarn

鉴于本人面试提到过这个问题：hadoop1.x和hadoop2.x的区别，起始存在很多模糊的地方，希望看到这篇文章，能够对hadoop有个基本的认识。

转载自http://www.aboutyun.com/forum.php?mod=viewthread&tid=19771&extra=page%3D1

由于现在大家都接触的是hadoop2.x。对于hadoop1.x了解还是比较少的。

很多人问，如果没有1.x的基础，能否学习hadoop2.x。答案是可以的。但是如果了解hadoop1.x有助于我们理解hadoop2.x。

我们来看看hadoop1.x存在哪些问题？

hadoop有jobtracker,trasktracker.对于jobtracker,trasktracker刚接触其实还是比较抽象的。可能多次遇到过。但是对于它的认识和理解还是比较模糊。
我们这里打个比喻：在一个组织结构中，既有管理者，又有执行者。而jobtracker,trasktracker则是管理者，执行者是map task和reduce task。

trasktracker像是一个中层管理者，既监控执行者--map task和reduce task，如果map任务或reduce任务有更新，会通过心跳（一般间隔是3秒）告诉TraskTracker，TraskTracker再通过心跳（一般至少5s，因为代价比较大）告诉JobTracker。

JobTracker是最高层管理者，它接受trasktracker的心跳，负责资源管理和job的调度。

上面如果你思维谨密，就能看出，如果一旦最高层管理JobTracker挂掉，那么整个集群就瘫痪了。
为什么那？
1.不能提交job。
2.不能分配资源
3.job无法调度
这就有点像一个国家的leader挂掉了，那么谁会来负责国家的运转。如果你了解运行机制，其实也是有方案的。而这个方案就是我们所熟悉的高可用方案。而如果JobTracker挂掉了，显然hadoop集群就挂掉了。所以显然hadoop1.x是存在缺陷的。

既然存在缺陷，那么我们该如何来弥补。如果还是在原先的框架上修改，弄两个jobtracker是否可以。这肯定是一种方案。但是hadoop也是有野心的。作为大数据最初的开拓者，spark，storm都非常的活跃。
所以我们列出了，hadoop需改造的下面需求：
1.hadoop存在单点故障
2.hadoop能否统一spark，storm

从上面我们看到hadoop自身存在问题，需要改造，同时又想统一spark和storm。所以hadoop急切需要改造升级。

这里想到了很多种解决方案。

方案1：两个jobtraker

hadoop自身来讲，既然存在单点故障，所以那么我们可以创建两个jobtraker，这是否可以。答案是可以的。因为一旦一个挂掉。我们启用另外一个jobtraker，这也是合适的。但是还存在另外一个问题，就是该如何统一spark和storm。如果spark和storm运行的话，两个jobtraker是否可以。答案是不行的，因为jobtraker其实还是没有脱离他本身的框架，只能运行hadoop的map和reduce。spark的DAG和storm的拓扑，还是不能运行的。那如果你说我们在jobtraker中加入不就行了。可是这是相当麻烦的，jobtraker肯定会累死的，他的任务太多。显然需要分离的职务。

方案2：Yarn
两个jobtraker是不行了，那么就从jobtraker职能分离并且解决存在的问题
1.性能问题
2.单点故障
3.能运行mapreduce，spark，storm。

所以这时候就产生了Yarn。

补充hadoop的发展历程

（1）Hadoop 1.0
Hadoop 1.0即第一代Hadoop，由分布式存储系统HDFS和分布式计算框架MapReduce组成，其中，HDFS由一个NameNode和多个DataNode组成，MapReduce由一个JobTracker和多个TaskTracker组成，对应Hadoop版本为Apache Hadoop 0.20.x、1.x、0.21.X、0.22.x和CDH3。
（2）Hadoop 2.0
Hadoop 2.0即第二代Hadoop，为克服Hadoop 1.0中HDFS和MapReduce存在的各种问题而提出的。针对Hadoop 1.0中的单NameNode制约HDFS的扩展性问题，提出了HDFS Federation，它让多个NameNode分管不同的目录进而实现访问隔离和横向扩展，同时它彻底解决了NameNode 单点故障问题；针对Hadoop 1.0中的MapReduce在扩展性和多框架支持等方面的不足，它将JobTracker中的资源管理和作业控制功能分开，分别由组件ResourceManager和ApplicationMaster实现，其中，ResourceManager负责所有应用程序的资源分配，而ApplicationMaster仅负责管理一个应用程序，进而诞生了全新的通用资源管理框架YARN。基于YARN，用户可以运行各种类型的应用程序（不再像1.0那样仅局限于MapReduce一类应用），从离线计算的MapReduce到在线计算（流式处理）的Storm等。Hadoop 2.0对应Hadoop版本为Apache Hadoop 0.23.x、2.x和CDH4。

（3）MapReduce 1.0或MRv1
MapReduce 1.0计算框架主要由三部分组成，分别是编程模型、数据处理引擎和运行时环境。它的基本编程模型是将问题抽象成Map和Reduce两个阶段，其中Map阶段将输入数据解析成key/value，迭代调用map()函数处理后，再以key/value的形式输出到本地目录，而Reduce阶段则将key相同的value进行规约处理，并将最终结果写到HDFS上；它的数据处理引擎由MapTask和ReduceTask组成，分别负责Map阶段逻辑和Reduce阶段逻辑的处理；它的运行时环境由（一个）JobTracker和（若干个）TaskTracker两类服务组成，其中，JobTracker负责资源管理和所有作业的控制，而TaskTracker负责接收来自JobTracker的命令并执行它。该框架在扩展性、容错性和多框架支持等方面存在不足，这也促使了MRv2的产生。
（4）MRv2
MRv2具有与MRv1相同的编程模型和数据处理引擎，唯一不同的是运行时环境。MRv2是在MRv1基础上经加工之后，运行于资源管理框架YARN之上的计算框架MapReduce。它的运行时环境不再由JobTracker和TaskTracker等服务组成，而是变为通用资源管理系统YARN和作业控制进程ApplicationMaster，其中，YARN负责资源管理和调度，而ApplicationMaster仅负责一个作业的管理。简言之，MRv1仅是一个独立的离线计算框架，而MRv2则是运行于YARN之上的MapReduce。
（5）YARN
YARN是Hadoop 2.0中的资源管理系统，它是一个通用的资源管理模块，可为各类应用程序进行资源管理和调度。YARN不仅限于MapReduce一种框架使用，也可以供其他框架使用，比如Tez（将在第9章介绍）、Spark、Storm（将在第10章介绍）等。YARN类似于几年前的资源管理系统Mesos（将在12章介绍）和更早的Torque（将在6章介绍）。由于YARN的通用性，下一代MapReduce的核心已经从简单的支持单一应用的计算框架MapReduce转移到通用的资源管理系统YARN。
（6）HDFS Federation
Hadoop 2.0中对HDFS进行了改进，使NameNode可以横向扩展成多个，每个NameNode分管一部分目录，进而产生了HDFS Federation，该机制的引入不仅增强了HDFS的扩展性，也使HDFS具备了隔离性。