apache / apache/parquet-java

Configure the encoding used by ValueWriters

オープン
#1,989 コメント 3 件 リアクション 0 件 担当者 0 名 GitHub で見る
Component: Parquet Priority: Major Type: enhancement
主要言語
Java
スター
3.1k
フォーク
1.6k
平均マージ
3日 12時間
マージ済み PR(30日)
33

説明

This was supposed to be tackled by jira: https://issues.apache.org/jira/browse/PARQUET-601 but that ended up being just the work done to refactor the ValuesWriter factory code out of ParquetProperties. As that is now merged, it would be nice to revisit the original purpose - being able to configure which type of ValuesWriters to be used for writing out columns.

Background: Parquet is currently structured to choose the appropriate value writer based on the type of the column as well as the Parquet version. Value writers are responsible for writing out values with the appropriate encoding. As an example, for Boolean data types, we use BooleanPlainValuesWriter (v1.0) or RunLengthBitPackingHybridValuesWriter (v2.0). Code to do this is in the [DefaultV1ValuesWriterFactory](https://github.com/apache/parquet-mr/blob/master/parquet-column/src/main/java/org/apache/parquet/column/values/factory/DefaultV1ValuesWriterFactory.java#L31) and the [DefaultV2ValuesWriterFactory](https://github.com/apache/parquet-mr/blob/master/parquet-column/src/main/java/org/apache/parquet/column/values/factory/DefaultV2ValuesWriterFactory.java#L35).

Would be nice to support being able to override the encodings in some way.
That allows users to experiment with various encoding strategies manually as well as enables them to override the hardcoded defaults if they don't suit their use case.

Couple of options I can think of:

Specifying encoding by type (or column):
```Java
parquet.writer.encoding-override. = "encoding1[,encoding2]"
As an example:
"parquet.writer.encoding-override.int32" = "plain"
```
Chooses Plain encoding and hence the PlainValuesWriter.

When a primary + fallback need to be specified, we can do the following:
```Java
"parquet.writer.encoding-override.binary" = "rle_dictionary,delta_byte_array"
```

Chooses RLE_DICTIONARY encoding as the initial encoding and DELTA_BYTE_ARRAY encoding as the fallback and hence creates a FallbackWriter(PlainBinaryDictionaryValuesWriter, DeltaByteArrayWriter).
In such cases we can mandate that the first encoding listed must allow for Fallbacks by implementing [RequiresFallback](https://github.com/apache/parquet-mr/blob/master/parquet-column/src/main/java/org/apache/parquet/column/values/RequiresFallback.java#L31).

Another option suggested by @isnotinvain, was to allow overriding of the ValuesWriterFactory using reflection:
```Java
parquet.writer.factory-override = "org.apache.parquet.hadoop.MyValuesWriterFactory"
```

This creates a factory, MyValuesWriterFactory which is then invoked for every ColumnDescriptor to get a ValueWriter. This provides the flexibility to the user to implement a ValuesWriterFactory that can read configuration for per type / column encoding overrides. Can also be used to plug-in a more sophisticated approach where we choose the appropriate encoding based on the data being seen. A concern raised by @rdblue regarding this approach was that ValuesWriters are supposed to be internal classes in Parquet. So we shouldn't be allowing users to configure the ValuesWriter factories via config.

cc @julienledem / @rdblue / @isnotinvain for you thoughts / other ideas. We could also explore other ideas based on any other potential use cases.

**Reporter**: [Piyush Narang](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=pnarang) / @piyushnarang

**Note**: *This issue was originally created as [PARQUET-682](https://issues.apache.org/jira/browse/PARQUET-682). Please see the [migration documentation](https://issues.apache.org/jira/browse/PARQUET-2502) for further details.*

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

調査の方向性

まず DefaultV1ValuesWriterFactory.java と DefaultV2ValuesWriterFactory.java を読み、次に ValuesWriterFactory と RequiresFallback を調べます。この issue では未解決の設定設計が複数提示されているため、まずどのアプローチが受け入れられるかを判断してください。ユーザーが指定どおりに value-writer のエンコーディングまたはファクトリを上書きでき、関連する動作がテストでカバーされれば完了です。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
java
領域
data-engineering
issue の種類
機能追加
難易度
5/5
見積もり時間
1週間以上
活発さ
停滞
明瞭さ
説明が足りない
初心者へのやさしさ
25/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。