在实际的生产环境中，一般都会搭建HDFS的集群来进行大数据文件的存储。而作为集群来说，应该提供基本负载均衡的功能。HDFS的联盟Federation便是负载均衡的一种具体实现方式。另一方面，通过使用HDFS的联盟Federation也可以对NameNode进行水平的扩展。
视频讲解如下：
一、什么是联盟？
HDFS提供的存储服务实际上包含两个部分，即：命名空间管理（Namespace management）和块存储管理服务（Block/Storage management）。HDFS中的目录、文件和数据块都属于命名空间。命名空间管理则是指对目录和文件的基本操作，如：创建、修改、删除等；而块存储管理服务则主要负责将数据按照数据块进行存储。图1（摘自Hadoop官网）明了它们之间的关系。
如果在整个HDFS中只存在一个命名空间并且只由一个NameNode来维护，必然存在单点故障的问题；也不利于集群的扩展和性能的提高。因此，HDFS引入了联盟的机制。简单来说，就是让HDFS可以支持多个命名空间，并由不同的NameNode来进行维护。
图2（摘自Hadoop官网）使用了多个NameNode来维护不同的命名空间，就相当于在MySQL数据库中创建不同的数据库一样，它们彼此之间可以相互逻辑隔离。尽管是不同的命名空间，但是从数据块存储的角度来看，这些NameNode维护的命名空间是使用的共享存储的方式来存储数据块，即：后端的DataNode将会为每一个命名空间提供存储的空间。
另一方面，由于NameNode会接收客户端的请求。如果存在多个NameNode，那么客户端的请求应该由谁进行处理呢？这时候我们就需要有ViewFS（视图文件系统）的支持。ViewFS的本质就是一系列的路由规则，这些路由规则需要事先创建好。客户端的请求先提交到ViewFS上，再根据事先配置好的路由规则，进而转发给不同的NameNode进行处理。
二、基于ViewFS的联盟架构
下图展示了以四个节点为例来部署联盟的架构。这里使用了四台虚拟机，分别是：bigdata112、bigdata113、bigdata114和bigdata115。在bigdata112和bigdata113上分别部署两个NameNode；在bigdata114和bigdata115上各部署一个DataNode。而ViewFS可以跟NameNode部署在同一个节点上，即：bigdata112和bigdata113。
在解决NameNode扩展能力方面，HDFS虽然提供了ViewFS的联盟架构，但这个方案有很强的局限性，主要体现在以下几个方面：
- HDFS路径Scheme需要变为ViewFs，ViewFs路径和其他Scheme路径互不兼容。比如DistributedFileSystem无法处理ViewFs的路径，也就是说如果启用ViewFS，则需要将Hive的元数据管理、ETL脚本、MR/Spark作业中的所有HDFS路径修改为ViewFS。
- ViewFS是基于客户端实现的，需要用户在客户端进行相关的配置，那么后面对客户端升级就会比较困难，这个客户端相当于重客户端了。
- 新增或者修改路径映射，需要多方配合完成，维护成本比较高。
