hadoop1.0 和 Hadoop 2.0 的区别

1.Hadoop概述

在Google三篇大数据论文发表以后,Cloudera公司在这几篇论文的基础上,开发出了如今的Hadoop。但Hadoop开发出来也并不是一路顺风的,Hadoop1.0版本有诸多局限。在后续的不断实践之中,Hadoop2.0横空出世,然后Hadoop2.0逐渐成为大数据中的主流。那么Hadoop1.0究竟存在哪些缺陷,在它升级到Hadoop2.0的时候又作出了怎样的调整,最终使得Hadoop2.0成为大数据的基石呢?html

2.Hadoop1.0

首先咱们来看hadoop1.0的总体结构。在hadoop1.0中有两个模块,一个是分布式文件系统HDFS(Hadoop Distrbuted File System)。另外一个则是分布式计算框架MapReduce。咱们分别来看看这两个模块的架构吧。node

2.1HDFS1.0

对HDFS来讲,其主要的运行架构则是master-slave架构,即主从架构。其中呢,master主节点称之为Namenode节点,而slave从节点称为DataNode节点。 Hadoop1.0整体结构 这个NameNode的职责是什么呢?程序员

  1. NameNode管理着整个文件系统,负责接收用户的操做请求
  2. NameNode管理着整个文件系统的目录结构,所谓目录结构相似于咱们Windows操做系统的体系结构
  3. NameNode管理着整个文件系统的元数据信息,所谓元数据信息指定是除了数据自己以外涉及到文件自身的相关信息
  4. NameNode保管着文件与block块序列之间的对应关系以及block块与DataNode节点之间的对应关系

在hadoop1.0中,namenode有且只有一个,虽然能够经过SecondaryNameNode与NameNode进行数据同步备份,可是总会存在必定的延时,若是NameNode挂掉,可是若是有部份数据尚未同步到SecondaryNameNode上,仍是可能会存在着数据丢失的问题。算法

值得一提的是,在HDFS中,咱们真实的数据是由DataNode来负责来存储的,可是数据具体被存储到了哪一个DataNode节点等元数据信息则是由咱们的NameNode来存储的。编程

这种架构实现的好处的简单,但其局限一样明显:服务器

  • 单点故障问题:由于NameNode含有咱们用户存储文件的所有的元数据信息,当咱们的NameNode没法在内存中加载所有元数据信息的时候,集群的寿命就到头了。
  • 拓展性问题:NameNode在内存中存储了整个分布式文件系统中的元数据信息,而且NameNode只能有一台机器,没法拓展。单台机器的NameNode必然有到达极限的地方。
  • 性能问题:当HDFS中存储大量的小文件时,会使NameNode的内存压力增长。
  • 隔离性问题:单个namenode难以提供隔离性,即:某个用户提交的负载很大的job会减慢其余用户的job。

2.2MapReduce

对MapReduce来讲,一样时一个主从结构,是由一个JobTracker(主)和多个TaskTracker(从)组成。网络

而JobTracker在hadoop1.0的MapReduce中作了不少事情,能够说当爹又当妈。架构

  1. 负责接收client提交给的计算任务。
  2. 负责将接收的计算任务分配给各个的TaskTracker进行执行。
  3. 经过heartbeat(心跳)来管理TaskTracker机器的状况,同时监控任务task的执行情况。

这个架构的缺陷:并发

  • 单点故障:依旧是单点故障问题,若是JobTracker挂掉了会致使MapReduce做业没法执行。
  • 资源浪费:JobTracker完成了太多的任务,形成了过多的资源消耗,当map-reduce job很是多的时候,会形成很大的内存开销,潜在来讲,也增长了JobTracker失效的风险,这也是业界广泛总结出老Hadoop的Map-Reduce只能支持4000节点主机的上限;
  • 只支持简单的MapReduce编程模型:要使用Hadoop进行编程的话只能使用基础的MapReduce,而没法使用诸如Spark这些计算模型。而且它也不支持流式计算和实时计算。

3.Hadoop2.0

Hadoop2.0主要架构 Hadoop2.0比起Hadoop1.0来讲,最大的改进是加入了资源调度框架Yarn,咱们依旧分为HDFS和Yarn/MapReduce2.0两部分来说述Hadoop的改进。框架

3.1HDFS2.0

针对Hadoop1.0中NameNode制约HDFS的扩展性问题,提出HDFSFederation以及高可用HA。此时NameNode间相互独立,也就是说它们之间不须要相互协调。且多个NameNode分管不一样的目录进而实现访问隔离和横向扩展。

这样NameNode的可拓展性天然而然可用增长,据统计Hadoop2.0中最多能够达到10000个节点同时运行,而且这样的架构改进也解决了NameNode单点故障问题。

再来讲说高可用(HA),HA主要指的是能够同时启动2个NameNode。其中一个处于工做(Active)状态,另外一个处于随时待命(Standby)状态。这样,当一个NameNode所在的服务器宕机时,能够在数据不丢失的状况下,手工或者自动切换到另外一个NameNode提供服务。

3.2Yarn/MapReduce2

针对Hadoop1.0中MR的不足,引入了Yarn框架。Yarn框架中将JobTracker资源分配和做业控制分开,分为Resource Manager(RM)以及Application Master(AM)。 Hadoop Yarn

而Yarn框架做为一个通用的资源调度和管理模块,同时支持多种其余的编程模型,好比最出名的Spark。

Yarn的主要三个组件以下:

  • Resource Manager:ResourceManager包含两个主要的组件:定时调用器(Scheduler)以及应用管理器(ApplicationManager)。

    1. 定时调度器(Scheduler):定时调度器负责向应用程序分配资源,它不作监控以及应用程序的状态跟踪,而且它不保证会重启因为应用程序自己或硬件出错而执行失败的应用程序。

    2. 应用管理器(ApplicationManager):应用程序管理器负责接收新任务,协调并提供在ApplicationMaster容器失败时的重启功能。

  • Application Master:每一个应用程序的ApplicationMaster负责从Scheduler申请资源,以及跟踪这些资源的使用状况以及任务进度的监控。

  • Node Manager:NodeManager是ResourceManager在每台机器的上代理,负责容器的管理,并监控他们的资源使用状况(cpu,内存,磁盘及网络等),以及向ResourceManager/Scheduler提供这些资源使用报告。

关于Hadoop1.0和2.0的一点点感悟

没有什么是一开始就完美的,当下最流行的Hadoop也同样。从上面说的,咱们能够知道Hadoop1.0是比较简陋的,这样作的目的就是为了易于实现。Hadoop这样作也契合了敏捷开发的原则,也能够说契合产品经理口中的最小可行性产品(MVP),就是先实现一个简单些,但核心功能齐全的版本出来,让市场对其进行检验,而有告终果以后再进行拓展升级。

在当时那种许多公司都苦恼于没有本身的大数据环境的状况下,Hadoop一炮而红。这时候再根据市场,也就是开源社区给出的反馈,不断迭代,更新升级。最终成为大数群山中最为坚固的一座山峰。

咱们在平时的产品开发中应该也要像Hadoop学习,先作出最小可行性产品出来,再在后面进行更新升级,不断完善。固然这对一些完美主义者来讲,可能会让他感到比较痛苦。

你看,世间的事可能是相通,技术的发展过程其实也暗合产品之道。有时候咱们或许能够跳出技术以外,思考它背后产品的逻辑,这其中又有哪些是咱们能够学习的,这些一样是珍贵的宝藏,所谓他山之石,能够攻玉,莫过于此~~

以上~


推荐阅读: 从分治算法到 MapReduce Actor并发编程模型浅析 大数据存储的进化史 --从 RAID 到 Hadoop Hdfs 一个故事告诉你什么才是好的程序员

相关文章
相关标签/搜索