Recommandations d'optimisation sur Databricks

Les query lentes et les coûts de compute élevés ont généralement quelques causes profondes : lecture de plus de données que nécessaire par une query, brassage (shuffle) de données entre les nœuds, choix d'un mauvais plan de query ou réécriture de fichiers qui n'ont pas changé. Databricks traite automatiquement beaucoup de ces causes sur des charges de travail allant du traitement ETL à grande échelle aux query ad-hoc et interactives. D’autres optimisations ne s’appliquent que si vous les activez ou les ajustez pour une charge de travail spécifique.

Cette page commence par des recommandations pour la plupart des charges de travail, puis regroupe les optimisations selon qu’elles s’exécutent automatiquement ou que vous devez les configurer, et décrit le problème que chacune résout. La plupart des optimisations Databricks Runtime nécessitent Delta Lake, qui est le format de table default dans Databricks.

Start avec ces recommandations

Ces choix permettent d'obtenir les plus grands gains de performance pour la plupart des charges de travail. Ils aident également bon nombre des optimisations automatiques de cette page à fonctionner pleinement.

• Utilisez le clustering fluide pour la Layout de la table. Le clustering fluide remplace le partitionnement de table et ZORDER. Il organise les données par les colonnes sur lesquelles vous filtrez fréquemment, ce qui améliore le saut de données et l'élagage dynamique des fichiers.
• Utilisez des tables gérées par Unity Catalog. L’optimisation prédictive gère automatiquement les tables gérées. Voir Tables gérées par Unity Catalog pour Delta Lake et Apache Iceberg.
• Utilisez un compute activé pour Photon. Les E/S prédictives nécessitent Photon, tout comme l'élagage dynamique de fichiers dans les instructions MERGE, UPDATE et DELETE. Voir Qu'est-ce que Photon ?.
• Activer les vecteurs de suppression. Les E/S prédictives utilisent des vecteurs de suppression pour éviter de réécrire des fichiers entiers lors des mises à jour, des suppressions et des Merge. Ils sont également nécessaires pour la concurrence au niveau des lignes. Pour les tables Delta Lake, vous devez activer explicitement les vecteurs de suppression. Voir Vecteurs de suppression dans Databricks.
• Utilisez la dernière version de Databricks Runtime. Les nouvelles versions incluent les dernières améliorations de performance. Certaines optimisations nécessitent une version minimale de Databricks Runtime ou un compute avec Photon activé. Voir chaque page pour les prérequis.

Optimisations automatiques

Ces optimisations sont activées par default. Vous n'avez pas besoin de les activer, mais certaines sont plus avantageuses si vos tables et votre compute répondent à certaines conditions, comme l'utilisation de Photon ou la tenue à jour des statistiques de table.

• Mise en cache sur disque: accélère les requêtes qui lisent de manière répétée les mêmes fichiers de données Parquet et Delta Lake distants. Databricks met en cache des copies des fichiers sur le stockage local des nœuds de compute, afin que les lectures ultérieures s’exécutent localement. Databricks l’active automatiquement sur les types d’instances Worker qui la prennent en charge.
• Dynamic file pruning: ignore les fichiers qui ne peuvent pas contenir de lignes correspondantes dans les jointures sur les tables Delta Lake. Les instructions MERGE, UPDATE et DELETE nécessitent un compute compatible avec Photon pour le pruning dynamique des fichiers.
• Low shuffle Merge: Accélère les opérations MERGE qui mettent à jour ou suppriment quelques lignes dans chaque fichier. La Merge à faible brassage traite les lignes non modifiées sans brassage et conserve leur Layout de données existant.
• Exécution adaptative des query: réoptimise les plans de query pendant leur exécution, en fonction de la taille réelle des données. Cela corrige également les stratégies de jointure lentes, le trop grand nombre de petites tâches et les tâches déséquilibrées résultant d’estimations inexactes.
• E/S prédictives: accélèrent les scans de données et réduisent les données réécrites lors des mises à jour, des suppressions et des Merge sur le compute avec Photon activé.
• Optimiseur basé sur le coût: utilise des statistiques de table et de colonne pour choisir des plans de query efficaces, en particulier pour les query avec plusieurs jointures. L'optimiseur basé sur les coûts dépend des statistiques ; collectez-les donc et maintenez-les à jour.
• Optimisation prédictive: exécute OPTIMIZE, VACUUM et ANALYZE sur les tables gérées par Unity Catalog automatiquement, afin que vous n’ayez pas à planifier la maintenance des tables. Elle maintient également à jour les statistiques que l’optimiseur basé sur les coûts utilise. Pour vérifier si elle est activée pour votre compte, consultez Vérifier si l’optimisation prédictive est activée.

Optimisations que vous configurez

Ces optimisations nécessitent que vous les activiez, que vous les régliez ou que vous modifiiez la configuration de la table. Utilisez-les lorsqu'un workload a besoin d'un comportement que les default ne couvrent pas.

• Jointure de plage: à utiliser lorsque les jointures utilisent un point dans une condition d'intervalle ou de chevauchement d'intervalle. Databricks SQL optimise automatiquement les jointures de plage. Sur d'autres compute, ajustez les jointures de plage avec des indicateurs de jointure ou la configuration de session.
• Niveaux d'isolement et conflits d'écriture: utilisez-les lorsque les écritures simultanées sur la même table sont en conflit, ou lorsqu'un workload a besoin de garanties plus strictes que le niveau d'isolement par default WriteSerializable. L'isolement sérialisable réduit le throughput pour les écritures simultanées. La simultanéité au niveau de la ligne résout automatiquement de nombreux conflits entre des écritures simultanées sur des tables qui remplissent ses conditions.
• Index de recherche en texte intégral: à utiliser lorsque les query recherchent des sous-chaînes ou des mots dans des colonnes de texte à l’aide des fonctions search ou isearch. L’index ignore les fichiers qui ne peuvent pas contenir de lignes correspondantes. Cette fonctionnalité est en version bêta.

remarque

Les index de filtre de Bloom sont une fonctionnalité d'évitement de données obsolète. Ils ajoutent une surcharge d'écriture et sont difficiles à régler. Si vos tables en possèdent, consultez Index de filtre de Bloom (obsolète) pour les remplacer et les supprimer.

Autres fonctionnalités de performance

• Les fonctions d'ordre supérieur offrent des performances optimisées et intégrées pour de nombreuses opérations qui ne disposent pas d'opérateurs Spark courants. Les fonctions d'ordre supérieur sont plus performantes que les fonctions définies par l'utilisateur.
• Databricks dispose d’opérateurs intégrés et d’une syntaxe spéciale pour travailler avec des types de données complexes, notamment les tableaux, les structures et les chaînes JSON.
• Les queries Spark SQL interrogent des chaînes JSON sans les analyser au préalable.
• Pour contrôler la taille des fichiers de données générés par les écritures, consultez Contrôler la taille des fichiers de données.
• Pour des conseils sur la conception et la maintenance des tables, consultez Bonnes pratiques : Delta Lake.

Diagnostiquer les charges de travail lentes ou coûteuses

Si un workload est plus lent ou plus coûteux que prévu et que vous ne savez pas pourquoi, utilisez le Spark UI pour trouver le goulot d’étranglement avant de modifier la configuration. Consultez Diagnostiquer les problèmes de coût et de performance à l’aide de Spark UI.