聊聊HDFS RBF第二阶段的主要改进
前言
HDFS RBF特性（基于路由的Federation解决方案）已经在Apache Hadoop 3.0.0中正式发布了，此特性的发布将会大大方便于广大用户多于多集群的使用。另一方面来说，面对往后日益扩展，日益多样化的环境，单一，同构化的集群运行模式，不会是一个一劳永逸的方式了，异构，多集群的方式将会是一个趋势。其实在目前发布的版本中，HDFS RBF特性单纯实现了一个最基本功能的版本，里面还有很多地方可以继续完善，使之与当前的HDFS完全匹配，比如目前还没有支持的改进点有例如：webHDFS, 安全认证，Quota配额支持，ACL管控等等。不过不用担心，这些提到的点，社区都将会在RBF第二阶段的工作中进行完善（详见社区JIRA： HDFS-12615，想必听完大家都很期待吧。本文，笔者讲带领大家展望一下这方面的内容。
RBF第二阶段工作概述
由于笔者在过去2个月时间内，一直关注和参与了部分HDFS RBF第二阶段的工作，所以对这块还是比较熟悉的。针对目前第二阶段的工作进展，主要实现或正在实现了下面一些小特性：
已实现的：
- Mount table ACL管理，为每个mount table设置了ACL属性。这样每个用户只能管理自己权利范围之内的挂载点了。
- 全局Quota的支持。这里的Quota值是从各个子集群的Quota值进行汇聚所得。
- Router状态管理。类似于NameNode节点的运行/安全模式/下线这类状态的跟踪管理。
- Erasure Coding操作在RBF环境的支持。
- 其它改进。这个就比较泛了，比如单元测试的完善，日志信息的纠正改进或是其它一些小的改动等等。
正在实现中：
- RBF的WebHDFS实现。
- RBF内部实现kerberos认证。这是RBF内部对安全这块的一个改进。
待定中的内容。这块内容请继续往下看，这个属于比较开放式的话题内容。
RBF第二阶段开放式话题
这里的开放式内容指的是针对RBF第二阶段工作来说，这并不是必须要完成的工作。这部分的内容是一些比较大胆的创新和改进，主要有以下3点内容。
集群间数据平衡： Subcluster Rebalancer
这个大家可以类比于目前HDFS中的Balancer工具。在federation的环境下，每个子集群就相当于是一个“节点”，这些“节点”共同构成了一个大的集群。当RBF对外呈现为一个逻辑上的单一集群时，那么就可能存在所写入的数据出现分布不均衡的现象，里面的原因就有可能有很多种了。比如说A挂载点的路径下，写入的数据频率明显要高于其它目录，久而久之，A挂载点的目标路径集群所写入的数据自然就多了。这个时候我们可以用一种集群间的Balancer工具来做这种平衡，而对于集群间的数据拷贝，我们可以利用现成的DistCp工具来帮我做这件事情。一旦数据跨集群拷贝完毕，还有一步很重要的操作就是更新挂载点信息。因为对于源路径来说，目标路径已经换地址了。
动态HDFS集群： Router与DataNode的交互
说到动态HDFS集群，我们得先明白它的相对面-静态HDFS 集群在这里的含义。比方说，我们已经搭好若干套独立的HDFS集群，然后将他们加入到RBF内，那么这种模式就是静态的集群。而我们在这里所设想的动态模式是指我们只需事先定义好若干NameNode（子集群），然后我们只需往里加DataNode即可，这些DataNode会根据一定的分配策略自动被Router分配到所属的子集群内。在这里，相当于Router扮演了一种资源管控的角色。为什么会有这种想法呢？因为在现有模式下，DataNode需要依赖配置文件来决定它应该向哪个NameNode进行汇报，这种模式在集群进行扩容时显得比较麻烦，其实这个完全交给Router来做。也就是我们要增加Router和DataNode节点直接的通信。在未来，甚至我们可以做到集群间的节点迁移，这些也由Router来控制，对用户无感知。在这种理想的情况下，DataNode节点对于用户来说只是一种资源，根本无须人工介入进行集群的配置。
挂载点的合并
挂载点的合并指的是将目前的挂载点在某种关系上的合并。而不是当前各自完全独立的情况。
阐述了这么多，想必大家对HDFS RBF的新功能特性已经是非常期待了吧，如果不出意外的情况下，这些改进将会出现在即将发布的版本Apache Hadoop的2.9.1和3.0.1版本内，到时大家可以留意一下。
