GH-50910: [Parquet] Tolerate unrecognized logical/physical type combinations when reading - #50909
divjotarora wants to merge 8 commits into
Conversation
|
Thanks for opening a pull request! This pull request has been automatically converted to a draft because its title doesn't match Arrow's required format. If this is not a minor PR. Could you open an issue for this pull request on GitHub? https://github.com/apache/arrow/issues/new/choose Opening GitHub issues ahead of time contributes to the Openness of the Apache Arrow project. Then could you also rename the pull request title in the following format? or After updating the title, you can mark the pull request as ready for review. See also: |
|
|
4dc0ee3 to
6017b0e
Compare
6017b0e to
7062580
Compare
Reranko05
left a comment
There was a problem hiding this comment.
Could you also add Component of the PR in the title, it will be easier for maintainers to review it.
GH-<Issue Number>: [<Component>] <Title>
emkornfield
left a comment
There was a problem hiding this comment.
a couple of questions, but seems reasonable.
| // type annotation. | ||
| if (logical_type && | ||
| !logical_type->is_applicable(physical_type, element->type_length)) { | ||
| ARROW_LOG(WARNING) << "Dropping unsupported logical type " |
There was a problem hiding this comment.
I think this logging is worth adding if the behavior is not configurable.
There was a problem hiding this comment.
Hmm, I don't think I like the idea of logging "problems" like this, especially if the logging cannot be suppressed.
There was a problem hiding this comment.
Also cc @HuaHuaY
The main purpose of this PR is to allow reading Parquet files that use features not yet implemented in Parquet C++ (a new logical/physical type combination).
We don't emit warnings for other unrecognized features, so I think it's reasonable to be silent here as well.
(warnings could come across as noisy, especially if the user cannot do anything about them)
There was a problem hiding this comment.
I have no strong opinion here, but isn't it better for a user to know that they're using a library that doesn't understand the full semantic meaning of the files they're reading? The results are still correct, but the library is not doing any skipping/pruning that it might otherwise do and realistically they should upgrade it (or fix their files in case it's the data that's wrong for some reason).
There was a problem hiding this comment.
I have no strong opinion here, but isn't it better for a user to know that they're using a library that doesn't understand the full semantic meaning of the files they're reading?
Either they care about those semantics and they will notice anyway (because the contents won't be read as the expected Arrow datatype: for example a TIMESTAMP FLBA(12) column would be read as FixedSizeBinary rather Timestamp), or they don't care about those semantics and the warning message is just a distraction.
realistically they should upgrade it
Only if there is a newer version of the library that supports said combination, and only if they can reasonably upgrade (perhaps they are using some application that links Parquet C++, and the upgrade cycle depends on the application's release cycle).
There was a problem hiding this comment.
Dropped the logging and all related changes (e.g. schema path propagation in FromParquet) in 40e8e79.
@pitrou @emkornfield @wgtmac PTAL and let me know what you prefer
There was a problem hiding this comment.
I'm OK dropping it. But I think it could add value one additional way the log is useful is as telemetry for people running online services. Lets keep it removed for now.
There was a problem hiding this comment.
@pitrou any further concerns with this removed and the public API change gone?
|
Triggered workflows generally one question on logging that I'd like other input on, otherwise seems reasonable to be as long as CI passes. |
| // type annotation. | ||
| if (logical_type && | ||
| !logical_type->is_applicable(physical_type, element->type_length)) { | ||
| ARROW_LOG(WARNING) << "Dropping unsupported logical type " |
There was a problem hiding this comment.
I think this logging is worth adding if the behavior is not configurable.
Co-authored-by: Isaac <no-reply@databricks.com>
Co-authored-by: Isaac <no-reply@databricks.com>
Co-authored-by: Isaac <no-reply@databricks.com>
3205b68 to
b136ffd
Compare
Co-authored-by: Isaac <no-reply@databricks.com>
| size_t pos = 0; | ||
| size_t num_reserved = 0; | ||
|
|
||
| std::function<std::unique_ptr<Node>(int depth)> NextNode = [&](int depth) { |
There was a problem hiding this comment.
The majority of the remove/add changes here are due to whitespace because of the addition of a const SchemaPath* parent_path parameter.
emkornfield
left a comment
There was a problem hiding this comment.
Generally, LGTM, unless there are other comments, I think once other comments are addressed we can merge this (will aim to do so Monday unless there is additional feedback).
emkornfield
left a comment
There was a problem hiding this comment.
it would be nice if we could test the nested case to ensure the new path naming works as intended.
Co-authored-by: Isaac <no-reply@databricks.com>
Added a test to |
|
CI failure looks unrelated. Going to merge now (actually might be a little bit, need to reset up the merge script on my box). |
| public: | ||
| static std::unique_ptr<Node> FromParquet(const void* opaque_element); | ||
| static std::unique_ptr<Node> FromParquet(const void* opaque_element, | ||
| const SchemaPath* parent_path); |
There was a problem hiding this comment.
Hmm, why are we exposing a public API that the user cannot call (because it expects an incomplete type)?
There was a problem hiding this comment.
I added this so Unflatten could call it. Maybe let's resolve the logging discussion first as this function is only needed to do the logging?
There was a problem hiding this comment.
If we decide to keep the logging, we could make this new overload private but still accessible from Unflatten:
PARQUET_EXPORT friend std::unique_ptr<Node> Unflatten(
std::span<const format::SchemaElement> elements, int max_depth);
Let me know if you'd prefer this approach.
Co-authored-by: Isaac <no-reply@databricks.com>
Rationale for this change
See apache/parquet-format#607 for rationale.
What changes are included in this PR?
This PR gracefully handles unrecognized logical/physical type combinations by dropping the logical type during the read and dropping any associated statistics for the relevant columns. Note that unrecognized logical types are already handled gracefully and no changes were required.
Are these changes tested?
Yes, via unit tests and an e2e test that reads a real file that contains an invalid type combination.
Are there any user-facing changes?
No