apache / apache/parquet-format
Adding Compression for BloomFilter
- Dominant language
- Thrift
- Stars
- 2.6k
- Forks
- 508
- Avg merge
- 2d 8h
- Merged PRs (30d)
- 4
Description
In Current Parquet implementions, if BloomFilter doesn't set the ndv, most implementions will guess the 1M as the ndv. And use it for fpp. So, if fpp is 0.01, the BloomFilter size may grows to 2M for each column, which is really huge. Should we support compression for BloomFilter, like:
```
/\*\*
- The compression used in the Bloom filter.
\*\*/
struct Uncompressed {}
union BloomFilterCompression {
1: Uncompressed UNCOMPRESSED;
+2: CompressionCodec COMPRESSION;
}
```
**Reporter**: [Xuwei Fu](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=mwish) / @mapleFU
**Assignee**: [Xuwei Fu](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=mwish) / @mapleFU
**Note**: *This issue was originally created as [PARQUET-2256](https://issues.apache.org/jira/browse/PARQUET-2256). Please see the [migration documentation](https://issues.apache.org/jira/browse/PARQUET-2502) for further details.*
Contributor guide
Research direction
No source file or test entry point is identified in the issue. Start by locating the Parquet BloomFilter schema and the existing CompressionCodec definition, then determine the compatibility and validation work needed; done means an agreed compression representation with corresponding format validation.
Written by the indexing model from the issue text.
Assessment
- Domain
- data-engineering
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100