鉴于好久没有更新博客，且最近开始找工作，所以对以往的相关知识进行整理

一：Haddop版本介绍

0.20.x版本最后演化成了现在的1.0.x版本

0.23.x版本最后演化成了现在的2.x版本

hadoop 1.0 指的是1.x(0.20.x),0.21,0.22

hadoop 2.0 指的是2.x,0.23.x

CDH3,CDH4分别对应了hadoop1.0 hadoop2.0

二、Hadoop1.X与Hadoop2.X区别

1、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.2 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.3 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状态。

2、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所示：

图6 YARN架构图

　　（1）ResourceManager包含两个主要的组件：定时调用器(Scheduler)以及应用管理器(ApplicationManager)。

　　①定时调度器(Scheduler)：

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

　　②应用管理器(ApplicationManager)：

　　应用程序管理器负责接收新任务，协调并提供在ApplicationMaster容器失败时的重启功能。

　　（2）ApplicationMaster：每个应用程序的ApplicationMaster负责从Scheduler申请资源，以及跟踪这些资源的使用情况以及任务进度的监控。

　　（3）NodeManager：NodeManager是ResourceManager在每台机器的上代理，负责容器的管理，并监控他们的资源使用情况（cpu，内存，磁盘及网络等），以及向 ResourceManager/Scheduler提供这些资源使用报告。

    23、具体变化

2.3.1、配置文件的路径

在1.x中，Hadoop的配置文件是放在$HADOOP_HOME/conf目录下的，关键的配置文件在src目录都有对应的存放着默认值的文件，如下：

配置文件	默认值配置文件
$HADOOP_HOME/conf/core-site.xml	$HADOOP_HOME/src/core/core-default.xml
$HADOOP_HOME/conf/hdfs-site.xml	$HADOOP_HOME/src/hdfs/hdfs-default.xml
$HADOOP_HOME/conf/mapred-site.xml	$HADOOP_HOME/src/mapred/mapred-default.xml

我们在$HADOOP_HOME/conf下面配置的core-site.xml等的值，就是对默认值的一个覆盖，如果没有在conf下面的配置文件中设置，那么就使用src下面对应文件中的默认值，这个在使用过程中非常方便，也非常有助于我们理解。

Hadoop可以说是云计算的代名词，其也有很多衍生的产品，不少衍生的配置方式都遵从Hadoop的这种配置方式，如HBase的配置文件也是$HBase/conf目录，核心配置的名称就是hbase-site.xml，如果学习了Hadoop再去学习HBase，从配置的理解上来说，就会有一种亲切的感觉。

 

可是在2.x中，Hadoop的架构发生了变化，而配置文件的路径也发生了变化，放到了$HADOOP_HOME/etc/hadoop目录，这样修改的目的，应该是让其更接近于Linux的目录结构吧，让Linux用户理解起来更容易。Hadoop 2.x中配置文件的几个主要的变化：

l 去除了原来1.x中包括的$HADOOP_HOME/src目录，该目录包括关键配置文件的默认值；

l 默认不存在mapred-site.xml文件，需要将当前mapred-site.xml.template文件copy一份并重命名为mapred-site.xml，并且只是一个具有configuration节点的空文件；

l 默认不存在mapred-queues.xml文件，需要将当前mapred-queues.xml.template文件copy一份并重命名为mapred-queues.xml；

l 删除了master文件，现在master的配置在hdfs-site.xml通过属性dfs.namenode.secondary.http-address来设置，如下：

<property>         <name>dfs.namenode.secondary.http-address</name>         <value>nginx1:9001</value> </property>

 

 

 

 

 

l 增加了yarn-env.sh，用于设置ResourceManager需要的环境变量，主要需要修改JAVA_HOME；

l 增加yarn-site.xml配置文件，用于设置ResourceManager；

 

 

2.3.2、命令文件目录的变化

在1.x中，所有的命令文件，都是放在bin目录下，没有区分客户端和服务端命令，并且最终命令的执行都会调用hadoop去执行；而在2.x中将服务端使用的命令单独放到了sbin目录，其中有几个主要的变化：

l 将./bin/hadoop的功能分离。在2.x中./bin/hadoop命令只保留了这些功能：客户端对文件系统的操作、执行Jar文件、远程拷贝、创建一个Hadoop压缩、为每个守护进程设置优先级及执行类文件，另外增加了一个检查本地hadoop及压缩库是否可用的功能，详情可以通过命令“hadoop -help”查看。

而在1.x中，./bin/hadoop命令还包括：NameNode的管理、DataNode的管理、 TaskTracker及JobTracker的管理、服务端对文件系统的管理、文件系统的检查、获取队列 信息等，详情可以通过命令“hadoop -help”查看。

l 增加./bin/hdfs命令。./bin/hadoop命令的功能被剥离了，并不是代表这些命令不需要了，而是将这些命令提到另外一个名为hdfs的命令中，通过hdfs命令可以对NameNode格式化及启动操作、启动datanode、启动集群平衡工具、从配置库中获取配置信息、获取用户所在组、执行DFS的管理客户端等，详细可以通过“hdfs -help”查看。

l 增加./bin/yarn命令。原来1.x中对JobTracker及TaskTracker的管理，放到了新增的yarn命令中，该命令可以启动及管理ResourceManager、在每台slave上面都启一个NodeManager、执行一个JAR或CLASS文件、打印需要的classpath、打印应用程序报告或者杀死应用程序等、打印节点报告等，详情可以通过命令“yarn -help”查看。

l 增加./bin/mapred命令。该命令可以用于执行一个基于管道的任务、计算MapReduce任务、获取队列的信息、独立启动任务历史服务、远程目录的递归拷贝、创建hadooop压缩包，详情可以通过“./mapred -help”。

Hadoop目前的HA(High Availability)机制分析和源代码研究