Bonnes pratiques en matière d’efficacité des performances

Cet article décrit les bonnes pratiques en matière d’efficacité des performances, organisées selon les principes architecturaux listés dans les sections suivantes.

1. Mise à l’échelle verticale, mise à l’échelle horizontale et scalabilité linéaire

Avant de get dans les meilleures pratiques, examinons quelques concepts de calcul distribué : mise à l’échelle horizontale, mise à l’échelle verticale et scalabilité linéaire.

• Mise à l’échelle verticale : effectuez une mise à l’échelle verticale en ajoutant ou en supprimant des ressources d’une seule machine, généralement des processeurs, de la mémoire ou des GPU. Cela signifie généralement d’arrêter la charge de travail, la déplacer vers une machine plus grande et la redémarrer. La mise à l’échelle verticale comporte des limites : il se peut qu’aucune machine de plus grande taille ne soit disponible, ou que le coût de cette machine soit prohibitif si elle est disponible.
• Mise à l’échelle horizontale : effectuez une mise à l’échelle horizontale en ajoutant ou en supprimant des nœuds d’un système distribué. Lorsque les limites de la mise à l’échelle verticale sont atteintes, la solution consiste à mettre à l’échelle horizontalement : l’informatique distribuée utilise des systèmes avec plusieurs machines (appelées clusters) pour exécuter des charges de travail. Pour que cela soit possible, il est indispensable que les charges de travail soient préparées pour l’exécution parallèle, comme le permettent les moteurs de Databricks Data Intelligence Platform, Apache Spark et Photon. Cela permet de combiner plusieurs machines peu coûteuses en un système informatique plus important. Si vous avez besoin de plus de ressources de calcul, la mise à l’échelle horizontale ajoute davantage de nœuds au cluster et les supprime lorsque vous n’en avez plus besoin. Bien qu’il n’existe aucune limit techniquement (et que le moteur Spark effectue la partie complexe de l’équilibrage de charge), un grand nombre de nœuds augmentent la complexité de la gestion.
• Scalabilité linéaire, ce qui signifie que lorsque vous ajoutez des ressources supplémentaires à un système, la relation entre le débit et les ressources utilisées est linéaire. Cela n’est possible que si les tâches effectuées en parallèle sont indépendantes. Si ce n’est pas le cas, les résultats intermédiaires d’une set de nœuds seront nécessaires sur un autre set de nœuds du cluster pour un calcul supplémentaire. Cet échange de données entre nœuds implique le transport des résultats sur le réseau d’un set de nœuds vers un autre set de nœuds, ce qui prend beaucoup de temps. En général, l’informatique distribuée est soumise à certains impératifs pour la gestion de la distribution et de l’échange de données. Par conséquent, les charges de travail de petites données set, qui peuvent être analysées sur un seul nœud, peuvent être encore plus lentes sur un système distribué. La plateforme Databricks Data Intelligence offre une informatique flexible (nœud unique et distribuée) pour répondre aux besoins uniques de vos charges de travail.

2. Utiliser des architectures serverless

Privilégier le calcul serverless

Avec le calcul serverless sur Databricks Data Intelligence Platform, la couche de calcul s’exécute dans le compte Azure Databricks du client. Les services sont entièrement gérés et améliorés en continu par Databricks. En plus des clients qui paient uniquement ce qu’ils utilisent, cela entraîne une amélioration de la productivité :

• Les administrateurs de cloud n’ont plus besoin de gérer des environnements cloud complexes, notamment l’ajustement des quotas, la création et la maintenance de ressources réseau et la connexion à des sources de facturation. Ils peuvent recentrer leur temps sur des projets à meilleure valeur ajoutée au lieu de gérer des composants cloud de bas niveau.
• Les utilisateurs bénéficient d’une latence de démarrage de cluster proche de zéro et d’une concurrence de requête améliorée.

Databricks fournit des services managés pour différentes charges de travail :

• Entrepôts SQL serverless pour charges de travail SQL

  Les administrateurs d’espace de travail peuvent créer des entrepôts SQL serverless qui permettent d’activer le calcul instantané et sont gérés par Databricks. Utilisez-les conjointement à des requêtes SQL Databricks, de la même manière qu’avec les entrepôts SQL Databricks d’origine. Le calcul serverless offre un temps de démarrage très rapide pour les entrepôts SQL et l’infrastructure est gérée par Databricks.

• Travaux serverless pour des flux de travail efficaces et fiables

  Le calcul serverless pour les travaux vous permet d’exécuter votre travail Databricks sans configurer et déployer l’infrastructure. Avec le calcul serverless, vous vous concentrez sur l’implémentation de vos pipelines de traitement et d’analyse des données, et Databricks gère efficacement les ressources de calcul, notamment l’optimisation et la mise à l’échelle du calcul pour vos charges de travail. La mise à l’échelle automatique et Photon sont automatiquement activés pour les ressources de calcul qui exécutent votre travail.

  Vous pouvez surveiller le coût des travaux utilisant le calcul serverless en interrogeant le système d’utilisation facturabletable.

• Calcul serverless pour les notebooks

  Si votre espace de travail est configuré pour prendre en charge le calcul serverless interactif, toutes les personnes qui l’utilisent ont accès au calcul serverless pour les notebooks. Aucune autorisation supplémentaire n’est nécessaire.

Utiliser une mise en service de modèles de qualité professionnelle

Le Service de modèles Mosaic AI permet de déployer, de gérer et d’interroger des modèles d’IA à partir d’une interface unifiée. Chaque modèle servi est disponible en tant qu’API REST que vous pouvez intégrer à votre application web ou cliente.

Le service de modèles fournit un service à haute disponibilité et à faible latence pour le déploiement de modèles. Le service effectue automatiquement un scale-up ou un scale-down pour répondre aux modifications de la demande, ce qui réduit les coûts d’infrastructure tout en optimisant les performances de latence. Cette fonctionnalité utilise le calcul serverless.

3. Concevoir des charges de travail pour optimiser le niveau de performance

Comprendre vos modèles d’ingestion de données et d’accès aux données

Du point de vue des performances, les modèles d’accès aux données (par exemple : « agrégations par rapport à l’accès au point », « analyse ou recherche )», se comportent différemment en fonction de la taille des données. Les fichiers volumineux sont plus efficaces pour les requêtes d’analyse. En revanche, les fichiers plus petits sont adaptés à la recherche, car vous devez lire moins de données pour trouver la ou les lignes spécifiques.

Pour les modèles d’ingestion, il est courant d’utiliser des instructions du langage de manipulation de données (DML). Les instructions DML sont plus performantes lorsque les données sont organisées en cluster.Il vous suffit d’isoler la section de données. Il est important de conserver les données regroupées et isolables pendant l’ingestion : envisagez de conserver un ordre de tri chronologique naturel et d’appliquer autant de filtres que possible à la cible d’ingestion table. Pour les charges de travail d’ingestion d’ajout uniquement et de remplacement, il n’y a rien de particulier à prendre en compte, car il s’agit d’une opération relativement peu coûteuse.

Les modèles d’ingestion et d’accès pointent souvent vers une disposition et un clustering de données évidentes. Si ce n’est pas le cas, déterminez ce qui est le plus important pour votre entreprise et réfléchissez à des solutions pour mieux atteindre cet objectif.

Utiliser des calculs parallèles where il est bénéfique

La délai de valorisation est une dimension importante lors de l’utilisation de données. Bien que de nombreux cas d’usage puissent être facilement implémentés sur une seule machine (petites données, quelques étapes de calcul simples), il existe souvent des cas d’usage qui doivent traiter des jeux de données volumineux, qui ont de longs délais d’exécution en raison d’algorithmes complexes ou doivent être répétés des centaines et des milliers de fois.

L’environnement de cluster de la plateforme Databricks est idéal pour distribuer ces charges de travail de manière efficace. Il parallélise automatiquement les requêtes SQL sur tous les nœuds d’un cluster et fournit des bibliothèques pour effectuer la même opération avec Python et Scala . Plus précisément, les moteurs Apache Spark et Photon analysent les requêtes, déterminent le mode optimal d’exécution parallèle et gèrent l’exécution distribuée de manière résiliente.

De la même façon que les tâches par lots, Structured Streaming distribue les travaux de streaming sur le cluster pour des performances optimales.

L’une des façons les plus simples d’utiliser l’informatique parallèle est avec Delta Live Tables. Vous déclarez les tâches et les dépendances d’un travail dans SQL ou Python, puis Delta Live Tables gère la planification de l’exécution, la configuration efficace de l’infrastructure, l’exécution du travail et la surveillance.

Conçu pour les scientifiques des données, Pandas est un package Python qui fournit des structures de données faciles à utiliser et des outils d’analyse de données pour le langage de programmation Python. En revanche, Pandas n’effectue pas de scale-out pour le Big Data. L’API Pandas sur Spark comble cette lacune en fournissant des API équivalentes à Pandas qui fonctionnent sur Apache Spark.

En outre, la plateforme est fournie avec des algorithmes parallélisés de Machine Learning dans la bibliothèque standard de Machine Learning MLlib. Elle prend en charge l’utilisation multi-GPU prête à l’emploi. Le Deep Learning peut également être parallélisé à l’aide de DeepSpeed Distributor ou TorchDistributor.

Analyser l’ensemble de la chaîne d’exécution

La plupart des pipelines ou des modèles de consommation utilisent une chaîne de systèmes. Par exemple, pour les outils décisionnels, plusieurs facteurs impactent les performances :

• L’outil décisionnel lui-même
• Le connecteur de l’outil décisionnel et du moteur SQL
• Le moteur SQL vers qui l’outil décisionnel envoie la requête.

Pour des performances optimales, l’ensemble de la chaîne doit être pris en compte et sélectionné/paramétré.

Privilégier des clusters plus volumineux

Envisagez des clusters plus volumineux, en particulier lorsque la charge de travail est mise à l’échelle de façon linéaire. Dans ce cas, l’utilisation d’un cluster volumineux pour une charge de travail n’est pas plus coûteuse que l’utilisation d’un cluster plus petit. C’est simplement plus rapide. L’idée principale est que vous louez le cluster pour la durée de la charge de travail. Ainsi, si vous créez des clusters de deux Workers et que l’opération prend une heure, vous payez pour ces Workers pour l’heure complète. De même, si vous faites tourner un cluster de quatre workers et que cela ne prend qu’une demi-heure (c’est where de scalabilité linéaire), les coûts sont identiques. Si les coûts représentent le principal atout d’un contrat de niveau de service (SLA) très flexible, les clusters avec mise à l’échelle automatique sont généralement les moins chers, mais pas nécessairement les plus rapides.

Remarque

Privilégier des clusters volumineux n’est pas nécessaire pour le calcul serverless, car il gère automatiquement les clusters.

Utiliser des opérations Spark natives

Les fonctions définies par l’utilisateur sont un excellent moyen d’étendre les fonctionnalités de Spark SQL. Toutefois, n’utilisez pas les fonctions définies par l’utilisateur Python ou Scala si une fonction native existe :

• Spark SQL
• PySpark

Raisons :

• Pour transférer des données entre Python et Spark, une sérialisation est nécessaire. Cela ralentit considérablement les requêtes.
• Effort accru pour implémenter et tester des fonctionnalités qui existent déjà dans la plateforme.

Si des fonctions natives sont manquantes et doivent être implémentées en tant que fonctions Python définies par l’utilisateur, utilisez des fonctions Pandas définies par l’utilisateur. Apache Arrow garantit une transmission efficace des données entre Spark et Python.

Utiliser des moteurs de plateforme natifs

Photon est le moteur d’Azure Databricks. Il offre des performances de requête extrêmement rapides à faible coût (ingestion de données, ETL, streaming, science des données et requêtes interactives) directement sur votre lac de données. Photon étant compatible avec les API Apache Spark, la prise en main ne requiert qu’une simple activation. Aucune modification du code ni aucun verrouillage ne sont nécessaires.

Photon fait partie d’un runtime hautes performances qui exécute vos appels d’API SQL et tableau existants plus rapidement et réduit le coût total par charge de travail. Photon est utilisé par défaut dans les entrepôts Databricks SQL.

Comprendre votre matériel et votre type de charge de travail

Toutes les machines virtuelles cloud ne sont pas créées de manière égale. Les différentes familles de machines offertes par le cloud providers sont suffisamment différentes pour être importantes. Il existe des différences évidentes (RAM et cœurs) et des différences plus subtiles comme le type et la génération du processeur, les garanties de bande passante réseau et le stockage haut débit local par rapport au disque local et au disque distant. Il existe également des différences de marché physique. Celles-ci doivent être analysées avant de choisir le meilleur type de machine virtuelle pour votre charge de travail.

Remarque

Privilégier des clusters volumineux n’est pas nécessaire pour le calcul serverless, car il gère automatiquement les clusters.

Utiliser la mise en cache

La mise en cache stocke les données fréquemment consultées sur un support plus rapide, réduisant ainsi le temps nécessaire pour les récupérer par rapport à l’accès à la source de données d’origine. Cela entraîne une latence plus faible et des temps de réponse plus rapides, ce qui peut améliorer considérablement les performances globales d’une application et l’expérience utilisateur. En minimisant le nombre de requêtes adressées à la source de données d’origine, la mise en cache permet de réduire le trafic réseau et les coûts de transfert de données. Ce gain d’efficacité peut être particulièrement avantageux pour les applications qui s’appuient sur des API externes ou des bases de données de paiement à l’utilisation. Cela peut aider à répartir la charge plus uniformément sur le système, en empêchant les goulots d’étranglement et les temps d’arrêt potentiels.

Différents types de mise en cache sont disponibles dans Azure Databricks. Voici les caractéristiques de chacune :

• Utiliser le cache du disque

  Le cache du disque (anciennement appelé « cache delta ») stocke des copies des données distantes sur les disques locaux (par exemple, SSD) des machines virtuelles. Il peut améliorer les performances d’un large éventail de requêtes, mais ne permet pas de stocker les résultats de sous-requêtes arbitraires. Le cache du disque détecte automatiquement les événements de création ou de suppression de fichiers de données et met à jour son contenu en conséquence. Le moyen recommandé (et le plus simple) d’utiliser la mise en cache de disque consiste à choisir un type de worker avec ssd volumes lors de la configuration de votre cluster. Ces Workers sont activés et configurés pour la mise en cache de disque.

• Éviter la mise en cache Spark

  Le cache Spark (en utilisant .persist() et .unpersist()) peut stocker le résultat de l’ensemble des données de sous-requêtes et des données stockées dans des formats autres que Parquet (notamment CSV, JSON et ORC). Toutefois, s’il est utilisé à des emplacements incorrects dans une requête, il peut consommer toute la mémoire et même ralentir considérablement les requêtes. En règle générale, évitez la mise en cache Spark, sauf si vous êtes parfaitement au courant de l’impact.

• Cache des résultats de requête

  Mise en cache des résultats de requête par cluster de toutes les requêtes effectuées via des entrepôts SQL. Pour tirer parti de la mise en cache des résultats des requêtes, concentrez-vous sur les requêtes déterministes qui, par exemple, n’utilisent pas de prédicats comme = NOW(). Lorsqu’une requête est déterministe et que les données sous-jacentes sont au format Delta et inchangées, les entrepôts SQL retournent le résultat directement à partir du cache des résultats de la requête.

• Mise en cache de l’interface utilisateur Databricks SQL

  Mise en cache par utilisateur de l’ensemble des résultats des requêtes et des tableaux de bord hérités dans l’interface utilisateur Databricks SQL.

Utiliser le compactage

Delta Lake sur Azure Databricks peut améliorer la vitesse de lecture des requêtes à partir d’un table. Une façon d’y parvenir onsiste à fusionner les petits fichiers en fichiers plus volumineux. Vous déclenchez un compactage en exécutant la commande OPTIMIZE. Consultez Optimize disposition des fichiers de données.

Delta Lake fournit des options pour configurer automatiquement la taille de fichier cible pour les écritures et pour les opérations de OPTIMIZE. Databricks ajuste automatiquement la plupart de ces paramètres et active les fonctionnalités qui améliorent automatiquement les performances table en recherchant des fichiers de taille appropriée :

• Auto compact combine de petits fichiers au sein des partitions Delta table afin de résoudre automatiquement les problèmes liés aux petits fichiers. Le compactage automatique se produit après qu’une écriture dans un table a réussi et s’exécute de manière synchrone sur le cluster ayant effectué l’écriture. Le compactage automatique ne compacte que les fichiers qui n’ont pas été compactés précédemment.
• Les écritures optimisées améliorent la taille des fichiers à mesure que les données sont écrites et augmentent l'efficacité des lectures ultérieures sur le table. Les écritures optimisées sont les plus efficaces pour les tablespartitionnés, car elles réduisent le nombre de petits fichiers écrits dans chaque partition.

Pour plus d’informations, consultez Configurer Delta Lake pour contrôler la taille du fichier de données.

Envisager d’ignorer des données

Le saut de données peut considérablement améliorer les performances des requêtes en ignorant les données qui ne répondent pas aux critères de requête. Cela réduit la quantité de données qui doivent être lues et traitées, ce qui entraîne des temps d’exécution de requête plus rapides.

Pour ce faire, les informations de saut de données sont automatiquement collectées lorsque vous écrivez des données dans un Delta table (par défaut, Delta Lake sur Azure Databricks collecte des statistiques sur les 32 premières columns définies dans votre tableschema). Delta Lake sur Azure Databricks utilise ces informations (valuesminimale et maximale) au moment de la requête pour fournir des requêtes plus rapides. Consultez Ignorer les données pour Delta Lake.

Les techniques suivantes peuvent être appliquées pour le saut de données :

• ordre Z, une technique pour organiser les informations connexes dans les mêmes set de fichiers. Cette colocalisation est automatiquement utilisée par Delta Lake sur les algorithmes Azure Databricks servant à ignorer des données. Ce comportement réduit considérablement la quantité de données que Delta Lake doit lire.

• Le clustering Liquid simplifie les décisions de disposition des données et optimise les performances des requêtes. Il remplace le partitionnement et l’ordre Z au fil du temps. Databricks recommande le clustering liquide pour toutes les nouvelles delta tables. Le clustering liquide offre la possibilité de redéfinir les clés de clustering sans réécrire les données existantes, ce qui permet aux dispositions de données d’évoluer avec des besoins analytiques au fil du temps. Databricks recommande le clustering liquide pour toutes les nouvelles delta tables.

  Tables avec les caractéristiques suivantes bénéficient du clustering liquide :

  • Filtré selon columns avec une cardinalité élevée.
  • Avec une distribution de données considérablement asymétrique.
  • Augmentent rapidement de taille et nécessitent des efforts de maintenance et de réglage.
  • Avec des requêtes d’écriture concurrentes.
  • Avec des modèles d’accès qui changent au fil du temps.
  • Where une clé partition classique peut laisser le table avec trop ou trop peu de partitions.

Pour plus d’informations et de techniques, consultez le guide complet pour Optimize Databricks, Spark et Delta Lake Workloads.

Activer l’optimisation prédictive pour Delta Lake

optimisation prédictive supprime la nécessité de gérer manuellement les opérations de maintenance pour Delta tables sur Databricks. Avec l’optimisation prédictive activée, Databricks identifie automatiquement tables qui bénéficierait des opérations de maintenance et les exécute pour l’utilisateur. Les opérations de maintenance ne sont exécutées que si nécessaire, ce qui élimine les exécutions inutiles pour les opérations de maintenance et la charge associée au suivi et à la résolution des problèmes de performances.

Éviter un partitionnement excessif

Dans le passé, le partitionnement était le moyen le plus courant d’ignorer des données. Toutefois, le partitionnement est statique et se manifeste sous la forme d’une hiérarchie de système de fichiers. Il n’existe aucun moyen simple de modifier les partitions si les modèles d’accès changent au fil du temps. Souvent, le partitionnement entraîne un partitionnement excessif, c’est-à-dire un trop grand nombre de partitions avec des fichiers trop petits, ce qui entrave les performances de requête.

Databricks vous recommande de ne pas partitiontables en dessous de 1 To et de n'utiliser partition par un column que si vous vous attendez à ce que les données dans chaque partition soient d'au moins 1 Go.

En attendant, un meilleur choix que le partitionnement est l’ordre Z ou le clustering liquide plus récent (voir ci-dessus).

performances Optimizejoin

• Envisagez l'optimisationjoin de la plage.

  Une plage join se produit lorsque deux relations sont jointes à l’aide d’un point dans une condition de chevauchement ou d’un intervalle. L'optimisation de la prise en charge de la plage join dans Databricks Runtime peut considérablement améliorer les performances des requêtes, mais elle nécessite un réglage manuel minutieux.

• Utilisez l’exécution de requête adaptative.

  L’exécution adaptative des requêtes ou (AQE) correspond à la réoptimisation de la requête qui se produit pendant son exécution. Elle comporte quatre fonctionnalités majeures :

  • Modifie dynamiquement la fusion de tri join en hachage diffusé join.
  • Fusionne dynamiquement les partitions après l’échange aléatoire.
  • Gère dynamiquement l’asymétrie dans la fusion de tri join et le hachage aléatoire join.
  • Détection et propagation dynamique des relations vides.

  Il est recommandé de garder AQE activé. Différentes fonctionnalités peuvent être configurées séparément.

Pour plus d’informations, consultez le guide complet sur les charges de travail Databricks, Spark et Delta Lake optimize.

Exécuter l’analyse table pour collecter des statistiques de table

L’instruction ANALYZE TABLE collecte des statistiques sur tables dans une schemaspécifiée. Ces statistiques sont utilisées par l’optimiseur de requête pour generate un plan de requête optimal, en sélectionnant le type de join approprié, en sélectionnant le côté de build approprié dans unjoinde hachage ou en calibrant l’ordre de join dans un joinmultidirectionnel.

L’optimisation prédictive exécute automatiquement ANALYZE (aperçu public), une commande permettant de collecter des statistiques, sur Unity Catalog managée tables. Databricks recommande d’activer l’optimisation prédictive pour toutes les Catalog Unity managées tables afin de simplifier la maintenance des données et de réduire les coûts de stockage. Consultez l'optimisation prédictive pour Unity Catalogmanagée tables.

4. Exécuter des tests de performances dans l’étendue de développement

Effectuer les tests sur des données représentatives des données en production

Exécutez des tests de performances sur des données en production (lecture seule) ou des données équivalentes. Lorsque vous utilisez des données équivalentes, les caractéristiques telles que le volume, la disposition des fichiers et les asymétries des données doivent être similaires aux données en production, car cela a un impact significatif sur les performances.

Prendre en compte le préchauffage des ressources

Indépendamment du format de requête et de données, la requête initiale sur un cluster sera toujours plus lente que les requêtes suivantes. Cela est dû au fait que tous les sous-systèmes différents démarrent et lisent toutes les données dont ils ont besoin. Le préchauffage a un impact significatif sur les résultats des tests de performances :

• Préchauffer les clusters : en général, les ressources de cluster nécessitent une initialisation sur plusieurs couches. Il est possible de préchauffer les clusters : les pools Databricks sont un set d’instances inactives prêtes à l’emploi. Lorsque des nœuds de cluster sont créés à l’aide de ces instances inactives, les délais de démarrage du cluster et de mise à l’échelle automatique sont réduits.
• Préchauffer les caches : lorsque la mise en cache fait partie de la configuration, la première exécution permet de garantir que les données sont dans le cache, ce qui accélère les travaux suivants. Les caches peuvent être préchauffés en exécutant des requêtes spécifiques en vue d’initialiser des caches (par exemple, après le redémarrage d’un cluster). Cela peut améliorer considérablement les performances des premières requêtes.

Par conséquent, pour analyser le comportement des différents scénarios, testez les performances de l’exécution initiale (avec et sans préchauffage) et des exécutions suivantes.

Identifier les goulots d’étranglement

Les goulots d’étranglement sont des zones de votre charge de travail qui peuvent dégrader les performances globales lorsque la charge en production augmente. L’identification de ces charges de travail au moment de la conception et les tests sur des charges de travail plus élevées permettent de maintenir la stabilité des charges de travail en production.

5. Superviser les performances

Superviser les performances des requêtes

La supervision des performances des requêtes vous aide à comprendre comment les ressources sont utilisées par différentes requêtes. Vous pouvez identifier les requêtes qui s’exécutent lentement, ce qui vous permet de repérer les goulets d’étranglement dans votre système. Vous pouvez également identifier les requêtes qui consomment des ressources système importantes, ce qui peut entraîner une instabilité ou un temps d’arrêt. Ces informations vous aident à optimize l’allocation de ressources, à réduire les déchets et à garantir que les ressources sont utilisées efficacement.

La plateforme Databricks Data Intelligence dispose de différentes fonctionnalités de supervision (consultez Excellence opérationnelle - Set la supervision, les alertes et la journalisation), dont certaines peuvent être utilisées pour la surveillance des performances :

• Profil de requête : utilisez la fonctionnalité de profil de requête pour résoudre les goulets l’étranglement en matière de performances pendant l’exécution de la requête. Elle vous aide à visualiser chaque tâche de requête et ses mesures associées, notamment le temps passé, le nombre de lignes traitées, les lignes traitées et la mémoire consommée.
• Surveillance des SQL Warehouses: Surveillez les SQL Warehouses en affichant des statistiques en temps réel, des graphiques du nombre maximal de requêtes, des graphiques des clusters actifs et l’historique des requêtes table

Surveiller les charges de travail de streaming

La surveillance du streaming vous permet d’analyser les données et de détecter les problèmes à mesure qu’ils se produisent, en fournissant des insights en temps réel sur les performances et le comportement de votre système. En analysant les données de streaming, vous pouvez identifier les tendances, les modèles et les opportunités d’optimisation. Cela peut vous aider à affiner votre système, à améliorer l’utilisation des ressources et à réduire les coûts.

Pour les requêtes de streaming, utilisez la surveillance Structured Streaming intégrée dans l’interface utilisateur Spark ou envoyez des métriques à des services externes à l’aide de l’interface d’écouteur de requêtes de streaming d’Apache Spark.

Surveillance des performances du travail

La supervision des travaux permet d’identifier et de résoudre les problèmes liés aux travaux Databricks (comme les échecs, les retards ou les goulots d’étranglement des performances). La supervision des travaux fournit des insights sur les performances des travaux, ce qui vous permet d'optimize l’utilisation des ressources, de réduire le gaspillage et d’améliorer l’efficacité globale.