Router-Based HDFS Federation 在滴滴大数据的应用

出品 | 滴滴技术

做者 | 费辉

1.背景

HDFS 的 Master/Slave 架构，使得其具备单点瓶颈，即随着业务数据的大规模膨胀，Master 节点在元数据存储与提供服务上都会存在瓶颈。为了克服 HDFS 单点瓶颈存在的扩展性、性能、隔离问题，社区提出了Federation（https://issues.apache.org/jira/browse/HDFS-1052 ）方案来进行解决。

可是使用该方案以后，暴露给客户的问题就是，同一个集群出现了多个命名空间（namespace），客户须要知道读写的数据在哪一个命名空间下才能够进行操做。为了解决统一命名空间的问题，社区提出了基于客户端（client-side）的解决方案 ViewFS（https://issues.apache.org/jira/browse/HADOOP-7257 ），该方案会在客户端作好配置，用户目录一对一的挂载到具体的命名空间目录上，滴滴在解决 Federation 问题时使用的就是这个方案。

ViewFS 方案也存在一些问题：

• 对于已经发布出去客户端升级比较困难；

• 对于新增目录须要增长挂载配置，与产品对接，维护起来比较困难。

社区在 2.9 和 3.0 版本中发布了一个新的解决统一命名空间问题的方案 Router-Based Federation（https://issues.apache.org/jira/browse/HDFS-10467 ），该方案是基于服务端进行实现的，在升级管理方面比较好维护，滴滴最近引入了该方案，并进行了一些改造。

2.Router-Based Federation 方案介绍

Router-Based Federation 对外提供了 Router 服务，包含在 Federation layer 中，以下图所示。这个 Router 服务将容许用户透明地访问任何子集群，让子集群独立管理本身的 Blockpool。为了实现这些目标，Federation layer 必须将 Block 访问引导至适当的子群集。同时，它具备可扩展性，高可用性和容错性。

Federation layer 包含多个组件。Router 是一个与 Namenode 具备相同接口的组件，根据 State Store 的元数据信息将客户端请求转发给正确的子集群。State Store 组件包含了远程挂载表（具备 ViewFS 特性，但在客户端之间共享）和有关 SubCluster 的负载/空间信息。

下图架构中显示每一个子集群增长了 Router（标记为“R”）和逻辑集中式（但物理分布式）的状态存储（State Store），以及每一个 SubCluster 的 Namenodes（“NN”）和 Datanodes（“DN”）。这种方法与 YARN Federation（YARN-2915）具备相同的架构。

一、Router 组件

系统中能够有多个的 Router，每一个 Router 有两个角色：

1）向客户端提供一个全局 Namenode 接口并负责转发请求正确的子群集中的 Active Namenode；

2）在 State Store 中维护关于 Namenode 的信息。

Router 在收到客户端请求，根据 mount-table 中的信息查找正确的子集群，而后转发对该集群请求到对应子集群 Active Namenode。在收到 Active Namenode 的响应结果以后，将结果返回给客户端 。 为了提高性能，Router 能够缓存远程挂载表条目和子集群的状态。

对于 Namenode 信息的维护，Router 按期检查一个 Namenode 的状态和向 State Store 报告其高可用性（HA）状态和负载/空间状态。 为了提升 Namenode HA 的性能，Router 使用 State Store 中的高可用性状态信息,以将请求转发到最有可能处于活动状态的 Namenode。

1.1 可用性与容错性

Router 是无状态的，全部 Router 同时提供服务。若是某个 Router 变成不可用，不影响其余任何 Router 提供服务。

客户端配置他们的 DFS HA 客户端（例如 ConfiguredFailoverProvider 或 RequestHedgingProxyProvider）与 Federation 中的全部 Router 配合使用。

为了实现高可用性和灵活性，多个 Router 能够监控相同的 Namenode 并把心跳发送信息到 State Store。 若是 Router 出现故障，这会增长信息的恢复能力。

1.2 Safe Mode

若是 Router 不能链接到 State Store，它可能会错误地提供过时 locations 的访问，让 Federation 进入不一致的状态。

为防止这种状况发生，当 Router 没法链接到 State Store 一段时间后，它会进入安全模式（相似于 Namenode 的 safe mode）。当客户端尝试访问 safe mode 的 Router 时候，会抛出异常，客户端的 Proxy 捕获后，会尝试链接其余的 Router。相似于 Namenode，Router 保持在这个安全模式，直到它肯定 State Store 可用为止。

这能够防止 Router 启动时出现不一致。 假定一个 Router 若是在一段时间内没有心跳（例如，心跳间隔的五倍），则它已经死亡或处于安全模式。

1.3 交互接口

为了与用户和管理员进行交互，Router 公开了多个接口。包括 RPC、Admin、WebUI 。

RPC 实现了客户端与 HDFS 交互的最多见接口。 目前仅支持使用普通 MapReduce，Spark 和 Hive ( on Tez，Spark 和MapReduce）。一些高级特性，如快照、加密和分层存储在将来版本实现。 全部未实现的功能都会抛出异常。

Admin 为管理员实现的一个 RPC 接口，包括从子集群获取信息、添加/删除条目到 mout table。也能够经过命令行获取和修改 Federation 信息。WebUI 实现了一个可视化 Federation 状态，模仿了当前的 Namenode UI，除此以外，还包含 mout table，每一个子集群的成员信息以及 Router 的状态。

二、State Store 组件

State Store 维护的信息包括：

1）子集群的块访问负载，可用磁盘空间，HA 状态等状态；

2）文件夹/文件和子集群之间的映射，即远程 Mount Table；

3）Router 的状态。State Store 的后端存储是可配置的。 既能够能够存储在文件中，也能够存在 ZooKeeper 中。

2.1 Membership

Membership 反映了 Federation 中的 Namenode 的状态。包括有关子集群的信息，例如存储量和节点数量。Router 按期检测一个或多个 Namenode 的信息。

2.2 Mount Table

管理文件夹和子集群之间的映射。 它与 ViewFS 中的 Mount Table 相似：hdfs://tmp → hdfs://C0-1/tmp /* Folder tmp is mapped to folder tmp in subcluster C0-1 */

2.3 Router State

为了跟踪 Router 中 caches 的状态，Router 将其版本信息、状态信息等存储在 State Store 中。

三、将来计划

目前 RBF 只是实现了一些基本 Namenode 接口，有些接口并不支持，HDFS-13655（https://issues.apache.org/jira/browse/HDFS-13655 ）中会实现一些不支持的协议接口；当前 RBF 的稳定性也还存在一些问题，HDFS-13891（https://issues.apache.org/jira/browse/HDFS-13891 ）会跟踪一些稳定性问题进而解决掉。

3.Router-Based Federation 在滴滴的应用

一、部署状况

社区 Hadoop 在 2.9 和 3.0 中发布了 RBF 这个 Feature，滴滴目前的 Hadoop 版本是 2.7.2，咱们的作法是将 branch-2 分支里关于 RBF 的提交都移植到了咱们的代码中，作了一些必要的修改工做。

在滴滴的大数据集群中，Federation 拆成了 5 组 Namenode。通过性能测试，咱们得出这样的结论：一个 Router 对应服务一组 Namenode 不存在压力，所以咱们选择部署 5 个 Router 来服务整个集群。目前 Router-Based Federation 方案在滴滴已经稳定运行 2 月有余。

二、兼容性

直接引入 RBF 在运行 Hive 任务时会出现一些错误，例如 Wrong FS 等等。为此咱们将 Hive 客户端代码作了修改，使其兼容 RBF。在 Hive 的元数据存储中，location 信息存储的是带HDFS Schema 的绝对路径信息，在 Hive 代码中处理 move 逻辑时，咱们都会将路径作一个 resolve 获得实际的 HDFS 路径，而后再进行处理，这样能够避免该问题的出现。

三、RBF 社区贡献

在实际测试中，咱们也发现了 RBF 的一些性能问题和 BUG，包括 Quota 问题、mount-table cache 使用不当问题、mount-table 建立 znode 出现 Null 问题等等。在解决这些问题以后，将 patch 贡献给了社区，大部分被社区接收，具体修复和优化以下：

• HDFS-13710：https://issues.apache.org/jira/browse/HDFS-13710

• HDFS-13821：https://issues.apache.org/jira/browse/HDFS-13821

• HDFS-13836：https://issues.apache.org/jira/browse/HDFS-13836

• HDFS-13844：https://issues.apache.org/jira/browse/HDFS-13844

• HDFS-13845：https://issues.apache.org/jira/browse/HDFS-13845

• HDFS-13854：https://issues.apache.org/jira/browse/HDFS-13854

• HDFS-13856：https://issues.apache.org/jira/browse/HDFS-13856

• HDFS-13857：https://issues.apache.org/jira/browse/HDFS-13857

• HDFS-13802：https://issues.apache.org/jira/browse/HDFS-13802

• HDFS-13852：https://issues.apache.org/jira/browse/HDFS-13852

• HDFS-14114：https://issues.apache.org/jira/browse/HDFS-14114

四、额外工做

除了贡献给社区的一些工做，内部也有额外的一些对 RBF 的工做。RBF 的 WebUI 目前的显示存在一些问题，节点数量、存储总量的显示为各个集群之和，内部对存储、节点数量的计算作了一些修改；为了更好的对接产品，对外增长了一些 API，方便产品服务经过 API 远程增长 mount table 条目信息，而不仅是使用管理工具。

4.总结

Router-Based Federation 方案在滴滴内部已经上线，稳定运行了两个多月的时间了，在运维和产品上提供了极大的便利。将来咱们会继续参与社区，为丰富 RBF 的功能以及提升其稳定性贡献一份力量。