[ 
https://issues.apache.org/jira/browse/PARQUET-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542117#comment-17542117
 ] 

ASF GitHub Bot commented on PARQUET-2149:
-----------------------------------------

sunchao commented on PR #968:
URL: https://github.com/apache/parquet-mr/pull/968#issuecomment-1137568979

   > and yes, updating parquet dependencies would be good, hadoop 3.3.0 should 
be the baseline.
   
   +1 on upgrading to 3.3.0, although currently parquet is using 2.10.1 as a 
provided dependency and we need to make sure it continues to work with hadoop 
2.x
   
   > It may be because I was using Spark's vectorized parquet decoding which is 
an order or magnitude faster than parquet library's row by row decoding (see 
[Spark 
benchmarks](https://github.com/apache/spark/blob/master/sql/core/benchmarks/DataSourceReadBenchmark-results.txt)).
 If trino is not doing vectorized decoding (I took a very quick look and I 
don't think it is), I would suggest you can look into that next. All the cool 
kids are doing it.
   
   Presto already has a [batch 
reader](https://github.com/prestodb/presto/tree/master/presto-parquet/src/main/java/com/facebook/presto/parquet/batchreader)
 but seems the feature is not in Trino yet. The batch reader did help a lot to 
reduce the CPU load. See [the 
slides](https://github.com/prestodb/presto/wiki/files/presto-meetup-oct-2019/uber.pdf).




> 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)

Reply via email to