从 Hadoop 1.0 到 Hadoop 2.0 ，你需要了解这些

学习大数据，刚开始接触的是 Hadoop 1.0，然后过度到 Hadoop 2.0 ，这里为了书写方便，本文中 Hadoop 1.0 采用 HV1 的缩写方式，Hadoop 2.0 采用 HV2 的缩写方式。

HV1 中不得不提的两个进程：JobTracker 和 TaskTracker。JobTracker 主要负责任务调度和集群资源管理，TaskTracker 主要负责任务执行。在 HV1 向 HV2 变迁后，引入了一个中间件Yarn，负责集群资源调度。可以简单地理解，Yarn 分离出了JobTracker 资源管理的权柄。

Yarn

Yarn 是一个分布式资源调度框架，其架构图如下所示：



图中的三个重要进程：

• 资源管理器（ResourceManager，RM）
• 节点管理器（NodeManager，NM）
• ApplicationMaster（AM）

两个对比：

• Yarn 中容器（Container）可以对比 HV1 中 slot（槽） ，前者是逻辑层的概念，后者是物理层的概念。Container 是任务运行环境的抽象封装。
• HV1 中一个重要的概念 Job（作业），在 Yarn 中对应 Application（应用程序）。

HV1 和 HV2 对比示例图如下：

Yarn 的执行流程

Yarn 执行流程示意图如下所示：



执行流程说明如下：

• Client 请求 ResourceManager 运行一个 ApplicationMaster 实例。
• ResourceManager 选择一个 NodeManager 启动一个 Container 运行 ApplicationMaster 实例。
• ApplicationMaster 根据实际需要向 ResourceManager 请求更多的 Container 资源，ApplicationMaster 通过获取到的 Container 资源执行分布式计算。

功能分析

通过执行流程，我们尝试去理解 Yarn 中三个重要进程（RM、NM、AM）对应的职责和功能。

RM 处理客户端请求，接收 JobSubmitter 提交的作业，按照作业的上下文（Context）信息，以及从 NM 收集来的状态信息，启动调度过程，分配一个 Container 作为 AM。RM 拥有系统中所有应用资源的决定权，是中心服务，调度、启动每一个作业所属的 Application，并监测 Application 的存在情况。

NM 处理来自 RM 的任务请求，接收并处理来自 AM 的 Container 启动、停止等请求。NM 负责启动应用程序的 Container ，监控它们的资源使用情况，并汇报给 RM。可以理解 NM 是在单节点上进行任务管理 和 资源管理。

AM 是应用程序的 Master，每一个 应用程序对应一个 AM，在用户提交一个应用程序时，一个 AM 的轻量型进程实例会启动，AM 协调应用程序内所有任务的执行。

HV2 新特性

HV2 的新特性包括：

• NameNode HA
• NameNode Federation
• HDFS 快照
• HDFS ACL
• 异构层级存储结构

本文只详述其中两点：NameNode HA 和NameNode Federation。NameNode HA优化的是单点故障问题，NameNode Federation优化的是集群的横向扩展问题。

NameNode HA

HV2 对 HV1 中存在的很多问题进行了优化。例如，HV1 中 NameNode 的单点故障问题，在 HV2 中可以通过一个集群中运行两个NameNode（active NameNode 和 standby NameNode）来解决。任何时间，只有一台机器处于 Active 状态，另一台机器处于standby 状态，其框架如下图所示：



通过zookeeper（ZK）选举确定当前唯一active状态的NameNode，依赖 JournalNodes（JN）守护进程确保两个NameNode 数据同步。

NameNode Federation

HV1 中 HDFS 只有一个NameSpace，元数据信息是存储在NameNode 上的，单一存储会使得 NameNode 的资源使用率达到上限，同时负载能力越来越高，影响 HDFS性能。HV2 中对NameNode 进行了一个横向扩展，引入了NameNode “城邦”特性。该特性允许在集群中提供多个 NameNode ，同时对外提供服务，每个 NameNode 管理一部分 DataNode。其框架如下图所示：

再谈

引入Yarn资源管理框架，将HV1中资源管理和任务调度的功能解耦，带来的好处如下：

1. 减少了JobTracker（也就是现在的RM）的资源消耗，并且让监测每一个Job子任务（tasks）状态的程序分布式化了，更安全。
2. AM是一个可变更的部分，用户可以对不同的编程模型编写自己的AM，让更多类型的编程模型能够跑在Hadoop集群中。
3. 对于资源的表示以内存为单位，比以前以剩余slot数目更合理。
4. 老的框架中，jobTracker一个很大的负担就是监控Job下的Task的运行情况，现在，这部分扔给ApplicationMaster做了。
5. 资源表示成内存量，那就没有了之前的map slot/reduce slot分开造成集群资源闲置的尴尬情况。

好了，今天的博客就到这里了，期待你的指正。