Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Partitioned object store lists all files on every query when using hive-partitioned parquet files #9654

Open
henrifroese opened this issue Mar 17, 2024 · 2 comments
Labels
bug Something isn't working

Comments

@henrifroese
Copy link

henrifroese commented Mar 17, 2024

Describe the bug

Hey,

awesome project! I'm trying to use datafusion to query across 100s of thousands of partitioned parquet files in S3. Partitioning is e.g. experiment=A/measurement=B/date_id=20230101/file.parquet.

Now say I want to query SELECT * FROM table WHERE experiment='A' AND measurement='B' AND date_id=20230101.

Depending on what I do I get very different performance:

  1. If I first register_listing_table with prefix experiment=A/measurement=B/ and only specify date_id in ListingOptions.with_table_partition_cols , and then send query SELECT * WHERE date_id=20230101 that's very fast.

  2. If I just register_listing_table without prefix, and in ListingOptions.with_table_partition_cols specify experiment, measurement, date_id, and send the full query SELECT * WHERE experiment='A' AND measurement='B' AND date_id=20230101, that's very slow. (Still works!)

It makes sense to me that the first time, we have to list all files, so (2) is slower. But it's also slower on repeated queries.

Afaict the actual filtering happens in https://github.com/apache/arrow-datafusion/blob/cf0f8eececd37f593b811320f89c0edd00fd3945/datafusion/core/src/datasource/listing/helpers.rs#L328
which calls list_partitions.

I can think of two ways to speed this up:

  1. Allow caching a ListingTable's files
  2. In ListingTable, allow specifying the order of partitioning columns (e.g. in this case [experiment, measurement, date_id]), and if specified filters are a prefix of this, use that to only list beyond that prefix. E.g. here that'd lead to only listing files after experiment=A/measurement=B/.

Do any of these ways already exist and I just didn't find them? Or already have tickets?

To Reproduce

No response

Expected behavior

No response

Additional context

No response

@henrifroese henrifroese added the bug Something isn't working label Mar 17, 2024
@henrifroese
Copy link
Author

henrifroese commented Mar 17, 2024

Ah seems to be exactly what @suremarc mentioned in this comment: #7620 (comment)

So #7620 added an optional file cache, but it's not used when using partitions.

henrifroese pushed a commit to henrifroese/arrow-datafusion that referenced this issue Mar 17, 2024
When discovering partitions for pruning, if we specify
no partition columns, we call `list_all_files`, which
uses the `list_files_cache` if it exists and is filled.

If we specify partition columns, before this change, we
recursively list files in the object store to discover
partitions. That happens on every request, and listing
files e.g. in AWS S3 can be slow (especially if it's
100k+).

With this change, if the `list_files_cache` exists and is
filled, we get all files from there and use that to discover
partitions.

Closes apache#9654
@henrifroese
Copy link
Author

henrifroese commented Mar 17, 2024

Tried having a go at this in #9655 @suremarc @Ted-Jiang lmk whether that makes sense

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant