Aller au contenu principal
Dernière mise à jour le

Meilleures pratiques pour le compute serverless

Suivez ces recommandations pour maximiser la productivité, réduire les coûts et améliorer la fiabilité lors de l'utilisation du compute serverless pour les notebooks, les jobs et les pipelines sur Databricks.

Migrez les charges de travail vers le compute Serverless​

Pour des instructions pas à pas sur la migration du compute classique vers le Serverless, y compris les prérequis, les modifications de code requises, les stratégies de test et un plan de déploiement par étapes, consultez Migrer du compute classique vers le compute Serverless.

Spécifier les versions de package Python​

Lors de la migration vers le compute Serverless, pin 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 à une version différente en fonction de la version de l'environnement serverless, ce qui peut augmenter la latence, car de nouveaux packages devront être installés.

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

Text
numpy==2.2.2
pandas==2.2.3

Utilisez des noms uniques pour les vues temporaires​

Le compute Serverless utilise Spark Connect, une architecture client-serveur qui évalue les vues temporaires de manière paresseuse. Ce comportement diffère de l'architecture Spark classique et peut provoquer des erreurs lorsque le code réutilise le même nom de vue temporaire, par exemple dans une boucle.

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

Réseau et connectivité​

Le compute Serverless ne prend pas en charge l'appairage VPC, qui est un moyen courant de connecter le compute Databricks classique aux sources de données de votre compte cloud.

Au lieu de cela, si vous avez besoin d'une connectivité privée depuis Serverless, vous pouvez créer des endpoints privés depuis Serverless vers des ressources de votre Virtual Private Cloud (VPC).

Vous pouvez également créer des Endpoint privés vers des Ressources gérées par AWS.

Si la connectivité privée n'est pas possible ou requise, vous pouvez toujours protéger vos ressources en créant un pare-feu autour d'elles qui autorise le trafic Serverless de Databricks.

remarque

Les services de stockage d'objets comme Amazon S3 sont des services régionaux qui n'utilisent pas de VPC et ne sont pas affectés par cette limitation.

Par exemple, pour activer la connectivité à partir du compute serverless, vous pouvez ajouter l'ensemble d'adresses IP sortantes de Databricks à la liste d'autorisation sur les VPC externes. Les IP de Databricks sont sujettes à modification, vous devez donc créer une automatisation pour maintenir vos listes d’autorisation à jour plutôt que d’utiliser une copie unique. Pour plus de détails, consultez la configuration du pare-feu du compute Serverless.

Pour vous connecter aux applications d'entreprise (telles que Salesforce) ou aux bases de données gérées (telles que MySQL), utilisez Lakeflow Connect.

Pour restreindre et surveiller le trafic sortant du compute serverless, configurez les contrôles de sortie pour votre Workspace. Consultez Gérer les stratégies réseau pour le contrôle de sortie Serverless.

Versions de l'environnement Serverless​

Le compute 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 de Databricks Runtime : Vous sélectionnez une version spécifique de Databricks Runtime pour votre charge de travail et gérez les mises à niveau manuellement pour maintenir la compatibilité.
  • Approche Serverless : Vous écrivez du code pour une version d'environnement, et Databricks met à niveau indépendamment le serveur sous-jacent.

Les versions d'environnement fournissent une API client stable qui garantit la compatibilité de votre charge de travail, Databricks offrant indépendamment des améliorations de performance, des améliorations de sécurité et des correctifs de bogues sans modification de code pour vos charges de travail.

Chaque version d'environnement inclut des bibliothèques système mises à jour, des fonctionnalités et des corrections de bugs, tout en maintenant la rétrocompatibilité pour les charges de travail. Databricks prend en charge chaque version d'environnement pendant trois ans à compter de sa date de publication, offrant 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 de détails sur les versions d'environnement disponibles et leurs fonctionnalités, consultez Versions d'environnement Serverless.

Gérer les dépendances​

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

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

Choisir un mode de performance​

Le compute serverless Databricks 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, comme suit :

  • **Mode optimisé pour la performance** (default) : Idéal pour les charges de travail interactives qui nécessitent des temps de Startup rapides. Databricks maintient un Pool de compute ressources chaudes prêt à minimiser le temps d'attente.
  • **Mode standard** : Idéal pour les Jobs batch automatisés et les pipelines qui peuvent tolérer des temps de Startup plus longs, de 4 à 6 minutes. Le mode standard peut réduire les coûts jusqu'à 70 % par rapport au mode optimisé pour les performances. Le mode standard est disponible pour les Lakeflow Jobs et les LakeFlow Pipelines, mais pas pour les notebooks.

Choisissez le mode qui correspond le mieux à vos exigences en matière de charge de travail. Pour les Jobs planifiés où la latence de Startup n’est pas critique, le mode Standard offre généralement le meilleur rapport qualité-prix. Pour connaître les Tarifs actuels, consultez la page Tarifs de Databricks.

Optimiser les charges de travail en streaming​

Le compute Serverless prend en charge le streaming structuré avec Trigger.AvailableNow. Les intervalles de Trigger temporels ne sont pas pris en charge. Pour plus de détails sur les Triggers pris en charge, les exemples de code et les alternatives pour le streaming continu, consultez la section streaming du guide de migration.

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

Pour un guide de décision qui met en correspondance les cas d'utilisation du streaming avec le bon produit serverless, voir Streaming sur compute serverless.

Déboguer les charges de travail serverless​

La Spark UI n'est pas disponible dans le compute serverless. Utilisez plutôt le profil de query pour analyser les performances des queries et résoudre les problèmes de charges de travail. Le profil de query fournit des information détaillées sur l'exécution et est accessible depuis l'historique des queries dans l'interface utilisateur de Databricks.

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

Les stratégies alternatives que vous pouvez utiliser pour l'ingestion incluent :

Alternatives d'ingestion​

Lorsque vous utilisez le compute Serverless, vous pouvez également utiliser les fonctionnalités suivantes pour query 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 possibles, Databricks recommande d'utiliser OpenSharing. Consultez Qu'est-ce qu'OpenSharing ?.
  • Pour les rapports ad hoc et les travaux de preuve de concept, Lakehouse Federation vous permet de query des bases de données externes directement depuis Databricks sans déplacer les données, régie par Unity Catalog. Consultez Se connecter à des bases de données et des catalogues externes.

Essayez l'une ou les deux de ces fonctionnalités et voyez si elles répondent à vos exigences en matière de performances de query.

Puits non pris en charge​

Si un système sink n’est pas pris en charge comme cible d’écriture directe à partir du compute serverless, vous pouvez utiliser le catalogue Iceberg REST de Unity Catalog pour permettre à ce système de lire directement à partir des tables Databricks. Par exemple, Snowflake n’est pas un sink serverless pris en charge, mais il peut être configuré comme un client Iceberg pour lire les tables gérées par Unity Catalog.

Cette approche évite de dupliquer les données et maintient Unity Catalog comme couche de gouvernance pour toutes les lectures. Pour les clients pris en charge et les étapes de configuration, consultez Accéder aux tables Databricks depuis les clients Apache Iceberg.

Configurations Spark prises en charge​

Pour automatiser la configuration de Spark sur un compute Serverless, Databricks a supprimé la prise en charge de la définition manuelle de la plupart des configurations Spark. Pour afficher une liste des paramètres de configuration Spark pris en charge, consultez Configurer les propriétés Spark pour les Notebooks et Jobs Serverless.

Les exécutions de Job sur le compute serverless échoueront si vous définissez une configuration Spark non prise en charge.

Surveiller le coût du compute Serverless​

Il existe plusieurs fonctionnalités que vous pouvez utiliser pour vous aider à surveiller le coût du compute serverless :

Sur cette page