Quels sont les avantages et les inconvénients du format parquet par rapport aux autres formats?
Les caractéristiques du parquet Apache sont:
- Auto-description
- Format colonne
- Indépendant de la langue
En comparaison avec Avro, Sequence Files, RC File etc. Je souhaite un aperçu des formats. J'ai déjà lu: Comment Impala fonctionne avec les formats de fichiers Hadoop , il donne quelques indications 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. Comment 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 par rapport aux formats orientés colonne. Les formats orientés enregistrement sont ce à quoi nous sommes tous habitués - fichiers texte, formats délimités tels que CSV, TSV. AVRO est légèrement plus froid que ceux-ci car il peut changer de schéma au fil du temps, par exemple. ajouter ou supprimer des colonnes d'un enregistrement. D'autres astuces de divers formats (notamment la compression) impliquent de savoir si un format peut être fractionné - autrement dit, pouvez-vous lire un bloc d'enregistrements à partir de n'importe où dans le jeu de données et savoir quand même qu'il s'agit d'un schéma? Mais voici plus de détails sur les formats en colonnes comme Parquet.
Le parquet et les autres formats en colonne gèrent très efficacement une situation Hadoop commune. Il est courant que les tables (ensembles de données) comportent 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 ne sont pas inhabituelles. En effet, nous utilisons souvent Hadoop comme un endroit pour dénormaliser des données provenant de formats relationnels - oui, vous obtenez beaucoup de valeurs répétées et de nombreux tableaux, qui sont tous aplatis en un seul. 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 sur l'état dans le temps. De toute façon, il est courant d’avoir un bateau chargé de colonnes dans une table.
Supposons qu'il y a 132 colonnes, dont certaines sont des champs de texte très longs, chaque colonne différente se succédant, et peut-être utiliser jusqu'à 10 000 $ par enregistrement.
Bien que l'interrogation de ces tables soit simple avec le point de vue SQL, il est courant que vous souhaitiez obtenir une plage d'enregistrements basée uniquement sur quelques-unes de ces centaines de colonnes. Par exemple, vous souhaiterez peut-être utiliser tous les enregistrements de février et de 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 dans des champs (colonnes) et obtenez les colonnes de date et de vente, puis incluez-le dans votre résultat s'il satisfait à la condition. Répéter. Si vous avez 10 ans (120 mois) d’histoire, vous lisez chaque enregistrement pour en trouver 2. Bien sûr, c’est une excellente occasion d’utiliser une partition sur un mois et un mois, mais même dans ce cas, vous lisez et analysez 10 Ko de chaque enregistrement/ligne pendant ces deux mois afin de déterminer si les ventes du client sont supérieures à 500 USD.
Dans un format en colonnes, chaque colonne (champ) d’un enregistrement est stockée avec d’autres types, répartie 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). texte long), et tous les autres qui rendent ces enregistrements si énormes, tous dans leur propre emplacement séparé sur le disque, et bien sûr des colonnes pour les ventes ensemble. Eh bien, la date et les mois sont des chiffres, les ventes aussi - ce ne sont que quelques octets. Ne serait-il pas formidable de ne lire que quelques octets pour chaque enregistrement afin de déterminer quels enregistrements correspondent à notre requête? Stockage en colonnes à la rescousse!
Même sans partitions, il est extrêmement rapide de numériser les petits champs nécessaires pour satisfaire notre requête: ils sont tous classés par enregistrement et de même taille. Le disque recherche donc beaucoup moins de données en vérifiant les enregistrements inclus. Nul besoin de lire ce manuel de l’employé et d’autres champs de texte descriptif - ne les ignorez pas. 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 devait seulement connaître ces valeurs et quelques autres (disons 10 des 132 colonnes) et ne se souciait pas de cette colonne du manuel de l'employé, une fois qu'elle avait sélectionné les bons enregistrements à renvoyer, il ne lui restait plus qu'à passer retour aux 10 colonnes nécessaires au rendu des résultats, en ignorant les 122 autres des 132 de notre jeu de données. Encore une fois, nous sautons beaucoup de lecture.
(Remarque: pour cette raison, les formats de colonne sont un choix néfaste pour les transformations directes. Par exemple, si vous joignez toutes les deux tables dans un grand ensemble de résultats (ger) que vous enregistrez sous une nouvelle table, les sources De toute façon, les performances de lecture ne seront pas vraiment optimales, et comme les formats en colonnes ont besoin de plus de mémoire, ils utilisent plus de mémoire que les formats de lignes similaires).
Un autre avantage de la colonne: les données sont réparties. Pour obtenir un enregistrement unique, vous pouvez faire en sorte que 132 travailleurs lisent (et écrivent) des données depuis/vers 132 emplacements différents sur 132 blocs de données. Yay pour la parallélisation!
Et maintenant pour le décisif: les algorithmes de compression fonctionnent beaucoup mieux quand il peut trouver des motifs répétitifs. Vous pouvez compresser AABBBBBBCCCCCCCCCCCCCCCC comme 2A6B16C mais ABCABCBCBCBCCCCCCCCCCCCCC ne deviendrait pas aussi petit (enfin, dans ce cas, ce serait le cas, mais croyez-moi :-)). 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 à fonctionner beaucoup mieux.
Columnar est génial lorsque votre entrée est grande et que votre sortie est un sous-ensemble filtré: de grand à petit, c'est génial. Pas aussi bénéfique lorsque l'entrée et les sorties sont à peu près les mêmes.
Mais dans notre cas, Impala a pris nos anciennes requêtes Hive qui duraient 5, 10, 20 ou 30 minutes et se terminaient en quelques secondes ou une minute.
J'espère que cela aide à répondre au moins en partie à votre question!
Avro est un format de stockage basé sur les lignes pour Hadoop.
Le parquet est un format de stockage basé sur des colonnes pour Hadoop.
Si votre cas d'utilisation analyse 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 jeu de données comporte plusieurs colonnes et que votre cas d'utilisation implique généralement de travailler avec un sous-ensemble de ces colonnes plutôt que des enregistrements entiers, Parquet est optimisé pour ce type de travail.
La réponse de Tom est assez détaillée et exhaustive, mais vous pouvez également être intéressé par cette étude simple à propos de Parquet vs Avro réalisé chez Allstate Insurance, résumé ici:
"Globalement, Parquet a montré des résultats similaires ou meilleurs sur chaque test [qu'Avro]. Les différences de performances de requête sur les jeux de données plus volumineux en faveur de Parquet sont en partie dues aux résultats de compression; lors de l'interrogation du jeu de données étendu, Spark devait lire 3,5 fois moins de données pour Parquet qu'Avro. Avro n'a pas bien fonctionné lors du traitement de l'intégralité du jeu de données, comme on le suspecte. "