[
https://issues.apache.org/jira/browse/PARQUET-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17276187#comment-17276187
]
ASF GitHub Bot commented on PARQUET-1950:
-----------------------------------------
gszadovszky commented on pull request #164:
URL: https://github.com/apache/parquet-format/pull/164#issuecomment-770716726
@emkornfield, in parquet-mr there was another reason to use the `file_path`
in the footer. The feature is called _summary files_. The idea was to have a
separate file containing a summarized footer of several parquet files so you
might do filtering and pruning without even checking a file's own footer. As
far as I know this implementation exists in parquet-mr only and there are no
specification for it in parquet-format.
This feature is more or less abandoned meaning during the development of
some newer features (e.g. column indexes, bloom filters) the related parts
might not updated properly. There were a couple of discussions about this topic
in the dev list:
[here](https://lists.apache.org/thread.html/fb232d024d3ca0f3900b76fb884b55fad11dffafb182d6f336b37a69%40%3Cdev.parquet.apache.org%3E)
and
[here](https://lists.apache.org/thread.html/r2e539c50c1cc818304de2b7dc28a4109aaa529955a42664e3073f811%40%3Cdev.parquet.apache.org%3E).
Because non of the ideas of _external column chunks_ nor the _summary files_
were spread across the different implementations (because of the lack of
specification) I think we should not include the usage of the field `file_path`
in this document or even explicitly specify that this field is not supported.
I am open to specify such features properly and after the required
demonstration we may include them in a later version of the core features.
However, I think these requirements (e.g. snapshot API, summary files) are not
necessarily needed by all of our clients or already implemented in some ways
(e.g. storing statistics in HMS, Iceberg).
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> Define core features / compliance level
> ---------------------------------------
>
> Key: PARQUET-1950
> URL: https://issues.apache.org/jira/browse/PARQUET-1950
> Project: Parquet
> Issue Type: New Feature
> Components: parquet-format
> Reporter: Gabor Szadovszky
> Assignee: Gabor Szadovszky
> Priority: Major
>
> Parquet format is getting more and more features while the different
> implementations cannot keep the pace and left behind with some features
> implemented and some are not. In many cases it is also not clear if the
> related feature is mature enough to be used widely or more an experimental
> one.
> These are huge issues that makes hard ensure interoperability between the
> different implementations.
> The following idea came up in a
> [discussion|https://lists.apache.org/thread.html/rde5cba8443487bccd47593ddf5dfb39f69c729d260165cb936a1a289%40%3Cdev.parquet.apache.org%3E].
> Create a now document in the parquet-format repository that lists the "core
> features". This document is versioned by the parquet-format releases. This
> way a certain version of "core features" defines a level of compatibility
> between the different implementations. This version number can be written to
> a new field (e.g. complianceLevel) in the footer. If an implementation writes
> a file with a version in the field it must implement all the related "core
> features" (read and write) and must not use any other features at write
> because it makes the data unreadable by another implementation if only the
> same level of "core features" are implemented.
> For example if we have encoding A listed in the version 1 "core features" but
> encoding B is not then at "complianceLevel = 1" we can use encoding A but we
> cannot use encoding B because it would make the related data unreadable.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
