Écarts entre les Spark Jobs
Ainsi, vous verrez des lacunes dans la chronologie de vos jobs, comme suit :
Plusieurs raisons peuvent expliquer cela. Si les lacunes représentent une proportion importante du temps passé sur votre charge de travail, vous devez déterminer ce qui cause ces lacunes et si cela est attendu ou non. Plusieurs choses pourraient se produire pendant les écarts :
- Il n'y a pas de travail à faire.
- Le Driver compile un plan d'exécution complexe
- Exécution de code non-Spark
- Le Driver est surchargé
- Le cluster est défaillant
Aucun travail
Sur le all-purpose compute, le fait de n'avoir aucun travail à effectuer est l'explication la plus probable des lacunes. Puisque le cluster est en cours d'exécution et que les utilisateurs soumettent des requêtes, des lacunes sont attendues. Ces écarts correspondent au temps entre les soumissions de query. Envisagez plutôt d'utiliser le serverless compute. Avec le serverless, vous ne paierez pas de temps d’inactivité, ce qui réduit potentiellement considérablement les coûts.
Plan d'exécution complexe
Par exemple, si vous utilisez withColumn() dans une boucle, cela crée un plan très coûteux à traiter. Les lacunes pourraient correspondre au temps que le Driver passe simplement à construire et à traiter le plan. Si tel est le cas, essayez de simplifier le code. Utilisez selectExpr() pour combiner plusieurs appels withColumn() en une seule expression, ou convertissez le code en SQL. Vous pouvez toujours intégrer le SQL dans votre code Python, en utilisant Python pour manipuler la query avec des fonctions de chaîne. Cela résout souvent ce type de problème.
Exécution de code non-Spark
Le code Spark est soit écrit en SQL, soit utilise une API Spark comme PySpark. Toute exécution de code qui n'est pas Spark apparaîtra dans la chronologie sous forme d'écarts. Par exemple, vous pourriez avoir une boucle en Python qui appelle des fonctions Python natives. Ce code ne s'exécute pas dans Spark et peut apparaître comme un écart dans la chronologie. Si vous n'êtes pas sûr que votre code exécute Spark, essayez de l'exécuter de manière interactive dans un notebook. Si le code utilise Spark, vous verrez des jobs Spark sous la cellule :
Vous pouvez également développer le menu déroulant **Spark Jobs** sous la cellule pour voir si les jobs sont en cours d'exécution active (au cas où Spark serait inactif maintenant). Si vous n'utilisez pas Spark, vous ne verrez pas les **Spark Jobs** sous la cellule, ou vous verrez qu'aucun n'est actif. Si vous ne pouvez pas exécuter le code de manière interactive, vous pouvez essayer de vous connecter à votre code et voir si vous pouvez faire correspondre les lacunes avec les sections de votre code par horodatage, mais cela peut être difficile.
Si vous constatez des lacunes dans votre chronologie causées par l'exécution de code non-Spark, cela signifie que vos Worker sont tous inactifs et gaspillent probablement de l'argent pendant ces lacunes. C'est peut-être intentionnel et inévitable, mais si vous pouvez écrire ce code pour utiliser Spark, vous utiliserez pleinement le cluster. Start with ce tutoriel pour apprendre à travailler avec Spark, ou si le code non-Spark est intentionnel, envisagez plutôt d'utiliser le compute Serverless. Avec le serverless, vous ne paierez pas pour le temps d'inactivité, ce qui réduira potentiellement considérablement les coûts.
Le Driver est surchargé
Pour déterminer si votre driver est surchargé, vous devez examiner les métriques du cluster.
Si votre cluster utilise Databricks Runtime 13.0 ou version ultérieure, cliquez sur Metrics comme indiqué dans cette capture d'écran :
Remarquez la **visualisation de la répartition de la charge du serveur**. Vous devriez vérifier si le Driver est fortement chargé. Cette visualisation a un bloc de couleur pour chaque machine du cluster. Rouge signifie fortement chargé, et bleu signifie pas du tout chargé.
La capture d'écran précédente montre un cluster essentiellement inactif. Si le Driver est surchargé, cela ressemblerait à ceci :
Nous pouvons voir qu'un carré est rouge, tandis que les autres sont bleus. Passez votre souris sur le carré rouge pour vous assurer que le bloc rouge représente votre Driver.
Pour corriger un driver Spark surchargé, consultez Driver Spark surchargé.
Le cluster est défectueux.
Les clusters défectueux sont rares, mais si tel est le cas, il peut être difficile de déterminer ce qui s'est passé. Vous pouvez simplement redémarrer le cluster pour voir si cela résout le problème. Vous pouvez également consulter les logs pour voir s'il y a quelque chose de suspect. L'onglet **Journal des événements** et les onglets **Driver Logs**, mis en évidence dans la capture d'écran ci-dessous, seront les endroits où chercher :
Vous pouvez activer la Cluster logs delivery afin d'accéder aux logs des workers. Vous pouvez également modifier le niveau de Logs, mais vous pourriez avoir besoin de contacter votre équipe de compte Databricks Databricks pour obtenir de l'aide.