HDFS Federation(HDFS 联盟)介绍

1. 当前HDFS架构和功能概述

咱们先回顾一下HDFS功能。HDFS实际上具备两个功能：命名空间管理（Namespace management）和块/存储管理服务（block/storage management）。

1.1 命名空间管理

HDFS的命名空间包含目录、文件和块。命名空间管理：是指命名空间支持对HDFS中的目录、文件和块作相似文件系统的建立、修改、删除、列表文件和目录等基本操做。

1.2 块/存储管理

在块存储服务中包含两部分工做：块管理和物理存储。这是一个更通用的存储服务。其余的应用能够直接创建在Block Storage上，如HBase，Foreign Namespaces等。

1.2.1 块管理

A) 处理Data Node向Name Node注册的请求，处理datanode的成员关系，处理来自Data Node周期性的心跳。

B) 处理来自块的报告信息，维护块的位置信息。

C) 处理与块相关的操做：块的建立、删除、修改及获取块信息。

D) 管理副本放置（replica placement）和块的复制及多余块的删除。

1.2.2 物理存储

所谓物理存储就是：Data Node把块存储到本地文件系统中，对本地文件系统的读、写。

1.3 当前HDFS的架构

在当前的HDFS架构中（Hadoop v0.23以前），在整个HDFS集群中只有一个命名空间，而且只有单独的一个Name Node，这个Name Node负责对这单独的一个命名空间进行管理。这也正是单点失效（Single Point Failure）的隐患所在。本文所讲的HDFS Federation就是针对当前HDFS架构上的缺陷所作的改进，简单说HDFS Federation就是使得HDFS支持多个命名空间，而且容许在HDFS中同时存在多个Name Node。

简单回顾一下目前HDFS的架构，以下图所示。在整个HDFS集群中只有一个Namenode，还有一个Backup Namenode。Namenode会实时将变化的HDFS的信息同步给Backup Namenode。Backup Namenode顾名思义是用来作Namenode的备份的。Namenode中命名空间以层次结构组织中存储着文件名和BlockID的对应关系、 BlockID和具体Block位置的对应关系。这个单独的Namenode管理着数个Datanode，Block分布在各个Datanode中，每一个 Datanode会周期性的向此Namenode发送心跳消息，报告本身所在Datanode的使用状态。Block是用来存储数据的最小单元，一般一个 文件会存储在一个或者多个Block中，默认Block大小为64MB。

2. 单个Namenode的HDFS架构的局限性

2.1 Namespace（命名空间）的限制

因为Namenode在内存中存储全部的元数据（metadata），所以单个Namenode所能存储的对象（文件+块）数目受到 Namenode所在JVM的heap size的限制。50G的heap可以存储20亿（200 million）个对象，这20亿个对象支持4000个datanode，12PB的存储（假设文件平均大小为40MB）。

随着数据的飞速增加，存储的需求也随之增加。单个datanode从4T增加到36T，集群的尺寸增加到8000个datanode。存储的需求从12PB增加到大于100PB。

2.2 性能的瓶颈

因为是单个Namenode的HDFS架构，所以整个HDFS文件系统的吞吐量受限于单个Namenode的吞吐量。毫无疑问，这将成为下一代MapReduce的瓶颈。

2.3 隔离问题

因为HDFS仅有一个Namenode，没法隔离各个程序，所以HDFS上的一个实验程序就颇有可能影响整个HDFS上运行的程序。那么在 HDFS Federation中，能够用不一样的Namespace来隔离不一样的用户应用程序，使得不一样Namespace Volume中的程序相互不影响。

2.4 集群的可用性

在只有一个Namenode的HDFS中，此Namenode的宕机无疑会致使整个集群不可用。

2.5 Namespace和Block Management的紧密耦合

当前在Namenode中的Namespace和Block Management组合的紧密耦合关系会致使若是想要实现另一套Namenode方案比较困难，并且也限制了其余想要直接使用块存储的应用。

2.6 为何纵向扩展目前的Namenode不可行？好比将Namenode的Heap空间扩大到512GB。

这样纵向扩展带来的第一个问题就是启动问题，启动花费的时间太长。当前具备50GB Heap Namenode的HDFS启动一次大概须要30分钟到2小时，那512GB的须要多久？

第二个潜在的问题就是Namenode在Full GC时，若是发生错误将会致使整个集群宕机。

第三个问题是对大JVM Heap进行调试比较困难。优化Namenode的内存使用性价比比较低。

3. 为何要引入Federation

引入Federation的最主要缘由是简单，其简单性是与真正的分布式Namenode相比而言的。Federation可以快速的解决了大部分单Namenode HDFS的问题。

Federation是简单鲁棒的设计，因为联盟中各个Namenode之间是相互独立的。Federation 整个核心设计实现大概用了3.5个月。大部分改变是在Datanode、Config和Tools，而Namenode自己的改动很是少，这样 Namenode原先的鲁棒性不会受到影响。比分布式的Namenode简单，虽然这种实现的扩展性比起真正的分布式的Namenode要小些，可是能够 迅速知足需求。另一个缘由是Federation良好的向后兼容性，已有的单Namenode的部署配置不须要任何改变就能够继续工做。

所以Federation（联盟）是将来可选的方案之一。在Federation架构中能够无缝的支持目前单Namenode架构中的配置。

4. HDFS Federation

HDFS Federation使用了多个独立的Namenode/namespace来使得HDFS的命名服务可以水平扩展。在HDFS Federation中的Namenode之间是联盟关系，他们之间相互独立且不须要相互协调。HDFS Federation中的Namenode提供了提供了命名空间和块管理功能。HDFS Federation中的datanode被全部的Namenode用做公共存储块的地方。每个datanode都会向所在集群中全部的 Namenode注册，而且会周期性的发送心跳和块信息报告，同时处理来自Namenode的指令。

4.1 Federation HDFS与当前HDFS的比较

• 当前HDFS只有一个命名空间（Namespace），它使用所有的块。而Federation HDFS中有多个独立的命名空间（Namespace），而且每个命名空间使用一个块池（block pool）。

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

• 当前HDFS由一个Namenode和一组datanode组成。而Federation HDFS由多个Namenode和一组datanode，每个datanode会为多个块池（block pool）存储块。

4.2 Block Pool(块池)

所谓Block pool(块池)就是属于单个命名空间的一组block(块)。每个datanode为全部的block pool存储块。Datanode是一个物理概念，而block pool是一个从新将block划分的逻辑概念。同一个datanode中能够存着属于多个block pool的多个块。Block pool容许一个命名空间在不通知其余命名空间的状况下为一个新的block建立Block ID。同时，一个Namenode失效不会影响其下的datanode为其余Namenode的服务。

当datanode与Namenode创建联系并开始会话后自动创建Block pool。每一个block都有一个惟一的标识，这个标识咱们称之为扩展的块ID（Extended Block ID）= BlockID+BlockID。这个扩展的块ID在HDFS集群之间都是惟一的，这为之后集群归并创造了条件。

Datanode中的数据结构都经过块池ID（BlockPoolID）索引，即datanode中的BlockMap，storage等都经过BPID索引。

在HDFS中，全部的更新、回滚都是以Namenode和BlockPool为单元发生的。即同一HDFS Federation中不一样的Namenode/BlockPool之间没有什么关系。

Hadoop V0.23版本中Block Pool的管理功能依然放在了Namenode中，未来的版本中会将Block Pool的管理功能移动的新的功能节点中。

4.3 Datanode的改进

在datanode中，对应于每一个Namnode都有一条相应的线程。每一个datanode会去每个Namenode注册，而且周期性的给全部的 Namenode发送心跳及datanode的使用报告。Datanode还会给Namenode发送其所在的block pool的block report（块报告）。因为有多个Namenode同时存在，所以任何一个Namenode均可以随时动态加入、删除和更新。

4.4 Federation中的其余方面的改进

• 提供了工具，对于Namenode的初始化和退役的监控和管理。

• 容许在datanode级别或者block pool级别的负载均衡。

• Datanode的后台守护进程，为Federation所作的磁盘和目录扫描。

• 提供了显示Namenode的Block pool的使用状态的Web UI。

• 还提供了对所有集群存储使用状态的UI展现。

• 在Web UI中列出了全部的Namenode及其细节，如Namenode-BlockPoolID和存储的使用状态，失去联系的、活的和死的块信息。还有前往各个Namenode Web UI的连接。

• Datanode退役状态的展现。

4.5 多命名空间的管理问题

在一个集群中须要惟一的命名空间仍是多个命名空间，核心问题命名空间中数据的共享和访问的问题。使用全局惟一的命名空间是解决数据共享和访问的一种方法。在多命名空间下，咱们还可使用Client Side Mount Table方式作到数据共享和访问。

如上图所示，每一个深色三角形表明一个独立的命名空间，上方浅色的三角形表明从客户角度去访问下方的子命名空间。各个深色的命名空间Mount到浅色 的表中，客户能够访问不一样的挂载点来访问不一样的命名空间，这就如同在Linux系统中访问不一样挂载点同样。这就是HDFS Federation中命名空间管理的基本原理：将各个命名空间挂载到全局mount－table中，就能够作将数据到全局共享；一样的命名空间挂载到我的的mount-table中，这就成为应用程序可见的命名空间视图。

4.6 Namespace Volume（命名空间卷）

一个Namespace和它的Block Pool合在一块儿称做Namespace Volume。Namespace Volume是一个独立完整的管理单元。当一个Namenode/Namespace被删除，与之相对应的Block Pool也也被删除。在升级时每个Namespace Volume也会总体做为一个单元。

4.7 ClusterID

在HDFS Federation中添加了Cluster ID用来区分集群中的每一个节点。当格式化一个Namenode时，这个ClusterID会自动生成或者手动提供。在格式化同一集群中其余Namenode时会用到这个ClusterID。

4.8 HDFS Federation对老版本的HDFS是兼容的

这种兼容性可使得已有的Namenode配置不须要任何改变继续工做。