Bonnes pratiques pour l'efficacité des performances

Ces meilleures pratiques vous aident à monter en charge les Ressources et à ajuster les charges de travail pour un throughput rentable sur Databricks, organisées par les principes architecturaux dans les sections suivantes.

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

Avant d'aborder 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 : Montez en charge verticalement en ajoutant ou en supprimant des ressources d'une seule machine, généralement des CPU, de la mémoire ou des GPU. Cela signifie généralement arrêter la charge de travail, la déplacer vers une machine plus grande et la redémarrer. La mise à l'échelle verticale a des limites : il se peut qu'il n'y ait pas de machine plus grande, ou que le prix de la prochaine machine plus grande soit prohibitif.
• Mise à l'échelle horizontale : Montez en charge horizontalement 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 à monter en charge horizontalement : Le calcul distribué utilise des systèmes avec plusieurs machines (appelés clusters) pour exécuter les charges de travail. Il est important de comprendre que pour que cela soit possible, les charges de travail doivent être préparées pour l'exécution parallèle, telles que prises en charge par les moteurs de la Databricks Data Intelligence Platform, Apache Spark et Photon. Cela permet de combiner plusieurs machines peu coûteuses en un système informatique plus grand. Lorsque davantage de ressources compute sont nécessaires, la mise à l'échelle horizontale ajoute plus de nœuds au cluster et les supprime lorsqu'ils ne sont plus nécessaires. Bien que techniquement il n'y ait pas de limite (et que le moteur Spark gère la partie complexe de l'équilibrage de charge), un grand nombre de nœuds augmente la complexité de la gestion.
• Scalabilité linéaire , ce qui signifie que lorsque vous ajoutez plus de ressources à un système, la relation entre le throughput et les ressources utilisées est linéaire. Ceci n'est possible que si les tâches parallèles sont indépendantes. Sinon, des résultats intermédiaires sur un ensemble de nœuds seront nécessaires sur un autre ensemble de nœuds dans le cluster pour un calcul ultérieur. Cet échange de données entre les nœuds implique le transport des résultats sur le réseau d'un ensemble de nœuds à un autre, ce qui prend un temps considérable. En général, le calcul distribué engendre une certaine surcharge pour la gestion de la distribution et l'échange des données. Par conséquent, les charges de travail de petits ensembles de données qui peuvent être analysées sur un seul nœud peuvent être encore plus lentes lorsqu'elles sont exécutées sur un système distribué. La Databricks Data Intelligence Platform offre un compute flexible (nœud unique et distribué) pour répondre aux besoins uniques de vos charges de travail.

2. Utiliser des architectures Serverless

Utiliser le compute serverless

Avec le calcul serverless sur la Databricks Data Intelligence Platform, la couche de compute s'exécute dans le compte Databricks du client. Les services sont entièrement managés et continuellement améliorés par Databricks. Outre le fait que les clients ne paient que ce qu'ils utilisent, cela améliore la productivité :

• Les administrateurs cloud n'ont plus à gérer des environnements cloud complexes, comme l'ajustement des quotas, la création et la maintenance des ressources réseau, et la connexion aux sources de facturation. Ils peuvent consacrer leur temps à des projets à plus forte valeur ajoutée au lieu de gérer des composants cloud de bas niveau.
• Les utilisateurs bénéficient d’une latence de Startup de cluster quasi nulle et d’une concurrence des requêtes améliorée.

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

• Serverless SQL Warehouse pour les charges de travail SQL

  Les administrateurs de workspace peuvent créer des SQL Warehouse serverless qui permettent un compute instantané et sont gérés par Databricks. Utilisez-les avec les requêtes Databricks SQL comme vous le feriez habituellement avec les warehouses Databricks SQL d’origine. Le compute Serverless offre un temps de Startup très rapide pour les SQL Warehouse, et l'infrastructure est gérée et optimisée par Databricks.

• Jobs Serverless pour des workflows efficaces et fiables

  Le Compute Serverless pour les Jobs vous permet d'exécuter votre Job Databricks sans configurer ni déployer d'infrastructure. Avec le compute serverless, vous vous concentrez sur l'implémentation de vos pipelines de traitement des données et d'analytique, et Databricks gère efficacement les ressources de compute, y compris l'optimisation et la mise à l'échelle du compute pour vos charges de travail. La mise à l'échelle automatique et Photon sont automatiquement activés pour les ressources de compute exécutant votre Job.

  Vous pouvez surveiller le coût des Jobs qui utilisent le compute serverless pour les Jobs en interrogeant la table du système d'utilisation facturable.

• Compute serverless pour les Notebooks

  Si votre workspace est activé pour le compute interactif Serverless, tous les utilisateurs du workspace ont accès au compute Serverless pour les notebooks. Aucune autorisation supplémentaire n'est requise.

Utilisez un service de mise à disposition de modèles de niveau entreprise

Model Serving offre une interface unifiée pour déployer, gouverner et interroger les modèles d'IA. Chaque modèle que vous servez 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 hautement disponible et à faible latence pour le déploiement de modèles. Le service monte ou descend en charge automatiquement pour répondre aux changements de la demande, ce qui permet d'économiser les coûts d'infrastructure tout en optimisant les performances en matière de latence. Cette fonctionnalité utilise le compute serverless.

3. Concevoir des charges de travail pour la performance

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

Du point de vue des performances, les modèles d'accès aux données — tels que « agrégations versus accès ponctuel » ou « analyse versus recherche » — se comportent différemment selon la taille des données. Les fichiers volumineux sont plus efficaces pour les queries d'analyse, et les fichiers plus petits sont meilleurs pour les recherches, car vous avez besoin de 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 DML. Les instructions DML sont les plus performantes lorsque les données sont en cluster et que vous pouvez simplement isoler la section de données. Il est important de maintenir les données groupées et isolables pendant l'ingestion : envisagez de conserver un ordre de tri temporel naturel et d'appliquer autant de filtres que possible à la table cible d'ingestion. Pour les workloads d'ingestion en ajout seul et de remplacement, il n'y a pas grand-chose à considérer, car il s'agit d'une opération relativement peu coûteuse.

L'ingestion et les modèles d'accès indiquent souvent un Layout et un regroupement évidents des données. Si ce n'est pas le cas, décidez ce qui est le plus important pour votre entreprise et concentrez-vous sur la manière de mieux atteindre cet objectif.

Utilisez le calcul parallèle là où il est avantageux

Le délai de rentabilisation est une dimension importante lors du travail avec les données. Alors que de nombreux cas d'utilisation peuvent être facilement implémentés sur une seule machine (petites données, quelques étapes de calcul simples), il existe souvent des cas d'utilisation qui nécessitent de traiter de grands ensembles de données, qui ont de longs temps d'exécution en raison d'algorithmes compliqués, ou qui doivent être répétés des centaines et des milliers de fois.

L'environnement de cluster de la plateforme Databricks est un excellent environnement pour la distribution efficace de ces charges de travail. Il parallélise automatiquement les requêtes SQL sur tous les nœuds d'un cluster et fournit des bibliothèques pour Python et Scala pour faire de même. En coulisses, les moteurs Apache Spark et Photon analysent les requêtes, déterminent la méthode optimale d'exécution parallèle et gèrent l'exécution distribuée de manière résiliente.

De la même manière que les tâches par batch, Structured Streaming distribue les jobs de streaming sur le cluster pour des performances optimales.

L'un des moyens les plus simples d'utiliser le calcul parallèle est avec les LakeFlow Pipelines. Vous déclarez les tâches et les dépendances d'un Job en SQL ou Python, puis les LakeFlow Pipelines prennent en charge la planification de l'exécution, la configuration efficace de l'infrastructure, l'exécution du Job et le monitoring.

Pour les data scientists, 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. Cependant, Pandas ne s'adapte pas aux Big Data. L'API Pandas sur Spark comble cette lacune en fournissant des APIs équivalentes à Pandas qui fonctionnent sur Apache Spark.

De plus, la plateforme est fournie avec des algorithmes de Machine Learning parallélisés dans la Machine Learning Library (MLlib) standard MLlib. Il prend en charge l'utilisation multi-GPU prête à l'emploi. Le deep learning peut également être parallélisé en utilisant DeepSpeed Distributor ou TorchDistributor.

Analysez la chaîne d'exécution complète

La plupart des pipelines ou des modèles de consommation impliquent une chaîne de systèmes. Par exemple, avec les outils de BI, la performance est impactée par plusieurs facteurs :

• L'outil de BI lui-même.
• Le connecteur qui connecte l'outil BI et le moteur SQL.
• Le moteur SQL auquel l'outil de BI envoie la requête.

Pour une performance optimale, toute la chaîne doit être considérée et sélectionnée/ajustée pour une meilleure performance.

Préférer les clusters plus grands

Prévoyez des clusters plus grands, surtout si la charge de travail évolue de manière linéaire. Dans ce cas, l’utilisation d’un grand cluster pour une charge de travail n’est pas plus chère que l’utilisation d’un cluster plus petit. C'est juste plus rapide. La clé est que vous louez le cluster pour la durée de la charge de travail. Ainsi, si vous lancez deux clusters de Worker et que cela prend une heure, vous payez pour ces Worker pendant l'heure entière. De même, si vous lancez un cluster à quatre Worker et que cela ne prend qu’une demi-heure (c’est là qu’intervient la scalabilité linéaire), les coûts sont les mêmes. Si les coûts sont le Driver principal avec un SLA très flexible, un cluster à mise à l'échelle automatique est généralement le moins cher, mais pas nécessairement le plus rapide.

remarque

Privilégier les grands clusters n'est pas nécessaire pour le compute Serverless car il gère automatiquement les clusters.

Utiliser l'optimisation prédictive

Pour améliorer les performances, les tables nécessitent une maintenance régulière, telle que l'optimisation du Layout des données, le nettoyage des anciennes versions de fichiers de données qui ne sont plus nécessaires et la mise à jour du clustering des données. Pour garantir des performances optimales, certaines de ces tâches nécessitent une bonne compréhension des modèles d'accès aux données sur l'ensemble de la plateforme.

Databricks Unity Catalog gouverne toutes les lectures et écritures pour les tables qu'il gère et est conscient de tous les modèles de query sur toute la plateforme. Basé sur ces modèles, l'optimisation prédictive peut optimiser les tables en fonction de la manière dont les données sont réellement utilisées, ce qui se traduit généralement par des améliorations significatives des performances. De plus, l'optimisation prédictive élimine la nécessité de gérer manuellement les opérations de maintenance des tables Delta sur Databricks. La plateforme identifie automatiquement les tables qui bénéficieraient d'opérations de maintenance et les exécute pour l'utilisateur.

Databricks vous recommande d' activer l'optimisation prédictive pour votre compte, votre catalogue ou votre schéma, si elle n'est pas déjà activée (comme avec les tables gérées).

Utiliser les tables gérées par Unity Catalog

Les tables dans Unity Catalog peuvent être créées en tant que tables gérées ou tables externes. Pour créer des tables externes, vous devez spécifier l'emplacement de stockage d'objets, et vous êtes responsable de la maintenance et de l'optimisation de ces tables. Pour les tables gérées, Databricks gère l'ensemble du cycle de vie des données, y compris le layout de fichier et l'optimisation prédictive automatiquement activée, ce qui entraîne généralement des améliorations significatives des performances.

Il est recommandé d'utiliser les tables gérées par Unity Catalog pour toutes les données tabulaires gérées dans Databricks.

Utiliser les opérations Spark natives

Les fonctions définies par l'utilisateur (UDF) sont un excellent moyen d'étendre la fonctionnalité de Spark SQL. Cependant, n'utilisez pas de fonctions UDF Python ou Scala si une fonction native existe :

• Spark SQL
• pyspark

Raisons :

• La sérialisation est requise pour transférer des données entre Python et Spark. Cela ralentit considérablement les requêtes.
• Des efforts accrus pour implémenter et tester des fonctionnalités qui existent déjà sur la plateforme.

Si des fonctions natives sont manquantes et devraient être implémentées sous forme d'UDF Python, utilisez les UDF Pandas. Apache Arrow garantit que les données circulent efficacement entre Spark et Python.

Utiliser les moteurs de plateforme natifs

Photon est le moteur sur Databricks qui offre des performances de query rapides à faible coût — de l'ingestion de données, ETL, streaming, Data Science, et queries interactives — directement sur votre data lake. Photon est compatible avec les API Apache Spark. Ainsi, pour **start**, il suffit de l'activer, sans aucune modification de code ni dépendance vis-à-vis d'un fournisseur.

Photon fait partie d'un runtime de haute performance qui exécute plus rapidement vos appels SQL et DataFrame API existants, réduisant ainsi votre coût total par charge de travail. Photon est utilisé par default dans les Databricks SQL warehouses.

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

Toutes les VM cloud ne se valent pas. Les différentes familles de machines proposées par les fournisseurs cloud sont toutes suffisamment différentes pour avoir leur importance. Il y a des différences évidentes, comme la RAM et les cœurs, et des différences plus subtiles : le type et la génération de processeur, les garanties de bande passante réseau, et le stockage local haute vitesse par rapport au disque local par rapport au disque distant. Il y a aussi des différences sur les marchés « spot ». Ceux-ci doivent être compris avant de décider du meilleur type de VM pour votre charge de travail.

remarque

Ceci n'est pas nécessaire pour le compute Serverless, car le compute Serverless gère automatiquement les clusters.

Utiliser le caching

La mise en cache stocke les données fréquemment accédé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 originale. Cela se traduit par une latence réduite et des temps de réponse plus rapides, ce qui peut améliorer considérablement les performances globales et l'expérience utilisateur d'une application. En minimisant le nombre de requêtes vers la source de données originale, la mise en cache aide à réduire le trafic réseau et les coûts de transfert de données. Ce gain d'efficacité peut être particulièrement bénéfique pour les applications qui s'appuient sur des APIs externes ou des bases de données payantes à l'usage. Cela peut aider à répartir la charge plus uniformément sur le système, évitant ainsi les goulets d'étranglement et les temps d'arrêt potentiels.

Il existe plusieurs types de mise en cache disponibles dans Databricks. Voici les caractéristiques de chaque type :

• Utiliser le cache de disque

  Le cache disque (anciennement appelé « cache Delta ») stocke des copies des données distantes sur les disques locaux (par exemple, SSD) des machines virtuelles. Cela peut améliorer les performances pour un large éventail de requêtes, mais ne peut pas être utilisé pour stocker les résultats de sous-requêtes arbitraires. Le cache de disque détecte automatiquement la création ou la 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 sur disque est de choisir un type de Worker avec des volumes SSD lors de la configuration de votre cluster. De tels Worker sont activés et configurés pour la mise en cache sur disque.

• Éviter la mise en cache Spark

  Le cache Spark (en utilisant .persist() et .unpersist()) peut stocker le résultat de toutes les données de sous-requête et des données stockées dans des formats autres que Parquet (tels que CSV, JSON et ORC). Cependant, l'utilisation d'emplacements incorrects dans une query peut consommer toute la mémoire disponible et ralentir considérablement les queries. En règle générale, évitez la mise en cache Spark.

• Cache de résultats de query

  Mise en cache par cluster des résultats de query pour toutes les queries via les SQL warehouses. Pour bénéficier de la mise en cache des résultats de query, concentrez-vous sur les queries déterministes qui, par exemple, n’utilisent pas de prédicats tels que = NOW(). Lorsqu'une query est déterministe et que les données sous-jacentes sont au format Delta et inchangées, les SQL Warehouses renvoient le résultat directement à partir du cache de résultats de la query.

• Mise en cache de l'IU Databricks SQL

  Mise en cache par utilisateur de tous les résultats de query dans l'interface utilisateur de Databricks SQL.

Utiliser le compactage

Delta Lake sur Databricks peut améliorer la vitesse de lecture des queries à partir d'une table. Une solution consiste à fusionner les petits fichiers en fichiers plus volumineux. Vous Trigger le compactage en exécutant la commande OPTIMIZE. Consultez Optimiser le Layout des fichiers de données.

Delta Lake offre des options pour la configuration automatique de la taille de fichier cible pour les écritures et pour les opérations OPTIMIZE. Databricks ajuste automatiquement bon nombre de ces paramètres et active des fonctionnalités qui améliorent automatiquement les performances de la table en cherchant à optimiser la taille des fichiers :

• L' auto-compactage combine les petits fichiers au sein des partitions de table Delta pour réduire automatiquement les problèmes liés aux petits fichiers. L'auto-compactage se produit après la réussite d'une écriture dans une table et s'exécute de manière synchrone sur le cluster qui a effectué l'écriture. L'auto-compactage ne compacte que les fichiers qui n'ont pas été compactés auparavant.
• Les écritures optimisées améliorent la taille des fichiers à mesure que les données sont écrites et bénéficient aux lectures ultérieures sur la table. Les écritures optimisées sont les plus efficaces pour les tables partitionnées, car elles réduisent le nombre de petits fichiers écrits dans chaque partition.

Pour plus de détails, consultez Contrôler la taille des fichiers de données.

Utiliser l'omission de données

L'omission de données peut améliorer considérablement les performances des query en ignorant les données qui ne répondent pas aux critères de la query. Cela réduit la quantité de données à lire et à traiter, ce qui entraîne des temps d'exécution de query plus rapides.

Pour ce faire, les informations de saut de données sont automatiquement collectées lorsque vous écrivez des données dans une table Delta (par default, Delta Lake sur Databricks collecte des statistiques sur les 32 premières colonnes définies dans le schéma de votre table). Delta Lake sur Databricks utilise ces informations (valeurs minimales et maximales) au moment de la requête pour fournir des requêtes plus rapides. Voir le saut de données.

Databricks vous recommande d'utiliser le clustering liquide pour l'omission de données. Le clustering liquide simplifie les décisions de Layout des données et optimise les performances des query. Il vous permet également de redéfinir les clés de clustering sans réécrire les données existantes, et permet aux Layout des données d'évoluer avec les besoins analytiques au fil du temps.

Les tables présentant les caractéristiques suivantes bénéficient du clustering liquide :

• Filtré par les colonnes à forte cardinalité.
• Avec une distribution de données nettement asymétriques.
• Qui se développent rapidement et nécessitent des efforts de maintenance et d'ajustement.
• Avec des requêtes d'écriture simultanées.
• Avec des schémas d’accès qui évoluent au fil du temps.
• Où une clé de partition typique pourrait laisser la table avec trop ou pas assez de partitions.

Pour plus de détails et de techniques, consultez le Guide complet pour optimiser les charges de travail Databricks, Spark et Delta Lake.

Éviter le sur-partitionnement

Dans le passé, le partitionnement était le moyen le plus courant d'ignorer les données. Cependant, le partitionnement est statique et se manifeste sous la forme d'une hiérarchie de système de fichiers. Il n'y a pas de moyen facile de modifier les partitions à mesure que les modèles d'accès évoluent au fil du temps. Souvent, le partitionnement conduit à un sur-partitionnement — en d'autres termes, à trop de partitions avec des fichiers trop petits, ce qui entraîne des performances de query médiocres.

Databricks vous recommande de ne pas partitionner les tables dont la taille est inférieure à 1 To, et de ne partitionner par colonne que si vous prévoyez que les données de chaque partition soient d'au moins 1 Go.

Databricks vous recommande d'utiliser le clustering liquide au lieu du partitionnement pour les nouvelles tables Delta.

Optimiser les performances de jonction

• Envisagez l’ optimisation des jointures de plages .

  Une jointure d'intervalle se produit lorsque deux relations sont jointes à l'aide d'un point dans un intervalle ou d'une condition de chevauchement d'intervalle. Le support de l'optimisation des jointures d'intervalle dans Databricks Runtime peut apporter des améliorations d'un ordre de grandeur aux performances de query, mais nécessite un réglage manuel minutieux.

• Utilisez l'**exécution adaptative de requêtes**.

  L'exécution de query adaptative (AQE) est une réoptimisation de query qui se produit pendant l'exécution de la query. Il dispose de 4 fonctionnalités majeures :

  • Modifie dynamiquement le tri Merge Join en un Broadcast Hash Join.
  • Agrège dynamiquement les partitions après l'échange aléatoire.
  • Gère dynamiquement le décalage dans la jointure par tri-Merge et la jointure par hachage de brassage.
  • Détecte et propage dynamiquement les relations vides.

  Il est recommandé de maintenir l'AQE activée. Différentes fonctionnalités peuvent être configurées séparément.

Pour plus de détails, consultez le guide complet pour optimiser les charges de travail Databricks, Spark et Delta Lake.

Exécuter l'analyse de la table pour collecter les statistiques de table

L'instruction ANALYZE TABLE collecte des statistiques sur les tables dans un schéma spécifié. Ces statistiques sont utilisées par l'optimiseur de requêtes pour générer un plan de requête optimal, en sélectionnant le bon type de jointure, en sélectionnant le bon côté de construction dans une jointure de hachage, ou en calibrant l'ordre de jointure dans une jointure multi-directionnelle.

L'optimisation prédictive exécute automatiquement ANALYZE (préversion publique), une commande de collecte de statistiques, sur les tables gérées par Unity Catalog. Databricks recommande d'activer l'optimisation prédictive pour toutes les tables gérées par Unity Catalog afin de simplifier la maintenance des données et de réduire les coûts de stockage. Voir Optimisation prédictive pour les tables gérées par Unity Catalog.

4e. Exécutez des tests de performance dans le cadre du développement

Tester des données représentatives des données de production

Exécutez des tests de performance sur des données de production (en lecture seule) ou des données similaires. Lorsque vous utilisez des données similaires, des caractéristiques comme le volume, le file layout et l'asymétrie des données devraient être similaires aux données de production, car cela a un impact significatif sur les performances.

Envisagez le préchauffage des ressources

Quel que soit le format de la query et des données, la première query sur un clusters est toujours plus lente que les query suivantes. C'est parce que tous les différents sous-systèmes 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 performance :

• Prewarm clusters : Les ressources des clusters doivent être initialisées sur plusieurs couches. Il est possible de préchauffer des clusters : les pools Databricks sont un ensemble d'instances inactives et prêtes à l'emploi. Lorsque les nœuds de clusters sont créés à l'aide de ces instances inactives, le Startup des clusters et le temps 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 garantit que les données se trouvent dans le cache, ce qui accélère les jobs suivants. Les caches peuvent être préchauffés en exécutant des requêtes spécifiques pour initialiser les caches (par exemple, après le redémarrage d’un cluster). Cela peut améliorer considérablement les performances des premières requêtes.

Ainsi, pour comprendre le comportement dans les différents scénarios, testez la performance de la première exécution avec et sans préchauffage, et des exécutions ultérieures.

Identifiez les goulets d'étranglement

Les goulots d'étranglement sont des zones de votre charge de travail qui pourraient dégrader les performances globales à mesure que la charge augmente en production. L'identification de ces éléments au moment de la conception et les tests par rapport à des charges de travail plus élevées aideront à maintenir la stabilité des charges de travail en production.

5. Surveiller les performances

Configurez le monitoring des performances lors du déploiement

Mettez en œuvre un monitoring complet des performances pendant le déploiement pour établir des métriques de référence et permettre une optimisation proactive. Les stratégies suivantes vous aident à surveiller efficacement les performances :

Tables système pour l'analyse des performances : activez les tables système pour accéder aux données de performances pour la facturation, le compute, les workflows et les queries. Interrogez system.compute tables pour l'utilisation des clusters, system.workflow tables pour les performances des Jobs et system.query tables pour les métriques de query de SQL warehouse.

monitoring Spark : Configurez la livraison des logs du cluster pour conserver les logs d'événements Spark à des fins d'analyse historique des performances. Analysez les Logs d'événements Spark pour identifier les étapes de longue durée, l'asymétrie des données, les shuffles excessifs et la pression mémoire.

**Monitoring des Job et pipeline** : Configurez le monitoring des Lakeflow Jobs et des pipeline pour suivre les temps d'exécution, l'utilisation des Ressources et les modèles d'échec. Configurez les alertes en cas de dégradation des performances ou de violations de SLA.

Query performance monitoring : Activez le suivi de l'historique des requêtes et utilisez les profils de requête pour analyser les plans d'exécution. Identifiez les requêtes lentes, les index manquants et les opportunités d'optimisation des requêtes.

Pour les procédures de configuration du monitoring des performances étape par étape, consultez Phase 9 : conception de la stratégie d’observabilité.

Surveiller les performances des query

Le monitoring des performances des queries vous aide à comprendre comment les Ressources sont utilisées par les différentes queries. Vous pouvez identifier les queries qui s'exécutent lentement, ce qui vous permet d'identifier les goulets d'étranglement de performance dans votre système. Vous pouvez également identifier les queries qui consomment des ressources système importantes, ce qui peut entraîner une instabilité ou des temps d'arrêt. Cette information vous aide à optimiser l'allocation des ressources, à réduire le gaspillage et à garantir que les ressources sont utilisées efficacement.

La Databricks Data Intelligence Platform dispose de diverses capacités de monitoring (voir Excellence opérationnelle – Configurez le monitoring, les alertes et la journalisation), dont certaines peuvent être utilisées pour le monitoring des performances :

• Query Profile : Utilisez la fonctionnalité de query profile pour résoudre les goulots d'étranglement de performance pendant l'exécution de la query. Il fournit une visualisation de chaque tâche de requête et des métriques associées telles que le temps passé, le nombre de lignes traitées et la mémoire utilisée.
• SQL Warehouse monitoring : Surveillez les SQL Warehouse en affichant les statistiques en direct, les graphiques du nombre maximal de requêtes, les graphiques des clusters en cours d'exécution et le tableau de l'historique des requêtes.

Surveiller les charges de travail en streaming

Le monitoring en streaming vous permet d'analyser les données et de détecter les problèmes au fur et à 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 en streaming, vous pouvez identifier les tendances, les modèles et les opportunités d'optimisation. Cela peut vous aider à régler fin votre système, à améliorer l'utilisation des Ressources et à réduire les coûts.

Pour les requêtes de streaming, utilisez le monitoring Structured Streaming intégré dans la Spark UI ou transférez les métriques vers des services externes à l'aide de l'interface Apache Spark Streaming Query Listener.

Surveiller les performances du Job

Le monitoring des Jobs vous aide à identifier et à résoudre les problèmes dans vos Lakeflow Jobs, tels que les échecs, les retards ou les goulots d'étranglement de performance. Le monitoring des Jobs fournit des insights sur les performances des Jobs, vous permettant d'optimiser l'utilisation des Ressources, de réduire le gaspillage et d'améliorer l'efficacité globale.