-
Notifications
You must be signed in to change notification settings - Fork 1.3k
parquet: Convert page indexes to Vec<Vec<Option<T>>>
#10653
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Large diffs are not rendered by default.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -141,29 +141,31 @@ pub(crate) use writer::ThriftMetadataWriter; | |
| /// documentation]. Each [`ColumnIndex`] holds statistics about all the pages in a | ||
| /// particular column chunk. | ||
| /// | ||
| /// `column_index[row_group_number][column_number]` holds the | ||
| /// `column_index[row_group_number][column_number]` holds the optional | ||
| /// [`ColumnIndex`] corresponding to column `column_number` of row group | ||
| /// `row_group_number`. | ||
| /// `row_group_number`. This will be `None` if no index is present for the given | ||
| /// column chunk. | ||
| /// | ||
| /// For example `column_index[2][3]` holds the [`ColumnIndex`] for the fourth | ||
| /// column in the third row group of the parquet file. | ||
| /// | ||
| /// [PageIndex documentation]: https://github.com/apache/parquet-format/blob/master/PageIndex.md | ||
| /// [`ColumnIndex`]: crate::file::page_index::column_index::ColumnIndexMetaData | ||
| pub type ParquetColumnIndex = Vec<Vec<ColumnIndexMetaData>>; | ||
| pub type ParquetColumnIndex = Vec<Vec<Option<ColumnIndexMetaData>>>; | ||
|
|
||
| /// [`OffsetIndexMetaData`] for each data page of each row group of each column | ||
| /// [`OffsetIndexMetaData`] for each column chunk of each row group | ||
| /// | ||
| /// This structure is the parsed representation of the [`OffsetIndex`] from the | ||
| /// Parquet file footer, as described in the Parquet [PageIndex documentation]. | ||
| /// | ||
| /// `offset_index[row_group_number][column_number]` holds | ||
| /// the [`OffsetIndexMetaData`] corresponding to column | ||
| /// `column_number`of row group `row_group_number`. | ||
| /// the optional [`OffsetIndexMetaData`] corresponding to column | ||
| /// `column_number`of row group `row_group_number`. This will be `None` if no index | ||
| /// is present for the given column chunk. | ||
| /// | ||
| /// [PageIndex documentation]: https://github.com/apache/parquet-format/blob/master/PageIndex.md | ||
| /// [`OffsetIndex`]: https://github.com/apache/parquet-format/blob/master/PageIndex.md | ||
| pub type ParquetOffsetIndex = Vec<Vec<OffsetIndexMetaData>>; | ||
| pub type ParquetOffsetIndex = Vec<Vec<Option<OffsetIndexMetaData>>>; | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If we are going to change the page index representation (and force a breaking change downstream on the users) I wonder if we can think bigger than just adding an Option here and making it align with the parquet-format names For example what do you think about making it a struct so that we have a better chance of evolving it over time (and make it easier to document)? For example: struct ParquetOffsetIndex {
page_locations: Vec<ParquetPageLocation>,
unencoded_byte_array_data_bytes: Option<Vec<i64>,
}struct ParquetPageLocation {
offset: i64,
compressed_page_size: i32,
first_row_index: i64,
}
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We could also just do something slightly more encapsulated rather than a typedef struct ParquetOffsetIndex {
inner: Vec<Vec<Option<OffsetIndexMetaData>>>;
}🤔 |
||
|
|
||
| /// Parsed metadata for a single Parquet file | ||
| /// | ||
|
|
@@ -2117,11 +2119,13 @@ mod tests { | |
| offset_index.append_row_count(1); | ||
| offset_index.append_offset_and_size(2, 3); | ||
| offset_index.append_unencoded_byte_array_data_bytes(Some(10)); | ||
| let offset_index = offset_index.build(); | ||
| let offset_index = Some(offset_index.build()); | ||
|
|
||
| let parquet_meta = ParquetMetaDataBuilder::new(file_metadata) | ||
| .set_row_groups(row_group_meta) | ||
| .set_column_index(Some(vec![vec![ColumnIndexMetaData::BOOLEAN(native_index)]])) | ||
| .set_column_index(Some(vec![vec![Some(ColumnIndexMetaData::BOOLEAN( | ||
| native_index, | ||
| ))]])) | ||
| .set_offset_index(Some(vec![vec![offset_index]])) | ||
| .build(); | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes here are the big change...the rest is dealing with the consequences
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have always found this structure to be very confusing (as it is a Vec of Vecs). Adding Option makes it even more confusing in my mind.
What would you think about at least encapsulating the PageIndex into a structure of its own (rather than two parallel structure)?
🤔
Then we could add accessors like
That might also allow us to tweak the internal representation of these indexes to support options, etc without breaking the structure again