Aller au contenu principal
Dernière mise à jour le

Écarts entre les Spark Jobs

Un écart dans la timeline des jobs est une période durant laquelle aucun job Spark n'est en cours d'exécution. Durant un écart, les Worker sont généralement inactifs, mais vous continuez de payer pour le cluster. Si les écarts représentent une grande partie du runtime d'un workload, celui-ci prend plus de temps et coûte plus cher que ne le nécessite le travail Spark proprement dit.

Utilisez cette page lorsque la chronologie des jobs montre des lacunes d'une minute ou plus au milieu d'un pipeline, par exemple :

Lacunes du Job

De courtes interruptions sont normales lorsque le driver coordonne le travail. Si la chronologie présente un modèle différent, comme des Job de longue durée, consultez la chronologie des Job pour détecter d'autres modèles et utilisez les autres pages de ce guide pour diagnostiquer le problème. Voir Diagnostiquer les problèmes de coût et de performance à l'aide de Spark UI.

Pour déterminer si les écarts sont normaux, déterminez ce que fait le cluster pendant ce temps. Voici les causes les plus courantes :

Aucun travail​

Sur le all-purpose compute, les écarts signifient généralement que le cluster n’a rien à faire. Par exemple, les utilisateurs soumettent des query par intermittence, de sorte que le cluster est inactif entre elles. Pour réduire les coûts, Databricks recommande d’utiliser le Serverless compute, pour ne pas payer les temps d’inactivité.

Plan d'exécution complexe​

Un driver peut mettre beaucoup de temps à construire et traiter un plan d'exécution complexe. Aucun job Spark n'est en cours d'exécution pendant cette période ; elle apparaît donc comme un vide dans la chronologie des jobs. Par exemple, l'appel de withColumn() dans une boucle crée un plan très coûteux. Pour corriger ce problème, simplifiez le code. Utilisez selectExpr() pour combiner plusieurs appels withColumn() en une seule expression, ou convertissez le code en SQL. Vous pouvez intégrer le SQL dans du code Python et utiliser des fonctions de chaîne Python pour créer la query.

Exécution de code non-Spark​

Le code Spark utilise SQL ou une Spark API comme PySpark. Le code qui n'utilise pas Spark apparaît sous forme d'intervalles dans la chronologie. Par exemple, une boucle Python qui appelle des fonctions Python natives s'exécute en dehors de Spark. Si vous n'êtes pas sûr que votre code exécute Spark, exécutez-le de manière interactive dans un notebook. Si le code utilise Spark, vous verrez des jobs Spark sous la cellule :

Exécution Spark

Pour vérifier si ces jobs sont toujours en cours d’exécution, développez le menu déroulant Jobs Spark sous la cellule. Si le code n’utilise pas Spark, la cellule n’affiche aucun Job Spark , ou aucun des jobs n’est en cours d’exécution. Si vous ne pouvez pas exécuter le code de manière interactive, ajoutez la journalisation au code et faites correspondre les écarts aux sections du code par timestamp. Cette approche peut être complexe.

Si la chronologie montre des lacunes lors de l'exécution de code non-Spark, les Worker sont inactifs pendant ces lacunes, mais vous les payez toujours. Si ce n'est pas intentionnel, réécrivez le code pour utiliser Spark et utiliser pleinement le cluster :

Si le code hors Spark est nécessaire, envisagez le compute serverless, pour ne pas payer les temps d'inactivité. Cette approche pourrait réduire considérablement les coûts.

Le Driver est surchargé​

Pour vérifier si le driver est surchargé, consultez les métriques du cluster. Sur Databricks Runtime 13.0 et versions supérieures, cliquez sur Métriques , comme indiqué dans cette capture d'écran :

Nouvelles métriques de cluster

Dans la visualisation de la répartition de la charge du serveur , vérifiez si le driver est fortement chargé. La visualisation dispose d'un bloc de couleur pour chaque machine du cluster. Le rouge indique une charge lourde et le bleu indique une absence de charge.

La capture d’écran précédente montre un cluster principalement inactif. Si le driver est surchargé, la visualisation ressemble à ceci :

Nouvelles métriques, Driver occupé

Dans cet exemple, un carré est rouge, tandis que les autres sont bleus. Survolez le carré rouge pour vérifier qu’il représente le driver.

Pour corriger un driver Spark surchargé, consultez Driver Spark surchargé.

Le cluster est défectueux.​

Il est rare qu'un cluster dysfonctionne. Toutefois, le cas échéant, il peut être difficile d'en trouver la cause. Redémarrez le cluster pour vérifier si cela résout le problème. Pour vérifier les Logs à la recherche d’éléments suspects, utilisez les tab Event Logs et Driver Logs , surlignés dans la capture d’écran suivante :

Obtention des Logs du Driver

Pour accéder aux Logs des Worker, activez la livraison des Logs de cluster. Vous pouvez également modifier le niveau de log, ce qui peut nécessiter l'aide de votre équipe de compte Databricks.

Sur cette page