Formatos de Armazenamento de Dados para Análise de Big Data: implicações de desempenho e custo de Parquet, Avro e ORC

O processamento eficiente de dados é crucial para as empresas e organizações que dependem de análise de dados em escala grande para tomar decisões informadas. Um fator chave que afeta significativamente o desempenho do processamento de dados é o formato de armazenamento dos dados. Este artigo explora o impacto de diferentes formatos de armazenamento, especificamente Parquet, Avro e ORC, no desempenho de consultas e custos em ambientes de dados em escala grande na Google Cloud Platform (GCP). Este artigo fornece benchmark, discute implicações de custo e oferece recomendações sobre a seleção do formato apropriado baseado em casos de uso específicos.

Introdução a Formatos de Armazenamento em Dados em Escala Grande

Formatos de armazenamento de dados são o cerne de qualquer ambiente de processamento de dados em escala grande. Eles definem como os dados são armazenados, lidos e escritos, impactando diretamente a eficiência de armazenamento, o desempenho de consultas e as velocidades de recuperação de dados. No ecossistema de dados em escala grande, formatos de coluna, como Parquet e ORC, e formatos de linha, como Avro, são amplamente usados devido à sua otimização para tipos específicos de consultas e tarefas de processamento.

• Parquet: Parquet é um formato de armazenamento de coluna otimizado para operações de leitura e análise pesadas. Ele é altamente eficiente em termos de compressão e codificação, tornando-se ideal para cenários onde o desempenho de leitura e a eficiência de armazenamento são priorizados.
• Avro: Avro é um formato de armazenamento de linha projetado para serialização de dados. Ele é conhecido por suas capacidades de evolução de esquema e é frequentemente usado para operações de gravação pesadas, onde os dados precisam ser serializados e deserializados rapidamente.
• ORC (Optimized Row Columnar): ORC é um formato de armazenamento em colunas semelhante a Parquet, mas otimizado para as operações de leitura e gravação, o ORC é altamente eficiente em termos de compressão, reduzindo o custo de armazenamento e acelerando a recuperação de dados.

Objetivo de Pesquisa

O objetivo primário desta pesquisa é avaliar como diferentes formatos de armazenamento (Parquet, Avro, ORC) afetam o desempenho de consulta e os custos em ambientes de big data. Este artigo visa fornecer benchmarks baseados em diferentes tipos de consultas e volumes de dados para ajudar os engenheiros de dados e arquitetos a escolher o formato mais adequado para seus casos de uso específicos.

Configuração Experimental

Para realizar esta pesquisa, usamos uma configuração padrão na Plataforma da Google Cloud (GCP) com o Google Cloud Storage como repositório de dados e o Google Cloud Dataproc para executar jobs de Hive e Spark-SQL. Os dados usados nas experiências eram uma mistura de conjuntos de dados estruturados e semi-estruturados para mimetizar cenários reais.

Componentes Chave

• Google Cloud Storage: Usado para armazenar os conjuntos de dados em diferentes formatos (Parquet, Avro, ORC)
• Google Cloud Dataproc: Um serviço gerenciado que utiliza o Apache Hadoop e o Apache Spark, usado para executar jobs de Hive e Spark-SQL.
• Conjuntos de Dados: Três conjuntos de dados de tamanhos diferentes (10GB, 50GB, 100GB) com tipos de dados misturados.

# 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")

Consultas de Teste

• Query simples de SELECT: Recuperação básica de todas as colunas de uma tabela
• Query de filtragem: Consultas de SELECT com cláusulas WHERE para filtrar linhas específicas
• Query de agregação: Consultas que envolvem GROUP BY e funções agregadas, como SUM, AVG, etc..
• Query de junção: Consultas que juntam duas ou mais tabelas em uma chave comum

Resultados e Análise

1. Query simples de SELECT

• Parquet: Permitiu um desempenho excepcional devido ao seu formato de armazenamento em colunas, que permitiu a leitura rápida de colunas específicas. Os arquivos Parquet são altamente comprimidos, reduzindo a quantidade de dados lidos do disco, o que resultou em tempos de execução de consulta mais rápidos.

# Simple SELECT query on Parquet file

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

• Avro: O Avro apresentou desempenho moderado. Sendo um formato baseado em linhas, o Avro necessitou de ler a linha inteira, mesmo que apenas colunas específicas fossem necessárias. Isto aumentou as operações de E/S, levando a um desempenho de consulta mais lento em comparação com o Parquet e o 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: O ORC mostrou desempenho semelhante ao Parquet, com compressão ligeiramente melhor e técnicas de armazenamento otimizadas que melhoraram as velocidades de leitura. Os arquivos ORC também são colunares, tornando-os adequados para consultas de SELECT que recuperam apenas colunas específicas.

# Simple SELECT query on ORC file

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

2. Consultas de filtragem

• Parquet: O Parquet manteve sua vantagem de desempenho devido à sua natureza em colunas e a capacidade de pular colunas irrelevantes rapidamente. No entanto, o desempenho foi ligeiramente afetado pela necessidade de scanner mais linhas para aplicar filtros.

# Filter query on Parquet file

filtered_parquet_df = parquet_df.filter(parquet_df.column1 == 'some_value')

filtered_parquet_df.show()

• Avro:O desempenho diminuiu ainda mais devido à necessidade de ler linhas inteiras e aplicar filtros em todas as colunas, aumentando o tempo de processamento.

-- Filter query on Avro file in Hive

SELECT * FROM avro_table WHERE column1 = 'some_value';

• ORC:Este superou o Parquet ligeiramente em consultas de filtro devido à sua funcionalidade de pushdown de predicado, que permite o filtrado diretamente no nível de armazenamento antes que os dados sejam carregados na memória.

# Filter query on ORC file

filtered_orc_df = orc_df.filter(orc_df.column1 == 'some_value')

filtered_orc_df.show()

3. Consultas de Agregação

• Parquet:O Parquet teve um bom desempenho, mas não tão eficiente quanto o ORC. O formato colunar beneficia as operações de agregação ao acessar rapidamente as colunas necessárias, mas o Parquet carece de algumas optimizações embutidas que o ORC oferece.

# Aggregation query on Parquet file

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

agg_parquet_df.show()

• Avro:O Avro ficou atrás devido ao seu armazenamento baseado em linhas, que exigiu que cada linha fosse escaneada e processada em todas as colunas, aumentando a sobrecarga computacional.

-- Aggregation query on Avro file in Hive

SELECT column1, SUM(column2), AVG(column3) FROM avro_table GROUP BY column1;

• ORC:O ORC superou ambos o Parquet e o Avro em consultas de agregação. O índice avançado e os algoritmos de compressão embutidos do ORC permitiram um acesso a dados mais rápido e redução de operações de E/S, tornando-o altamente adequado para tarefas de agregação.

# Aggregation query on ORC file

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

agg_orc_df.show()

4. Consultas de Junção

• Parquet:O Parquet teve um bom desempenho, mas não tão eficiente quanto o ORC em operações de junção devido à sua leitura de dados menos otimizada para as condições de junção.

# Join query between Parquet and ORC files

joined_df = parquet_df.join(orc_df, parquet_df.key == orc_df.key)

joined_df.show()

• ORC:O ORC excelente nas consultas de junção, beneficiando de índices avançados e capacidades de pushdown de predicado, que minimizaram o escaneamento e o processamento de dados durante as operações de junção.

# 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 teve dificuldades significativas com operações de união, principalmente devido ao alto custo de leitura de linhas inteiras e a falta de otimizações colunares para chaves de união.

-- 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;

Impacto do Formato de Armazenamento nos Custos

1. Eficiência de Armazenamento e Custo

• Parquet e ORC (formatos colunares)
  • Compressão e custo de armazenamento: Ambos o Parquet e o ORC são formatos de armazenamento colunares que oferecem altas taxas de compressão, especialmente para conjuntos de dados com muitos valoresrepetidos ou semelhantes dentro de colunas. Esta alta compressão reduce o tamanho de dados geral, o que por sua vez reduz o custo de armazenamento, particularmente em ambientes na nuvem onde o armazenamento é cobrado por GB.
  • Otimizado para cargas de trabalho de análise: Devido à sua natureza colunar, esses formatos são ideais para cargas de trabalho de análise onde apenas colunas específicas são frequentemente consultadas. Isso significa que menos dados são lidos do armazenamento, reduzindo ambas as operações de E/S e seus custos associados.
• Avro (formato baseado em linhas)
  • Custo de compressão e armazenamento: O Avro normalmente oferece taxas de compressão inferiores a formatos de coluna, como Parquet e ORC, pois armazena dados linha por linha. Isso pode resultar em custos de armazenamento superiores, principalmente para conjuntos de dados grandes com muitas colunas, já que todos os dados de uma linha devem ser lidos, mesmo que somente algumas colunas sejam necessárias.
  • Melhor para cargas de trabalho com elevada gravação: Apesar do Avro poder resultar em custos de armazenamento superiores por ter baixas taxas de compressão, ele é melhor adaptado para cargas de trabalho com elevada gravação onde dados estão sendo gravados ou acrescidos contínuamente. Os custos associados a armazenamento podem ser compensados pelos ganhos de eficiência na serialização e deserialização de dados.

2. Performance e custo de processamento de dados

• Parquet e ORC (formatos colunares)
  • Custos de processamento reduzidos: Esses formatos são otimizados para operações com alto volume de leitura, o que os torna altamente eficientes para consultar grandes conjuntos de dados. Como permitem a leitura apenas das colunas relevantes necessárias para uma consulta, reduzem a quantidade de dados processados. Isso leva a um menor uso de CPU e a tempos de execução de consultas mais rápidos, o que pode reduzir significativamente os custos computacionais em um ambiente de nuvem onde os recursos são cobrados com base no uso.
  • Recursos avançados para otimização de custos: ORC, em particular, inclui recursos como “predicate push-down” e estatísticas embutidas, que permitem ao mecanismo de consulta ignorar a leitura de dados desnecessários. Isso reduz ainda mais as operações de E/S e acelera o desempenho da consulta, otimizando os custos.
• Avro (formatos baseados em linhas)
  • Custos de processamento superiores: Como o Avro é um formato baseado em linhas, ele normalmente requer mais operações de E/S para ler linhas inteiras mesmo que apenas algumas colunas sejam necessárias. Isso pode resultar em custos de processamento aumentados devido ao maior uso de CPU e a execuções de consultas mais longas, especialmente em ambientes com elevado volume de leitura.
  • Eficiente para streaming e serialização: Apesar dos custos de processamento superiores para consultas, o Avro é bem adequado para tarefas de streaming e serialização onde a velocidade de gravação rápida e a evolução do esquema são mais críticas.

3. Análise de Custo com detalhes de Preços

• Para quantificar o impacto de custo de cada formato de armazenamento, nós realizamos um experimento usando o GCP. Nós calcularmos os custos associados com ambos o armazenamento e o processamento de dados para cada formato com base nos modelos de preços do GCP.
• Custos de armazenamento do Google Cloud
  • Custo de armazenamento: Este é calculado com base na quantidade de dados armazenados em cada formato. O GCP cobra por GB por mês para dados armazenados no Google Cloud Storage. As taxas de compressão alcançadas por cada formato afetam diretamente estes custos. Formatos de coluna, como Parquet e ORC, normalmente têm melhores taxas de compressão do que formatos baseados em linhas, como Avro, resultando em custos de armazenamento mais baixos.
  • Aqui está um exemplo de como os custos de armazenamento foram calculados:
    • Parquet: A alta compressão resultou na redução do tamanho dos dados, abaixando o custo de armazenamento
    • ORC: Similarmente ao Parquet, a compressão avançada do ORC também reduziu eficientemente os custos de armazenamento
    • Avro: A eficiência baixa de compressão resultou em custos de armazenamento maiores em comparação com o Parquet e o ORC

# 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")

• Custos de processamento de dados
  • Os custos de processamento de dados foram calculados com base nas recursos de computação necessários para executar várias consultas usando Dataproc no GCP. O GCP cobra por uso de dataproc com base no tamanho do cluster e na duração para a qual os recursos são usados.
  • Custos de computação:
    • Parquet e ORC: Devido a seu armazenamento colunar eficiente, esses formatos reduziram a quantidade de dados lidos e processados, resultando em custos de computação mais baixos. As execuções de consulta mais rápidas também contribuíram para os economizados, especialmente para consultas complexas envolvendo grandes conjuntos de dados.
    • Avro: Avro exigiu mais recursos de computação devido ao formato de linhas, o que aumentou a quantidade de dados lidos e processados. Isto resultou em custos maiores, particularmente para operações de leitura intensiva.

Conclusão

A escolha do formato de armazenamento em ambientes de big data impacta significativamente tanto a performance de consulta quanto o custo. O estudo e os experimentos acima demonstram os seguintes pontos chave:

1. Parquet e ORC: Estes formatos de coluna fornecem excelente compressão, reduzindo os custos de armazenamento. Sua capacidade de ler somente as colunas necessárias melhora consideravelmente a performance de consulta e reduz os custos de processamento de dados. ORC supera ligeiramente Parquet em certos tipos de consultas devido às suas características de índice avançadas e melhorias, tornando-o uma excelente escolha para cargas de trabalho mistas que exigem tanto alto desempenho de leitura quanto de gravação.
2. Avro: Embora Avro não seja tão eficiente em termos de compressão e performance de consulta quanto Parquet e ORC, ele se destaca em casos de uso que exigem operações de gravação rápidas e evolução de esquema. Este formato é ideal para situações que envolvam serialização de dados e streaming, onde a performance de gravação e a flexibilidade são priorizadas sobre a eficiência de leitura.
3. Eficiência de custo: Em um ambiente cloud como o GCP, onde os custos estão intimamente ligados à utilização de armazenamento e computação, escolher o formato correto pode resultar em grandes economias. Para cargas de trabalho de análise que são predominantemente pesadas na leitura, Parquet e ORC são as opções mais econômicas. Para aplicações que exigem ingestão de dados rápida e gerenciamento de esquema flexível, Avro é uma escolha adequada apesar de seus custos de armazenamento e computação superiores.

Recomendações

Baseado em nossa análise, recomendamos o seguinte:

1. Para cargas de trabalho analíticas com forte leitura: Use Parquet ou ORC. Esses formatos oferecem desempenho e eficiência de custo superiores devido à alta compressão e desempenho de consulta otimizado.
2. Para cargas de trabalho com forte escrita e serialização: Use Avro. Ele é melhor adequado para cenários onde escrita rápida e evolução de esquema são críticos, como em streaming de dados e sistemas de mensagens.
3. Para cargas de trabalho mistas: ORC oferece desempenho equilibrado para operações de leitura e escrita, tornando-se uma escolha ideal para ambientes onde as cargas de trabalho de dados variam.

Pensamentos Finais

Selecionar o formato de armazenamento certo para ambientes de big data é crucial para otimizar o desempenho e o custo. Entender as forças e as fraquezas de cada formato permite que os engenheiros de dados personalizem sua arquitetura de dados para casos de uso específicos, maximizando a eficiência e minimizando despesas. À medida que os volumes de dados continuam a crescer, tomar decisões informadas sobre formatos de armazenamento se tornará cada vez mais importante para manter soluções de dados escaláveis e eficientes em termos de custo.

Ao avaliar cuidadosamente as medições de desempenho e as implicações de custo apresentadas neste artigo, as organizações podem escolher o formato de armazenamento que melhor alinha com suas necessidades operacionais e objetivos financeiros.