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.

Migrer des charges de travail vers l'informatique sans serveur

Pour obtenir des instructions pas à pas sur la migration de calcul classique vers serverless, notamment les prérequis, les modifications de code requises, les stratégies de test et un plan de déploiement par phases, consultez Migrer du calcul classique vers le calcul serverless.

Spécifier les versions de paquets 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 VPN externes à une liste d’autorisation pour activer la connectivité à et à partir de Azure Databricks calcul serverless. 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 sans serveur : vous écrivez du code sur une version d’environnement et Azure Databricks mettez à 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 que 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 un environnement de base 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

Azure Databricks serverless offre deux modes de performance qui vous permettent d’équilibrer la vitesse et le coût en fonction de votre type de charge de travail de la manière suivante :

  • 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

Le calcul serverless supporte la diffusion en continu structurée avec Trigger.AvailableNow. Les intervalles de déclencheur basés sur le temps ne sont pas pris en charge. Pour plus d’informations sur les déclencheurs, exemples de code et alternatives pris en charge pour la diffusion en continu, consultez la section streaming du guide de migration.

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 de Azure Databricks sans déplacer de données, régies par le catalogue Unity. 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.

Puits non pris en charge

Si un système de destination n'est pas pris en charge en tant que cible d'écriture directe à partir du calcul sans serveur, vous pouvez utiliser le Unity Catalog Iceberg REST Catalog pour permettre à ce système de lire directement à partir des tables Azure Databricks. Par exemple, Snowflake n’est pas une destination sans serveur prise en charge, mais il peut être configuré comme client Iceberg pour accéder aux tables gérées par Unity Catalog.

Cette approche évite de dupliquer les données et conserve Unity Catalog comme couche de gouvernance pour toutes les lectures. Pour connaître les clients pris en charge et les étapes de configuration, consultez Access Azure Databricks tables à partir de clients Apache Iceberg.

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