深入分析大数据存储格式:Parquet、Avro 和 ORC 的性能和成本影响
对于依赖大数据分析做出决策的企业和组织来说,高效的数据处理至关重要。影响数据处理性能的一个关键因素是数据的存储格式。本文探讨了不同存储格式(特别是 Parquet、Avro 和 ORC)对 Google Cloud Platform (GCP) 上大数据环境中查询性能和成本的影响。本文提供了基准,讨论了成本影响,并根据特定用例提供了选择适当格式的建议。
1.存储格式简介
数据存储格式是任何大数据处理环境的支柱。它们定义了数据的存储、读取和写入方式,直接影响存储效率、查询性能和数据检索速度。在大数据生态系统中,列式格式(如 Parquet 和 ORC)和行式格式(如 Avro)因其针对特定类型的查询和处理任务的优化性能而被广泛使用。
Parquet: Parquet 是一种针对读取密集型操作和分析进行优化的列式存储格式。它在压缩和编码方面非常高效,非常适合优先考虑读取性能和存储效率的场景。
Avro: Avro 是一种专为数据序列化而设计的基于行的存储格式。它以其模式演变功能而闻名,通常用于需要快速序列化和反序列化数据的写入密集型操作。
ORC(优化行列式): ORC 是一种类似于 Parquet 的列式存储格式,但针对读写操作进行了优化,ORC 在压缩方面效率很高,从而降低了存储成本并加快了数据检索速度。
2.研究目标
本次研究的主要目的是评估不同的存储格式(Parquet、Avro、ORC)如何影响大数据环境中的查询性能和成本。旨在根据各种查询类型和数据量提供基准,以帮助数据工程师和架构师为其特定用例选择最合适的格式。
3.实验设置
为了开展这项研究,我们在 Google Cloud Platform (GCP) 上使用了一个标准化设置,以 Google Cloud Storage 作为数据存储库,并使用 Google Cloud Dataproc 运行 Hive 和 Spark-SQL 作业。实验中使用的数据是结构化和半结构化数据集的混合,以模拟真实场景。
4.使用组件
Google Cloud Storage: 用于以不同格式存储数据集(Parquet、Avro、ORC)
Google Cloud Dataproc: 一种托管的Apache Hadoop和Apache Spark服务,用于运行 Hive 和 Spark-SQL 作业。
数据集: 三个大小各异(10GB、50GB、100GB)的数据集,包含混合数据类型。
# Initialize PySpark and set up Google Cloud Storage as file system
from pyspark.sql import SparkSession
spark = SparkSession.builder \
.appName("BigDataQueryPerformance") \
.config("spark.jars.packages", "com.google.cloud.bigdataoss:gcs-connector:hadoop3-2.2.5") \
.getOrCreate()
# Configure the access to Google Cloud Storage
spark.conf.set("fs.gs.impl", "com.google.cloud.hadoop.fs.gcs.GoogleHadoopFileSystem")
spark.conf.set("fs.gs.auth.service.account.enable", "true")
spark.conf.set("google.cloud.auth.service.account.json.keyfile", "/path/to/your-service-account-file.json")
简单 SELECT 查询: 从表中的所有列进行基本检索
过滤查询: 使用 WHERE 子句的 SELECT 查询来过滤特定的行
聚合查询: 涉及 GROUP BY 和聚合函数(如 SUM、AVG 等)的查询。
连接查询: 根据公共键连接两个或多个表的查询
5.结果与分析
1. 简单的 SELECT 查询
Parquet:由于采用列式存储格式,因此性能出众,可以快速扫描特定列。Parquet 文件经过高度压缩,减少了从磁盘读取的数据量,从而缩短了查询执行时间。
# Simple SELECT query on Parquet file
parquet_df.select("column1", "column2").show()
Avro:Avro 表现中等。作为基于行的格式,Avro 需要读取整行,即使只需要特定列也是如此。这会增加 I/O 操作,导致查询性能比 Parquet 和 ORC 更慢。
-- Simple SELECT query on Avro file in Hive
CREATE EXTERNAL TABLE avro_table
STORED AS AVRO
LOCATION 'gs://your-bucket/dataset.avro';
SELECT column1, column2 FROM avro_table;
ORC:ORC 的性能与 Parquet 类似,但压缩效果略好,存储技术也经过优化,提高了读取速度。ORC 文件也是列式的,因此适合仅检索特定列的 SELECT 查询。
# Simple SELECT query on ORC file
orc_df.select("column1", "column2").show()
2. 过滤查询
Parquet:Parquet 凭借其列式特性和快速跳过不相关列的能力保持了其性能优势。然而,由于需要扫描更多行来应用过滤器,性能略有下降。
# Filter query on Parquet file
filtered_parquet_df = parquet_df.filter(parquet_df.column1 == 'some_value')
filtered_parquet_df.show()
Avro:由于需要读取整行并对所有列应用过滤器,从而增加了处理时间,导致性能进一步下降。
-- Filter query on Avro file in Hive
SELECT * FROM avro_table WHERE column1 = 'some_value';
ORC:由于其谓词下推功能,其在过滤查询中的表现略优于 Parquet,该功能允许在数据加载到内存之前直接在存储级别进行过滤。
# Filter query on ORC file
filtered_orc_df = orc_df.filter(orc_df.column1 == 'some_value')
filtered_orc_df.show()
3. 聚合查询
Parquet:Parquet 性能良好,但效率略低于 ORC。列式格式有利于聚合操作,因为它可以快速访问所需的列,但 Parquet 缺少 ORC 提供的一些内置优化。
# Aggregation query on Parquet file
agg_parquet_df = parquet_df.groupBy("column1").agg({"column2": "sum", "column3": "avg"})
agg_parquet_df.show()
Avro:Avro 由于其基于行的存储而落后,这需要扫描和处理每一行的所有列,从而增加了计算开销。
-- Aggregation query on Avro file in Hive
SELECT column1, SUM(column2), AVG(column3) FROM avro_table GROUP BY column1;
ORC:在聚合查询方面,ORC 的表现优于 Parquet 和 Avro。ORC 的高级索引和内置压缩算法可以加快数据访问速度并减少 I/O 操作,非常适合聚合任务。
# Aggregation query on ORC file
agg_orc_df = orc_df.groupBy("column1").agg({"column2": "sum", "column3": "avg"})
agg_orc_df.show()
4. 连接查询
Parquet:Parquet 表现良好,但由于其对连接条件的数据读取不够优化,在连接操作方面不如 ORC 高效。
# Join query between Parquet and ORC files
joined_df = parquet_df.join(orc_df, parquet_df.key == orc_df.key)
joined_df.show()
ORC:ORC 在连接查询方面表现出色,得益于高级索引和谓词下推功能,这最大限度地减少了连接操作期间扫描和处理的数据。
# Join query between two ORC files
joined_orc_df = orc_df.join(other_orc_df, orc_df.key == other_orc_df.key)
joined_orc_df.show()
Avro:Avro 在连接操作方面遇到了很大困难,主要是因为读取整行数据的开销很大,而且缺乏对连接键的列优化。
-- Join query between Parquet and Avro files in Hive
SELECT a.column1, b.column2
FROM parquet_table a
JOIN avro_table b
ON a.key = b.key;
6.存储格式对成本的影响
1.存储效率和成本
Parquet 和 ORC(列格式)
压缩和存储成本: Parquet 和 ORC 都是列式存储格式,可提供高压缩率,尤其是对于列中具有许多重复值或相似值的数据集。这种高压缩率可减少总体数据大小,从而降低存储成本,尤其是在按 GB 计费的云环境中。
最适合分析工作负载:由于其列式特性,这些格式非常适合仅频繁查询特定列的分析工作负载。这意味着从存储中读取的数据更少,从而减少了 I/O 操作和相关成本。
Avro(基于行的格式)
压缩和存储成本: Avro 通常提供比 Parquet 和 ORC 等列式格式更低的压缩率,因为它逐行存储数据。这会导致更高的存储成本,尤其是对于包含许多列的大型数据集,因为即使只需要几列,也必须读取一行中的所有数据。
更适合写入密集型工作负载:虽然 Avro 可能会因压缩率较低而导致更高的存储成本,但它更适合写入密集型工作负载(即不断写入或附加数据)。与存储相关的成本可能会被数据序列化和反序列化的效率提升所抵消。
2. 数据处理性能和成本
Parquet 和 ORC(列格式)
降低处理成本:这些格式针对读取密集型操作进行了优化,这使得它们在查询大型数据集时非常高效。由于它们只允许读取查询所需的相关列,因此它们减少了处理的数据量。这可以降低 CPU 使用率并加快查询执行时间,从而可以显著降低计算成本,因为在云环境中,计算资源是按使用量计费的。
成本优化的高级功能:特别是 ORC,它包含谓词下推和内置统计等功能,使查询引擎可以跳过读取不必要的数据。这进一步减少了 I/O 操作并加快了查询性能,从而优化了成本。
Avro(基于行的格式)
处理成本更高:由于 Avro 是一种基于行的格式,因此即使只需要几列,通常也需要更多 I/O 操作来读取整行。这会导致计算成本增加,因为 CPU 使用率更高,查询执行时间更长,尤其是在读取密集型环境中。
流式传输和序列化效率高:尽管查询处理成本较高,但 Avro 非常适合流式传输和序列化任务,因为快速写入速度和模式演变对流式传输和序列化任务更为关键。
3. 包含定价细节的成本分析
为了量化每种存储格式的成本影响,我们使用 GCP 进行了一项实验。我们根据 GCP 的定价模型计算了每种格式的存储和数据处理相关成本。
Google Cloud 存储费用
Parquet:高压缩率可减少数据大小,从而降低存储成本
ORC:与 Parquet 类似,ORC 的高级压缩功能也有效降低了存储成本
Avro:与 Parquet 和 ORC 相比,压缩效率较低导致存储成本较高
存储成本: 此成本根据每种格式存储的数据量计算得出。GCP 按每月每 GB 收取存储在 Google Cloud Storage 中的数据费用。每种格式实现的压缩率会直接影响这些成本。Parquet 和 ORC 等列式格式的压缩率通常比 Avro 等基于行的格式更高,从而降低存储成本。
以下是存储成本计算方法的示例:
# Example of how to save data back to Google Cloud Storage in different formats
# Save DataFrame as Parque
parquet_df.write.parquet("gs://your-bucket/output_parquet")
# Save DataFrame as Avro
avro_df.write.format("avro").save("gs://your-bucket/output_avro")
# Save DataFrame as ORC
orc_df.write.orc("gs://your-bucket/output_orc")
数据处理成本
数据处理成本是根据在 GCP 上使用 Dataproc 执行各种查询所需的计算资源计算得出的。GCP 根据集群大小和使用资源的时长收取 dataproc 使用费。
计算成本:
Parquet 和 ORC:由于采用高效的列式存储,这些格式减少了读取和处理的数据量,从而降低了计算成本。更快的查询执行时间也有助于节省成本,尤其是对于涉及大型数据集的复杂查询。
Avro:Avro 采用基于行的格式,因此需要更多计算资源,这增加了读取和处理的数据量。这会导致成本增加,尤其是对于读取量大的操作。
7.总结
大数据环境中存储格式的选择对查询性能和成本都有很大的影响。上述研究和实验证明了以下几个关键点:
Parquet 和 ORC:这些列式格式提供出色的压缩功能,从而降低了存储成本。它们能够高效地只读取必要的列,从而大大提高了查询性能并降低了数据处理成本。由于其高级索引和优化功能,ORC 在某些查询类型中的表现略优于 Parquet,使其成为需要高读写性能的混合工作负载的绝佳选择。
Avro:虽然 Avro 在压缩和查询性能方面不如 Parquet 和 ORC,但它在需要快速写入操作和模式演变的用例中表现出色。这种格式非常适合涉及数据序列化和流式传输的场景,在这些场景中,写入性能和灵活性优先于读取效率。
成本效益:在 GCP 这样的云环境中,成本与存储和计算使用密切相关,选择正确的格式可以节省大量成本。对于以读取为主的分析工作负载,Parquet 和 ORC 是最具成本效益的选项。对于需要快速数据提取和灵活架构管理的应用程序,尽管 Avro 的存储和计算成本较高,但它仍是一个合适的选择。
根据我们的分析,建议以下几点:
对于读取量大的分析工作负载:使用Parquet 或 ORC。这些格式具有高压缩率和优化的查询性能,可提供卓越的性能和成本效益。
对于写入繁重的工作负载和序列化:使用 Avro。 它更适合快速写入和模式演变至关重要的场景,例如数据流和消息传递系统。
对于混合工作负载:ORC 为读写操作提供了均衡的性能,使其成为数据工作负载变化的环境的理想选择。
为大数据环境选择正确的存储格式对于优化性能和成本至关重要。了解每种格式的优缺点可让数据工程师根据特定用例定制其数据架构,从而最大限度地提高效率并最大限度地降低费用。随着数据量的不断增长,做出更优的存储格式决策对于维护可扩展且经济高效的数据解决方案将变得越来越重要。通过仔细评估本文中提出的性能基准和成本影响,可以选择最符合其运营需求和财务目标的存储格式。
涤生大数据往期精彩推荐
8.SQL之优化篇:一文搞懂如何优化线上任务性能,增效降本!
10.基于FlinkSQL +Hbase在O2O场景营销域实时数仓的实践
12.涤生大数据实战:基于Flink+ODPS历史累计计算项目分析与优化(一)
13.涤生大数据实战:基于Flink+ODPS历史累计计算项目分析与优化(二)
14.5分钟了解实时车联网,车联网(IoV)OLAP 解决方案是怎样的?
15.企业级Apache Kafka集群策略:Kakfa最佳实践总结
20.大数据实战:基于Flink+ODPS进行最近N天实时标签构建
25.玩转大厂金融风控体系建设
26.实际开发中:如何有效运用Spark Catalyst的执行流程