Hadoop学习笔记—21.Hadoop2的改进内容简介

Hadoop2相比较于Hadoop1.x来说，HDFS的架构与MapReduce的都有较大的变化，且速度上和可用性上都有了很大的提高，Hadoop2中有两个重要的变更：

（1）HDFS的NameNode可以以集群的方式布署，增强了NameNodes的水平扩展能力和高可用性，分别是:HDFS Federation与HA；

（2）MapReduce将JobTracker中的资源管理及任务生命周期管理（包括定时触发及监控），拆分成两个独立的组件，并更名为YARN（Yet Another Resource Negotiator）；

一、HDFS的改进

1.1 Hadoop1.x时代的HDFS架构

　　在Hadoop1.x中的NameNode只可能有一个，虽然可以通过SecondaryNameNode与NameNode进行数据同步备份，但是总会存在一定的时延，如果NameNode挂掉，但是如果有部份数据还没有同步到SecondaryNameNode上，还是可能会存在着数据丢失的问题。该架构如图1所示：

　　图1 Hadoop1.x时代的HDFS结构图

　　该架构包含两层：Namespace 和 Block Storage Service；

　　其中，Namespace 层面包含目录、文件以及块的信息，支持对Namespace相关文件系统的操作，如增加、删除、修改以及文件和目录的展示；

　　而Block Storage Service层面又包含两个部分：

　　①Block Management（块管理）维护集群中DataNode的基本关系，它支持数据块相关的操作，如：创建数据块，删除数据块等，同时，它也会管理副本的复制和存放。

　　②Physical Storage（物理存储）存储实际的数据块并提供针对数据块的读写服务。

　　当前HDFS架构只允许整个集群中存在一个Namespace，而该Namespace被仅有的一个NameNode管理。这个架构使得HDFS非常容易实现，但是，它（见上图）在具体实现过程中会出现一些模糊点，进而导致了很多局限性（下面将要详细说明），当然这些局限性只有在拥有大集群的公司，像baidu，腾讯等出现。

Hadoop1.x的HDFS架构的局限：

（1）Block Storage和namespace高耦合

当前namenode中的namespace和block management的结合使得这两层架构耦合在一起，难以让其他可能namenode实现方案直接使用block storage。

（2）NameNode扩展性

HDFS的底层存储是可以水平扩展的（解释：底层存储指的是datanode，当集群存储空间不够时，可简单的添加机器已进行水平扩展），但namespace不可以。当前的namespace只能存放在单个namenode上，而namenode在内存中存储了整个分布式文件系统中的元数据信息，这限制了集群中数据块，文件和目录的数目。

（3）NameNode性能

文件操作的性能制约于单个Namenode的吞吐量，单个Namenode当前仅支持约60K的task，而下一代Apache MapReduce将支持多余100K的并发任务，这隐含着要支持多个Namenode。

（4）隔离性

现在大部分公司的集群都是共享的，每天有来自不同group的不同用户提交作业。单个namenode难以提供隔离性，即：某个用户提交的负载很大的job会减慢其他用户的job，单一的namenode难以像HBase按照应用类别将不同作业分派到不同namenode上。

1.1 HDFS Federation

　　（1）全新的Feration架构

　　在Hadoop2.x中，HDFS的变化主要体现在增强了NameNode的水平扩展（Horizontal Scalability）及高可用性（HA）->【这不就是针对我们刚刚提到到的Hadoop1.x HDFS架构的局限性而做的改进，么么嗒！】，可以同时部署多个NameNode，这些NameNode之间是相互独立，也就是说他们不需要相互协调，DataNode同时在所有NameNode中注册，作为他们共有的存储节点，并定时向所有的这些NameNode发送心跳块使用情况的报告，并处理所有NameNode向其发送的指令。该架构如图2所示：

图2 Hadoop2.x时代的HDFS结构图

　　该架构引入了两个新的概念：存储块池（Block Pool）和集群ID（ClusterID）；

　　①一个Bock Pool 是块的集合，这些块属于一个单一的Namespace。DataNode存储着集群中所有Block Pool中的块。Block Pool的管理相互之间是独立的。这意味着一个Namespace可以独立的生成块ID，不需要与其他Namespace协调。一个NameNode失败不会导致Datanode的失败，这些Datanode还可以服务其他的Namenode。

　　一个Namespace和它的Block Pool一起称作命名空间向量（Namespace Volume）。这是一个自包含单元。当一个NameNode/Namespace删除后，对应的Block Pool也会被删除。当集群升级时，每个Namespace Volume也会升级。

　　②集群ID（ClusterID）的加入，是用于确认集群中所有的节点，也可以在格式化其它Namenode时指定集群ID，并使其加入到某个集群中。

　　（2）HDFS Federation与老HDFS架构的比较

①老HDFS架构只有一个命名空间（Namespace），它使用全部的块。而HDFS Federation 中有多个独立的命名空间（Namespace），并且每一个命名空间使用一个块池（block pool）。

②老HDFS架构中只有一组块。而HDFS Federation 中有多组独立的块。块池（block pool）就是属于同一个命名空间的一组块。

③老HDFS架构由一个Namenode和一组datanode组成。而HDFS Federation 由多个Namenode和一组Datanode，每一个Datanode会为多个块池（block pool）存储块。

1.2 NameNode的HA

　　Hadoop中的NameNode好比是人的心脏，非常重要，绝对不可以停止工作。在Hadoop1.x时代，只有一个NameNode。如果该NameNode数据丢失或者不能工作，那么整个集群就不能恢复了。这是Hadoop1.x中的单点问题，也是Hadoop1.x不可靠的表现，如图1所示。Hadoop2的出现解决了这个问题，也被称为HA。

　　Hadoop2中HDFS的HA主要指的是可以同时启动2个NameNode。其中一个处于工作（Active）状态，另一个处于随时待命（Standby）状态。这样，当一个NameNode所在的服务器宕机时，可以在数据不丢失的情况下，手工或者自动切换到另一个NameNode提供服务。如图3所示，它展示了一个在Hadoop2下实现HA的一种方式结构：

图3 Hadoop2.x时代实现HA的一种架构图

　　下面对上图做一下简单的介绍：

　　（1）这些NameNode之间通过共享存储同步edits信息，保证数据的状态一致。多个NameNode之间共享数据，可以通过Network File System（NFS）或者Quorum Journal Node。前者是通过Linux共享的文件系统，属于操作系统层面的配置；后者是Hadoop自身的东西，属于软件层面的配置。

　　（2）DataNode同时向两个NameNode汇报块信息。这是让Standby NameNode保持集群最新状态的必需步骤。

　　（3）使用Zookeeper来进行心跳监测监控，在Active NameNode失效时自动切换Standby NameNode为Active状态。

二、MapReduce的改进

2.1 Hadoop1.x时代的MapReduce

　　在Hadoop1.x时代，Hadoop中的MapReduce实现是做了很多的事情，而该框架的核心Job Tracker则是既当爹又当妈的意思，如图4所示：

　　图4 Hadoop1.x时代的MapReduce框架架构图

　　（1）首先用户程序（JobClient）提交了一个 job，job 的信息会发送到 Job Tracker 中，Job Tracker 是 Map-reduce 框架的中心，他需要与集群中的机器定时通信 (heartbeat), 需要管理哪些程序应该跑在哪些机器上，需要管理所有 job 失败、重启等操作。

　　（2）TaskTracker 是 Map-reduce 集群中每台机器都有的一个部分，他做的事情主要是监视自己所在机器的资源情况。

　　（3）TaskTracker 同时监视当前机器的 tasks 运行状况。TaskTracker 需要把这些信息通过 heartbeat发送给JobTracker，JobTracker 会搜集这些信息以给新提交的 job 分配运行在哪些机器上。

Hadoop1.x的MapReduce框架的主要局限：

（1）JobTracker 是 Map-reduce 的集中处理点，存在单点故障；

（2）JobTracker 完成了太多的任务，造成了过多的资源消耗，当 map-reduce job 非常多的时候，会造成很大的内存开销，潜在来说，也增加了 JobTracker 失效的风险，这也是业界普遍总结出老 Hadoop 的 Map-Reduce 只能支持 4000 节点主机的上限；

2.2 Hadoop2中新方案：YARN+MapReduce

　　首先的不要被YARN给迷惑住了，它只是负责资源调度管理。而MapReduce才是负责运算的家伙，所以YARN != MapReduce2.

YARN 并不是下一代MapReduce（MRv2），下一代MapReduce与第一代MapReduce（MRv1）在编程接口、数据处理引擎（MapTask和ReduceTask）是完全一样的，可认为MRv2重用了MRv1的这些模块，不同的是资源管理和作业管理系统，MRv1中资源管理和作业管理均是由JobTracker实现的，集两个功能于一身，而在MRv2中，将这两部分分开了。 其中，作业管理由ApplicationMaster实现，而资源管理由新增系统YARN完成，由于YARN具有通用性，因此YARN也可以作为其他计算框架的资源管理系统，不仅限于MapReduce，也是其他计算框架（例如Spark）的管理平台。　　

图5 Hadoop2时代的新方案架构图

　　从图5中也可以看出，Hadoop1时代中MapReduce可以说是啥事都干，而Hadoop2中的MapReduce的话则是专门处理数据分析，而YARN则做为资源管理器而存在。

　　该架构将JobTracker中的资源管理及任务生命周期管理（包括定时触发及监控），拆分成两个独立的服务，用于管理全部资源的ResourceManager以及管理每个应用的ApplicationMaster，ResourceManager用于管理向应用程序分配计算资源，每个ApplicationMaster用于管理应用程序、调度以及协调。一个应用程序可以是经典的MapReduce架构中的一个单独的Job任务，也可以是这些任务的一个DAG（有向无环图）任务。ResourceManager及每台机上的NodeManager服务，用于管理那台主机的用户进程，形成计算架构。每个应用程序的ApplicationMaster实际上是一个框架具体库，并负责从ResourceManager中协调资源及与NodeManager(s)协作执行并监控任务。如图6所示：