Avro contre Parquet


92

Je prévois d'utiliser l'un des formats de fichier hadoop pour mon projet lié à hadoop. Je comprends que parquet est efficace pour les requêtes basées sur des colonnes et avro pour une analyse complète ou lorsque nous avons besoin de toutes les données des colonnes!

Avant de continuer et de choisir l'un des formats de fichier, je veux comprendre quels sont les inconvénients / inconvénients de l'un par rapport à l'autre. Quelqu'un peut-il me l'expliquer en termes simples?

Réponses:


53

Si vous ne l'avez pas déjà décidé, j'écrirais des schémas Avro pour vos données. Une fois que cela est fait, choisir entre les fichiers conteneurs Avro et les fichiers Parquet est à peu près aussi simple que d'échanger, par exemple,

job.setOutputFormatClass(AvroKeyOutputFormat.class);
AvroJob.setOutputKeySchema(MyAvroType.getClassSchema());

pour

job.setOutputFormatClass(AvroParquetOutputFormat.class);
AvroParquetOutputFormat.setSchema(job, MyAvroType.getClassSchema());

Le format Parquet semble être un peu plus intensif en termes de calcul du côté écriture - par exemple, il nécessite de la RAM pour la mise en mémoire tampon et du processeur pour commander les données, etc., mais il devrait réduire les coûts d'E / S, de stockage et de transfert ainsi que d'être efficace. lit en particulier avec des requêtes de type SQL (par exemple, Hive ou SparkSQL) qui ne concernent qu'une partie des colonnes.

Dans un projet, j'ai fini par revenir des conteneurs Parquet aux conteneurs Avro parce que le schéma était trop étendu et imbriqué (étant dérivé de classes orientées objet assez hiérarchiques) et aboutissait à des milliers de colonnes Parquet. À leur tour, nos groupes de lignes étaient vraiment larges et peu profonds, ce qui signifiait qu'il nous fallait une éternité avant de pouvoir traiter un petit nombre de lignes dans la dernière colonne de chaque groupe.

Je n'ai pas encore eu beaucoup de chance d'utiliser Parquet pour des données plus normalisées / saines, mais je comprends que s'il est bien utilisé, il permet des améliorations significatives des performances.


2
Parquet prend également en charge les ensembles de données / collections imbriqués.
Tagar

@Ruslan: Oui, il supportait techniquement les structures imbriquées. Le problème était le nombre très élevé de colonnes en raison de la dénormalisation extensive des données. Cela a fonctionné mais c'était très lent.
steamer25

4
Oui, écrire des données dans le parquet coûte plus cher. Les lectures sont inverses, en particulier si vos requêtes lisent normalement un sous-ensemble de colonnes.
Tagar

4
Je pense que Parquet convient à la plupart des cas d'utilisation, sauf que les données d'une même colonne varient beaucoup et sont toujours analysées sur presque toutes les colonnes.
Rockie Yang

Apache Arrow ne prend pas encore en charge l'imbrication mixte (listes avec dictionnaires ou dictionnaires avec listes). Donc, si vous voulez travailler avec une imbrication complexe dans Parquet, vous êtes coincé avec Spark, Hive, etc. et des outils qui ne dépendent pas d'Arrow pour lire et écrire Parquet.
Josiah

49

Avro est un format basé sur les lignes. Si vous souhaitez récupérer les données dans leur ensemble, vous pouvez utiliser Avro

Parquet est un format basé sur des colonnes. Si vos données se composent de nombreuses colonnes mais que vous êtes intéressé par un sous-ensemble de colonnes, vous pouvez utiliser Parquet

HBase est utile lorsque la mise à jour fréquente des données est impliquée. Avro est rapide dans la récupération, Parquet est beaucoup plus rapide.


7
Veuillez corriger vos 2 dernières phrases dans le dernier paragraphe. Ils sont carrément incompréhensibles.
Cbhihe

39

Avro

  • Largement utilisé comme plateforme de sérialisation
  • Basée sur les lignes, offre un format binaire compact et rapide
  • Le schéma est codé sur le fichier afin que les données ne soient pas balisées
  • Les fichiers prennent en charge la compression de bloc et peuvent être fractionnés
  • Prend en charge l'évolution du schéma

Parquet

  • Format de fichier binaire orienté colonne
  • Utilise l'algorithme de déchiquetage et d'assemblage des enregistrements décrit dans l'article de Dremel
  • Chaque fichier de données contient les valeurs d'un ensemble de lignes
  • Efficace en termes d'E / S disque lorsque des colonnes spécifiques doivent être interrogées

Du choix d'un format de stockage de données HDFS - Avro vs Parquet et plus


30

Avro et Parquet sont tous deux des formats de stockage «auto-descriptifs», ce qui signifie qu'ils intègrent tous deux des données, des informations de métadonnées et un schéma lors du stockage de données dans un fichier. L'utilisation de l'un ou l'autre des formats de stockage dépend du cas d'utilisation. Trois aspects constituent la base sur laquelle vous pouvez choisir le format qui sera optimal dans votre cas:

  1. Opération de lecture / écriture : Parquet est un format de fichier basé sur des colonnes. Il prend en charge l'indexation. Pour cette raison, il convient aux requêtes de données à faible latence et à écriture unique, complexes ou analytiques, complexes ou analytiques. Ceci est généralement utilisé par les utilisateurs finaux / les data scientists.
    Pendant ce temps, Avro, étant un format de fichier basé sur des lignes, est mieux utilisé pour les opérations intensives en écriture. Ceci est généralement utilisé par les ingénieurs de données. Les deux prennent en charge les formats de sérialisation et de compression, bien qu'ils le fassent de différentes manières.

  2. Outils : Le parquet convient parfaitement à Impala. (Impala est un moteur de requête SQL RDBM Massive Parallel Processing (MPP) qui sait comment fonctionner sur des données résidant dans un ou plusieurs moteurs de stockage externes.) Là encore, Parquet se prête bien à des requêtes complexes / interactives et rapides (faible latence ) sort sur les données en HDFS. Ceci est pris en charge par CDH (Cloudera Distribution Hadoop). Hadoop prend en charge les formats ORC (Optimized Row Columnar) d'Apache (les sélections dépendent de la distribution Hadoop), alors qu'Avro est le mieux adapté au traitement Spark.

  3. Evolution du schéma: faire évoluer un schéma de base de données signifie changer la structure de la base de données, donc ses données, et donc son traitement des requêtes.
    Parquet et Avro prennent tous deux en charge l'évolution des schémas, mais à un degré variable.
    Parquet est bon pour les opérations «d'ajout», par exemple l'ajout de colonnes, mais pas pour renommer les colonnes à moins que «read» ne soit fait par index.
    Avro est mieux adapté pour ajouter, supprimer et généralement muter des colonnes que Parquet. Historiquement, Avro a fourni un ensemble plus riche de possibilités d'évolution de schéma que Parquet, et bien que leurs capacités d'évolution de schéma aient tendance à s'estomper, Avro brille toujours dans ce domaine, par rapport à Parquet.


5
La partie "Outils" est un peu trompeuse. Parquet est efficacement utilisé par de nombreux autres frameworks comme Spark, Presto, Hive etc. Avro n'est pas spécifique à Spark, il est largement utilisé comme format de stockage HDFS et scénarios de passage de messages comme dans Kafka.
的 devrimbaris

2
Aakash Aggarwal: Pouvez-vous expliquer ce que vous voulez dire au paragraphe 2 par "Avro est le mieux adapté au traitement Spark"? Comme mentionné par devrimbaris, Parquet est également très bien intégré dans l'environnement de traitement Spark. o_O?!?
Cbhihe

11

Votre compréhension est juste. En fait, nous avons rencontré une situation similaire lors de la migration des données dans notre DWH. Nous avons choisi Parquet plutôt qu'Avro car l'économie de disque que nous avons obtenue était presque le double de ce que nous avons obtenu avec AVro. En outre, le temps de traitement des requêtes était bien meilleur que celui d'Avro. Mais oui, nos requêtes étaient basées sur l'agrégation, les opérations basées sur les colonnes, etc. Parquet était donc, de manière prévisible, un gagnant clair.

Nous utilisons Hive 0.12 de la distribution CDH. Vous avez mentionné que vous rencontrez des problèmes avec Hive + Parquet, quels sont-ils? Nous n'en avons rencontré aucun.


3

Silver Blaze a joliment mis la description avec un exemple de cas d'utilisation et décrit comment Parquet était le meilleur choix pour lui. Il est logique de considérer l'un sur l'autre en fonction de vos besoins. Je mets en place une brève description de différents autres formats de fichiers ainsi qu'une comparaison de la complexité de l'espace-temps. J'espère que ça t'as aidé.

Il existe de nombreux formats de fichiers que vous pouvez utiliser dans Hive. Les mentions notables sont AVRO, Parquet. RCFile et ORC. Il existe de bons documents disponibles en ligne auxquels vous pouvez vous référer si vous souhaitez comparer les performances et l'utilisation de l'espace de ces formats de fichiers. Suit quelques liens utiles qui vous permettront de démarrer.

Ce billet de blog

Ce lien de MapR [Ils ne parlent pas de Parquet cependant]

Ce lien d'Inquidia

Les liens ci-dessus vous permettront de démarrer. J'espère que cette réponse à votre question.

Merci!


0

Juste pour une description sur Parquet, vous pouvez vous référer ici: http://bigdata.devcodenote.com/2015/04/parquet-file-format.html

J'ai l'intention d'écrire très prochainement sur Avro et une comparaison entre les 2 également. Le postera ici une fois terminé.


En attente de la comparaison. Actuellement, j'ai choisi Avro pour mon projet car le parquet a des problèmes de compatibilité avec la ruche :)
Abhishek

1
@Abshinek, pouvez-vous fournir des informations sur les problèmes de compatibilité avec hive et avro
EB

@EB Il ne devrait y avoir aucun problème, s'il y en a, ils seront mentionnés sur cwiki.apache.org/confluence/display/Hive/AvroSerDe
OneCricketeer
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.