从 hadoop 1.0 到 hadoop 2.0 的演化

1. 概述

在 google 三篇大数据论文发表之后，cloudera 公司在这几篇论文的基础上，开发出了现在的 hadoop 。但 hadoop 开发出来也并非一帆风顺的，hadoop 1.0 版本有诸多局限。在后续的不断实践之中， hadoop 2.0 横空出世，而后 hadoop 2.0 逐渐成为主流。这次我们就来看看 hadoop 从 1.0 遇到了哪些问题，又为什么需要做架构的升级呢？

2. hadoop 1.0

首先我们来看 hadoop1.0 的整体结构。在 hadoop1.0 中有两个模块，一个是分布式文件系统 hdfs(hadoop distrbuted file system) 。另一个则是分布式计算框架 mapreduce 。我们分别来看看这两个模块的架构吧。

2.1 hdfs

对hdfs来说，其主要的运行架构则是 master-slave 架构，即主从架构。其中呢，master 主节点称之为 namenode 节点，而slave从节点称为 datanode 节点。

这个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.2 mapreduce

对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. hadoop 2.0

hadoop 2.0 比起 hadoop 1.0 来说，最大的改进是加入了 资源调度框架 yarn ，我们依旧分为hdfs和 yarn/mapreduce2.0 两部分来讲述hadoop的改进。

3.1 hdfs

针对 hadoop 1.0 中 namenode 制约hdfs的扩展性问题，提出hdfs federation 以及高可用 ha 。此时 namenode 间相互独立，也就是说它们之间不需要相互协调。且多个namenode分管不同的目录进而实现访问隔离和横向扩展。

这样 namenode 的可拓展性自然而然可用增加，据统计 hadoop 2.0 中最多可以达到 10000 个节点同时运行，并且这样的架构改进也解决了namenode单点故障问题。

再来说说高可用 (ha) , ha 主要指的是可以同时启动2个 namenode 。其中一个处于工作 (active) 状态，另一个处于随时待命（standby）状态。这样，当一个namenode所在的服务器宕机时，可以在数据不丢失的情况下，手工或者自动切换到另一个 namenode 提供服务。

3.2 yarn/mapreduce2

针对 hadoop 1.0 中 mr 的不足，引入了yarn 框架。yarn 框架中将 jobtracker 资源分配和作业控制分开，分为 resource manager (rm) 以及 application master (am) 。

而yarn框架作为一个通用的资源调度和管理模块，同时支持多种其他的编程模型，比如最出名的 spark 。

yarn的主要三个组件如下：

• resource manager：resourcemanager包含两个主要的组件：定时调用器(scheduler)以及应用管理器(applicationmanager)。

  1. 定时调度器(scheduler)：定时调度器负责向应用程序分配资源，它不做监控以及应用程序的状态跟踪，并且它不保证会重启由于应用程序本身或硬件出错而执行失败的应用程序。

  2. 应用管理器(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