在Google三篇大数据论文发表以后,Cloudera公司在这几篇论文的基础上,开发出了如今的Hadoop。但Hadoop开发出来也并不是一路顺风的,Hadoop1.0版本有诸多局限。在后续的不断实践之中,Hadoop2.0横空出世,然后Hadoop2.0逐渐成为大数据中的主流。那么Hadoop1.0究竟存在哪些缺陷,在它升级到Hadoop2.0的时候又作出了怎样的调整,最终使得Hadoop2.0成为大数据的基石呢?html
首先咱们来看hadoop1.0的总体结构。在hadoop1.0中有两个模块,一个是分布式文件系统HDFS(Hadoop Distrbuted File System)。另外一个则是分布式计算框架MapReduce。咱们分别来看看这两个模块的架构吧。node
对HDFS来讲,其主要的运行架构则是master-slave架构,即主从架构。其中呢,master主节点称之为Namenode节点,而slave从节点称为DataNode节点。 这个NameNode的职责是什么呢?程序员
在hadoop1.0中,namenode有且只有一个,虽然能够经过SecondaryNameNode与NameNode进行数据同步备份,可是总会存在必定的延时,若是NameNode挂掉,可是若是有部份数据尚未同步到SecondaryNameNode上,仍是可能会存在着数据丢失的问题。算法
值得一提的是,在HDFS中,咱们真实的数据是由DataNode来负责来存储的,可是数据具体被存储到了哪一个DataNode节点等元数据信息则是由咱们的NameNode来存储的。编程
这种架构实现的好处的简单,但其局限一样明显:服务器
对MapReduce来讲,一样时一个主从结构,是由一个JobTracker(主)和多个TaskTracker(从)组成。网络
而JobTracker在hadoop1.0的MapReduce中作了不少事情,能够说当爹又当妈。架构
这个架构的缺陷:并发
Hadoop2.0比起Hadoop1.0来讲,最大的改进是加入了资源调度框架Yarn,咱们依旧分为HDFS和Yarn/MapReduce2.0两部分来说述Hadoop的改进。框架
针对Hadoop1.0中NameNode制约HDFS的扩展性问题,提出HDFSFederation以及高可用HA。此时NameNode间相互独立,也就是说它们之间不须要相互协调。且多个NameNode分管不一样的目录进而实现访问隔离和横向扩展。
这样NameNode的可拓展性天然而然可用增长,据统计Hadoop2.0中最多能够达到10000个节点同时运行,而且这样的架构改进也解决了NameNode单点故障问题。
再来讲说高可用(HA),HA主要指的是能够同时启动2个NameNode。其中一个处于工做(Active)状态,另外一个处于随时待命(Standby)状态。这样,当一个NameNode所在的服务器宕机时,能够在数据不丢失的状况下,手工或者自动切换到另外一个NameNode提供服务。
针对Hadoop1.0中MR的不足,引入了Yarn框架。Yarn框架中将JobTracker资源分配和做业控制分开,分为Resource Manager(RM)以及Application Master(AM)。
而Yarn框架做为一个通用的资源调度和管理模块,同时支持多种其余的编程模型,好比最出名的Spark。
Yarn的主要三个组件以下:
Resource Manager:ResourceManager包含两个主要的组件:定时调用器(Scheduler)以及应用管理器(ApplicationManager)。
定时调度器(Scheduler):定时调度器负责向应用程序分配资源,它不作监控以及应用程序的状态跟踪,而且它不保证会重启因为应用程序自己或硬件出错而执行失败的应用程序。
应用管理器(ApplicationManager):应用程序管理器负责接收新任务,协调并提供在ApplicationMaster容器失败时的重启功能。
Application Master:每一个应用程序的ApplicationMaster负责从Scheduler申请资源,以及跟踪这些资源的使用状况以及任务进度的监控。
Node Manager:NodeManager是ResourceManager在每台机器的上代理,负责容器的管理,并监控他们的资源使用状况(cpu,内存,磁盘及网络等),以及向ResourceManager/Scheduler提供这些资源使用报告。
没有什么是一开始就完美的,当下最流行的Hadoop也同样。从上面说的,咱们能够知道Hadoop1.0是比较简陋的,这样作的目的就是为了易于实现。Hadoop这样作也契合了敏捷开发的原则,也能够说契合产品经理口中的最小可行性产品(MVP),就是先实现一个简单些,但核心功能齐全的版本出来,让市场对其进行检验,而有告终果以后再进行拓展升级。
在当时那种许多公司都苦恼于没有本身的大数据环境的状况下,Hadoop一炮而红。这时候再根据市场,也就是开源社区给出的反馈,不断迭代,更新升级。最终成为大数群山中最为坚固的一座山峰。
咱们在平时的产品开发中应该也要像Hadoop学习,先作出最小可行性产品出来,再在后面进行更新升级,不断完善。固然这对一些完美主义者来讲,可能会让他感到比较痛苦。
你看,世间的事可能是相通,技术的发展过程其实也暗合产品之道。有时候咱们或许能够跳出技术以外,思考它背后产品的逻辑,这其中又有哪些是咱们能够学习的,这些一样是珍贵的宝藏,所谓他山之石,能够攻玉,莫过于此~~
以上~
推荐阅读: 从分治算法到 MapReduce Actor并发编程模型浅析 大数据存储的进化史 --从 RAID 到 Hadoop Hdfs 一个故事告诉你什么才是好的程序员