Description
Is your feature request related to a problem or challenge? Please describe what you are trying to do.
There are several cases where we would like to have more control over the encoding/deocing of Parquet metadata:
- serialize and deserialize it outside of a parquet file so I can store it in a cache outside of parquet files and avoid slow object store requests (Page indexes in `decode_metadata` and `encode_metadata` #5988)
- Selective decoding of a subset (e.g. columns or row groups) of parquet metadata #5855
- Way to share
SchemaDescriptorPtr
acrossParquetMetadata
objects #5999 - Ensuring that the Page index structures are read properly requires setting some non obvious settings on the reader scuh as ArrowReaderOptions::with_page_index
At the time of writing, the current APIs exposed
- No API exposed for creating / writing parquet metadata
- The API exposed for reading parquet metadata,
decode_metadata
, has no way for finer grained control
Describe the solution you'd like
I would like an API that allows more fine grained control over reading/writing metadata and that permits adding additional features over time in a backwards compatible way
Describe alternatives you've considered
Here is one potential idea -- to create Encoder
/ Decoder
structs that can encode and decode the metadata along with various configuration options.
Ideally this struct would be integrated into the rest of the crate, e.g. used in SerializedFileWriter?
let encoder = ParquetMetadataEncoder::new()
.with_some_options(foo);
let mut buffer = vec![]
encoder.encode(metadata, &mut buffer)
Similarly for decoding
let decoder = ParquetMetadataDecoder::new()
.with_offset_index(true)
.with_column_index(true);
let result = decoder.decode(&buffer);
// decoder need to have some way to communicate
// if it doesn't have sufficient information (e.g the PageIndex
// wasn't present). Maybe this should just be an error?
match result {
FullDecode(metadata) => return metadata,
NeedMoreData(range) => {
// fetch additional data and pass to deocder?
todo!()
}
..
};
Additional context
This ticket is based on the discussion with @adriangb here #5988
There are a bunch of discussions on metadata speed here #5770
Here is a PR with a proposed 'encode_metadata' function: #6000