在 google 三篇大数据论文发表之后,cloudera 公司在这几篇论文的基础上,开发出了现在的 hadoop 。但 hadoop 开发出来也并非一帆风顺的,hadoop 1.0 版本有诸多局限。在后续的不断实践之中, hadoop 2.0 横空出世,而后 hadoop 2.0 逐渐成为主流。这次我们就来看看 hadoop 从 1.0 遇到了哪些问题,又为什么需要做架构的升级呢?
首先我们来看 hadoop1.0 的整体结构。在 hadoop1.0 中有两个模块,一个是分布式文件系统 hdfs(hadoop distrbuted file system) 。另一个则是分布式计算框架 mapreduce 。我们分别来看看这两个模块的架构吧。
对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中做了很多事情,可以说当爹又当妈。
这个架构的缺陷:
hadoop 2.0 比起 hadoop 1.0 来说,最大的改进是加入了 资源调度框架 yarn ,我们依旧分为hdfs和 yarn/mapreduce2.0 两部分来讲述hadoop的改进。
针对 hadoop 1.0 中 namenode 制约hdfs的扩展性问题,提出hdfs federation 以及高可用 ha 。此时 namenode 间相互独立,也就是说它们之间不需要相互协调。且多个namenode分管不同的目录进而实现访问隔离和横向扩展。
这样 namenode 的可拓展性自然而然可用增加,据统计 hadoop 2.0 中最多可以达到 10000 个节点同时运行,并且这样的架构改进也解决了namenode单点故障问题。
再来说说高可用 (ha) , ha 主要指的是可以同时启动2个 namenode 。其中一个处于工作 (active) 状态,另一个处于随时待命(standby)状态。这样,当一个namenode所在的服务器宕机时,可以在数据不丢失的情况下,手工或者自动切换到另一个 namenode 提供服务。
针对 hadoop 1.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 也一样。从上面说的,我们可以知道 hadoop 1.0 是比较简陋的,这样做的目的就是为了易于实现。hadoop 这样做也契合了敏捷开发的原则,也可以说契合产品经理口中的最小可行性产品(mvp),就是先实现一个简单些,但核心功能齐全的版本出来,让市场对其进行检验,而有了结果之后再进行拓展升级。
在当时那种许多公司都苦恼于没有自己的大数据环境的情况下,hadoop 一炮而红。这时候再根据市场,也就是开源社区给出的反馈,不断迭代,更新升级。最终成为大数群山中最为坚固的一座山峰。
我们在平时的产品开发中应该也要像 hadoop 学习,先做出最小可行性产品出来,再在后面进行更新升级,不断完善。当然这对一些完美主义者来说,可能会让他感到比较痛苦。
你看,世间的事多是相通,技术的发展过程其实也暗合产品之道。有时候我们或许可以跳出技术之外,思考它背后产品的逻辑,这其中又有哪些是我们可以学习的,这些同样是珍贵的宝藏,所谓他山之石,可以攻玉,莫过于此~~
以上~
推荐阅读 :
从分治算法到 mapreduce
actor并发编程模型浅析
大数据存储的进化史 --从 raid 到 hadoop hdfs
如对本文有疑问, 点击进行留言回复!!
unity的错误解决办法:NullReferenceException: Object reference not set to an instance of an object;tiny proje
Hadoop 之 HDFS (HDFS 数据流的 读写 流程)
听说你一读Spring源码就懵逼?我帮你把架子搭好了,你填就行!
首席架构师推荐:金融保险领域数字化转型实践--如何优雅地修改业务中台中分层应用Maven多模块的版本号?(命令导入式)
[JVM学习之路]一、初识JVM,了解其结构、模型及生命周期
网友评论