共计 1731 个字符，预计需要花费 5 分钟才能阅读完成。
1 概述
在 Hadoop1.0 的架构中，HDFS 的所有的元数据都放在一个 namenode 中，只有一个 namespace(名字空间)。这样随着 HDFS 的数据越来越多，单个 namenode 的资源使用必然会达到上限，而且 namenode 的负载也会越来越高，限制了 HDFS 的性能。
在 hadoop2.0 架构中，namenode federation（联合）通过多个 namenode/namespace 把元数据的存储和管理分散到多个节点中，使到 namenode/namespace 可以通过增加机器来进行水平扩展，并且能把单个 namenode 的负载分散到多个节点中，在 HDFS 数据规模较大的时候不会也降低 HDFS 的性能。还有可以通过多个 namespace 来隔离不同类型的应用，把不同类型应用的 HDFS 元数据的存储和管理分派到不同的 namenode 中。
2 架构
如果上图所示，一个 block pool 由属于同一个 namespace 的数据块组成，每个 namenode 管理一个 namespace，即每个 namenode 负责存储和管理一个 block pool 的元数据。而每个 datanode 是会连接所有的 namenode 的，为所有的 block pools 所共享，即每个 datanode 都会存储所有的 block pools 的数据块。每个 block pool 通过 namespace 隔离开来，对一个 block pool 的操作不会影响另外一个 block pool。
从配置和使用的角度来看，整个 HDFS 有一个唯一的 clusterid，如“hellokitty”，它可以配置多个 block pool/namespace（也叫 name service），如“mycluster”和“yourcluster”。为了方便访问不同名字空间的目录和文件，federation 还提供了一个类似 linux 的 Client Side Mount Table 的挂载机制，提供了一个统一的全局的文件系统视图（viewfs）。用户可以根据自己的需要把各个 namespace 挂载到一个叫做 viewFS 的文件系统视图的不同目录下。例如 namespace/name service“mycluster”和“yourcluster”分别挂载到 viewfs 的“/my”和“/your”目录下，如下图所示：
3 federation 和 HA
上面提到的每个 namespace/name service 配置一个 namenode，这样这个 namespace/name service 的单点问题还是存在，因此可以给每个 namespace/name service 配置成 HA。
假设我们有 4 台 namenode，分别是 namenode1，namenode2，namenode3，namenode4。其中 namenode1 和 namenode2 是 namespace/name service“mycluster”的两个主备 namenode 节点，NN_ID 分别是“mycluster”的“nn1”和“nn2”；而 namenode3 和 namenode4 是 namespace/name service“yourcluster”的两个主备 namenode 节点，NN_ID 分别是“yourcluster”的“nn1”和“nn2”。
“mycluster”和“yourcluster”分别挂载在 viewfs 的“/my”和“/your”目录下。
结构如下图所示：
4 实战 tips
一般 1000 台机器一下的中小规模的 hadoop 集群，一个 namespace/name service 就足够了，不需要考虑 federation，以免增加不必要的复杂性。
下一篇文章会详细介绍 hadoop2.0 federation 的配置
见 http://www.linuxidc.com/Linux/2014-05/101180.htm
参考资料：
http://hadoop.apache.org/docs/r2.2.0/hadoop-project-dist/hadoop-hdfs/Federation.html
更多 Hadoop 相关信息见 Hadoop 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=13
