HDFS FoldedTreeSet的引入以及FBR优化处理
前言
在现有HDFS处理FBR（全量块汇报）逻辑中，处理开销是比较高的，尤其当集群中有大量块的时候。对此，社区在HDFS-9260中提出了一种新的树型结构来优化这块的处理。它本质上是一种排序好的Set集合，名为FoldedTreeSet。
FoldedTreeSet的作用
社区在实现FoldedTreeSet的时候，主要考虑到下面几点优化方向：
- 提升NN的FBR处理过程。
- 提高NN,DN中块数据信息的内存使用率，实质是新的结构比原来链表式的GSet会使用到更少的内存。
- 新的结构将会更利于GC处理。
首先第一点，NN的FBR处理可以借助于FoldedTreeSet的排序结果，进行更高效的处理，而且这个排序在NN和DN上都是可以排序好的。在原先老的处理过程中，因为块是未排序好的，针对每个块，需要检查NN上是否有这些块，然后还要跟踪这些块，在链表中做标记，然后区分出哪些块是没有被DN汇报上来的，整个过程非常的复杂。另一方面排序好的，Block，Replica信息查询起来也会更快。
FoldedTreeSet根据字面意思，是一个“折叠”了的TreeSet,因为在FoldedTreeSet里，每个Node包含了多个实体项，而不是传统中的一个。
FoldedTreeSet带来的隐患
FoldedTreeSet的实质是一个红黑树的实现，所以它在插入和删除操作时需要做一定的树节点平衡操作处理。更进一步地说，它对于大规模的block调整操作（比如删除大目录），会花更多的时间，相较于原来的实现。社区在其设计文档中也着重提到了这点，给出的一个解决办法是定期做这种树结构的调整，调整的间隔时间可以根据用户使用场景调整时间。
笔者最近在内部集群使用时发现了这个问题，每次当集群内部自动清理到大目录的时候，就会触发长时间的删除块操作，从而阻塞集群对其它RPC请求的处理，社区也在讨论是否要将这个改动revert回去，直到这个功能经过更加稳定的性能测试再合入到主分支，细节可查阅issue，HDFS-13671：Namenode deletes large dir slowly caused by FoldedTreeSet#removeAndGet。
参考资料
[1].HDFS Block and Replica Management. https://issues.apache.org/jira/secure/attachment/12767102/HDFS%20Block%20and%20Replica%20Management%2020151013.pdf
