Partage via

Meilleures pratiques pour le calcul sans serveur

Suivez ces recommandations pour optimiser la productivité, réduire les coûts et améliorer la fiabilité lors de l’utilisation de calcul serverless pour les notebooks, les travaux et les pipelines sur Azure Databricks.

Migration des charges de travail vers le calcul sans serveur

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.

Azure Databricks recommande de hiérarchiser la compatibilité du calcul serverless lors de la création de nouvelles charges de travail. Pour les charges de travail existantes qui nécessitent des modifications de code, migrez-les de manière incrémentielle dans le cadre de votre cycle de développement et de maintenance standard.

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

Utiliser des noms uniques pour les vues temporaires

Le calcul serverless utilise Spark Connect, une architecture client-serveur qui évalue les vues temporaires de manière différée. Ce comportement diffère de l’architecture Spark classique et peut entraîner des erreurs lorsque le code réutilise le même nom d’affichage temporaire, tel que dans une boucle.

Pour éviter les erreurs, utilisez des noms uniques pour toutes les vues temporaires de votre code.

Mise en réseau et connectivité

Le calcul serverless ne prend pas en charge le peering VPC, qui est un moyen courant de connecter le calcul Databricks classique aux sources de données dans votre compte cloud. En guise d’alternative, utilisez des configurations de connectivité réseau pour gérer les points de terminaison, les pare-feu et la connectivité aux services externes.

Par exemple, vous pouvez ajouter un ensemble d’adresses IP de sortie stables dans des VPC externes à une liste d’autorisation pour activer la connectivité à et depuis le calcul serverless Azure Databricks. Pour vous connecter à des applications d’entreprise (telles que Salesforce) ou des bases de données managées (telles que MySQL), utilisez Lakeflow Connect.

Pour restreindre et surveiller le trafic sortant à partir du calcul serverless, configurez les contrôles de sortie pour votre espace de travail. Consultez Gérer les stratégies réseau pour le contrôle de sortie serverless.

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, fournissant 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 un environnement de base. Pour plus d’informations sur les versions d’environnement disponibles et leurs fonctionnalités, consultez les versions d’environnement serverless.

Gérer les dépendances

Le calcul serverless ne prend pas en charge les scripts init. Utilisez plutôt des environnements serverless pour installer et gérer des bibliothèques pour vos charges de travail serverless. Les environnements mettent en cache les packages installés, ce qui réduit la latence de démarrage pour les exécutions suivantes.

Pour utiliser des bibliothèques à partir d’un référentiel privé, configurez les URL pré-signées pour l’accès au référentiel authentifié dans vos paramètres d’environnement.

Choisir un mode de performance

Le calcul serverless Azure Databricks offre deux modes de performances qui vous permettent d’équilibrer la vitesse et le coût en fonction de votre type de charge de travail comme suit :

  • Mode optimisé pour les performances (par défaut) : idéal pour les charges de travail interactives nécessitant des temps de démarrage rapides. Azure Databricks conserve un pool de ressources de calcul chaudes prêtes à réduire le temps d’attente.
  • Mode standard : idéal pour les travaux et pipelines par lots automatisés qui peuvent tolérer des temps de démarrage plus longs de 4 à 6 minutes. Le mode standard peut réduire les coûts d’un maximum de 70% par rapport au mode optimisé pour les performances. Le mode standard est disponible pour les Jobs Lakeflow et les Pipelines Déclaratifs Spark Lakeflow, mais pas pour les notebooks.

Choisissez le mode qui correspond le mieux à vos besoins en charge de travail. Pour les travaux planifiés où la latence de démarrage n’est pas critique, le mode Standard offre généralement la meilleure valeur. Pour plus d’informations sur les tarifs actuels, consultez la page de tarification Databricks.

Optimiser les charges de travail de diffusion en continu

L'informatique serverless permet la diffusion en continu structurée avec les considérations suivantes :

  • Le mode de déclenchement Trigger.AvailableNow est pris en charge pour tous les travaux et pipelines sans serveur. Les intervalles de déclencheur basés sur le temps ne sont pas pris en charge.

  • Lorsque vous utilisez Trigger.AvailableNow, chaque déclencheur traite toutes les données disponibles dans la source, ce qui peut entraîner des micro-lots plus volumineux qu’un déclencheur basé sur le temps. Pour éviter les erreurs hors mémoire et maintenir les performances prévisibles, limitez la quantité de données traitées par micro-lot en définissant maxFilesPerTrigger ou maxBytesPerTrigger.

Déboguer des charges de travail sans serveur

L’interface utilisateur Spark n’est pas disponible dans le calcul serverless. Utilisez plutôt le profil de requête pour analyser les performances des requêtes et résoudre les problèmes de charges de travail. Le profil de requête fournit des informations d’exécution détaillées et est accessible à partir de l’historique des requêtes dans l’interface utilisateur Azure Databricks.

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

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 ?.
  • Pour les rapports ad hoc et le travail de preuve de concept, Lakehouse Federation vous permet d’interroger des bases de données externes directement à partir d’Azure Databricks sans déplacer de données, régies 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 sans serveur

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

  • Last updated on