Est-il préférable d'avoir une grande lime à parquet ou beaucoup de petites limes à parquet?
Je comprends que hdfs divisera les fichiers en quelque chose comme des morceaux de 64 Mo. Nous avons des données en streaming et nous pouvons les stocker dans des fichiers volumineux ou des fichiers de taille moyenne. Quelle est la taille optimale pour le stockage de fichiers en colonnes? Si je peux stocker des fichiers là où la plus petite colonne fait 64 Mo, cela permettrait-il d'économiser du temps de calcul par rapport à, disons, des fichiers de 1 Go?
Notez que les fichiers Parquet sont divisés en interne en row groups
https://parquet.Apache.org/documentation/latest/
Ainsi, en agrandissant les fichiers de parquet, les groupes de lignes peuvent toujours être les mêmes si vos fichiers de parquet de base n'étaient pas petits/minuscules. Il n'y a pas de pénalité directe énorme sur le traitement, mais en face, il y a plus de possibilités pour les lecteurs de profiter de groupes de lignes peut-être plus grands/plus optimaux si vos fichiers de parquet étaient plus petits/minuscules par exemple, car les groupes de lignes ne peuvent pas s'étendre sur plusieurs fichiers de parquet.
De plus, les fichiers parquet plus volumineux ne limitent pas le parallélisme des lecteurs, car chaque fichier parquet peut être divisé logiquement en plusieurs splits (consistant en un ou plusieurs groupes de lignes).
Le seul inconvénient des fichiers de parquet plus volumineux est qu'il faut plus de mémoire pour les créer. Vous pouvez donc faire attention si vous devez augmenter la mémoire des exécuteurs Spark).
row groups est un moyen pour les fichiers Parquet d'avoir un partitionnement vertical. Chaque row group possède de nombreux blocs de lignes (un pour chaque colonne, un moyen de fournir une partition horizontale pour les jeux de données en parquet).