在 《Apache Hadoop 的 HDFS federation 前世今生(上)》 已经介绍了 Hadoop 2.9.0 版本之前 HDFS federation 存在的问题，那么为了解决这个问题，社区采取了什么措施呢？

HDFS Router-based Federation

ViewFs 方案虽然可以很好的解决文件命名空间问题，但是它的实现有以下几个问题：

• ViewFS 是基于客户端实现的，需要用户在客户端进行相关的配置，那么后面对客户端升级就会比较困难，这个客户端相当于重客户端了；
• 新增或者修改路径映射，需要多方配合完成，维护成本比较高。

为了解决这个问题，社区从 Hadoop 2.9.0 和 Hadoop 3.0.0 版本开始引入了一种基于路由的 Federation方案（Router-Based Federation），具体参见 HDFS-10467，这个方案主要是由微软和优步的工程师实现。和之前的 ViewFS 不一样，这个是基于服务端实现的。

基于路由的 Federation 方案是在服务端添加了一个 Federation layer，这个额外的层允许客户端透明地访问任何子集群，让子集群独立地管理他们自己的 block pools，并支持跨子集群的数据平衡。为实现这些目标，Federation layer 必须将块访问路由到正确的子集群，维护 namespaces 的状态，并提供数据重新平衡的机制，跨集群的数据平衡可以参见 HDFS-13123。同时，这个层必须具有可扩展性，高可用性和容错性。

如果想及时了解Spark、Hadoop或者HBase相关的文章，欢迎关注微信公众号：iteblog_hadoop

Federation layer 的设计架构如上图所示，从上图可以看出，这个层包含了多个组件：Router、State Store 以及 Rebalancing mechanisms。Router 组件和 Namenode 具有相同的接口，并根据 State Store 里面的信息将客户端请求转发到正确的子集群。State Store 是远程挂载表（remote mount table，和 ViewFS 方案里面的配置文件类似，但在客户端之间共享），存储子集群相关的信息包括 load/capacity。下面对这几个模块进行介绍。

Router

一个系统中可以包含多个 Router，每个 Router 主要包含两个作用：

• 通过 Federated interface，Router 为客户端提供单个全局的 NameNode 接口，并将客户端的请求转发到正确子集群中的活动 NameNode 上；路由器接收到客户端的请求，然后检查 State Store 中是否有正确的子集群，并将请求转发到该子集群的活动 NameNode 上。路由器是无状态的，所以可以部署在负载均衡器后面并达到高可扩展性等。为了提高性能，路由器还会缓存远程挂载表里面的信息和子群集的状态。为确保 State Store 的更改可以传播到所有的路由器，每个路由器需要向 State Store 发送心跳信息。
• 收集 NameNode 的心跳信息，报告给 State Store，这样 State Store 维护的信息是实时更新的。路由器也会定期检查 NameNode 的状态（通常位于同一服务器上），并将其高可用性（HA）状态和负载/空间状态报告给 State Store。为了实现高可用性和灵活性，多个路由器可以监视相同的 Namenode 并将心跳发送到 State Store，这种方式可以提高整个系统的可靠性，State Store 中冲突的 NameNode 信息是由每个 Router 通过 quorum 协议解决。

如果想及时了解Spark、Hadoop或者HBase相关的文章，欢迎关注微信公众号：iteblog_hadoop

State Store

State Store 物理实现是分布式的，在 State Store 里面主要维护以下几方面的信息：

• 子集群的状态，包括块访问负载，可用磁盘空间，HA状态等；
• 文件夹/文件和子集群之间的映射，即远程挂载表；
• Rebalancer 操作的状态；
• Routers 的状态。

上面四点中的文件夹/文件和子集群之间的映射其实和 ViewFS 里面的远程挂载表类似，内容如下：

hdfs://tmp → hdfs://C0-1/tmp /* Folder tmp is mapped to folder tmp in subcluster C0-1 */
hdfs://share → hdfs://C0-2/share
hdfs://user/iteblog → hdfs://C0-3/user/iteblog
hdfs://user/user2 → hdfs://C0-2/user2

通过这些我们就可以知道数据在哪个子集群，针对这些信息的存储 Hadoop 为我们提供了几种实现，包括基于文件（StateStoreFileSystemImpl）的和基于ZK（StateStoreZooKeeperImpl）的方式，可以通过 dfs.federation.router.store.driver.class 参数配置。关于 Router-Based Federation 更多的情况请访问 Hadoop 的官方文档。

Router-Based Federation 整个访问流程

上面已经简单的介绍了 Router-Based Federation 的各个组件等情况，下面我们来看看这个方案客户端访问文件的流程，如下所示：

如果想及时了解Spark、Hadoop或者HBase相关的文章，欢迎关注微信公众号：iteblog_hadoop

图中的 R 代表 Router。当客户端需要进行读写操作，它的步骤如下：

• 客户端向集群中任意一个 Router 发出某个文件的读写请求操作；
• Router 从 State Store 里面的 Mount Table 查询哪个子集群包含这个文件，并从 State Store 里面的 Membership table 里面获取正确的 NN；
• Router 获取到正确的 NN 后，会将客户端的请求转发到 NN 上，然后也会给客户端一个请求告诉它需要请求哪个 子集群；
• 此后，客户端就可以直接访问对应子集群的 DN，并进行读写相关的操作。

由于 Router-based HDFS federation 还算比较新的特性，所以社区分了几个阶段修复或添加了一些新的功能，比如 Apache Hadoop 3.2.0 版本修复或添加了一些功能，参见 HDFS-12615，以及 Router-based HDFS federation 稳定性相关的 ISSUE HDFS-13891，这个 ISSUE 可能会在 Apache Hadoop 3.3.0 版本发布。