Parquet vs ORC vs ORC avec Snappy

87

J'exécute quelques tests sur les formats de stockage disponibles avec Hive et j'utilise Parquet et ORC comme options principales. J'ai inclus ORC une fois avec la compression par défaut et une fois avec Snappy.

J'ai lu de nombreux documents qui déclarent que Parquet est meilleur en complexité temps / espace par rapport à ORC, mais mes tests sont opposés aux documents que j'ai parcourus.

Suit quelques détails de mes données.

Table A- Text File Format- 2.5GB

Table B - ORC - 652MB

Table C - ORC with Snappy - 802MB

Table D - Parquet - 1.9 GB

Le parquet était pire en ce qui concerne la compression de ma table.

Mes tests avec les tableaux ci-dessus ont donné les résultats suivants.

Opération de comptage de lignes

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

Somme d'une opération de colonne

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

Moyenne d'une opération de colonne

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

Sélection de 4 colonnes dans une plage donnée à l'aide de la clause 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

Cela signifie-t-il que ORC est plus rapide que Parquet? Ou puis-je faire quelque chose pour que cela fonctionne mieux avec le temps de réponse des requêtes et le taux de compression?

Merci!

hadoop  hive  parquet  snappy  orc 
— Rahul
source
1
Pourriez-vous partager un algorithme générique utilisé pour faire cette expérience? Il est cependant nécessaire d'utiliser les mêmes données. Mais partager tout le reste pour obtenir les mêmes résultats avec différents ensembles de données peut être très utile pour vous donner une meilleure réponse ou pour prouver que vous avez un très bon point et pour changer le monde pour toujours.
— Mestre San
avez-vous des résultats Spark vs Tez en utilisant orc vs parquet? d'après ce que j'ai vu, il semble que tez soit plus rapide (3 fois plus rapide) lors de l'utilisation du format orc.
— David H
+ 1 pour votre belle vue d'ensemble. Quoi qu'il en soit, y a-t-il une chance que vous puissiez fournir une version mise à jour puisque certains aspects techniques dans les coulisses ont changé (par exemple, comme discuté dans la réponse de @jonathanChap)?
— Markus

Réponses:

52

Je dirais que ces deux formats ont leurs propres avantages.

Parquet pourrait être mieux si vous avez des données hautement imbriquées, car il stocke ses éléments sous forme d'arborescence comme le fait Google Dremel ( voir ici ).
Apache ORC pourrait être meilleur si votre structure de fichiers est aplatie.

Et pour autant que je sache, le parquet ne prend pas encore en charge les index. ORC est livré avec un index léger et depuis Hive 0.14 un filtre Bloom supplémentaire qui pourrait être utile pour améliorer le temps de réponse aux requêtes, en particulier lorsqu'il s'agit d'opérations de somme.

La compression par défaut de Parquet est SNAPPY. Les tableaux A - B - C et D contiennent-ils le même ensemble de données? Si oui, il semble qu'il y ait quelque chose de louche à ce sujet, quand il ne se compresse qu'à 1,9 Go

— PhanThomas
source
2
Tableau A - Format de fichier texte - Pas de compression ......... Tableau B - Format de fichier ORC avec compression ZLIB ......... Tableau C - ORC avec Snappy ....... Tableau D - Parquet avec Snappy ..... J'ai travaillé sur une autre table avec ~ 150 colonnes et ~ 160 Go de taille pour vérifier comment les formats de fichiers y fonctionnent. Parquet a pris 35 Go pour stocker ces 160 Go de données tandis que ORC avec Snappy a pris 39 Go ...... La compression semblait bien meilleure pour Parquet par rapport au test publié en question, mais les performances étaient à nouveau similaires. ORC a brillé ici avec même meilleures performances que la combinaison ORC + SNAPPY.
— Rahul
1
La structure de données pour mes cas d'utilisation était plus plate sans aucune imbrication. Je suis d'accord avec votre commentaire d'indexation sur Parquet vs ORC et cela fait une différence en fait. Avez-vous des résultats à partager de la comparaison des performances des deux? Cela pourrait aider à calmer ma conscience que j'implémente correctement les formats. :)
— Rahul
Je n'ai jamais testé mon ensemble de données sur Parquet car l'index était une exigence nécessaire et nous avons également une structure de données plate sans informations imbriquées. Ce que j'ai compris, c'est que selon l'endroit où vous stockez vos fichiers, vous avez besoin d'une bande et d'une taille de fichier différentes pour obtenir les meilleurs résultats. Lorsque vous stockez vos fichiers en permanence sur HDFS, il est préférable d'avoir des fichiers et des bandes plus volumineux. "set mapred.max.split.size = 4096000000" était le paramètre que j'ai utilisé pour influencer la taille du fichier et a laissé la taille de la bande à sa valeur par défaut. Avec ce paramètre, cela m'a donné environ 94% de requête et de compression.
— PhanThomas
Si vous souhaitez stocker vos fichiers sur Amazon S3 en tant que stockage à froid, une taille de fichier et de bande plus petite m'a donné de bien meilleurs résultats. J'ai utilisé des fichiers de 40 à 60 Mo contenant une seule bande.
— PhanThomas
44

Vous voyez cela parce que:

  • Hive dispose d'un lecteur ORC vectorisé mais pas de lecteur de parquet vectorisé.

  • Spark possède un lecteur de parquet vectorisé et aucun lecteur ORC vectorisé.

  • Spark fonctionne mieux avec du parquet, la ruche fonctionne mieux avec ORC.

J'ai vu des différences similaires lors de l'exécution d'ORC et de Parquet avec Spark.

La vectorisation signifie que les lignes sont décodées par lots, améliorant considérablement la localisation de la mémoire et l'utilisation du cache.

(correct à partir de Hive 2.0 et Spark 2.1)

— JonathanChap
source
18
A partir de 2.3.0, étincelle ne possède un lecteur ORC vectorisé: issues.apache.org/jira/browse/SPARK-16060
— Steen
6
Hive 2.3.0 a vectorisé Parquet reader - issues.apache.org/jira/browse/HIVE-14815
— ruhong
Depuis Spark 2.3, Spark prend en charge un lecteur ORC vectorisé spark.apache.org/docs/latest/sql-data-sources-orc.html
— Anurag Sharma
10

Parquet et ORC ont leurs propres avantages et inconvénients. Mais j'essaie simplement de suivre une règle empirique simple - "Comment vos données sont-elles imbriquées et combien de colonnes sont-elles présentes" . Si vous suivez le Google Dremel, vous pouvez découvrir comment le parquet est conçu. Ils utilisent une structure arborescente hiérarchique pour stocker des données. Plus la nidification est plus profonde dans l'arbre.

Mais ORC est conçu pour un magasin de fichiers aplati. Donc, si vos données sont aplaties avec moins de colonnes, vous pouvez utiliser ORC, sinon, le parquet vous conviendra. La compression sur des données aplaties fonctionne à merveille dans ORC.

Nous avons effectué des analyses comparatives avec un fichier aplati plus volumineux, l'avons converti en Spark Dataframe et l'avons stocké au format parquet et ORC dans S3 et avons interrogé avec ** 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.

Bientôt, nous ferons une analyse comparative des données imbriquées et mettrons à jour les résultats ici.

— james.bondu
source
6

Nous avons fait un benchmark comparant les différents formats de fichiers (Avro, JSON, ORC et Parquet) dans différents cas d'utilisation.

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

Les données sont toutes accessibles au public et le code de référence est entièrement open source à:

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

— Owen O'Malley
source
5
C'est vraiment utile, mais il devrait y avoir une clause de non-responsabilité selon laquelle @Owen fonctionne pour Horton Works, qui a initialement développé le format de fichier ORC
— Daniel Kats
1
Merci! Mais le deuxième lien est rompu. Pouvez-vous le corriger ou le supprimer de votre réponse?
— Danilo Gomes
3

Les deux ont leurs avantages. Nous utilisons Parquet en collaboration avec Hive et Impala, mais nous voulions juste souligner quelques avantages d'ORC par rapport à Parquet: lors de requêtes à exécution longue, lorsque Hive interroge les tables ORC, GC est appelé environ 10 fois moins fréquemment . Peut-être rien pour de nombreux projets, mais peut être crucial pour d'autres.

ORC prend également beaucoup moins de temps, lorsque vous devez sélectionner seulement quelques colonnes dans le tableau. Certaines autres requêtes, en particulier avec les jointures, prennent également moins de temps en raison de l'exécution de requêtes vectorisées, qui n'est pas disponible pour Parquet

De plus, la compression ORC est parfois un peu aléatoire, tandis que la compression Parquet est beaucoup plus cohérente. Cela ressemble à quand la table ORC a de nombreuses colonnes numériques - elle ne se compresse pas non plus. Il affecte à la fois zlib et la compression snappy

— Hasan Ammori
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.