社区版Federated HDFS（多Name Node）实现浅析

    目前，HDFS集群的架构包括了单个Name Node和若干个Data Node。Name Node负责两方面的事情：一方面是存储和管理整个命名空间，包括创建、修改、删除和列举文件目录等文件系统级别的操作；另一方面是管理Data Node和文件块。Data Node主要负责文件块的持久化存储和远程访问。

 

    在现有模式下，存储负载的增加对Data Node和Name Node都会造成影响。对于Data Node而言，可以通过添加节点实现水平扩展；而对于单个的Name Node而言，只能通过增加内存和硬盘的方式实现垂直扩展。正是单个Name Node的垂直扩展方式成为了HDFS集群的瓶颈。

    根据Yahoo HDFS团队的报告，一个存储能力为10.4PB，拥有3700个Data Node的HDFS集群，分配给Name Node的JAVA堆已达到40GB，随着存储负载的继续增加，很快就会达到单机可配置物理内存的极限（在一些机器上是64GB）。使用如此大的JAVA堆会造成多方面的性能问题，比如：垃圾回收会变得低效，更长的初始化时间，甚至调试JVM也会变得困难。

    为了解决HDFS单个Name Node的垂直扩展问题，Yahoo HDFS团队提出了采用多Name Node提高HDFS集群的扩展性，即实现Name Node的水平扩展。大致思路是，在一个HDFS集群里面可以拥有多个Name Node，每个Name Node负责管理一个命名空间（Namespace），而且命名空间之间是相互独立的，这些命名空间共享该HDFS集群里Data Node的存储空间，其共享方式并不是以Data Node粒度来划分，而是引入了Block Pool的概念。所谓Block Pool是一组文件块的集合，这些文件块分散在HDFS集群的Data Node上，每个文件块唯一属于一个Block Pool，每个Block Pool唯一属于一个命名空间。根据Yahoo HDFS团队的设计，一个命名空间可以拥有一个或者多个Block Pool，不过在最新的实现中一个命名空间只拥有一个Block Pool。另外，一个命名空间和它所拥有的Block Pool称为一个Namespace Volume，它是一个自包含的管理单位。下图是改进后的HDFS模型：

    从功能层次来看，HDFS从上到下包括命名空间管理，文件块管理（包括对Data Node的管理）和文件块存储及访问，在上图中，后两项统称为Block Storage。如前所述，目前HDFS的命名空间管理和文件块管理都实现在Name Node上，在API级别这两种功能都没有明确的区分开。不过，Block Pool的引入使得对文件块的抽象管理变得清晰。因此，实现新的模型也有两种方式，一种是沿用现在的方式，Block Pool放入Name Node中实现；另外一种是将文件块管理从Name Node中分离出来，单独创建一个服务来管理Block Pool。相对而言，第一种更简单，第二种更加灵活，比如能够支持非HDFS命名空间对文件块的直接访问。在最新的社区版本实现中，Yahoo HDFS团队采用的是第一种方式，如下图，但是从长远来看，还是会采用第二种方式。

       最后，Federated HDFS补丁在apache上的链接是：https://issues.apache.org/jira/browse/HDFS-1052，有兴趣的同学可以多去研究研究。