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.