关于Hadoop1.x和2.x的区别和联系讲解
问题导读
1.hadoop1.x改造如果是两个jobtraker，你认为解决了什么问题
2.hadoop1.x改造如果是两个jobtraker，你认为未解决了什么问题
3.你如何看待hadoop2.x的yarn
鉴于本人面试提到过这个问题：hadoop1.x和hadoop2.x的区别，起始存在很多模糊的地方，希望看到这篇文章，能够对hadoop有个基本的认识。
由于现在大家都接触的是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具备了隔离性。