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

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-les fichiers texte, les 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 différents formats (en particulier, y compris la compression) impliquent si un format peut être divisé - c'est-à-dire, Pouvez-vous lire un bloc d'enregistrements de n'importe où dans l'ensemble de données et sait toujours que c'est un schéma? Mais voici plus de détails sur les formats colonnaires comme le Parquet.

Parquet, et d'autres formats colonnaires gérer une situation Hadoop commune très efficacement. Il est courant d'avoir des tables (ensembles de données) ayant beaucoup plus de colonnes que prévu dans une base de données relationnelle bien conçue-cent ou deux cents colonnes n'est pas inhabituel. C'est le cas parce que nous utilisons souvent Hadoop comme un endroit pour dénormaliser 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 depuis toutes les jointures sont élaborés. Il existe d'autres avantages tels que la conservation des données d'état dans le temps. 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 l'une après l'autre et utilise peut-être 10K par enregistrement.

Tout en interrogeant ces tables est facile avec SQL standpoint, 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 vouloir tous les enregistrements en février et Mars pour les clients avec des ventes > $500.

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 date et ventes, incluez-le dans votre résultat s'il satisfait à la condition. Répéter. Si vous avoir 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 sur l'année et le mois, mais même ainsi, vous lisez et analysez 10K de chaque enregistrement/ligne pour ces deux mois juste pour trouver si les ventes du client sont > $500.

Dans un format colonnaire, chaque colonne (champ) d'un enregistrement est stockée avec d'autres de son genre, répartis sur de nombreux blocs différents sur le disque-colonnes pour l'année ensemble, des colonnes pour le mois ensemble, des colonnes pour le manuel de l'employé du client (ou autre texte long), et tous les autres qui rendent ces enregistrements si énormes tous dans leur propre endroit 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, tout comme les ventes-ils ne sont que quelques octets. Ne serait-il pas génial si nous devions seulement lire quelques octets pour chaque enregistrement pour déterminer quels enregistrements correspondaient à notre requête? Stockage colonnaire à la rescousse!

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

, Mais attendez, ça va mieux. Si votre requête n'avait besoin que de les connaître valeurs et un peu plus (disons 10 des 132 colonnes) et ne se souciait pas de cette colonne de manuel de l'employé, une fois qu'il avait choisi les bons enregistrements à retourner, il n'aurait plus qu'à revenir 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.

(Note: pour cette raison, les formats colonnaires sont un choix moche lors de transformations droites, par exemple, si vous joignez toutes les deux tables en une seule grand jeu de résultats (ger) que vous enregistrez en tant que nouvelle table, les sources vont être complètement scannées de toute façon, donc il n'y a pas beaucoup d'avantages dans les performances de lecture, et parce que les formats colonnaires doivent se souvenir de plus de choses, ils utilisent plus de mémoire qu'un format de ligne similaire).

Un avantage supplémentaire de columnar: les données sont réparties autour. Pour obtenir un seul enregistrement, vous pouvez avoir 132 travailleurs chacun lire (et écrire) des données de / vers 132 endroits 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 quand il peut trouver des motifs répétitifs. Vous pouvez compresser AABBBBBBCCCCCCCCCCCCCCCC comme 2A6B16C mais ABCABCBCBCBCCCCCCCCCCCCCC ne serait pas aussi petit (Eh bien, en fait, dans ce cas, il le serait, 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 à fonctionner beaucoup mieux.

Colonnaire est grand lorsque votre côté entrée est grand et que votre sortie est un sous-ensemble filtré: du grand au petit est génial. Pas aussi bénéfique 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 de Ruche qui ont couru en 5, 10, 20 ou 30 minutes, et ont fini la plupart en quelques secondes ou une minute.

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