动机（Motivation）

Parquet 的开发动机(Motivation)

我们创建 Parquet 是为了让压缩高效的列式数据表示方式能够被 Hadoop 生态系统中的任何项目所利用。

Parquet 从零开始构建，专为处理复杂的嵌套数据结构设计，并使用了 Dremel 论文中描述的记录切分和组装算法。我们认为这种方法优于对嵌套命名空间的简单扁平化处理。

Parquet 旨在支持高效的压缩和编码方案。多个项目已经证明，针对数据应用合适的压缩和编码方案会显著影响其性能。Parquet 允许在列级别指定不同的压缩方案，并且支持未来扩展，以便随着新的编码方案的发明和实现进行升级。

Parquet 旨在供任何人使用。Hadoop 生态系统拥有丰富的数据处理框架，而我们并不偏向任何特定的框架。我们相信，一个高效、良好实现的列式存储基础组件，应该能够被所有框架轻松使用，而不会因为依赖项复杂或难以设置而增加使用成本。

最佳实践

选择合适的压缩格式
- Parquet 支持多种压缩格式，如 Snappy、Gzip、ZSTD，应根据数据特性选择合适的格式。例如：
  - Snappy：解压速度快，适用于低延迟查询场景。
  - Gzip：压缩率高，适用于存储优化场景。
  - ZSTD：兼具较好的压缩率和解压速度，适用于大多数场景。
充分利用列式存储的优点
- 在数据分析和查询过程中，只读取所需的列可显著减少 I/O 开销。
- 避免在 Parquet 文件中存储过多不必要的列，以提升查询效率。
优化数据分区
- 结合 Hive 分区 或 Spark Partitioning，基于查询需求进行数据分区，提高查询性能。
- 例如，按 日期（year/month/day） 分区有助于加速基于时间范围的查询。
合理设置编码方式
- DICT_ENCODING（字典编码） 适用于高重复值的列，有助于提高压缩率和查询效率。
- BIT_PACKED 和 RLE（运行长度编码） 适用于布尔值或低基数整数列，减少存储开销。
适用于不同计算引擎
- Parquet 可被 Apache Spark、Presto、Trino、Hive、Impala 等多种引擎高效处理，在不同计算环境中具有广泛适用性。
避免小文件问题
- 过多的小 Parquet 文件会降低查询效率，应通过 合并小文件（coalesce/repartition） 或 适当的 batch size 控制文件数量。
保持 schema 兼容性
- 在数据演进过程中，尽量保持 schema 的稳定性，避免数据格式不兼容导致查询失败或性能下降。

以上实践可以帮助最大化利用 Parquet 的列式存储特性，提高数据存储和查询的效率。 🚀