什么是 Parquet 文件格式以及为什么要使用它

该文翻译整理自https://www.upsolver.com/blog/apache-parquet-why-use

Apache Parquet 自 2013 年首次推出以来，作为一种免费和开源的存储格式被广泛采用，用于快速分析查询。当 AWS 宣布数据湖导出时，他们将 Parquet 描述为 “与文本格式相比，在 Amazon S3 中卸载速度快 2 倍，消耗的存储空间减少多达 6 倍” 。还建议^[1]将数据转换为 Parquet 或 ORC 等列格式，作为提高 Amazon Athena 性能的一种方法。

很明显，Apache Parquet 在使用数据湖时对系统性能起着重要作用。让我们仔细看看 Parquet 究竟是什么，以及它对大数据存储和分析的重要性。

目录

• 基础知识：什么是 Apache Parquet？
• Parquet 列式存储的优势 – 为什么要使用它？
• 压缩
• 表现
• 模式演变
• 开源和非专有
• 用于分析查询的面向列与基于行的存储
• Apache Parquet 用例——你应该什么时候使用它？
• 示例：Parquet、CSV 和 Amazon Athena
• 使用 Parquet 就够了吗？

基础知识：什么是 Apache Parquet？

Apache Parquet 是一种文件格式，旨在支持对复杂数据进行快速数据处理，具有以下几个显着特点：

1.列式  ： 与 CSV 或 Avro 等基于行的格式不同，Apache Parquet 是面向列的——这意味着每个表列的值彼此相邻存储，而不是每条记录的值：

2. 开源： Parquet 在 Apache Hadoop 许可下免费使用和开源，兼容大多数 Hadoop 数据处理框架。引用项目网站^[2]的话说，“Apache Parquet ……可用于任何项目……无论选择何种数据处理框架、数据模型或编程语言。”

3. 自描述 ：除了数据，Parquet 文件还包含元数据，包括模式和结构。每个文件都存储了用于访问每条记录的数据和标准——这使得编写、存储和读取 Parquet 文件的服务更容易解耦。

Parquet 列式存储的优势 – 为什么要使用它？

在存储和分析大量数据时，Apache Parquet 文件格式的上述特征创造了几个明显的好处。让我们更深入地了解其中的一些。

压缩

文件压缩是获取文件并使其更小的行为。在 Parquet 中，压缩是逐列执行的，它旨在支持灵活的压缩选项和每种数据类型的可扩展编码模式——例如，不同的编码可用于压缩整数和字符串数据。

Parquet 数据可以使用以下编码方法进行压缩：

• 字典编码： 对于具有少量唯一值的数据，这是自动且动态地启用的。
• 位打包： 整数的存储通常使用每个整数专用的 32 或 64 位来完成。这允许更有效地存储小整数。
• 运行长度编码（RLE）： 当相同的值多次出现时，单个值连同出现次数一起存储一次。Parquet 实现了位打包和 RLE 的组合版本，其中编码切换基于哪个产生最佳压缩结果。

表现

与 CSV 等基于行的文件格式不同，Parquet 针对性能进行了优化。在基于 Parquet 的文件系统上运行查询时，您可以非常快速地只关注相关数据。此外，扫描的数据量会更小，并且会导致更少的 I/O 使用。为了理解这一点，让我们更深入地了解 Parquet 文件的结构。

正如我们上面提到的，Parquet 是一种自描述格式，因此每个文件都包含数据和元数据。Parquet 文件由行组、页眉和页脚组成。每个行组包含来自相同列的数据。相同的列一起存储在每个行组中：

该结构针对快速查询性能和低 I/O（最小化扫描的数据量）进行了很好的优化。例如，如果您有一个包含 1000 列的表，您通常只会使用一小部分列进行查询。使用 Parquet 文件将使您能够仅获取所需的列及其值，将它们加载到内存中并回答查询。如果使用 CSV 等基于行的文件格式，则必须将整个表加载到内存中，从而导致 I/O 增加和性能下降。

模式演变

当使用 Parquet 等列文件格式时，用户可以从简单的模式开始，然后根据需要逐渐向模式中添加更多列。这样，用户最终可能会得到多个 Parquet 文件，这些文件具有不同但相互兼容的模式。在这些情况下，Parquet 支持这些文件之间的自动模式合并。

开源和非专有

Apache Parquet 是开源 Apache Hadoop 生态系统的一部分。围绕它的开发工作很活跃，并且由强大的用户和开发人员社区不断改进和维护。

与许多现代高性能数据库使用的专有文件格式相比，以开放格式存储数据意味着您可以避免供应商锁定并提高灵活性。这意味着您可以在同一个数据湖架构中使用各种查询引擎，例如 Amazon Athena、Qubole 和 Amazon Redshift Spectrum，而不必受制于特定的数据库供应商。

用于分析查询的面向列与基于行的存储

数据通常是按行生成的，并且更容易概念化。我们习惯于用 Excel 电子表格来思考，在那里我们可以在整齐有序的行中查看与特定记录相关的所有数据。但是，对于大规模的分析查询，列式存储在成本和性能方面具有显着优势。

日志和事件流等复杂数据需要表示为具有数百或数千列和数百万行的表。以基于行的格式（例如 CSV）存储此表意味着：

• 查询将需要更长的时间来运行，因为需要扫描更多数据，而不是只查询我们需要回答查询的列子集（这通常需要基于维度或类别进行聚合）
• 存储成本会更高，因为 CSV 的压缩效率不如 Parquet

列格式提供更好的压缩和开箱即用的改进性能，并使您能够逐列垂直查询数据。

Apache Parquet 用例——你应该什么时候使用它？

虽然这不是一个完整的列表，但您应该在 Parquet 中存储数据的一些明显迹象包括：

• 当您处理大量数据时 。Parquet 专为提高性能和有效压缩而设计。各种基准测试比较了 Parquet 上的 SQL 查询与 Avro 或 CSV 等格式（包括本文中描述的一种，以及本文中的一种^[3]）的处理时间，发现查询 Parquet 可以显着提高查询速度。
• 当您的完整数据集有很多列，但您只需要访问一个子集时 。由于您正在记录的业务数据日益复杂，您可能会发现，您现在不是为每个数据事件收集 20 个字段，而是捕获了 100 多个字段。虽然这些数据很容易存储在数据湖中，但如果以基于行的格式存储，则查询它需要扫描大量数据。Parquet 的列式和自描述性质允许您只提取回答特定查询所需的列，从而减少处理的数据量。

当您希望多个服务使用对象存储中的相同数据时 。虽然 Oracle 和 Snowflake 等数据库供应商更喜欢您以只有他们的工具可以读取的专有格式存储数据，但现代数据架构倾向于将存储与计算分离。如果您想使用多个分析服务来回答不同的用例，您应该将数据存储在 Parquet 中。

示例：Parquet、CSV 和 Amazon Athena

在我们最近与 Looker 的网络研讨会中，我们已经更深入地探讨了这个示例。 ***在这里观看录音。***^[4]

为了展示列 Parquet 存储与基于行的替代方案相比的影响，让我们看看在这两种情况下使用 Amazon Athena^[5] 查询存储在 Amazon S3 上的数据时会发生什么。

使用 Upsolver，我们将服务器日志的 CSV 数据集摄取到 S3。在常见的 AWS 数据湖架构中，Athena 将用于直接从 S3 查询数据。然后可以使用 Tableau 或 Looker 等交互式数据可视化工具对这些查询进行可视化。

我们针对存储为压缩 CSV 和 Apache Parquet 的相同数据集测试了 Athena 。

这是我们在 Athena 中运行的查询：

SELECT tags_host AS host_id, AVG(fields_usage_active) as avg_usage
FROM server_usage
GROUP BY tags_host
HAVING AVG(fields_usage_active) > 0
LIMIT 10

结果：

1. 压缩的 CSV： 压缩的 CSV 有 18 列，在 S3 上 有 27 GB。Athena 必须扫描整个 CSV 文件才能回答查询，因此我们需要为 27 GB 的扫描数据付费。在更高的规模上，这也会对性能产生负面影响。
2. Parquet： 将我们压缩的 CSV 文件转换为 Apache Parquet，您最终会在 S3 中获得类似数量的数据。但是，由于 Parquet 是列式的，Athena 只需要读取与正在运行的查询相关的列——数据的一小部分。在这种情况下，Athena 必须扫描 0.22 GB 的数据，因此我们无需为扫描的 27 GB 数据付费，而是只为 0.22 GB 付费。

这是网络研讨会的一个短片，您可以在此处完整观看：^[6]

使用 Parquet 就够了吗？

使用 Parquet 是一个好的开始；然而，优化数据湖查询并不止于此。您经常需要清理、丰富和转换数据，执行高聚合连接（high-cardinality joins）并实施一系列最佳实践，以确保始终快速且经济高效地返回查询。

参考资料