Parquet vs ORC vs ORC avec Snappy
J'effectue quelques tests sur les formats de stockage disponibles avec Hive et 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 dans lesquels il est dit que Parquet est plus complexe en temps et en espace que ORC, mais mes tests sont inversés par rapport aux documents que j'ai passés.
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 pour 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 d'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 à la requête et le taux de compression?
Merci!
Je dirais que ces deux formats ont leurs propres avantages.
Le parquet peut être préférable si vous avez des données hautement imbriquées, car il stocke ses éléments comme un arbre, comme le fait Google Dremel ( Voir ici ).
Apache ORC pourrait être mieux si votre structure de fichier est aplatie.
Et pour autant que je sache, le parquet ne supporte pas encore Index. ORC est livré avec un index léger et, depuis Hive 0.14, un filtre de Bloom supplémentaire qui pourrait être utile pour améliorer le temps de réponse aux requêtes, en particulier pour les opérations de somme.
La compression par défaut du parquet est SNAPPY. Les tableaux A - B - C et D contiennent-ils le même jeu de données? Si oui, il semble y avoir quelque chose de louche, quand il compresse seulement à 1,9 GB
Vous voyez cela parce que:
Hive a un lecteur ORC vectorisé mais pas de lecteur de parquet vectorisé.
Spark a un lecteur de parquet vectorisé et aucun lecteur ORC vectorisé.
Spark fonctionne mieux avec du parquet, Hive fonctionne mieux avec ORC.
J'ai vu des différences similaires lors de l'exécution de ORC et de Parquet avec Spark.
La vectorisation signifie que les lignes sont décodées par lots, ce qui améliore considérablement l'emplacement de la mémoire et l'utilisation du cache.
(correct à partir de Hive 2.0 et Spark 2.1)
Nous avons comparé 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 une source ouverte sur:
Les deux ont leurs avantages. Nous utilisons Parquet au travail avec Hive et Impala, mais nous voulions simplement souligner quelques avantages d’ORC par rapport à Parquet: lors de requêtes longues, lorsque les requêtes Hive interrogent des tables ORC GC est appelé environ 10 fois moins souvent . Pourrait être rien pour de nombreux projets, mais pourrait être crucial pour les autres.
ORC prend également beaucoup moins de temps lorsque vous devez sélectionner quelques colonnes de la table. Certaines autres requêtes, notamment avec des 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, alors que la compression Parquet est beaucoup plus cohérente. Cela ressemble à quand la table ORC a beaucoup de colonnes numériques - elle ne se compresse pas aussi bien. Il affecte à la fois la compression zlib et snappy
Parquet et ORC ont leurs propres avantages et inconvénients. Mais j'essaie simplement de suivre une simple règle empirique - "Comment vos données sont-elles imbriquées et combien de colonnes y at-il" . Si vous suivez les instructions de Google Dremel , vous découvrirez comment le parquet est conçu. Ils utilisent une structure hiérarchique en forme d'arborescence pour stocker les données. Plus la nidification est profonde dans l'arbre.
MaisORCest 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 conviendrait parfaitement. La compression sur des données aplaties fonctionne à merveille dans ORC.
Nous avons procédé à des analyses comparatives avec un fichier aplati plus volumineux, l'avons converti en Dataframe et l'avons stocké au format parquet et ORC dans S3 et avons interrogé ** 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.
Nous effectuerons bientôt des analyses comparatives des données imbriquées et mettrons à jour les résultats ici.