[jira] [Work logged] (HIVE-25827) Parquet file footer is read multiple times, when multiple splits are created in same file

["ASF GitHub Bot (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/HIVE-25827?focusedWorklogId=781116&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-781116 ]

ASF GitHub Bot logged work on HIVE-25827:
-----------------------------------------

                Author: ASF GitHub Bot
            Created on: 14/Jun/22 11:46
            Start Date: 14/Jun/22 11:46
    Worklog Time Spent: 10m 
      Work Description: szlta opened a new pull request, #3368:
URL: https://github.com/apache/hive/pull/3368

   This change refactors the Parquet record reader implementations in Hive (ParquetRecordReaderWrapper, VectorizedParquetRecordReader and their base class: ParquetRecordReaderBase). The way it's currently done is that the file footer is read at least 2 times.
   Also we don't need multiple splits of the same file for this to happen. Every file is opened 2 times with the vectorized reader. And yes, e.g. in LLAP's case that's two different streams as in that scenario there's a custom logic to load the metadata part of the file into metadata cache. If there's a cache hit, 1 of the reads would be served from cache, but the other occasion reads from file in the dumb way nevertheless.
   
   Key changes:
   
   - After the refactor the Parquet metadata loading happens via a virtual method instead and the result is stored in a field so depending on whether the job is non-vectorized/vectorized/llap this now can be done in separate ways.
   - Also did some cleanup and restructured common logic into ParquetRecordReaderBase.
   - Originally VectorizedParquetRecordReader had a code path for when `if (rowGroupOffsets == null) {`. I don't think this is a valid scenario and even if it was it wouldn't have worked correctly ever: in `range(split.getStart(), split.getEnd())` the split instance is of a ParquetInputSplit, where `getEnd()` calculates how many bytes would be read in that split (summed), and it doesn't denote a position. Therefore, projections where some columns are omitted would produce a bad result. So.., this code path is removed in this refactor too.




Issue Time Tracking
-------------------

            Worklog Id:     (was: 781116)
    Remaining Estimate: 0h
            Time Spent: 10m

> Parquet file footer is read multiple times, when multiple splits are created in same file
> -----------------------------------------------------------------------------------------
>
>                 Key: HIVE-25827
>                 URL: https://issues.apache.org/jira/browse/HIVE-25827
>             Project: Hive
>          Issue Type: Improvement
>            Reporter: Rajesh Balamohan
>            Assignee: Ádám Szita
>            Priority: Major
>              Labels: performance
>         Attachments: image-2021-12-21-03-19-38-577.png
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> With large files, it is possible that multiple splits are created in the same file. With current codebase, "ParquetRecordReaderBase" ends up reading file footer for each split. 
> It can be optimized not to read footer information multiple times for the same file.
>  
> [https://github.com/apache/hive/blob/master/ql/src/java/org/apache/hadoop/hive/ql/io/parquet/vector/VectorizedParquetRecordReader.java#L160]
>  
> [https://github.com/apache/hive/blob/master/ql/src/java/org/apache/hadoop/hive/ql/io/parquet/ParquetRecordReaderBase.java#L91]
>  
>  
> !image-2021-12-21-03-19-38-577.png|width=1363,height=1256!
>  



--
This message was sent by Atlassian Jira
(v8.20.7#820007)