[PARQUET-2161] Row positions are computed incorrectly when range or offset metadata filter is used

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.12.3
• Fix Version/s: 1.13.0
• Component/s: parquet-mr
• Assignee: Unassigned
• Reporter: Ala Luszczak
• Created: 20/Jun/22 10:55
• Updated: 12/Apr/23 01:33
• Resolved: 26/Mar/23 06:15

Description

The row indexes introduced in PARQUET-2117 are not computed correctly when
(1) range or offset metadata filter is applied, and
(2) the first row group was eliminated by the filter

For example, if a file has two row groups with 10 rows each, and we attempt to only read the 2nd row group, we are going to produce row indexes 0, 1, 2, ..., 9 instead of expected 10, 11, ..., 19.

This happens because functions `filterFileMetaDataByStart` (used here: https://github.com/apache/parquet-mr/blob/e06384455567c56d5906fc3a152ab00fd8dfdf33/parquet-hadoop/src/main/java/org/apache/parquet/format/converter/ParquetMetadataConverter.java#L1453) and `filterFileMetaDataByMidpoint` (used here: https://github.com/apache/parquet-mr/blob/e06384455567c56d5906fc3a152ab00fd8dfdf33/parquet-hadoop/src/main/java/org/apache/parquet/format/converter/ParquetMetadataConverter.java#L1460) modify their input `FileMetaData`. To address the issue we need to `generateRowGroupOffsets` before these filters are applied.

Issue Links

• causes: SPARK-39634 Allow file splitting in combination with row index generation
• relates to: PARQUET-2117 Add rowPosition API in parquet record readers