用于大数据分析的数据存储格式:Parquet、Avro 和 ORC 的性能和成本影响

本文涉及的产品
实时计算 Flink 版,5000CU*H 3个月
实时数仓Hologres,5000CU*H 100GB 3个月
智能开放搜索 OpenSearch行业算法版,1GB 20LCU 1个月
简介: 在大数据环境中,数据存储格式直接影响查询性能和成本。本文探讨了 Parquet、Avro 和 ORC 三种格式在 Google Cloud Platform (GCP) 上的表现。Parquet 和 ORC 作为列式存储格式,在压缩和读取效率方面表现优异,尤其适合分析工作负载;Avro 则适用于需要快速写入和架构演化的场景。通过对不同查询类型(如 SELECT、过滤、聚合和联接)的基准测试,本文提供了在各种使用案例中选择最优存储格式的建议。研究结果显示,Parquet 和 ORC 在读取密集型任务中更高效,而 Avro 更适合写入密集型任务。正确选择存储格式有助于显著降低成本并提升查询性能。

高效的数据处理对于依赖大数据分析做出明智决策的企业和组织至关重要。显著影响数据处理性能的一个关键因素是数据的存储格式。本文探讨了不同存储格式(特别是 Parquet、Avro 和 ORC)对 Google Cloud Platform (GCP) 上大数据环境中查询性能和成本的影响。本文提供了基准测试,讨论了成本影响,并提供了根据特定使用案例选择合适的格式的建议。

大数据中的存储格式简介
数据存储格式是任何大数据处理环境的支柱。它们定义了数据的存储、读取和写入方式,直接影响存储效率、查询性能和数据检索速度。在大数据生态系统中,Parquet 和 ORC 等列式格式以及 Avro 等基于行的格式因其针对特定类型的查询和处理任务的优化性能而被广泛使用。

木条镶花之地板: Parquet 是一种列式存储格式,针对读取密集型操作和分析进行了优化。它在压缩和编码方面非常高效,非常适合优先考虑读取性能和存储效率的场景。
阿夫罗: Avro 是一种基于行的存储格式,专为数据序列化而设计。它以其架构演化功能而闻名,通常用于需要快速序列化和反序列化数据的写入密集型操作。
ORC (Optimized Row Columnar): ORC 是一种类似于 Parquet 的列式存储格式,但针对读取和写入操作进行了优化,ORC 在压缩方面非常高效,从而降低了存储成本并加快了数据检索速度。
研究目标
本研究的主要目的是评估不同的存储格式(Parquet、Avro、ORC)如何影响大数据环境中的查询性能和成本。本文旨在提供基于各种查询类型和数据量的基准测试,以帮助数据工程师和架构师为其特定使用案例选择最合适的格式。

实验装置
为了进行这项研究,我们在 Google Cloud Platform (GCP) 上使用了标准化设置,将 Google Cloud Storage 作为数据存储库,并使用 Google Cloud Dataproc 来运行 Hive 和 Spark-SQL 作业。实验中使用的数据是结构化和半结构化数据集的混合,用于模拟真实场景。

关键组件
谷歌云存储: 用于以不同格式(Parquet、Avro、ORC)存储数据集
Google Cloud Dataproc: 用于运行 Hive 和 Spark-SQL 作业的托管 Apache Hadoop 和 Apache Spark 服务。
数据: 三个大小不同(10GB、50GB、100GB)的混合数据类型数据集。
image.png

Google 平台上的实验性设置


1

Initialize PySpark and set up Google Cloud Storage as file system

2
from pyspark.sql import SparkSession
3

4
spark = SparkSession.builder \
5
.appName("BigDataQueryPerformance") \
6
.config("spark.jars.packages", "com.google.cloud.bigdataoss:gcs-connector:hadoop3-2.2.5") \
7
.getOrCreate()
8

9

Configure the access to Google Cloud Storage

10
spark.conf.set("fs.gs.impl", "com.google.cloud.hadoop.fs.gcs.GoogleHadoopFileSystem")
11
spark.conf.set("fs.gs.auth.service.account.enable", "true")
12
spark.conf.set("google.cloud.auth.service.account.json.keyfile", "/path/to/your-service-account-file.json")

测试查询
简单的 SELECT 查询: 从表中基本检索所有列
筛选查询: 带有 WHERE 子句的 SELECT 查询以筛选特定行
聚合查询: 涉及 GROUP BY 和聚合函数(如 SUM、AVG 等)的查询。
联接查询: 在公共键上联接两个或多个表的查询
结果和分析

  1. 简单的 SELECT 查询
    木条镶花之地板:由于其柱状存储格式,它的性能非常出色,可以快速扫描特定色谱柱。Parquet 文件经过高度压缩,减少了从磁盘读取的数据量,从而缩短了查询执行时间。

    1

    Simple SELECT query on Parquet file

    2
    parquet_df.select("column1", "column2").show()

阿夫罗:Avro 表现一般。作为基于行的格式,Avro 需要读取整行,即使只需要特定列也是如此。这会增加 I/O 操作,导致与 Parquet 和 ORC 相比,查询性能较慢。
SQL
1
-- Simple SELECT query on Avro file in Hive
2
CREATE EXTERNAL TABLE avro_table
3
STORED AS AVRO
4
LOCATION 'gs://your-bucket/dataset.avro';
5

6
SELECT column1, column2 FROM avro_table;

ORC: ORC 表现出与 Parquet 相似的性能,压缩率略好,并且优化了存储技术,从而提高了读取速度。ORC 文件也是列式的,因此适用于仅检索特定列的 SELECT 查询。

1

Simple SELECT query on ORC file

2
orc_df.select("column1", "column2").show()

简单 SELECT 查询的查询性能

  1. 筛选查询
    木条镶花之地板: Parquet 由于其列式性质和快速跳过不相关列的能力而保持了其性能优势。但是,由于需要扫描更多行以应用筛选条件,性能受到了轻微影响。

    1

    Filter query on Parquet file

    2
    filtered_parquet_df = parquet_df.filter(parquet_df.column1 == 'some_value')
    3
    filtered_parquet_df.show()

阿夫罗: 由于需要读取整行并在所有列中应用筛选器,因此性能进一步下降,从而增加了处理时间。
SQL
1
-- Filter query on Avro file in Hive
2
SELECT * FROM avro_table WHERE column1 = 'some_value';

ORC: 这在筛选查询中略优于 Parquet,因为它的谓词下推功能允许在将数据加载到内存之前直接在存储级别进行筛选。

1

Filter query on ORC file

2
filtered_orc_df = orc_df.filter(orc_df.column1 == 'some_value')
3
filtered_orc_df.show()

筛选条件查询的查询性能

  1. 聚合查询
    木条镶花之地板: Parquet 表现良好,但效率略低于 ORC。列式格式通过快速访问所需的列来有利于聚合操作,但 Parquet 缺少 ORC 提供的一些内置优化。

    1

    Aggregation query on Parquet file

    2
    agg_parquet_df = parquet_df.groupBy("column1").agg({"column2": "sum", "column3": "avg"})
    3
    agg_parquet_df.show()

阿夫罗: Avro 由于其基于行的存储而落后,这需要扫描和处理每行的所有列,从而增加了计算开销。
SQL
1
-- Aggregation query on Avro file in Hive
2
SELECT column1, SUM(column2), AVG(column3) FROM avro_table GROUP BY column1;

ORC: ORC 在聚合查询方面的表现优于 Parquet 和 Avro。ORC 的高级索引和内置压缩算法可实现更快的数据访问并减少 I/O 操作,使其非常适合聚合任务。

1

Aggregation query on ORC file

2
agg_orc_df = orc_df.groupBy("column1").agg({"column2": "sum", "column3": "avg"})
3
agg_orc_df.show()

聚合查询的查询性能

  1. 联接查询
    木条镶花之地板: Parquet 性能良好,但在联接操作中效率不如 ORC,因为它对联接条件的数据读取不太优化。

    1

    Join query between Parquet and ORC files

    2
    joined_df = parquet_df.join(orc_df, parquet_df.key == orc_df.key)
    3
    joined_df.show()

ORC: ORC 在联接查询方面表现出色,受益于高级索引和谓词下推功能,这些功能最大限度地减少了联接操作期间扫描和处理的数据。

1

Join query between two ORC files

2
joined_orc_df = orc_df.join(other_orc_df, orc_df.key == other_orc_df.key)
3
joined_orc_df.show()

阿夫罗:Avro 在连接操作方面遇到了很大困难,主要是因为读取整行的开销很高,并且缺乏对连接键的列式优化。
SQL
1
-- Join query between Parquet and Avro files in Hive
2
SELECT a.column1, b.column2
3
FROM parquet_table a
4
JOIN avro_table b
5
ON a.key = b.key;

联接查询的查询性能

存储格式对成本的影响

  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 存储费用
    存储成本: 这是根据以每种格式存储的数据量计算的。GCP 对存储在 Google Cloud Storage 中的数据每月每 GB 收费。每种格式实现的压缩率直接影响这些成本。Parquet 和 ORC 等列式格式通常比 Avro 等基于行的格式具有更好的压缩率,从而降低存储成本。
    以下是仓储成本的计算方法示例:
    木条镶花之地板: 高压缩率可减小数据大小,从而降低存储成本
    ORC: 与 Parquet 类似,ORC 的高级压缩也有效地降低了存储成本
    阿夫罗: 与 Parquet 和 ORC 相比,较低的压缩效率导致更高的存储成本

    1

    Example of how to save data back to Google Cloud Storage in different formats

    2

    Save DataFrame as Parque

    3
    parquet_df.write.parquet("gs://your-bucket/output_parquet")
    4

    5

    Save DataFrame as Avro

    6
    avro_df.write.format("avro").save("gs://your-bucket/output_avro")
    7

    8

    Save DataFrame as ORC

    9
    orc_df.write.orc("gs://your-bucket/output_orc")

不同规格的仓储成本比较

数据处理成本
数据处理费用是根据在 GCP 上使用 Dataproc 执行各种查询所需的计算资源计算得出的。GCP 根据集群的大小和资源的使用时长收取 Dataproc 使用费。
计算成本:
镶木地板和 ORC: 由于它们高效的列式存储,这些格式减少了读取和处理的数据量,从而降低了计算成本。更快的查询执行时间也有助于节省成本,尤其是对于涉及大型数据集的复杂查询。
阿夫罗: 由于 Avro 采用基于行的格式,因此需要更多的计算资源,这增加了读取和处理的数据量。这导致了更高的成本,尤其是对于读取密集型操作。不同格式的数据处理成本比较
结论
在大数据环境中选择存储格式会显著影响查询性能和成本。以上研究和实验证明了以下关键点:

镶木地板和 ORC:这些列式格式可提供出色的压缩效果,从而降低存储成本。它们能够有效地仅读取必要的列,从而大大提高了查询性能并降低了数据处理成本。由于 ORC 具有高级索引和优化功能,因此在某些查询类型中略优于 Parquet,使其成为需要高读取和写入性能的混合工作负载的绝佳选择。
阿夫罗: 虽然 Avro 在压缩和查询性能方面的效率不如 Parquet 和 ORC,但它在需要快速写入操作和架构演变的使用案例中表现出色。这种格式非常适合涉及数据序列化和流式处理的场景,在这些场景中,写入性能和灵活性优先于读取效率。
成本效益: 在像 GCP 这样的云环境中,成本与存储和计算使用密切相关,选择正确的格式可以节省大量成本。对于主要读取密集型的分析工作负载,Parquet 和 ORC 是最具成本效益的选项。对于需要快速数据摄取和灵活 Schema 管理的应用程序,尽管 Avro 的存储和计算成本较高,但它是一个合适的选择。
建议
根据我们的分析,我们建议如下:

对于读取密集型分析工作负载: 使用 Parquet 或 ORC。这些格式由于其高压缩率和优化的查询性能而提供卓越的性能和成本效益。
对于写入密集型工作负载和序列化: 使用 Avro。 它更适合于快速写入和架构演变至关重要的场景,例如数据流和消息传递系统。
对于混合工作负载:ORC 为读取和写入操作提供平衡的性能,使其成为数据工作负载变化的环境的理想选择。
用于选择存储格式的决策树
最后的思考
为大数据环境选择正确的存储格式对于优化性能和成本至关重要。了解每种格式的优缺点使数据工程师能够根据特定用例定制其数据架构,从而最大限度地提高效率并最大限度地降低费用。随着数据量的持续增长,对于维护可扩展且经济高效的数据解决方案,就存储格式做出明智的决策将变得越来越重要。

相关实践学习
基于MaxCompute的热门话题分析
本实验围绕社交用户发布的文章做了详尽的分析,通过分析能得到用户群体年龄分布,性别分布,地理位置分布,以及热门话题的热度。
SaaS 模式云数据仓库必修课
本课程由阿里云开发者社区和阿里云大数据团队共同出品,是SaaS模式云原生数据仓库领导者MaxCompute核心课程。本课程由阿里云资深产品和技术专家们从概念到方法,从场景到实践,体系化的将阿里巴巴飞天大数据平台10多年的经过验证的方法与实践深入浅出的讲给开发者们。帮助大数据开发者快速了解并掌握SaaS模式的云原生的数据仓库,助力开发者学习了解先进的技术栈,并能在实际业务中敏捷的进行大数据分析,赋能企业业务。 通过本课程可以了解SaaS模式云原生数据仓库领导者MaxCompute核心功能及典型适用场景,可应用MaxCompute实现数仓搭建,快速进行大数据分析。适合大数据工程师、大数据分析师 大量数据需要处理、存储和管理,需要搭建数据仓库?学它! 没有足够人员和经验来运维大数据平台,不想自建IDC买机器,需要免运维的大数据平台?会SQL就等于会大数据?学它! 想知道大数据用得对不对,想用更少的钱得到持续演进的数仓能力?获得极致弹性的计算资源和更好的性能,以及持续保护数据安全的生产环境?学它! 想要获得灵活的分析能力,快速洞察数据规律特征?想要兼得数据湖的灵活性与数据仓库的成长性?学它! 出品人:阿里云大数据产品及研发团队专家 产品 MaxCompute 官网 https://www.aliyun.com/product/odps 
目录
相关文章
|
1月前
|
存储 机器学习/深度学习 SQL
大数据处理与分析技术
大数据处理与分析技术
124 2
|
7天前
|
机器学习/深度学习 数据可视化 大数据
机器学习与大数据分析的结合:智能决策的新引擎
机器学习与大数据分析的结合:智能决策的新引擎
76 15
|
1天前
|
机器学习/深度学习 分布式计算 数据挖掘
MaxFrame 性能评测:阿里云MaxCompute上的分布式Pandas引擎
MaxFrame是一款兼容Pandas API的分布式数据分析工具,基于MaxCompute平台,极大提升了大规模数据处理效率。其核心优势在于结合了Pandas的易用性和MaxCompute的分布式计算能力,无需学习新编程模型即可处理海量数据。性能测试显示,在涉及`groupby`和`merge`等复杂操作时,MaxFrame相比本地Pandas有显著性能提升,最高可达9倍。适用于大规模数据分析、数据清洗、预处理及机器学习特征工程等场景。尽管存在网络延迟和资源消耗等问题,MaxFrame仍是处理TB级甚至PB级数据的理想选择。
19 4
|
13天前
|
SQL 分布式计算 DataWorks
DataWorks产品测评|基于DataWorks和MaxCompute产品组合实现用户画像分析
本文介绍了如何使用DataWorks和MaxCompute产品组合实现用户画像分析。首先,通过阿里云官网开通DataWorks服务并创建资源组,接着创建MaxCompute项目和数据源。随后,利用DataWorks的数据集成和数据开发模块,将业务数据同步至MaxCompute,并通过ODPS SQL完成用户画像的数据加工,最终将结果写入`ads_user_info_1d`表。文章详细记录了每一步的操作过程,包括任务开发、运行、运维操作和资源释放,帮助读者顺利完成用户画像分析。此外,还指出了文档中的一些不一致之处,并提供了相应的解决方法。
|
12天前
|
分布式计算 DataWorks 搜索推荐
用户画像分析(MaxCompute简化版)
通过本教程,您可以了解如何使用DataWorks和MaxCompute产品组合进行数仓开发与分析,并通过案例体验DataWorks数据集成、数据开发和运维中心模块的相关能力。
|
1月前
|
机器学习/深度学习 存储 大数据
在大数据时代,高维数据处理成为难题,主成分分析(PCA)作为一种有效的数据降维技术,通过线性变换将数据投影到新的坐标系
在大数据时代,高维数据处理成为难题,主成分分析(PCA)作为一种有效的数据降维技术,通过线性变换将数据投影到新的坐标系,保留最大方差信息,实现数据压缩、去噪及可视化。本文详解PCA原理、步骤及其Python实现,探讨其在图像压缩、特征提取等领域的应用,并指出使用时的注意事项,旨在帮助读者掌握这一强大工具。
72 4
|
1月前
|
关系型数据库 分布式数据库 数据库
PolarDB 以其出色的性能和可扩展性,成为大数据分析的重要工具
在数字化时代,企业面对海量数据的挑战,PolarDB 以其出色的性能和可扩展性,成为大数据分析的重要工具。它不仅支持高速数据读写,还通过数据分区、索引优化等策略提升分析效率,适用于电商、金融等多个行业,助力企业精准决策。
36 4
|
1月前
|
机器学习/深度学习 分布式计算 算法
【大数据分析&机器学习】分布式机器学习
本文主要介绍分布式机器学习基础知识,并介绍主流的分布式机器学习框架,结合实例介绍一些机器学习算法。
211 5
|
1月前
|
存储 监控 数据挖掘
【Clikhouse 探秘】ClickHouse 物化视图:加速大数据分析的新利器
ClickHouse 的物化视图是一种特殊表,通过预先计算并存储查询结果,显著提高查询性能,减少资源消耗,适用于实时报表、日志分析、用户行为分析、金融数据分析和物联网数据分析等场景。物化视图的创建、数据插入、更新和一致性保证通过事务机制实现。
167 14
|
1月前
|
存储 大数据 数据管理
大数据分区提高查询性能
大数据分区提高查询性能
34 2

相关产品

  • 云原生大数据计算服务 MaxCompute