Barbara
MASTER SPARK: OPTIMIZE FILE SIZE & PARTITIONS
L’optimisation de la taille des fichiers et des partitions est un aspect crucial du traitement des données avec Spark. La gestion efficace du nombre de partitions et de la taille des fichiers peut avoir un impact significatif sur les performances des opérations de lecture et d’écriture. Dans cet article, nous explorerons les différents paramètres et méthodes à utiliser pour optimiser ces aspects.
L’opération d’écriture dans Spark crée un certain nombre de fichiers de sortie sur le disque, qui est égal au nombre de partitions dans les exécuteurs Spark. Cependant, il peut être difficile de déterminer le nombre exact de partitions avant l’exécution de l’opération d’écriture. En lisant une table, Spark lit par défaut des blocs d’une taille maximale de 128 Mo (mais cela peut être modifié avec le paramètre sql.files.maxPartitionBytes). Ainsi, le nombre de partitions dépend de la taille de l’entrée. Cependant, dans la réalité, le nombre de partitions correspondra très probablement au paramètre sql.shuffle.partitions. Ce paramètre a une valeur par défaut de 200, mais pour les charges de travail plus importantes, il n’est généralement pas suffisant. Il est donc important de bien ajuster le nombre de shuffle partitions pour optimiser les performances. (Source: vidéo sur la configuration du nombre idéal de partitions de shuffle)
Dans les exécuteurs Spark, le nombre de partitions est égal à sql.shuffle.partitions s’il y a au moins une transformation large (wide transformation) dans le processus ETL. Si seules des transformations étroites (narrow transformations) sont appliquées, le nombre de partitions correspondra au nombre de partitions créé lors de la lecture du fichier.
Pour gérer le nombre de partitions de manière dynamique, nous avons deux principales méthodes à notre disposition: repartition() et coalesce(). Voyons rapidement en quoi elles consistent:
– Repartition: repartition(partitionCols, n_partitions) est une transformation paresseuse avec deux paramètres – le nombre de partitions et la ou les colonnes de partitionnement. Lorsqu’elle est exécutée, Spark redistribue les partitions dans le cluster en fonction de la colonne de partitionnement. Cependant, une fois que la table est enregistrée, les informations sur la redistribution sont perdues. Par conséquent, cette information utile ne sera pas utilisée lors de la lecture du fichier. Par exemple, df = df.repartition(“nom_colonne”, n_partitions).
– Coalesce: coalesce(num_partitions) est également une transformation paresseuse, mais elle ne prend qu’un seul argument – le nombre de partitions. Il est important de noter que l’opération coalesce ne redistribue pas les données dans le cluster, elle est donc plus rapide que repartition. De plus, coalesce ne peut réduire le nombre de partitions, elle ne fonctionnera pas si vous essayez d’augmenter le nombre de partitions. Par exemple, df = df.coalesce(num_partitions).
En général, l’utilisation de la méthode coalesce est plus bénéfique. Cependant, la repartition peut être utile lorsque nous avons besoin d’ajuster le nombre de partitions à l’exécution d’un dataframe.
Dans mon expérience avec les processus ETL, où je travaille avec plusieurs tables de tailles variables et effectue des transformations complexes et des jointures, j’ai constaté que le paramètre sql.shuffle.partitions ne me permet pas d’avoir un contrôle précis sur le nombre de partitions. Par exemple, l’utilisation du même nombre de shuffle partitions pour joindre deux petites tables et deux grandes tables dans le même ETL serait inefficace, entraînant soit un excès de petites partitions pour les petites tables, soit un nombre insuffisant de partitions pour les grandes tables. La repartition présente également l’avantage supplémentaire de m’aider à contourner les problèmes de jointures déséquilibrées et de données déséquilibrées.
Cela étant dit, la repartition est moins adaptée avant d’écrire la table sur le disque, et dans la plupart des cas, elle peut être remplacée par coalesce. Coalesce présente deux avantages par rapport à repartition avant l’écriture:
– Il évite une redistribution inutile des données dans le cluster.
– Il permet un ordonnancement logique des données. Lorsque nous utilisons la méthode repartition avant d’écrire les données, les données sont redistribuées dans le cluster, ce qui entraîne une perte de leur ordre. En revanche, l’utilisation de coalesce permet de conserver l’ordre car les données sont regroupées plutôt que redistribuées.
Il est donc essentiel d’ordonner les données avant de les enregistrer. Les informations seront conservées dans les métadonnées de la table et seront utilisées lors de l’exécution des requêtes, ce qui rendra la requête beaucoup plus rapide.
Voyons maintenant les différences entre l’enregistrement dans une table non partitionnée et une table partitionnée, ainsi que les ajustements supplémentaires requis pour l’enregistrement dans une table partitionnée.
Dans le cas des tables non partitionnées, la gestion du nombre de fichiers lors de l’opération d’enregistrement est un processus direct. En utilisant la méthode coalesce avant l’enregistrement, la tâche est accomplie, que les données soient triées ou non.
Cependant, cette méthode n’est pas efficace pour les tables partitionnées, à moins que les données ne soient triées avant l’utilisation de coalesce. Pour comprendre pourquoi cela se produit, nous devons examiner les actions qui se déroulent dans les exécuteurs Spark lorsque les données sont triées par rapport à lorsqu’elles ne le sont pas.
En résumé, l’optimisation de la taille des fichiers et des partitions dans Spark est essentielle pour garantir des performances optimales lors des opérations de lecture et d’écriture. L’ajustement du nombre de partitions avec les méthodes repartition et coalesce peut être utilisé pour optimiser ces aspects. Dans le cas des tables partitionnées, il est important de trier les données avant de les enregistrer pour conserver l’ordre et améliorer les performances de requête. Pour en savoir plus sur ces sujets, consultez les références suivantes :
– Vidéo sur la configuration du nombre idéal de partitions de shuffle.
– Article sur la compréhension de la compression des formats de données.
Optimisez vos opérations Spark en gérant efficacement le nombre de partitions et la taille des fichiers, et profitez de performances accrues dans vos projets de traitement des données !
