-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Parquet Manifest - POC #13769
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?
Parquet Manifest - POC #13769
Conversation
| api project(':iceberg-api') | ||
| implementation project(':iceberg-common') | ||
| implementation project(path: ':iceberg-bundled-guava', configuration: 'shadow') | ||
| testRuntimeOnly project(':iceberg-parquet') |
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.
Allows tests to use parquet while running (it's only loaded via reflection)
|
|
||
| try { | ||
| try (CloseableIterable<ManifestEntry<T>> headerReader = | ||
| InternalData.read(FileFormat.AVRO, inputFile) |
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.
This breaks a backwards compatibility, previously an input file didn't actually have to have an avro suffix
6548471 to
bf8b60b
Compare
|
This pull request has been marked as stale due to 30 days of inactivity. It will be closed in 1 week if no further activity occurs. If you think that’s incorrect or this pull request requires a review, please simply write any comment. If closed, you can revive the PR at any time and @mention a reviewer or discuss it on the [email protected] list. Thank you for your contributions. |
|
This pull request has been closed due to lack of activity. This is not a judgement on the merit of the PR in any way. It is just a way of keeping the PR queue manageable. If you think that is incorrect, or the pull request requires review, you can revive the PR at any time. |
|
reopened the PR as @RussellSpitzer intends to resume this work upon his return from leave. |
|
Added non-stale lable |
A Proof of Concept pr to show what allowing writing to Parquet Manifests might look like as well as the illuminate the rough edges we will need to work around to get this into the project.
I'm collecting some thoughts on the work in the document below:
https://docs.google.com/document/d/13TeFu20jhkUFbb-FaaGQWFiXKO6kKyy_nX1QyFgoUoU/edit?usp=sharing
Implementation issues
Empty Structs
Parquet does not support an empty struct in the schema but our current definition of the manifest has a required “partition” struct. For an unpartitioned table this means an empty struct is required in the schema.
POC Work - I work around this by just putting in a dummy placeholder struct instead.
Public API from Manifest Reader Reliance on Manifest Metadata
Currently the Manifest Reader attempts to extract table’s Specs information from inside the avro metadata. This isn’t actually required by any of our code and there is basically never a time in production where we read a manifest and don’t already have the specs. The tests are a different case and require a lot of rewriting.
There is unfortunately one major exception to this,
Snapshot provides several apis like (addedFiles(FileIO io)) which reads manifests directly with a FileIO to produce their entries, this creates a manifest group directly but without setting specById. In this context we also do not have access to the table, we probably will need to change this interface if we want to remove reliance on file metadata.
POC Work - Originally I focused on just fixing all the test references after skimming and trying to determine if there were any real production uses of the API. Once I discovered the issue with BaseSnapshot I tried to determine exactly the scope, 30 of the above test failures are related to this issue. Many are test related (checking snapshot contents) but there are some public usages in cherry-pick snapshot.
Refactoring of Parquet InternalReader Implementation
The current parquet InternalReader API returns a reader function before we are able to get arguments for custom classes. ManifestReader needs to be able to read into custom classes (ManifestEntry, DataFile, etc ..) so the custom classes need to be created prior to the reader function being generated.
POC Work - Bit of a sloppy fix here but we move the reader into the Parquet class itself so that we can modify the function before it is built.
Use of Immutables in BaseFile
Parquet readers using a reusable container fail because BaseFile returns an immutable representation of the splitOffset list.
POC Work - Just return a mutable list for now
Determining Manifest Type Based on Extension
In order to have different behaviors for different types but allow reading both avro and parquet manifests, we need to rely on extensions. Most likely not a problem in the wild, but many of our tests use manifest file names without a type extension.
POC Work - Just fixing tests