Parquet 数据页压缩（Data Page Compression）
概述
Parquet 允许对字典页和数据页中的数据块进行压缩，以提高存储效率。Parquet 格式支持多种压缩算法，这些算法在压缩比和处理成本之间的不同范围内提供了不同的选择。
每种压缩算法的详细规范由各自的作者或维护者独立维护，我们在此提供参考链接。
除已弃用的 LZ4 编解码器外，所有压缩编解码器都会直接对数据页或字典页的原始数据进行压缩，而不会添加额外的框架或填充。解压缩所需的精确缓冲区分配信息存储在 PageHeader 结构体中。
编解码器（Codecs）
UNCOMPRESSED（未压缩）
不进行任何压缩，数据保持原样。
SNAPPY
基于 Snappy 压缩格式 的编解码器。如果在实现此格式时存在任何歧义，应参考 Google 提供的 Snappy 库 作为权威实现。
GZIP
基于 GZIP 格式的编解码器（与“zlib”或“deflate”格式不同），其格式定义在 RFC 1952 中。如果在实现此格式时存在任何歧义，应参考 zlib 压缩库 作为权威实现。
读取器应支持读取包含多个 GZIP 成员的页面，但由于历史上并非所有实现都支持这一特性，因此建议写入器默认避免创建此类页面，以提高兼容性。
LZO
基于或兼容 LZO 压缩库 的编解码器。
BROTLI
基于 RFC 7932 定义的 Brotli 格式的编解码器。如果在实现此格式时存在任何歧义，应参考 Brotli 压缩库 作为权威实现。
LZ4
已弃用 的编解码器，基于 LZ4 压缩算法，但包含额外的未记录的框架方案。该框架最初是 Hadoop 压缩库的一部分，并被 parquet-mr 复制，然后由 parquet-cpp 以不同程度的成功进行模拟。
强烈建议 Parquet 写入器的实现者在用户 API 中弃用此压缩编解码器，并建议用户改用新的 LZ4_RAW 编解码器，以提高互操作性。
ZSTD
基于 RFC 8478 定义的 Zstandard 格式的编解码器。如果在实现此格式时存在任何歧义，应参考 Zstandard 压缩库 作为权威实现。
LZ4_RAW
基于 LZ4 块格式 的编解码器。如果在实现此格式时存在任何歧义，应参考 LZ4 压缩库 作为权威实现。
最佳实践
- 选择适合的数据压缩算法
- 如果对压缩率要求较高，建议使用
ZSTD或GZIP，它们在压缩比和解压缩速度之间提供了良好的平衡。 - 如果需要更快的压缩/解压缩速度，可考虑
SNAPPY，其压缩率较低但性能优秀。 -
BROTLI在较高压缩比的场景下表现良好，适用于存储优化需求强的应用。 -
避免使用已弃用的
LZ4编解码器 -
LZ4编解码器由于历史原因存在不一致的实现，建议切换到LZ4_RAW，以确保数据的可读性和跨平台兼容性。 -
考虑数据读取性能
- 在只读查询较多的场景下，优先选择解压缩速度快的算法（如
SNAPPY）。 -
在需要较低存储占用的场景下，优先选择
ZSTD或GZIP。 -
测试不同的压缩策略
-
不同的数据集对压缩算法的适应性不同，建议在生产环境前进行压缩率和读取性能的基准测试，以选择最优的压缩算法。
-
保持 Parquet 文件的兼容性
- 避免使用不常见或实验性的编解码器，以确保数据可以在不同的 Parquet 解析库中正确读取。
通过合理选择压缩算法，可以在存储效率、读取性能和处理成本之间取得最佳平衡，从而优化 Parquet 文件的存储和使用体验。