zstd compressor and decompressor use the same configuration
- Dominant language
- Java
- Stars
- 3.1k
- Forks
- 1.6k
- Avg merge
- 3d 12h
- Merged PRs (30d)
- 33
Description
I use spark to rewrite the parquet files that are compressed by zstd. And the parquet version is 1.12.2. I want to read the parquet files compressed by level 3 and compress them on another level. But the level can't be changed.
After I check the source, I found the problem was the codec was cached, and the configuration will not be updated:
I think the problem is important. I found it when I try to use a different level to compaction the files in the iceberg table. Asynchronous rewriting with a higher level can lead to higher compression ratio. This is important to save storage costs.
**Reporter**: [Peidian Li](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=lipeidian)
**Note**: *This issue was originally created as [PARQUET-2152](https://issues.apache.org/jira/browse/PARQUET-2152). Please see the [migration documentation](https://issues.apache.org/jira/browse/PARQUET-2502) for further details.*
Contributor guide
No contributing guide indexed for this repository
Research direction
Start in parquet-hadoop/src/main/java/org/apache/parquet/hadoop/CodecFactory.java, especially the cache-related points at lines 144 and 226. Trace how compressor and decompressor configurations are cached and confirm that a rewrite can use a different Zstandard compression level. Done means the requested level is no longer blocked by a previously cached codec configuration, with regression coverage added if the surrounding tests identify an appropriate location.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, spark
- Domain
- data-engineering
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100