[
https://issues.apache.org/jira/browse/PARQUET-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541749#comment-17541749
]
ASF GitHub Bot commented on PARQUET-2149:
-----------------------------------------
parthchandra commented on PR #968:
URL: https://github.com/apache/parquet-mr/pull/968#issuecomment-1136528026
> Latency is the killer; in an HTTP request you want read enough but not
discard data or break an http connection if the client suddenly does a seek()
or readFully() somewhere else. file listings, existence checks etc.
>
> That'd be great. now, if you could also handle requesting different
columns in parallel and processing them out of order.
I do. The Parquet file reader api that reads row groups in sync mode reads
all columns in sequence. In async mode, it fires off a task for every column
blocking only to read the first page of every column before returning. This
part also uses a different thread pool from the IO tasks so that IO tasks never
wait because there are no available threads in the thread pool.
>
> be good to think about vectored IO.
I think I know how to integrate this PR with the vectored IO, but this is
only after a cursory look.
>
> and yes, updating parquet dependencies would be good, hadoop 3.3.0 should
be the baseline.
Who can drive this (presumably) non-trivial change? I myself have no karma
points :(
> just sketched out my thoughts on this. I've played with some of this in my
own branch. I think the next step would be for me to look at the benchmark code
to make it targetable elsewhere.
>
>
https://docs.google.com/document/d/1y9oOSYbI6fFt547zcQJ0BD8VgvJWdyHBveaiCHzk79k/
This is great. I now have much more context of where you are coming from
(and going to) !
> Implement async IO for Parquet file reader
> ------------------------------------------
>
> Key: PARQUET-2149
> URL: https://issues.apache.org/jira/browse/PARQUET-2149
> Project: Parquet
> Issue Type: Improvement
> Components: parquet-mr
> Reporter: Parth Chandra
> Priority: Major
>
> ParquetFileReader's implementation has the following flow (simplified) -
> - For every column -> Read from storage in 8MB blocks -> Read all
> uncompressed pages into output queue
> - From output queues -> (downstream ) decompression + decoding
> This flow is serialized, which means that downstream threads are blocked
> until the data has been read. Because a large part of the time spent is
> waiting for data from storage, threads are idle and CPU utilization is really
> low.
> There is no reason why this cannot be made asynchronous _and_ parallel. So
> For Column _i_ -> reading one chunk until end, from storage -> intermediate
> output queue -> read one uncompressed page until end -> output queue ->
> (downstream ) decompression + decoding
> Note that this can be made completely self contained in ParquetFileReader and
> downstream implementations like Iceberg and Spark will automatically be able
> to take advantage without code change as long as the ParquetFileReader apis
> are not changed.
> In past work with async io [Drill - async page reader
> |https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/store/parquet/columnreaders/AsyncPageReader.java]
> , I have seen 2x-3x improvement in reading speed for Parquet files.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
