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

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页