前言
在我们使用HDFS作为数据存储文件系统时,恐怕最常使用到的命令就是ls命令了。我们往往先使用这个命令查找出目前我们期待的文件目录信息,然后对查出的这些文件目录做后续的操作。所以说,list操作的执行效率高低对用户以及上层应用层调用程序来说就显得十分重要了。
当前List操作的问题
这里我们会从2个层面来展开此方面的讨论:
- 一个是针使用用户的角度,也就是CLI命令行使用方式的。
- 另一个就是针对应用程序调用底层API获取目录信息的。
先来看第一种情况,当使用ls命令行去查询目录树比较深并且其下子文件又比较多的时候,就会出现返回信息特别缓慢的情况。给到用户的第一感觉就是命令行执行了好几十秒,还是没有结果出来。这种情况,我们最直观的优化点,就是能够更快速地出结果。
再来看第二种情况,当然啦,第一钟情况里提到的情况也会包含在第二种情况里,但是额外地,它还有另外一个问题,应用程序在list文件目录操作时,往往不会只查找1次,往往它要根据比如说partition这种查找一系列的路径,这个时候就会有RTT往返时延的问题,以及多次RPC请求的开销。这时,我们可能需要一种Batch-list查询的API。
社区解决方案
因为最近社区有这方面的解决方案,所以笔者就拿来分享一下了,想提前使用的朋友,可以先apply到自己的测试分支中,进行使用。
ls命令执行缓慢
对应上述2种场景,首先来看第一种case,命令行方式的list优化,解决的核心要点在于将同步执行过程改为客户端多线程异步执行,用ForkJoinPool来执行递归的list查询,对子任务进行拆分执行,然后进行结果的再汇总。
以下是核心的改动,在基类Command.java里改的:
+
HDFS List操作优化:多线程与批量查询

本文探讨了HDFS中ls命令执行缓慢的问题,包括命令行使用和应用程序API调用两个方面。提出了通过客户端多线程异步执行和Batch-List API来优化,以提高查询效率并减少不必要的RPC调用。社区已有相关解决方案,如JIRA HADOOP-15471和HDFS-13616。
最低0.47元/天 解锁文章
1115

被折叠的 条评论
为什么被折叠?



