Recommandations d’optimisation sur Azure Databricks

Les requêtes lentes et les coûts de calcul élevés proviennent généralement de quelques causes profondes : lire plus de données qu’une requête n’en nécessite, redistribuer les données entre les nœuds, choisir un mauvais plan de requête, ou réécrire des fichiers qui n’ont pas changé. Azure Databricks résout automatiquement nombre de ces problèmes sur des charges de travail allant du traitement ETL à grande échelle aux requêtes interactives et ad hoc. D’autres optimisations ne s’appliquent que lorsque 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 nécessitent de les configurer, et décrit le problème que chacune résout. La plupart des optimisations de Databricks Runtime nécessitent Delta Lake, le format par défaut des tables dans Azure Databricks.

Commencez par ces recommandations

Ces choix offrent les plus grands gains de performance pour la plupart des charges de travail. Ils permettent également à de nombreuses optimisations automatiques sur cette page de fonctionner pleinement.

  • Utilisez le clustering liquide pour la disposition des tables.Le clustering liquide remplace le partitionnement des tables et le clustering ZORDER. Il organise les données selon les colonnes sur lesquelles vous filtrez fréquemment, ce qui améliore le data skipping et l’élagage dynamique des fichiers.
  • Utilisez les tables gérées par Unity Catalog.L’optimisation prédictive maintient automatiquement les tables gérées. Consultez les tables managées du catalogue Unity pour Delta Lake et Apache Iceberg.
  • Utilisez le calcul activé par Photon. L’E/S prédictive nécessite Photon, tout comme l’élagage dynamique de fichiers dans les instructions MERGE, UPDATE et DELETE. Consultez Qu’est-ce que Photon ?.
  • Activez les vecteurs de suppression. L’E/S prédictive utilise des vecteurs de suppression pour éviter de réécrire des fichiers entiers lors des mises à jour, suppressions et fusions, et la concurrence au niveau des lignes les exige. Pour les tables Delta Lake, il faut activer explicitement les vecteurs de suppression. Consultez les vecteurs de suppression dans Databricks.
  • Utilisez la dernière version du runtime Databricks. Les nouvelles versions intègrent les dernières améliorations de performance. Certaines optimisations nécessitent une version minimale de Databricks Runtime ou des ressources de calcul compatibles avec Photon. Consultez chaque page pour les exigences.

Optimisations automatiques

Ces optimisations sont activées par défaut. Vous n’avez pas besoin de les activer, mais certains apportent davantage d’avantages lorsque vos tables et vos ressources de calcul remplissent certaines conditions, comme l’utilisation de Photon ou la mise à jour des statistiques des tables.

  • Mise en cache disque : Accélère les requêtes qui lisent sans cesse les mêmes fichiers de données Parquet et Delta Lake distants. Azure Databricks met en cache des copies des fichiers sur le stockage local des nœuds de calcul afin que les lectures ultérieures s’exécutent localement. Azure Databricks l’active automatiquement sur les types d’instances de travailleurs qui le supportent.
  • Élagage dynamique des fichiers : Ignore les fichiers qui ne peuvent pas contenir de lignes correspondantes dans les jointures des tables Delta Lake. Les instructions MERGE, UPDATE et DELETE nécessitent un moteur de calcul compatible avec Photon pour l’élagage dynamique des fichiers.
  • Low shuffle merge : Accélère MERGE les opérations qui mettent à jour ou suppriment quelques lignes dans chaque fichier. La fusion low shuffle traite les lignes non modifiées sans shuffle et préserve leur disposition de données existante.
  • Exécution adaptative des requêtes : Réoptimise les plans de requête pendant l’exécution des requêtes, en fonction de la taille réelle des données. Cela corrige les stratégies de jointure lentes, trop de petites tâches et des tâches déséquilibrées résultant d’estimations inexactes.
  • E/S prédictive : Accélère les analyses de données et réduit les données réécrites lors des mises à jour, suppressions et fusions sur les ressources de calcul compatibles avec Photon.
  • Optimiseur basé sur le coût : utilise des statistiques de table et de colonne pour choisir des plans de requête efficaces, en particulier pour les requêtes à multiples jointures. L’optimiseur basé sur le coût dépend des statistiques, alors collectez-les et maintenez-les à jour.
  • Optimisation prédictive : exécute OPTIMIZE, VACUUM et ANALYZE automatiquement sur les tables gérées par Unity Catalog, donc vous n’avez pas besoin de programmer la maintenance des tables. Il maintient également à jour les statistiques utilisées par l’optimiseur basé sur les coûts. 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, les ajustiez ou modifiiez la configuration de la table. Utilisez-les quand une charge de travail nécessite un comportement que les paramètres par défaut ne couvrent pas.

  • Prise en charge de l’archivage : À utiliser lorsque les politiques du cycle de vie cloud déplacent d’anciens fichiers de table vers des tiers de stockage d’archivage afin de réduire les coûts de stockage. La prise en charge de l’archivage indique à Azure Databricks d’ignorer les fichiers plus anciens qu’une période spécifiée, afin que la politique de cycle de vie ne perturbe pas les requêtes qui ne lisent que des données récentes. Cette fonctionnalité est en version préliminaire publique.
  • Jointure par plage : À utiliser lorsque les jointures utilisent un point dans l’intervalle ou une condition de chevauchement d’intervalle. Databricks SQL optimise automatiquement les jointures de plage. Sur d’autres environnements de calcul, ajustez les jointures par intervalle avec des indications de jointure ou une configuration de session.
  • Niveaux d’isolation et conflits d’écriture : À utiliser lorsque des écritures concurrentes sur la même table sont en conflit, ou lorsqu’une charge de travail nécessite des garanties plus strictes que le niveau d’isolation par défaut WriteSerializable. L’isolation sérialisable réduit le débit pour les écritures concurrentes. La concurrence au niveau des lignes résout automatiquement de nombreux conflits entre les écritures concurrentes sur des tables qui répondent à ses exigences.
  • Index de recherche en texte intégral : À utiliser lorsque les requêtes recherchent dans les colonnes de texte des sous-chaînes ou des mots avec les fonctions search ou isearch. L’index ignore les fichiers qui ne peuvent pas contenir de lignes correspondantes. Cette fonctionnalité est en version Bêta.

Note

Les index Bloom filter sont une fonctionnalité de saut de données obsolète. Ils ajoutent une surcharge d’écriture et sont difficiles à régler. Si vos tables en ont, consultez les index de filtres de Bloom (obsolètes) pour les remplacer et les retirer.

Autres caractéristiques de performance

Diagnostiquez les charges de travail lentes ou onéreuses

Si une charge de travail est plus lente ou plus coûteuse que prévu et que vous ne savez pas pourquoi, utilisez l’interface Spark pour trouver le goulot d’étranglement avant de changer de configuration. Voir Diagnostiquer les problèmes de coût et de performance à l’aide de l’interface Spark.