You are viewing a plain text version of this content. The canonical link for it is here.
Posted to hdfs-dev@hadoop.apache.org by "Zheng Shao (JIRA)" <ji...@apache.org> on 2019/01/25 18:41:00 UTC
[jira] [Created] (HDFS-14233) Implement
DistributedFileSystem#listStatus(Path[]) by adding a batching listStatus
RPC call to NameNode
Zheng Shao created HDFS-14233:
---------------------------------
Summary: Implement DistributedFileSystem#listStatus(Path[]) by adding a batching listStatus RPC call to NameNode
Key: HDFS-14233
URL: https://issues.apache.org/jira/browse/HDFS-14233
Project: Hadoop HDFS
Issue Type: New Feature
Components: namenode
Reporter: Zheng Shao
HDFS-985 fixed an important problem for HDFS where listing a huge directory takes too long and needs to be paged.
This Jira proposed to solve the problem of the other extreme: Make it more efficient to list thousands of directories that contains very few files in each.
Note that this is already supported in the FileSystem API, but implemented using a loop:
{quote}{{public FileStatus[] listStatus(Path[] files, PathFilter filter) throws FileNotFoundException, IOException {}}
{{ ArrayList<FileStatus> results = new ArrayList();}}
{{ for(int i = 0; i < files.length; ++i) {}}
{{ this.listStatus(results, files[i], filter);}}
{{ }}}
{{ return (FileStatus[])results.toArray(new FileStatus[results.size()]);}}
{{ }}}{{ }}{quote}
HIVE-9736 is a real use case in Hive where we need to list the files in many directories (or partitions in hive concept). That Jira was proposed assuming that listStatus(Path[]) is more efficient in HDFS, but actually not.
There are 2 ways to achieve this:
A. Issue parallel RPCs to NameNode to speed things up;
B. Issue a single RPC to NameNode with all the paths;
While A is a simpler and safe change, it adds a lot more load into the NameNode since the overhead of an RPC (and the locking) for the actual listing of a small directory is huge.
We propose to do B as above instead. It can take advantage of the paging mechanism from HDFS-985 to ensure we don't overload the NameNode. This will greatly speed up the Hive use case above while also reducing the load on NameNode for such a use case, since NameNode can process many directory listing by paying the overhead of a single RPC and a single Global Shared Lock acquisition.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org