Diagnostiquer les performances des Lakeflow Jobs

Lorsqu’un job ou une tâche prend plus de temps que prévu, utilisez l’interface Jobs pour comprendre où le temps est consacré et ce que vous pouvez faire pour le réduire. L’interface Jobs affiche la répartition de l’exécution, les métriques des tâches de streaming et les métriques de performance des query pour les jobs Serverless. Pour rechercher et ouvrir les exécutions de jobs, consultez Surveiller Lakeflow Jobs.

Afficher la répartition de l'exécution par phase

La répartition de l'exécution montre où une exécution de job ou de tâche passe du temps. Lorsque vous consultez les détails d'exécution du job, survolez la Durée de l'exécution pour voir la durée totale décomposée en phases suivantes :

• En attente
• En attente de ressources
• Installation de la bibliothèque
• En cours d'exécution

La ventilation de l’exécution est disponible pour les exécutions de Job et les exécutions de tâches. Pour un job comportant plusieurs tâches, la répartition au niveau du job compte En attente de ressources seulement jusqu'à ce que la première tâche start son exécution. Pour une ventilation complète de chaque tâche, consultez la ventilation d'exécution dans le résultat d'exécution de la tâche.

Utilisez la ventilation pour identifier la phase qui prend le plus de temps, puis utilisez les sections suivantes pour comprendre les causes possibles et ce que vous pouvez faire pour réduire ce temps.

remarque

Les tâches de pipeline ont des phases différentes de la plupart des tâches. Ils sont : créés, en attente de ressources, en cours d'initialisation, en cours de configuration des tables et en cours d'exécution. Pour obtenir des conseils sur la réduction des temps d'initialisation et de configuration de table élevés, consultez Corriger les temps d'initialisation élevés dans les pipelines.

Phase en file d'attente

Votre Job ou tâche est en attente de start en raison des limites de concurrence.

Causes possibles :

• Le Job a atteint sa limite d'exécutions simultanées maximales car une exécution précédente du même Job est toujours en cours.
• D'autres jobs exécutés simultanément ont atteint la limite d'exécution concurrente au niveau du workspace.

Ce que vous pouvez faire :

• Augmentez le paramètre de nombre maximal d'exécutions simultanées pour le job.
• Passez en revue vos plannings de Jobs pour réduire les chevauchements. Si les Jobs sont constamment en concurrence pour les ressources, envisagez d'échelonner leurs heures de start. Pour plus d'informations, consultez les limites de ressources Databricks.

Phase d'attente de ressources

Votre Job ou votre tâche attend que le compute devienne disponible avant de pouvoir start à s'exécuter. Ce que vous pouvez faire pour réduire le temps d'attente dépend de votre type de compute.

Type de compute	Causes possibles	Ce que vous pouvez faire
Serverless	Le job serverless utilise le mode de performance standard, qui a une latence de Startup de 4 à 6 minutes, selon la disponibilité du compute et si vous utilisez Spark.	Passez en mode optimisé pour les performances pour réduire le temps de startup.
Classique	Temps de lancement lent des VM. Quota dépassé ou capacité insuffisante retardant le lancement du cluster.	Pour optimiser les temps de Startup sans gérer la configuration des clusters ou du compute, envisagez de migrer votre Job vers le Serverless. Si vous rencontrez des temps de lancement de VM lents, configurez des Pools d'instances avec auto-arrêt des instances inactives pour combler l'écart entre vos Jobs planifiés. Voir aussi les bonnes pratiques du Pool. Regroupez les Jobs successifs en tâches au sein d'un seul Job multitâche. Les tâches au sein d'un Job partagent le même cluster pendant toute la durée de l'exécution, ce qui évite les Startup répétés de clusters. Cela peut offrir des accélérations significatives par rapport aux exécutions de Job successives ou aux orchestrateurs tiers, qui ne peuvent pas réutiliser les clusters entre les tâches de Job. Pour gérer les problèmes de quota et de capacité, activez les types de nœuds flexibles afin que Databricks revienne automatiquement à des types d'instances compatibles lorsque votre type préféré n'est pas disponible. Si vous atteignez constamment les limites de quota, vous pouvez également demander une augmentation de quota auprès de votre fournisseur cloud.

Type de compute	Causes possibles	Ce que vous pouvez faire
Serverless	Le job serverless utilise le mode de performance standard, qui a une latence de Startup de 4 à 6 minutes, selon la disponibilité du compute et si vous utilisez Spark.	Passez en mode optimisé pour les performances pour réduire le temps de startup.
Classique	Temps de lancement lent des VM. Quota dépassé ou capacité insuffisante retardant le lancement du cluster.	Pour optimiser les temps de Startup sans gérer la configuration des clusters ou du compute, envisagez de migrer votre Job vers le Serverless. Si vous rencontrez des temps de lancement de VM lents, configurez des Pools d'instances avec auto-arrêt des instances inactives pour combler l'écart entre vos Jobs planifiés. Voir aussi les bonnes pratiques du Pool. Regroupez les Jobs successifs en tâches au sein d'un seul Job multitâche. Les tâches au sein d'un Job partagent le même cluster pendant toute la durée de l'exécution, ce qui évite les Startup répétés de clusters. Cela peut offrir des accélérations significatives par rapport aux exécutions de Job successives ou aux orchestrateurs tiers, qui ne peuvent pas réutiliser les clusters entre les tâches de Job. Pour gérer les problèmes de quota et de capacité, activez les types de nœuds flexibles afin que Databricks revienne automatiquement à des types d'instances compatibles lorsque votre type préféré n'est pas disponible. Si vous atteignez constamment les limites de quota, vous pouvez également demander une augmentation de quota auprès de votre fournisseur cloud.

Phase d'installation de la bibliothèque

Votre Job passe du temps à installer des bibliothèques avant de commencer à s'exécuter.

Type de compute	Causes possibles	Ce que vous pouvez faire
Serverless	Databricks n'a pas encore mis en cache l'environnement et doit le créer. Le Job installe de nombreux packages. Un repository PyPI personnalisé pourrait être lent à répondre, surtout lorsque de nombreuses tâches installent des packages en parallèle.	Réduisez le nombre de packages nécessaires. Envisagez d'utiliser un environnement de base de workspace.
Classique	Le temps d'installation des bibliothèques est élevé en raison de la taille et de la complexité de l'environnement défini sur le cluster, surtout lorsque vous utilisez des scripts d'initialisation pour installer les bibliothèques au Startup du cluster.	Vérifiez que le job utilise uniquement les packages nécessaires à l'exécution.

Type de compute	Causes possibles	Ce que vous pouvez faire
Serverless	Databricks n'a pas encore mis en cache l'environnement et doit le créer. Le Job installe de nombreux packages. Un repository PyPI personnalisé pourrait être lent à répondre, surtout lorsque de nombreuses tâches installent des packages en parallèle.	Réduisez le nombre de packages nécessaires. Envisagez d'utiliser un environnement de base de workspace.
Classique	Le temps d'installation des bibliothèques est élevé en raison de la taille et de la complexité de l'environnement défini sur le cluster, surtout lorsque vous utilisez des scripts d'initialisation pour installer les bibliothèques au Startup du cluster.	Vérifiez que le job utilise uniquement les packages nécessaires à l'exécution.

Phase d'exécution

Une exécution peut prendre plus de temps que prévu pour de nombreuses raisons. La liste suivante n'est pas exhaustive, mais elle couvre certaines causes courantes et actions possibles.

Causes possibles :

• Le volume de données a augmenté, une durée d'exécution plus longue pourrait donc être attendue.
• Configuration du Job ou du compute modifiée.
• Les modifications de code ont entraîné des query plus lentes ou des Opérations inefficaces.

Ce que vous pouvez faire :

• Passez en revue les modifications récentes à l'aide des tables système Databricks, telles que les tables système des Jobs et les tables système de compute.
• Pour les jobs Serverless, utilisez l'historique des querys pour trouver les querys qui ont pris le plus de temps et ouvrez leur profil de query pour identifier les opportunités d'optimisation. Pour trouver les queries pertinentes, ouvrez la vue Chronologie du job en cliquant sur Chronologie ou Passer à la vue chronologie , qui s'intègre aux profils de query, ou utilisez le lien Historique des queries dans la section compute de chaque tâche.
• Pour les jobs exécutés sur compute classique, utilisez l'Spark UI pour diagnostiquer les étapes et les tâches lentes. start avec la chronologie des événements pour repérer les Job de longue durée, les périodes d'inactivité ou les échecs, puis approfondissez les étapes et les tâches individuelles pour obtenir des détails.

Pour les Jobs Serverless, vous pouvez obtenir des indicateurs de tâche de streaming supplémentaires (aperçu public) et des indicateurs de performance des query.

Afficher les métriques pour les tâches de streaming

info

Aperçu

L’observabilité du streaming pour les Lakeflow Jobs est en Aperçu public.

L'interface utilisateur de Lakeflow Jobs fournit des métriques d'observabilité de streaming pour les charges de travail de streaming sur la page Détails d'exécution des Jobs . Ces métriques incluent les secondes de backlog, les octets de backlog, les enregistrements de backlog et les fichiers de backlog pour les sources prises en charge par Spark Structured Streaming, y compris Apache Kafka, Amazon Kinesis, Auto Loader, Google Pub/Sub et les tables Delta. Lorsque vous affichez les détails d'exécution d'une tâche, les métriques apparaissent sous forme de graphiques dans le volet de droite. Chaque graphique affiche les valeurs maximales agrégées par minute, pour les 48 dernières heures.

Chaque source de streaming ne prend en charge que des métriques spécifiques. L'interface utilisateur affiche uniquement les métriques prises en charge par une source de streaming. Le tableau suivant présente les métriques disponibles pour les sources de streaming prises en charge :

Source	octets de backlog	enregistrements du backlog	secondes de backlog	fichiers de backlog
Kafka	✓	✓
Kinesis	✓		✓
Delta	✓			✓
Auto Loader	✓			✓
Google Pub/Sub	✓	✓

Source	octets de backlog	enregistrements du backlog	secondes de backlog	fichiers de backlog
Kafka	✓	✓
Kinesis	✓		✓
Delta	✓			✓
Auto Loader	✓			✓
Google Pub/Sub	✓	✓

Vous pouvez également spécifier des threshold pour chaque métrique de streaming et configurer des notifications si un Stream dépasse un threshold lors de l'exécution d'une tâche. Consultez Configurer les notifications pour les Jobs lents.

Pour afficher les métriques de streaming pour une exécution de tâche qui diffuse des données depuis l’une des sources Structured Streaming prises en charge :

1. Sur la page Détails de l'exécution du Job , cliquez sur la tâche pour laquelle vous souhaitez afficher les métriques.
2. Cliquez sur le **tab** Metrics dans le volet **Task run**.
3. Pour ouvrir le Graphe d'une métrique, cliquez sur à côté du nom de la métrique.
4. Pour afficher les métriques d'un stream spécifique, entrez l'ID du stream dans la zone de texte Filtrer par stream_id . Vous pouvez trouver l'ID de stream dans la sortie de l'exécution du job.
5. Pour modifier la période des graphiques de métriques, utilisez le menu déroulant temporel.
6. Pour naviguer entre les Stream si l'exécution contient plus de dix Stream, cliquez sur Suivant ou Précédent .

Limites d'observabilité du streaming

• Databricks met à jour les métriques toutes les minutes, à moins qu'une exécution n'ait plus de quatre Stream. Si une exécution a plus de quatre streams, Databricks met à jour les métriques toutes les cinq minutes.
• Databricks collecte les métriques uniquement pour les cinquante premiers flux de chaque exécution.
• Databricks collecte des métriques à des intervalles d'une seconde. Les métriques peuvent ne pas être visibles si votre paramètre triggerInterval est inférieur à une seconde.
• La plupart des sources de données collectent les métriques de streaming par default. Cependant, pour d'autres, vous devez activer cette fonctionnalité. Si votre source de données ne collecte pas les métriques de streaming, définissez l'indicateur spark.sql.streaming.metricsEnabled sur True.

Afficher les métriques de performance des requêtes pour les jobs serverless

Lorsque vous exécutez un Job serverless, Databricks affiche des métriques Query Profile sélectionnées et des insights de performance directement dans l'interface utilisateur d'exécution du Job, afin que vous puissiez identifier les problèmes de performance sans ouvrir de profil de query distinct pour chaque query. Utilisez ces métriques pour examiner pourquoi une exécution est lente ou pour comparer les performances entre deux exécutions.

Databricks affiche les indicateurs de query et les insight suivants pour une exécution de Job Serverless :

• Lignes lues et lignes écrites par exécution de tâche et agrégées entre les tâches pour l’exécution du job.
• Nombre total de queries par exécution de tâche et agrégées entre les tâches pour l’exécution du job.
• Un **indicateur d'insights de performance** (ampoule) sur une tâche lorsqu'une ou plusieurs query de cette tâche ont des insights de performance.
• insight sur les performances dans la barre latérale d'exécution du Job qui agrègent les insight sur les tâches, suggèrent les étapes suivantes et établissent un lien vers les queries concernées.

Ces métriques et insights apparaissent à différents endroits selon la façon dont vous affichez l'exécution :

Où il apparaît	Ce que vous voyez
Barre latérale d’exécution de job	Lignes lues et écrites, nombre total de queries et insight sur les performances au fil des tâches.
Barre latérale d'exécution de tâche	Lignes lues et écrites, nombre total de query et un indicateur d’insights pour l’exécution de la tâche.
Vue graphique	Un icône d'ampoule sur un nœud de tâche lorsque l'une des queries de la tâche a des insights de performances.
Vue chronologique	Une ampoule à côté du nom de la tâche indiquant le nombre de queries contenant des informations, ainsi qu'une ampoule sur chaque query ayant des informations.
Vue Liste	Une ampoule dans la colonne **Insights** lorsque les queries d'une tâche ont des informations sur les performances. Si vous ne voyez pas cette colonne, ajoutez-la à partir du sélecteur de colonne.

Où il apparaît	Ce que vous voyez
Barre latérale d’exécution de job	Lignes lues et écrites, nombre total de queries et insight sur les performances au fil des tâches.
Barre latérale d'exécution de tâche	Lignes lues et écrites, nombre total de query et un indicateur d’insights pour l’exécution de la tâche.
Vue graphique	Un icône d'ampoule sur un nœud de tâche lorsque l'une des queries de la tâche a des insights de performances.
Vue chronologique	Une ampoule à côté du nom de la tâche indiquant le nombre de queries contenant des informations, ainsi qu'une ampoule sur chaque query ayant des informations.
Vue Liste	Une ampoule dans la colonne **Insights** lorsque les queries d'une tâche ont des informations sur les performances. Si vous ne voyez pas cette colonne, ajoutez-la à partir du sélecteur de colonne.

Comportement de clic et de survol :

• Dans la vue Chronologie , passez la souris sur une tâche pour afficher ses métriques agrégées et les insights sur les performances des queries de la tâche.
• Dans la vue Graphe ou la vue Liste , cliquez sur l’ampoule sur une tâche pour ouvrir la vue Chronologie avec les queries de cette tâche développées.
• Dans la vue Chronologie , cliquez sur le texte de la query d'une query qui a une ampoule pour ouvrir un volet avec un aperçu des insights de performance pour cette query.

Pour savoir pourquoi un Job Serverless s'exécute plus lentement que prévu :

1. Ouvrez l’exécution du job.

2. Passez à l' affichage Chronologie .

3. Identifiez les tâches dont la durée est supérieure à celle attendue, en fonction de la distribution des durées.

4. Survolez une tâche de longue durée pour voir :

   • Lignes lues et lignes écrites : vérifiez si la tâche a traité plus de données que d'habitude.
   • Nombre total de requêtes : repérer les changements dans le profil de la charge de travail.
   • L' indicateur d'insights de performance : repérer les régressions ou les modifications de code inefficaces.

5. Si un volume de données plus élevé explique l'augmentation de la durée, le ralentissement pourrait être attendu. Sinon, développez la tâche dans la chronologie pour voir ses queries individuelles. Les queries avec des insights détectés affichent une ampoule à côté d'elles.

6. Cliquez sur le **texte de la query** d'une query avec une ampoule pour ouvrir un volet avec les analyses de performance pour cette query.

7. Appliquez les modifications recommandées et réexécutez le job pour confirmer que le problème est résolu.

Si Optimize apparaît dans la section Query metrics de l’exécution de la tâche, sélectionnez-la pour ouvrir Genie Code avec les insights du job. Examinez les modifications proposées avant de les accepter. Voir Optimiser avec Genie Code.

Pour la liste complète des insights et leur signification, consultez Insights sur les performances des query. Pour des détails plus approfondis sur l'exécution de la query, consultez le profil de la query.

astuce

Ces mêmes métriques facilitent la détection des différences entre une exécution lente et une exécution rapide précédente. Ouvrez les deux exécutions côte à côte et comparez :

• Lignes lues et lignes écrites pour identifier les changements dans le volume de données.
• **Nombre total de requêtes** pour identifier les changements de forme de la charge de travail.
• Des insights de performance pour identifier les inefficacités introduites depuis l'exécution précédente.

Limites des métriques de performance de query

• Ces métriques et insights s'appliquent uniquement aux Lakeflow Jobs Serverless . Les exécutions de Job sur compute classique n'affichent pas cette information.
• Les indicateurs de query d'une exécution de tâche incluent les 100 premières queries de chaque exécution de tâche. Si une exécution de tâche comporte plus de queries, ses indicateurs reflètent uniquement les 100 premières.
• Les indicateurs de query d'exécution de job combinent des indicateurs de jusqu'à 50 exécutions de tâches, en utilisant les 100 premières queries de chaque exécution de tâche.