目录
1. 前言
Federation翻译成中文是联盟或联邦的意思，网上有很多介绍HDFS Federation的文章，官网上的Federation.html也做了专门的介绍。本文试图画蛇添足，以更通俗的方式重复一遍，以帮助对HDFS Federation的理解。
2. 背景
为何需要Federation？众所周知，之前的HDFS存在如下几个缺陷：
1) NameNode存在单点，不具备高可用性
2) 由于受限于单个NameNode，支撑的文件数量有限
3) 同样受限于单个NameNode，吞吐量有限
站在运维和高可用性的角度，解决这些问题，系统运行可以省心得多。HDFS Federation因此很自然的诞生了，但请注意它只解决了后两个问题，第一个问题不在它的解决范畴之内。
为何说很自然的诞生，稍加思考即可明白解决这两个问题能有什么手段：无非是升级机器的内存和CPU，也就是纵向升级；另一个就是增加机器，也就是横向升级。
显然升级内存和CPU的手段是非常有限的，不能从根本上解决问题，两个问题仍然存在，因此可行的只有增加机器这个唯一手段了。
3. 解析
没有Federation之前的HDFS架构如下图所示（没有画SecondaryNameNode，是因为SecondaryNameNode是针对单点，而非Federation要解决的两个问题），这是一种非常简洁的架构，很明显压力都集中在单个NameNode上，它成了系统瓶颈：
Federation版本的HDFS架构变成如下，显然这里不止一个NameNode，而是存在多个NameNode，并且可以按需要添加新的NameNode进行横向扩展。这里的多个NameNode间地位是平等的，而且互不干涉互不隶属，站在每个NameNode上看，它就是一个独立的HDFS集群：
南京全面深化改革工作领导小组成立，由市委书记和市长同时担任改革小组组长，通过前面的描述不难发现HDFS Federation和这个有点类似，那么就会产生一个疑问：听谁的？不乱了么？答案是：都听。
俗话曰无规则不成方圆，显然都听就乱序了。如果把这个关系理解成外包，可能更好理解一点，比如同一家外包公司会同时服务于多家公司，如下图所示：
可以进一步抽象：一个物理节点被虚拟化成多个虚拟节点，虚拟节点和NameNode是一一对应的，但物理节点和NameNode是一对多的关系。实际上Google Borg/Apache Mesos/Hadoop Yarn就是这样一种行为。进一步可看作：有多少个NameNode，就有多少个物理磁盘一样，Namespace就相当于C:、D:等：
HDFS Federation虽然未解决单点问题，但因为多个NameNode的存在，单个NameNode故障的影响就降低了，所以可以说HDFS Federation弱化了单点问题。
要从根本上解决单点，有多种可行的手段：
1) Share Storage，主备NameNode共享同一个存储，可保证数据完整性
2) 像SecondaryNamenode一样的备份，但不能保证数据完整性
3) 引入两阶段提交（2PC），可保证一致性，但写性能会下降
4) 引入Quorum NRW，也可保证一致性，可以选择牺牲读性能来提升写性能
也许2PC是相对较好的解决方式。