HDFS2.0的新特性(HA、Federation)

一、HDFS HA

　　Hadoop 1.0中SecondaryNameNode作用在于避免EditLog不断增大，导致NameNode从失败恢复时耗时太大的问题；另外起到冷备份的作用。但不能起到热备份的作用，所以还是不能解决NameNode单点故障问题。

　　名称节点保存信息：FsImage、EditLog、文件映射信息(文件包括的块，块存储在哪些数据节点)

　　HDFS HA（High Availability）是为了解决NameNode单点故障问题。
1、HA集群设置两个名称节点，“活跃（Active）”和“待命（Standby）”。

　　两种名称节点的状态实时同步，可以借助于一个共享存储系统来实现。一旦活跃名称节点出现故障，就可以立即切换到待命名称节点。

2、共享存储系统(Zookeeper等)负责把活跃的名称节点的EditLog实时同步到待命名称节点。

　　待命名称接收收到新的EditLog，更新到自己的FsImage和EditLog中，确保两个名称节点的FsImage和EditLog实时一致，以便实时可切换。

　　HDFS客户端对目录和文件的操作只影响活跃的名称节点的EditLog。

3、数据节点同时向两个名称节点汇报名称节点维护的映射信息(文件包括哪些块，块存储在哪些数据节点)。　　
4、Zookeeper集群通过心跳监测两个名称节点的状态，确保任何时刻只有一个名称节点在对外服务。

 二、HDFS Federation

1.HDFS1.0中存在的问题

单点故障问题--HA解决
不可以水平扩展--不可简单通过添加机器新增名称节点；通过增加CPU、内存等垂直扩展也有限，另外如果单个FsImage过大，会导致HDFS启动时间过长。
系统整体性能受限于单个名称节点的吞吐量
单个名称节点难以提供不同程序之间的隔离性
HDFS HA是热备份，提供高可用性，但是无法解决可扩展性、系统性能和隔离性

2.HDFS Federation的设计

(1)在HDFS Federation中，设计了多个相互独立的名称节点，使得HDFS的命名服务能够水平扩展，这些名称节点分别进行各自命名空间和块的管理，相互之间是联盟（Federation）关系，不需要彼此协调。并且向后兼容

(2)HDFS Federation中，所有名称节点会共享底层的数据节点存储资源，数据节点向所有名称节点汇报

(3)属于同一个命名空间的块构成一个“块池”

3. HDFS Federation的访问方式

(1)对于Federation中的多个命名空间，可以采用客户端挂载表（Client Side Mount Table）方式进行数据共享和访问
(2)客户可以访问不同的挂载点来访问不同的子命名空间

(3)把各个命名空间挂载到全局“挂载表”（mount-table）中，实现数据全局共享
(4)同样的命名空间挂载到个人的挂载表中，就成为应用程序可见的命名空间

图 客户端挂载表方式访问多个命名空间(每个阴影三角形代表一个独立名称节点维护的命名空间)

 4、HDFS Federation并不能解决单点故障问题　　

　　也就是说，每个名称节点都存在在单点故障问题，需要为每个名称节点部署一个“待命”名称节点，以应对名称节点挂掉对业务产生的影响