You are viewing a plain text version of this content. The canonical link for it is here.
Posted to github@arrow.apache.org by "kmitchener (via GitHub)" <gi...@apache.org> on 2023/02/06 19:12:24 UTC
[GitHub] [arrow-datafusion] kmitchener opened a new issue, #5205: use more than one core/thread when querying CSV
kmitchener opened a new issue, #5205:
URL: https://github.com/apache/arrow-datafusion/issues/5205
**Is your feature request related to a problem or challenge? Please describe what you are trying to do.**
When querying a CSV file on local disk only 1 thread is used, leaving the system mostly idle. For example, I have a 9 GB gzip-compressed CSV file that I'd like to query and convert to Parquet format. However, when running queries against the CSV, it can take 5 minutes or more for simple counts or group bys on single columns. 5 minutes per query isn't too unexpected (when uncompressed, it's a 100 GB file, 45 million records x 242 columns). But it's nowhere near utilizing all the machine's resources. It seems like there should be a way to move more of the work to other threads and querying/conversion to parquet could be substantially faster.
When profiled, it looks like this (green is the only busy thread):
and if you zoom into what that thread is doing, it's following a pattern of:
* read data from disk
* then for about 10 cycles, it
* decompresses a chunk
* reads csv records (csv_core) from decompressed chunk
* read again from disk and repeat the cycle
**Describe the solution you'd like**
Better utilization of the machine, work done in more than one thread and sustained reads from disk.
**Describe alternatives you've considered**
Is it possible to offload the decompression and processing of bytes -> csv records to other threads? I had an idea to try to implement some kind of fan-out/fan-in somewhere under CsvExec so that one thread is just reading from disk and sending the raw bytes to other threads to decompress/csv_read/convert to recordbatches (CPU-heavy work is in the CSV reading) -> fan back in to stream the recordbatches from CsvExec as expected. Is there a better way to do it?
**Additional context**
Add any other context or screenshots about the feature request here.
--
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.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [arrow-datafusion] kmitchener commented on issue #5205: use more than one core/thread when querying CSV
Posted by "kmitchener (via GitHub)" <gi...@apache.org>.
kmitchener commented on issue #5205:
URL: https://github.com/apache/arrow-datafusion/issues/5205#issuecomment-1420038954
> I definitely think a first step would be to interleave the fetching of the next set of bytes and decoding. This might be as simple as adding `buffered(1)` to the stream returned by `object_store` and polling it every call to `poll_fn`. I'd be happy to get a PR up to do this, if you'd be willing to help test it out (I don't have any realistic CSV workloads)
Sure, of course, I'll be happy to test out any patches.
> > I had an idea to try to implement some kind of fan-out/fan-in somewhere under CsvExec so that one thread is just reading from disk and sending the raw bytes to other threads to decompress/csv_read/convert to recordbatches
>
> Doing this correctly is quite tricky as CSV permits unescaped newlines, which makes it actually impossible to know where a given record starts without having read all prior records, you can't just seek to the next newline character as that might be part way through a record.
>
> That being said, a trick that I believe duckdb uses is to search for the next newline, and then test the first record against the expected schema, if it matches you have likely found a newline from which you can start reading.
Ah, yes. I was thinking of using the function you already made for something similar: `newline_delimited_stream`. It could at least help move the CSV-parsing -> recordbatch to other threads, if not decompression. CSV-parsing is the largest part of the work. But after playing with it for a while, I'm pretty sure this is beyond my capabilities.
> > 5 minutes per query isn't too unexpected (when uncompressed, it's a 100 GB file, 45 million records x 242 columns)
>
> Not to blow my own trumpet, but I'm pretty chuffed by this, 2.7Gbps on a single core is pretty sweet 😁 We can and should make it even faster, but I think this is already pretty cool.
Yeah, it's pretty great :) for a simple `select count(*) ..` query, current DF is faster than duckdb against my large test file. About twice as fast.
--
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.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [arrow-datafusion] alamb commented on issue #5205: use more than one core/thread when querying CSV
Posted by "alamb (via GitHub)" <gi...@apache.org>.
alamb commented on issue #5205:
URL: https://github.com/apache/arrow-datafusion/issues/5205#issuecomment-1420567792
DuckDB does parallel csv reading, FWIW. https://github.com/duckdb/duckdb/pull/5194
It would be great to implement this feature in DataFusion
Regarding the "csv escaping means you can't always know when a newline is a record delimiter" I suggest:
1. Default to parsing using multi cores with a newline heuristic, and document that it may be incorrect in some cases
2. Have a config setting that switches back to the slower but "handles newlines correctly" behavior
A small variation of 1 would be to detect (and error) if DataFusion realized the parallel split did not work well, and produce an error that mentioned the config setting,.
--
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.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [arrow-datafusion] alamb commented on issue #5205: use more than one core/thread when querying CSV
Posted by "alamb (via GitHub)" <gi...@apache.org>.
alamb commented on issue #5205:
URL: https://github.com/apache/arrow-datafusion/issues/5205#issuecomment-1638058056
Closed by https://github.com/apache/arrow-datafusion/pull/6801
--
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.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [arrow-datafusion] alamb commented on issue #5205: use more than one core/thread when querying CSV
Posted by "alamb (via GitHub)" <gi...@apache.org>.
alamb commented on issue #5205:
URL: https://github.com/apache/arrow-datafusion/issues/5205#issuecomment-1420569813
(nice work @tustvold on CSV reading). Maybe we can put this data into the blog post too https://github.com/apache/arrow-site/pull/305
--
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.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [arrow-datafusion] alamb commented on issue #5205: use more than one core/thread when querying CSV
Posted by "alamb (via GitHub)" <gi...@apache.org>.
alamb commented on issue #5205:
URL: https://github.com/apache/arrow-datafusion/issues/5205#issuecomment-1542041921
I filed https://github.com/apache/arrow-datafusion/issues/6325 to track a feature that might enable this to work
--
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.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [arrow-datafusion] tustvold commented on issue #5205: use more than one core/thread when querying CSV
Posted by "tustvold (via GitHub)" <gi...@apache.org>.
tustvold commented on issue #5205:
URL: https://github.com/apache/arrow-datafusion/issues/5205#issuecomment-1419876884
> Is it possible to offload the decompression and processing of bytes
I definitely think a first step would be to interleave the fetching of the next set of bytes and decoding. This might be as simple as adding `buffered(1)` to the stream returned by `object_store` and polling it every call to `poll_fn`. I'd be happy to get a PR up to do this, if you'd be willing to help test it out (I don't have any realistic CSV workloads)
> I had an idea to try to implement some kind of fan-out/fan-in somewhere under CsvExec so that one thread is just reading from disk and sending the raw bytes to other threads to decompress/csv_read/convert to recordbatches
Doing this correctly is quite tricky as CSV permits unescaped newlines, which makes it actually impossible to know where a given record starts without having read all prior records, you can't just seek to the next newline character, as that might be part way through a record.
That being said, a trick that I believe duckdb uses is to search for the next newline, and then test the first record against the expected schema, if it matches you have likely found a newline from which you can start reading.
--
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.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] use more than one core/thread when querying CSV [arrow-datafusion]
Posted by "alamb (via GitHub)" <gi...@apache.org>.
alamb closed issue #5205: use more than one core/thread when querying CSV
URL: https://github.com/apache/arrow-datafusion/issues/5205
--
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.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org