Quels sont les avantages et les inconvénients du format parquet par rapport aux autres formats?

Les caractéristiques d'Apache Parquet sont:

• Auto-descriptif
• Format en colonne
• Indépendant de la langue

En comparaison avec Avro, les fichiers de séquence, les fichiers RC, etc. je veux un aperçu des formats. J'ai déjà lu: Comment Impala fonctionne avec les formats de fichiers Hadoop , cela donne quelques aperçus sur les formats mais j'aimerais savoir comment l'accès aux données et le stockage des données se font dans chacun de ces formats. En quoi le parquet a-t-il un avantage sur les autres?

Je pense que la principale différence que je peux décrire concerne les formats orientés enregistrement et orientés colonnes. Les formats orientés enregistrement sont ce à quoi nous sommes tous habitués: fichiers texte, formats délimités comme CSV, TSV. AVRO est légèrement plus cool que ceux-ci car il peut changer de schéma au fil du temps, par exemple en ajoutant ou en supprimant des colonnes d'un enregistrement. D'autres astuces de divers formats (notamment la compression) impliquent de savoir si un format peut être divisé - c'est-à-dire, pouvez-vous lire un bloc d'enregistrements à partir de n'importe où dans l'ensemble de données et toujours connaître son schéma? Mais voici plus de détails sur les formats en colonnes comme Parquet.

Le parquet et les autres formats en colonnes gèrent très efficacement une situation Hadoop courante. Il est courant d'avoir des tables (ensembles de données) ayant beaucoup plus de colonnes que ce à quoi on pourrait s'attendre dans une base de données relationnelle bien conçue - cent ou deux cents colonnes n'est pas inhabituel. En effet, nous utilisons souvent Hadoop comme un endroit pour dénormaliser les données à partir de formats relationnels - oui, vous obtenez beaucoup de valeurs répétées et de nombreuses tables, toutes aplaties en une seule. Mais il devient beaucoup plus facile d'interroger puisque toutes les jointures sont élaborées. Il existe d'autres avantages tels que la conservation des données d'état dans le temps. Donc, de toute façon, il est courant d'avoir une cargaison de colonnes dans une table.

Disons qu'il y a 132 colonnes, et certaines d'entre elles sont de très longs champs de texte, chaque colonne différente se succédant et utilisant peut-être 10K par enregistrement.

Bien que l'interrogation de ces tables soit facile avec le point de vue SQL, il est courant que vous souhaitiez obtenir une plage d'enregistrements basée sur seulement quelques-unes de ces centaines de colonnes. Par exemple, vous pouvez souhaiter tous les enregistrements de février et mars pour les clients dont les ventes sont supérieures à 500 USD.

Pour ce faire dans un format de ligne, la requête doit analyser chaque enregistrement de l'ensemble de données. Lisez la première ligne, analysez l'enregistrement en champs (colonnes) et obtenez les colonnes de date et de ventes, incluez-le dans votre résultat s'il remplit la condition. Répéter. Si vous avez 10 ans (120 mois) d'histoire, vous lisez chaque enregistrement juste pour trouver 2 de ces mois. Bien sûr, c'est une excellente occasion d'utiliser une partition par année et par mois, mais malgré cela, vous lisez et analysez 10K de chaque enregistrement / ligne pendant ces deux mois juste pour déterminer si les ventes du client sont> 500 $.

Dans un format en colonnes, chaque colonne (champ) d'un enregistrement est stockée avec d'autres de son type, réparties sur de nombreux blocs différents sur le disque - colonnes pour l'année ensemble, colonnes pour le mois ensemble, colonnes pour le manuel de l'employé client (ou autre long texte), et tous les autres qui rendent ces enregistrements si énormes, tous à leur place sur le disque, et bien sûr des colonnes pour les ventes ensemble. Eh bien, la date et les mois sont des chiffres, tout comme les ventes - ce ne sont que quelques octets. Ne serait-il pas formidable de ne lire que quelques octets pour chaque enregistrement pour déterminer quels enregistrements correspondent à notre requête? Stockage en colonne à la rescousse!

Même sans partitions, l'analyse des petits champs nécessaires pour satisfaire notre requête est ultra-rapide - ils sont tous classés par enregistrement, et tous de la même taille, de sorte que le disque recherche beaucoup moins de données pour vérifier les enregistrements inclus. Pas besoin de lire ce manuel de l'employé et d'autres longs champs de texte - ignorez-les simplement. Ainsi, en regroupant les colonnes les unes avec les autres, au lieu de lignes, vous pouvez presque toujours analyser moins de données. Gagner!

Mais attendez, il ya mieux. Si votre requête n'avait besoin que de connaître ces valeurs et quelques autres (disons 10 des 132 colonnes) et qu'elle ne se souciait pas de cette colonne du manuel de l'employé, une fois qu'elle avait sélectionné les bons enregistrements à renvoyer, elle n'aurait plus qu'à aller retour aux 10 colonnes dont il avait besoin pour rendre les résultats, ignorant les 122 autres des 132 dans notre ensemble de données. Encore une fois, nous sautons beaucoup de lecture.

(Remarque: pour cette raison, les formats en colonnes sont un mauvais choix lorsque vous effectuez des transformations directes, par exemple, si vous joignez les deux tables en un seul grand ensemble de résultats (ger) que vous enregistrez en tant que nouvelle table, les sources vont être analysés complètement de toute façon, il n'y a donc pas beaucoup d'avantages en termes de performances de lecture, et comme les formats en colonnes doivent se souvenir davantage de l'endroit où se trouvent les choses, ils utilisent plus de mémoire qu'un format de ligne similaire).

Un autre avantage de la colonne: les données sont réparties. Pour obtenir un seul enregistrement, vous pouvez avoir 132 travailleurs chacun lisant (et écrivant) des données de / vers 132 emplacements différents sur 132 blocs de données. Yay pour la parallélisation!

Et maintenant pour le clincher: les algorithmes de compression fonctionnent beaucoup mieux lorsqu'ils peuvent trouver des motifs répétitifs. Vous pourriez compresser AABBBBBBCCCCCCCCCCCCCCCCcomme 2A6B16Cmais ABCABCBCBCBCCCCCCCCCCCCCCne serait pas aussi petit (enfin, en fait, dans ce cas, mais croyez-moi :-)). Donc encore une fois, moins de lecture. Et l'écriture aussi.

Nous lisons donc beaucoup moins de données pour répondre aux requêtes courantes, il est potentiellement plus rapide de lire et d'écrire en parallèle et la compression a tendance à bien mieux fonctionner.

Columnar est génial lorsque votre côté d'entrée est grand et que votre sortie est un sous-ensemble filtré: du grand au petit est super. Pas aussi avantageux lorsque les entrées et les sorties sont à peu près les mêmes.

Mais dans notre cas, Impala a pris nos anciennes requêtes Hive qui ont duré 5, 10, 20 ou 30 minutes, et ont terminé la plupart en quelques secondes ou une minute.

J'espère que cela aidera à répondre au moins à une partie de votre question!

Avro est un format de stockage basé sur des lignes pour Hadoop.

Parquet est un format de stockage basé sur des colonnes pour Hadoop.

Si votre cas d'utilisation scanne ou récupère généralement tous les champs d'une ligne dans chaque requête, Avro est généralement le meilleur choix.

Si votre ensemble de données comporte de nombreuses colonnes et que votre cas d'utilisation implique généralement de travailler avec un sous-ensemble de ces colonnes plutôt qu'avec des enregistrements entiers, Parquet est optimisé pour ce type de travail.

La source

La réponse de Tom est assez détaillée et exhaustive, mais vous pourriez également être intéressé par cette simple étude sur Parquet vs Avro réalisée chez Allstate Insurance, résumée ici:

"Dans l'ensemble, Parquet a affiché des résultats similaires ou meilleurs à chaque test [qu'Avro]. Les différences de performances des requêtes sur les grands ensembles de données en faveur de Parquet sont en partie dues aux résultats de la compression; lors de l'interrogation du vaste ensemble de données, Spark devait lire 3,5x moins de données pour Parquet que pour Avro. Avro n'a pas bien fonctionné lors du traitement de l'ensemble de données, comme on le soupçonnait. "