前言
在目前单一大HDFS集群越来越无法支撑我们的业务场景时，越来越多的公司开始考虑采用HDFS federation方案来做。这里就自然会衍生出一个问题：新federation出来的Namespace，我如何将数据从原集群（NameNode）同步出来呢？而且在这个过程中，还会有每天增量数据的写入在老集群内。假若只是静态的数据，我们启动一个distcp任务就可以做这部分跨namespace的数据的同步了，但是有了增量数据这个影响因素，这个事情就稍微会变得复杂一点了。最近Hadoop社区在做关于这块的实现和讨论，也实现了一个初始的HDFS federation间的balance工具。本文来聊聊此工具内部的实现细节，相信这个工具在我们实际的生成环境下还是十分有用处的。
粗粒度的federation Balance方案
关于federation Balance的使用场景，主要来源于下面两种情况：
- 纯粹为了平衡各个federation NN上的数据，防止一个集群下的数据量过多进而出现性能瓶颈问题，这种情况在已经使用多集群管理方案下(HDFS RBF或者ViewFs)是比较常见的，
- 新增federation namespace时，从原有的namespace下拆离出数据到新的namespace，这时我们也有着方面的数据同步的需求。
关于上面提到的第二点，笔者在之前写过一篇基于initial distcp + 多次snapshot diff ditcp的方案，不过那套方案执行起来比较的粗粒度，还不是特别的完善，需要额外大量的手工重复的命令的执行。与此粗粒度federation Balance方案的细节可参阅笔者之前写的文章：HDFS数据迁移解决方案之DistCp工具的巧妙使用。
系统化的federation Balance工具方案
本文笔者所要阐述的是上述粗粒度federation Balance方案的完善版本，即工具化的完整实现方案，目前社区已经有对应的实现在讨论了。
工具化实现方案和上面谈论的粗粒度的Balance方案在本质原理上是一样的，分两阶段执行：
1）第一阶段，执行首次distcp数据拷贝。
2）第二阶段，执行后续diff的distcp来做拷贝，基于目录的snapshot来做，每次执行完一次diff的distcp，随后比较一次此时快照和当前文件目录最新的状态，如果还是有updated的change diff，再执行diff的distcp拷贝直到数据完全无差异为止。
同步原理如下图所示：
相比较于纯手工触发执行distcp去做初始和diff的拷贝，federation balance方案还考虑了额外以下几点：
- ditcp任务的schedul执行管理，这样用户只需命令提交一次Balance任务，后续的distcp任务会在Job里面被调度起来。
- BalanceJob的信息持久化，这里持久化的外部存储为HDFS，这是为了防止BalanceJob一旦没有执行完毕，下次可从HDFS数据中恢复这些未执行的Job。
- 源端文件目录的自动清理，这个发生在BalanceJob执行完毕的收尾阶段，当我们完全将数据从源集群拷贝到目标集群后，我们就可以从原集群中把这部分数据给清理掉了。
多了上述的细节完善，这样使得整个工具能够更为方便的给admin来使用，减少了很多额外人工的数据同步操作的处理。
在federation Balance内部工具方案的实现中，它的原理过程如下图所示：
对应上述步骤的过程：
- 1，2）命令行入口，提交的主程序入口，提交一个新的BalanceJob或者从HDFS上读取BalanceJob ，恢复上次失败的未执行Job，然后提交到以个JobQueue内。
- 3）WorkThread工作线程从JobQueue内拉取BalanceJob来执行。
- 4）WorkThread开始调度执行BalanceJob时，将Job信息持久化到HDFS里去，为了做Job失败的recovery。
- 5）BalanceJob结束了，WorkThread从HDFS中将之前写入的BalanceJob信息进行移除。
整个过程不是特别的复杂。
上述federation balance工具化方案整体来看，实现比较清晰，而且没有在HDFS内部通过锁目录的方式来做数据的精准同步，巧妙利用distcp支持的diff拷贝来做增量同步，这个应该是目前来看是造成user impact比较小的方案了。上面所有的实现细节来自于社区JIRA HDFS-15294：RBF: Balance data across federation namespaces with DistCp and snapshot diff，感兴趣的同学可阅读其具体代码实现。
引用
[1].https://issues.apache.org/jira/browse/HDFS-15294