Partager via

Meilleures pratiques pour le calcul serverless

Cet article vous présente des recommandations sur les meilleures pratiques pour utiliser le calcul serverless dans vos notebooks et vos travaux.

En suivant ces recommandations, vous allez améliorer la productivité, l’efficacité des coûts et la fiabilité de vos charges de travail sur Azure Databricks.

Migration de charges de travail vers le calcul serverless

Pour garantir l’isolation du code utilisateur dans l’environnement de calcul serverless partagé, Azure Databricks utilise Lakeguard pour isoler le code utilisateur du moteur Spark et d’autres utilisateurs.

En raison de cela, certaines charges de travail nécessitent des modifications de code pour continuer à travailler sur le calcul serverless. Pour obtenir la liste des limitations, consultez Limitations du calcul serverless.

Certaines charges de travail sont plus faciles à migrer que d’autres. Les charges de travail qui répondent aux exigences suivantes seront les plus faciles à migrer :

  • Les données accessibles doivent être stockées dans Unity Catalog.
  • La charge de travail doit être compatible avec le calcul standard.
  • La charge de travail doit être compatible avec Databricks Runtime 14.3 ou version ultérieure.

Pour tester si une charge de travail fonctionne sur le calcul serverless, exécutez-la sur une ressource de calcul classique avec le mode d’accès Standard et un Runtime Databricks de 14.3 ou version ultérieure. Si l’exécution réussit, la charge de travail est prête pour la migration.

De nombreuses charges de travail plus anciennes ne migrent pas en toute transparence. Au lieu de tout enregistrer, Azure Databricks recommande de hiérarchiser la compatibilité du calcul serverless lorsque vous créez des charges de travail.

Spécifier les versions du package Python

Lors de la migration vers le calcul serverless, épinglez vos packages Python à des versions spécifiques pour garantir des environnements reproductibles. Si vous ne spécifiez pas de version, le package peut être résolu en une autre version basée sur la version de l’environnement serverless, ce qui peut augmenter la latence à mesure que de nouveaux packages doivent être installés.

Par exemple, votre requirements.txt fichier doit inclure des versions de package spécifiques, comme suit :

numpy==2.2.2
pandas==2.2.3

Versions d’environnement sans serveur

Le calcul serverless utilise des versions d’environnement au lieu des versions traditionnelles de Databricks Runtime. Cela représente un changement dans la façon dont vous gérez la compatibilité des charges de travail :

  • Approche Databricks Runtime : vous sélectionnez une version databricks Runtime spécifique pour votre charge de travail et gérez manuellement les mises à niveau pour maintenir la compatibilité.
  • Approche serverless : vous écrivez du code sur une version d’environnement et Azure Databricks met à niveau indépendamment le serveur sous-jacent.

Les versions d’environnement fournissent une API cliente stable qui garantit que votre charge de travail reste compatible, tandis qu’Azure Databricks offre indépendamment des améliorations des performances, des améliorations de sécurité et des correctifs de bogues sans nécessiter de modifications de code apportées à vos charges de travail.

Chaque version de l’environnement inclut des bibliothèques système, des fonctionnalités et des correctifs de bogues mis à jour, tout en conservant la compatibilité descendante pour les charges de travail. Azure Databricks prend en charge chaque version de l’environnement pendant trois ans à partir de sa date de publication, ce qui vous donne un cycle de vie prévisible pour la planification des mises à niveau.

Pour sélectionner une version d’environnement pour votre charge de travail serverless, consultez Sélectionner une version d’environnement. Pour plus d’informations sur les versions d’environnement disponibles et leurs fonctionnalités, consultez les versions d’environnement serverless.

Ingestion de données à partir de systèmes externes

Étant donné que le calcul serverless ne prend pas en charge l’installation de fichiers JAR, vous ne pouvez pas utiliser un pilote JDBC ou ODBC pour ingérer des données à partir d’une source de données externe.

Les autres stratégies que vous pouvez utiliser pour l’ingestion sont les suivantes :

  • Blocs de construction SQL tels que les tables de streaming COPY INTO, et.

Alternatives d’ingestion

Lorsque vous utilisez le calcul serverless, vous pouvez également utiliser les fonctionnalités suivantes pour interroger vos données sans les déplacer.

  • Si vous souhaitez limiter la duplication des données ou garantir que vous interrogez les données les plus récentes, Databricks recommande d’utiliser le partage Delta. Consultez Qu’est-ce que le Delta Sharing ?.
  • Si vous souhaitez générer des états ad hoc et effectuer un travail de preuve de concept, Databricks recommande d’essayer le bon choix, qui peut être Lakehouse Federation. Lakehouse Federation permet de synchroniser des bases de données entières avec Azure Databricks à partir de systèmes externes et est régi par Unity Catalog. Consultez Qu’est-ce que Lakehouse Federation ?.

Essayez une ou les deux de ces fonctionnalités et vérifiez si elles répondent à vos besoins en matière de performances de requête.

Configurations Spark prises en charge

Pour automatiser la configuration de Spark sur le calcul serverless, Azure Databricks a supprimé la prise en charge de la définition manuelle de la plupart des configurations Spark. Pour afficher la liste des paramètres de configuration Spark pris en charge, consultez Configurer les propriétés Spark pour les notebooks serverless et les travaux.

Les exécutions de tâches sur un calcul sans serveur échouent si une configuration Spark non prise en charge est définie.

Surveiller le coût du calcul serverless

Vous pouvez utiliser plusieurs fonctionnalités pour surveiller le coût du calcul serverless:

  • Last updated on