JoshRosen commented on a change in pull request #24672: [SPARK-27801][SQL]
Improve performance of InMemoryFileIndex.listLeafFiles for HDFS directories
with many files
URL: https://github.com/apache/spark/pull/24672#discussion_r287652831
##########
File path:
sql/core/src/main/scala/org/apache/spark/sql/execution/datasources/InMemoryFileIndex.scala
##########
@@ -274,7 +275,21 @@ object InMemoryFileIndex extends Logging {
// [SPARK-17599] Prevent InMemoryFileIndex from failing if path doesn't
exist
// Note that statuses only include FileStatus for the files and dirs
directly under path,
// and does not include anything else recursively.
- val statuses = try fs.listStatus(path) catch {
+ val statuses: Array[FileStatus] = try {
+ fs match {
+ // DistributedFileSystem overrides listLocatedStatus to make 1 single
call to namenode
+ // to retrieve the file status with the file block location. The
reason to still fallback
+ // to listStatus is because the default implementation would
potentially throw a
+ // FileNotFoundException which is better handled by doing the lookups
manually below.
+ case _: DistributedFileSystem =>
Review comment:
Unless I'm misunderstanding something, I don't think that @melin's posted
benchmark is an apples-to-apples comparison: `listLocatedStatus` is going to be
slower than `listStatus` because it's doing more work in order to get location
information. In order for this to be a fair performance comparison you'd want
to compare `listStatus + getBlockLocations` to `listLocatedStatus`.
The direct comparison is only useful in cases where we're never going to
make use of the location information and to my knowledge we currently do not
have a flag to bypass locality fetching in `InMemoryFileIndex` (so the
location-free performance isn't relevant).
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
