Bonnes pratiques pour travailler avec Apache Spark sur Databricks – Partie 1
- Publié le mercredi 20 avril 2022
- temps de lecture 7 minutes
Cependant, pour les utilisateurs de Spark, il reste difficile de déboguer et de comprendre comment leur code est interprété et distribué sur les clusters.
aide. Avec cette plate-forme d’analyse unifiée au-dessus d’Apache Spark, nous pouvons facilement gérer les clusters en quelques clics, utiliser l’interface utilisateur visuelle Spark pour le débogage.
« Chez Databricks, nous travaillons dur pour rendre Spark plus facile à utiliser et à exécuter que jamais, grâce à nos efforts sur la base de code Spark et les supports qui l’entourent. Tout notre travail sur Spark est open source et va directement à Apache. »
Matei Zaharia, VP, Apache Spark, Co-founder & Chief Technologist, Databricks
Les jointures sont l’une des opérations fondamentales lors du développement d’un travail Spark. Il vaut donc la peine de connaître les optimisations avant de travailler avec des jointures.
Une stratégie de jointure appropriée est utile pour optimiser les opérations de jointure délicates, en trouvant la cause première de certaines erreurs de mémoire insuffisante ; et l’amélioration des performances des travaux Spark.
Les performances des
Lorsque l’un des jeux de données est suffisamment petit pour tenir dans la mémoire, il est diffusé à tous les exécuteurs où réside le jeu de données plus volumineux. Il permet d’économiser les coûts de mélange, puis une jointure par hachage est effectuée.
Spark déploie cette stratégie de jointure lorsque la taille du jeu de données est inférieure au seuil. La propriété Spark est configurable :
spark.sql.autoBroadcastJoinThreshold
Default is 10MB
Comme nous le savons, Spark est un moteur informatique distribué. Le grand nombre de données peut être divisé en un jeu de données plus petit pour le calcul parallèle. Cette idée est appliquée dans la jointure par hachage aléatoire.
Il y a 2 phases dans la jointure par hachage Shuffle :
1. Phase de remaniement - L’idée ici est que si 2 tables ont les mêmes clés, elles se retrouvent dans la même partition de sorte que les données requises pour les jointures sont disponibles dans la même partition.
2. Phase de hachage – Un seul nœud de hachage joint les données sur chaque partition
La jointure par hachage aléatoire est toujours une jointure coûteuse car elle implique à la fois le brassage et le hachage. La maintenance d’une table de hachage nécessite de la mémoire et des calculs.
Lorsque les deux tables sont très volumineuses,
Il y a 3 phases dans Sort Merge Join :
1. Phase de lecture aléatoire : Les 2 grandes tables sont repartitionnées selon les clés de jointure sur les partitions du cluster.
2. Phase de tri : tri des données dans chaque partition en parallèle.
3. Phase de fusion : jointure des 2 données partitionnées triées.
Une grande partie de l’efficacité de
Le partitionnement est un concept important dans Spark car il détermine la façon dont les ressources sont accessibles lors de l’exécution d’une tâche. Dans Spark, une partition est créée avec une taille de 64 Mo par défaut.
Une bonne stratégie de partitionnement connaît les données, leur structure et la configuration du cluster. Il y a toujours un compromis lorsqu’il s’agit de décider du nombre de partitions.
En général, nous avons ces règles :
Limite inférieure : 2 x le nombre de cœurs dans le cluster disponibles pour l’application
Limite supérieure : l’exécution de la tâche doit prendre plus de 100 ms. Si cela prend moins de temps, cela signifie que les données partitionnées sont trop petites et que votre application passe peut-être plus de temps à planifier les tâches.
1. Partitionnement de hachage
Le partitionnement par hachage tente de répartir les données uniformément sur diverses partitions en fonction de la clé.
.
Attention, le partitionnement de hachage peut rendre les données distribuées faussées.
2. Partitionnement de plage
Il partitionne les données en fonction de certaines plages de clés triées. Les tuples avec la même gamme seront sur la même machine.
Les techniques de partitionnement de plage et de partitionnement par hachage de Spark sont idéales pour divers cas d’utilisation de Spark, mais le partitionnement n’est possible que dans les paires RDD.
Les RDD peuvent être créés avec un partitionnement spécifique de deux manières :
1. En appelant la méthode partitionBy() et en passant la partition function
2. En appelant la transformation à l’aide de partitionneurs spécifiques.
Opérations sur les RDD de paire qui tiennent à un partitionneur :
Plusieurs fois, les développeurs Spark devront changer la partition d’origine. Cela peut être réalisé en modifiant la taille de la partition Spark et le nombre de partitions Spark avec la méthode repartition( ). Il mélange les données et les divise en un certain nombre de partitions. Mais une meilleure façon de partitionner dans Spark est de le faire à la source de données et cela économise le trafic réseau.
Coalesce est utile car il évite un mélange complet, il utilise des partitions existantes pour minimiser la quantité de données qui sont mélangées.
Les deux contribuent à améliorer les performances des trames de données ou des tables fréquemment consultées. Quelle est la différence entre la
stocke autant de partitions lues en mémoire sur les exécuteurs Spark que la mémoire le permet, tandis que offre plus de contrôle sur la façon et l’endroit où vos données sont stockées, en mémoire ou sur disque, sérialisées ou non.
Les cas d’utilisation courants de la mise en cache sont lorsque vous souhaitez accéder fréquemment à un jeu de données volumineux pour des requêtes ou des transformations par exemple.
1. Formation itérative à l’apprentissage automatique
2. Transformations fréquentes pendant l’ETL
Tous les jeux de données n’ont pas besoin d’être mis en cache. Certains scénarios qui devraient éviter la mise en cache comme :
1. Jeux de données trop volumineux pour tenir dans la mémoire
2. Une transformation peu coûteuse sur des jeux de données rarement utilisés, quelle que soit leur taille.
En règle générale, vous devez utiliser la mise en cache de la mémoire avec bon sens, car elle peut entraîner des coûts de ressources.
Commentaires