Parquet vs ORC vs ORC com Snappy

87

Estou executando alguns testes nos formatos de armazenamento disponíveis com Hive e usando Parquet e ORC como opções principais. Eu incluí ORC uma vez com compressão padrão e uma vez com Snappy.

Eu li muitos documentos que afirmam que o Parquet é melhor em complexidade de tempo / espaço em comparação ao ORC, mas meus testes são opostos aos documentos que examinei.

Segue alguns detalhes dos meus dados.

Table A- Text File Format- 2.5GB

Table B - ORC - 652MB

Table C - ORC with Snappy - 802MB

Table D - Parquet - 1.9 GB

Parquet foi o pior no que diz respeito à compressão da minha mesa.

Meus testes com as tabelas acima produziram os seguintes resultados.

Operação de contagem de linha

Text Format Cumulative CPU - 123.33 sec

Parquet Format Cumulative CPU - 204.92 sec

ORC Format Cumulative CPU - 119.99 sec 

ORC with SNAPPY Cumulative CPU - 107.05 sec

Soma de uma operação de coluna

Text Format Cumulative CPU - 127.85 sec   

Parquet Format Cumulative CPU - 255.2 sec   

ORC Format Cumulative CPU - 120.48 sec   

ORC with SNAPPY Cumulative CPU - 98.27 sec

Média de uma operação de coluna

Text Format Cumulative CPU - 128.79 sec

Parquet Format Cumulative CPU - 211.73 sec    

ORC Format Cumulative CPU - 165.5 sec   

ORC with SNAPPY Cumulative CPU - 135.45 sec

Seleção de 4 colunas de um determinado intervalo usando a cláusula where

Text Format Cumulative CPU -  72.48 sec 

Parquet Format Cumulative CPU - 136.4 sec       

ORC Format Cumulative CPU - 96.63 sec 

ORC with SNAPPY Cumulative CPU - 82.05 sec

Isso significa que o ORC é mais rápido que o Parquet? Ou há algo que posso fazer para que funcione melhor com o tempo de resposta da consulta e a taxa de compactação?

Obrigado!

hadoop  hive  parquet  snappy  orc 
— Rahul
fonte
1
Você poderia compartilhar um algoritmo genérico usado para fazer esse experimento? É necessário usar os mesmos dados, no entanto. Mas compartilhar tudo o mais para obter os mesmos resultados com conjuntos de dados diferentes pode ser muito útil para lhe dar uma resposta melhor ou para provar que você tem um ponto muito bom e para mudar o mundo para sempre.
— Mestre San
você tem algum resultado de spark vs tez usando orc vs parquet? pelo que vi, parece que o tez é mais rápido (3 vezes mais rápido) ao usar o formato orc.
— David H
+ 1 para uma boa visão geral do benchmarking. De qualquer forma, há uma chance de você fornecer uma versão atualizada, visto que alguns aspectos técnicos nos bastidores mudaram (por exemplo, como discutido na resposta de @jonathanChap)?
— Markus

Respostas:

52

Eu diria que ambos os formatos têm suas próprias vantagens.

Parquet pode ser melhor se você tiver dados altamente aninhados, porque ele armazena seus elementos como uma árvore como o Google Dremel faz ( veja aqui ).
O Apache ORC pode ser melhor se sua estrutura de arquivos for simplificada.

E, pelo que eu sei, o parquet ainda não suporta índices. ORC vem com um índice leve e desde Hive 0.14 um filtro Bloom adicional que pode ser útil para melhorar o tempo de resposta da consulta, especialmente quando se trata de operações de soma.

A compressão padrão do Parquet é SNAPPY. As tabelas A - B - C e D contêm o mesmo conjunto de dados? Se sim, parece que há algo obscuro sobre isso, quando ele é compactado apenas para 1,9 GB

— PhanThomas
fonte
2
Tabela A - Formato de arquivo de texto - Sem compactação ......... Tabela B - Formato de arquivo ORC com compactação ZLIB ......... Tabela C - ORC com Snappy ....... Tabela D - Parquet com Snappy ..... Trabalhei em outra mesa com ~ 150 colunas e ~ 160 GB de tamanho para verificar o desempenho dos formatos de arquivo lá. Parquet levou 35 GB para armazenar os dados de 160 GB, enquanto ORC com snappy levou 39 GB ...... A compressão parecia muito melhor para Parquet em comparação com o teste postado em questão, mas o desempenho estava novamente em linhas semelhantes. ORC brilhou aqui com mesmo melhor desempenho do que a combinação ORC + SNAPPY.
— Rahul,
1
A estrutura de dados para meus casos de uso era mais plana, sem qualquer aninhamento. Eu concordo com seu comentário de indexação em Parquet vs ORC e ​​isso faz a diferença, na verdade. Você tem algum resultado para compartilhar da comparação de desempenho de ambos? Isso pode ajudar a acalmar minha consciência de que estou implementando os formatos corretamente. :)
— Rahul
Nunca testei meu conjunto de dados no Parquet porque o índice era um requisito necessário e também temos uma estrutura de dados plana sem informações aninhadas. O que descobri é que, dependendo de onde você armazena seus arquivos, você precisa de uma faixa e um tamanho de arquivo diferentes para obter os melhores resultados. Quando você armazena seus arquivos permanentemente no HDFS, é melhor ter arquivos maiores e faixas. "set mapred.max.split.size = 4096000000" foi o parâmetro que usei para influenciar o tamanho do arquivo e deixei o tamanho da faixa com seu valor padrão. Com essa configuração, obtive cerca de 94% de aumento de consulta e compressão.
— PhanThomas,
Se você deseja armazenar seus arquivos no Amazon S3 como um armazenamento frio, um arquivo bem menor e tamanho de faixa me deu resultados muito melhores. Usei arquivos do tamanho de 40-60 MB contendo uma única faixa.
— PhanThomas,
44

Você está vendo isso porque:

  • O Hive tem um leitor ORC vetorizado, mas nenhum leitor de parquete vetorizado.

  • O Spark tem um leitor de parquete vetorizado e nenhum leitor ORC vetorizado.

  • Spark tem melhor desempenho com parquete, hive tem melhor desempenho com ORC.

Eu vi diferenças semelhantes ao executar ORC e ​​Parquet com Spark.

Vetorização significa que as linhas são decodificadas em lotes, melhorando drasticamente a localização da memória e a utilização do cache.

(correto a partir do Hive 2.0 e Spark 2.1)

— JonathanChap
fonte
18
A partir de 2.3.0, faísca não tiver um leitor de ORC vetorizado: issues.apache.org/jira/browse/SPARK-16060
— Steen
6
O Hive 2.3.0 vetorizou o
— ruhong
Desde o Spark 2.3, o Spark oferece suporte a um leitor ORC vetorizado spark.apache.org/docs/latest/sql-data-sources-orc.html
— Anurag Sharma
10

Ambos Parquet e ORC têm suas próprias vantagens e desvantagens. Mas eu simplesmente tento seguir uma regra prática simples - "Quão aninhados estão seus dados e quantas colunas existem" . Se você seguir o Dremel do Google, poderá descobrir como o parquet é projetado. Eles usam uma estrutura semelhante a uma árvore hierárquica para armazenar dados. Mais o aninhamento mais profundo na árvore.

Mas o ORC foi projetado para um armazenamento de arquivos simplificado. Portanto, se seus dados forem nivelados com menos colunas, você pode usar ORC, caso contrário, o parquet seria adequado para você. A compactação em dados nivelados funciona de maneira incrível no ORC.

Fizemos alguns benchmarking com um arquivo maior achatado, convertido para spark Dataframe e armazenamos em ambos os formatos parquet e ORC no S3 e fez consultas com ** Redshift-Spectrum **.

Size of the file in parquet: ~7.5 GB and took 7 minutes to write
Size of the file in ORC: ~7.1. GB and took 6 minutes to write
Query seems faster in ORC files.

Em breve, faremos alguns benchmarking para dados aninhados e atualizaremos os resultados aqui.

— james.bondu
fonte
6

Fizemos alguns benchmarks comparando os diferentes formatos de arquivo (Avro, JSON, ORC e ​​Parquet) em diferentes casos de uso.

https://www.slideshare.net/oom65/file-format-benchmarks-avro-json-orc-parquet

Os dados estão todos disponíveis publicamente e o código de referência é totalmente de código aberto em:

https://github.com/apache/orc/tree/branch-1.4/java/bench

— Owen O'Malley
fonte
5
Isso é realmente útil, mas deve haver um aviso de que @Owen trabalha para Horton Works, que desenvolveu originalmente o formato de arquivo ORC
— Daniel Kats
1
Obrigado! Mas o segundo link está quebrado. Você pode corrigir ou remover de sua resposta?
— Danilo Gomes
3

Ambos têm suas vantagens. Usamos Parquet no trabalho junto com o Hive e o Impala, mas só queríamos apontar algumas vantagens do ORC sobre o Parquet: durante consultas de longa execução, quando o Hive consulta as tabelas ORC, o GC é chamado cerca de 10 vezes menos frequentemente . Pode não ser nada para muitos projetos, mas pode ser crucial para outros.

O ORC também leva muito menos tempo, quando você precisa selecionar apenas algumas colunas da tabela. Algumas outras consultas, especialmente com joins, também levam menos tempo por causa da execução de consulta vetorizada, que não está disponível para Parquet

Além disso, a compressão ORC às vezes é um pouco aleatória, enquanto a compressão Parquet é muito mais consistente. Parece que quando a tabela ORC tem muitas colunas numéricas - ela também não compacta. Afeta a compressão zlib e rápida

— Hasan Ammori
fonte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.