[Parquet] ALP encoder/decoder support - #9372
Conversation
|
amaaazing |
|
@alamb I worked with codex on replicating the c++ implementation reviewing commit by commit. I'll do one final read myself, but this should be ready for initial review. |
|
Thank you -- I will put this on my short list to reivew I was out last week |
|
@devanbenz Sorry for taking so long to address your comments. I'll make sure to work on it this week! |
devanbenz
left a comment
There was a problem hiding this comment.
Comment about header regarding publication of spec.
|
Thanks @devanbenz, I've finally addressed your reviews! |
Please cargo fmt the code 🫡 |
|
|
|
added #10785 to update the parquet-testing dep |
|
Added another one with just the pinned rev change - #10786 |
# Conflicts: # parquet-testing # parquet/src/encodings/encoding/mod.rs
|
BTW if you want to see a sneak preview of a blog post about what ALP is |
|
@alamb @devanbenz thanks for your help 🙏 |
Yes, I don't see a problem with that. It's in "preview" in the spec, and it requires opt-in from users.
Yes thanks to all for getting this done so soon! |
|
sounds good; i was hoping to take a proper look at this since ive just skimmed it, but kept getting sidetracked by other PRs 😅 |
I think we still have some more time until the 60 release -- so we can wait a while to merge it in |
# Which issue does this PR close? - Follow-up to #10786, which updated the `parquet-testing` revision. - No tracking issue yet; one can be added if needed. # Rationale for this change The updated `parquet-testing` revision included: - [apache/parquet-testing#113](apache/parquet-testing#113): malformed and edge-case Variant files. - [apache/parquet-testing#117](apache/parquet-testing#117): mark four shredded Variant cases as invalid because they omit required `value` columns. - [apache/parquet-testing#118](apache/parquet-testing#118): JSON and BSON logical-type files. - [apache/parquet-testing#119](apache/parquet-testing#119): an extended ALP fixture. #10786 made these fixtures available to Arrow Rust, but did not exercise the JSON, BSON, or malformed Variant files. The same revision also added an extended ALP fixture. That fixture is covered by the ALP encoder/decoder work in #9372, where the required decoding support exists. # What changes are included in this PR? - Read the JSON logical-type fixture and verify all decoded string values. - Read the BSON logical-type fixture and verify all decoded binary values. - Validate all 14 files under `bad_data/variants`, including the one valid duplicate-offset case and 13 malformed cases. The four shredded Variant cases renamed as invalid by the same `parquet-testing` update are already exercised by the existing Variant integration harness. # Are these changes tested? Yes. The Parquet and Variant integration tests pass locally, along with formatting and clippy checks. The PR's CI checks are also green. # Are there any user-facing changes? No. This PR only adds integration-test coverage for existing `parquet-testing` fixtures. # AI usage This PR was prepared with OpenAI Codex and reviewed by a human. The integration tests, formatting, and clippy checks described above were run against the final branch, and the GitHub CI checks passed. --------- Co-authored-by: cetra3 <cetra3@hotmail.com>
|
I plan to merge this PR tomorrow unless anyone would like more time to review beforehand |
|
Ignored one new test for MIRI in ea6d049 Followed the same pattern as existing tests that try to use zstd arrow-rs/parquet/src/compression.rs Line 959 in ec21627 |
|
It is time. Thank you (so much) @sdf-jkl and @devanbenz for all your work getting this into such great shape. I can't wait to see this released in 60.0.0 (hopefully next week)! |
|
Thanks @alamb @devanbenz 🚀 🚀 🚀 |
# Which issue does this PR close? <!-- We generally require a GitHub issue to be filed for all bug fixes and enhancements and this helps us generate change logs for our releases. You can link an issue to this PR using the GitHub syntax. --> - Closes #10642 . - stacks on #9372 # Rationale for this change We need a benchmark to measure performance and prove future optimizations <!-- Why are you proposing this change? If this is already explained clearly in the issue then this section is not needed. Explaining clearly why changes are proposed helps reviewers understand your changes and offer better suggestions for fixes. --> # What changes are included in this PR? - Added a criterion benchmark <!-- There is no need to duplicate the description in the issue here but it is sometimes worth providing a summary of the individual changes in this PR. --> # Are these changes tested? - N/A <!-- We typically require tests for all PRs in order to: 1. Prevent the code from being accidentally broken by subsequent changes 2. Serve as another way to document the expected behavior of the code If tests are not included in your PR, please explain why (for example, are they covered by existing tests)? If this PR claims a performance improvement, please include evidence such as benchmark results. --> # Are there any user-facing changes? <!-- If there are user-facing changes then we may require documentation to be updated before approving the PR. If there are any breaking changes to public APIs, please call them out. -->
Which issue does this PR close?
Rationale for this change
check issue
What changes are included in this PR?
Are these changes tested?
Are there any user-facing changes?