Aller au contenu principal
Dernière mise à jour le

Référence de configuration de compute

remarque

L'organisation de cet article suppose que vous utilisez l'interface utilisateur de compute du formulaire simple. Pour un aperçu des mises à jour du formulaire simple, consultez Utiliser le formulaire simple pour gérer les compute.

Cet article explique les paramètres de configuration disponibles lors de la création d'une ressource de compute polyvalente ou de Job. La plupart des utilisateurs créent des ressources de compute à l'aide de leurs politiques attribuées, ce qui limite les paramètres configurables. Si vous ne voyez pas un paramètre particulier dans votre interface utilisateur, c'est parce que la politique que vous avez sélectionnée ne vous permet pas de configurer ce paramètre.

Pour des recommandations sur la configuration du compute pour votre charge de travail, consultez les bonnes pratiques de configuration du compute classique.

Formulaire de compute simple

Les configurations et les outils de gestion décrits dans cet article s'appliquent à la fois au compute multifonction et au compute des Job. Pour plus de considérations sur la configuration du compute des Jobs, consultez Configurer le compute pour les Jobs.

Créer une nouvelle ressource compute à usage général​

Pour créer une nouvelle ressource de compute à usage général :

  1. Dans la barre latérale du Workspace, cliquez sur Compute .
  2. Cliquez sur le bouton **Create compute**.
  3. Configurez la ressource de compute.
  4. Cliquez sur Créer .

Votre nouvelle Ressource compute commencera automatiquement à start et sera bientôt prête à l'emploi.

Politique de compute​

Les politiques sont un ensemble de règles utilisées pour limiter les options de configuration disponibles pour les utilisateurs lorsqu'ils créent des ressources de compute. Si un utilisateur ne dispose pas du droit Création de cluster sans restriction , il ne peut créer des ressources de compute qu'en utilisant les politiques qui lui ont été attribuées.

Pour créer des ressources de compute selon une politique, sélectionnez une politique dans le menu déroulant Politique .

Par default, tous les utilisateurs ont accès à la politique Personal compute , ce qui leur permet de créer des ressources compute sur une seule machine. Si vous avez besoin d'accéder à Calcul personnel ou à d'autres politiques, contactez l'administrateur de votre workspace.

Paramètres de performance​

Les paramètres suivants apparaissent sous la section Performance de l'interface utilisateur de compute simple :

Versions de Databricks Runtime​

Databricks Runtime est l'ensemble des composants principaux qui s'exécutent sur votre compute. Sélectionnez l'exécution à l'aide du menu déroulant Databricks Runtime Version . Pour plus de détails sur les versions spécifiques de Databricks Runtime, consultez les notes de publication et la compatibilité de Databricks Runtime. Toutes les versions incluent Apache Spark. Databricks recommande ce qui suit :

  • Pour le compute à usage général, utilisez la version la plus récente pour vous assurer de bénéficier des dernières optimisations et de la compatibilité la plus à jour entre votre code et les packages préchargés.
  • Pour les compute de Job exécutant des charges de travail opérationnelles, envisagez d'utiliser la version LTS (Long Term Support) de Databricks Runtime. L'utilisation de la version LTS vous permettra d'éviter les problèmes de compatibilité et de tester en profondeur votre charge de travail avant la mise à niveau.
  • Pour les cas d'utilisation de Data Science et de Machine Learning, envisagez la version Databricks Runtime ML.

Utiliser l'accélération de Photon​

Photon est disponible sur les ressources de compute exécutant Databricks Runtime 9.1 LTS et versions ultérieures.

Pour activer ou désactiver l’accélération Photon, cochez la case Utiliser l’accélération Photon . Pour en savoir plus sur Photon, consultez Qu'est-ce que Photon ?.

Type de nœud Worker​

Une ressource de compute se compose d'un nœud driver et de zéro ou plusieurs nœuds worker. Vous pouvez choisir des types d'instances de fournisseur cloud distincts pour les nœuds driver et worker, bien que par default le nœud driver utilise le même type d'instance que le nœud worker. Le paramètre de nœud du driver se trouve sous la section Performances avancées .

Différentes familles de types d'instances conviennent à différents cas d'utilisation, tels que les charges de travail gourmandes en mémoire ou en compute. Vous pouvez également sélectionner un pool à utiliser comme nœud worker ou driver.

important

N'utilisez pas un pool avec des instances de VM préemptives comme type de driver. Sélectionnez un type de driver à la demande pour éviter que votre driver ne soit récupéré. Voir Se connecter aux pools.

Dans le compute multi-nœuds, les nœuds Worker exécutent les exécuteurs Spark et d'autres services nécessaires au bon fonctionnement d'une ressource de compute. Lorsque vous distribuez votre charge de travail avec Spark, tout le traitement distribué s'effectue sur les nœuds Worker. Databricks exécute un exécuteur par nœud worker. Par conséquent, les termes exécuteur et nœud worker sont utilisés de manière interchangeable dans le contexte de l’architecture Databricks.

astuce

Pour exécuter un Job Spark, vous avez besoin d'au moins un nœud Worker. Si la ressource compute ne compte aucun Worker, vous pouvez exécuter des commandes non-Spark sur le nœud Driver, mais les commandes Spark échoueront.

Types de nœuds flexibles​

Si votre Workspace dispose de types de nœuds flexibles activés, vous pouvez utiliser des types de nœuds flexibles pour votre ressource de compute. Les types de nœuds flexibles permettent à votre ressource compute de revenir à des types d'instances alternatifs et compatibles lorsque le type d'instance spécifié n'est pas disponible. Ce comportement améliore la fiabilité du lancement des computes en réduisant les défaillances de capacité pendant les lancements de computes. Voir Améliorer la fiabilité du lancement des computes à l’aide de types de nœuds flexibles.

Adresses IP des nœuds worker​

Databricks lance des nœuds Worker avec deux adresses IP privées chacun. L'adresse IP privée principale du nœud héberge le trafic interne de Databricks. L'adresse IP privée secondaire est utilisée par le conteneur Spark pour la communication intra-cluster. Ce modèle permet à Databricks d'assurer l'isolation entre plusieurs ressources de compute dans le même workspace.

Stockage de nœud Worker provisionné par default​

Databricks attache plusieurs disques à chaque instance de compute afin d'isoler l'utilisation du disque et les performances à différentes fins. Vous pourriez voir plusieurs disques par nœud dans la console Google Cloud. Pour le compute à nœud unique, le driver et l'exécuteur s'exécutent sur la même instance, de sorte que tous les disques sont toujours provisionnés pour ce nœud unique.

Databricks provisionne le stockage suivant pour chaque instance de compute :

  • Un disque de démarrage utilisé par le système d'exploitation hôte et les services internes de Databricks. La taille default est de 30 Go.
  • Un volume racine de conteneur de 150 Go utilisé par le conteneur Spark. Ceci héberge l'environnement d'exécution, les services et les Logs Spark.
  • Disques SSD locaux utilisés pour stocker les fichiers de brassage Spark et les données de cache. Chaque SSD local a une capacité de 375 Go.
  • SSD distants lorsque le dimensionnement automatique du stockage est activé. Ces start à 80 Go à la création (ou 0 Go si un SSD local est présent) et s'adaptent automatiquement selon les besoins.

Types d'instances GPU​

Pour les tâches exigeantes en termes de calcul qui exigent de hautes performances, comme celles associées au deep learning, Databricks prend en charge les ressources de compute qui sont accélérées par des unités de traitement graphique (GPU). Pour plus d'informations, voir compute compatible GPU.

Types d'instances avec SSD locaux​

Pour la liste la plus récente des types d'instances, les Tarifs de chacun et la taille des SSD locaux, consultez l'estimateur de Tarifs GCP.

Les types d'instances qui ont des SSD locaux sont chiffrés avec le chiffrement côté serveur par default de Google Cloud et utilisent automatiquement la mise en cache sur disque pour des performances améliorées. Les tailles de cache sur tous les types d'instances sont définies automatiquement, vous n'avez donc pas besoin de définir explicitement l'utilisation du disque.

Configurer les SSD locaux pour votre compute​

Lorsque vous créez ou modifiez une ressource de compute, développez la section **Options avancées** et sélectionnez l'onglet **tab**. Vous verrez un menu déroulant **SSD local** qui vous permet de choisir le nombre de SSD locaux à attacher à chaque nœud. Le SSD local peut uniquement être configuré pour certains types d'instances GCP de première et deuxième générations (par exemple : n1, n2 et n2d).

Le menu déroulant comprend une option **default** ainsi que des valeurs numériques spécifiques. **Default** utilise le nombre standard de SSD locaux pour le type d'instance sélectionné. Pour les types d'instance avec le suffixe -lssd (tels que c3-standard-8-lssd), le nombre de SSD locaux est fixe et intégré au type d'instance. Reportez-vous à la documentation GCP pour connaître le nombre de SSD locaux pris en charge pour chaque type d'instance.

Compute à nœud unique​

La case à cocher Nœud unique vous permet de créer une ressource de compute à nœud unique.

Le compute à nœud unique est destiné aux Jobs qui utilisent de petites quantités de données ou des charges de travail non distribuées telles que des bibliothèques de machine learning à nœud unique. Le compute multi-nœuds doit être utilisé pour les Jobs plus importants avec des charges de travail distribuées.

Propriétés du nœud unique​

Une ressource de compute à nœud unique possède les propriétés suivantes :

  • Spark s'exécute localement.
  • Le Driver agit à la fois comme maître et worker, sans nœud worker.
  • Génère un thread d'exécuteur par cœur logique dans la ressource de compute, moins 1 cœur pour le Driver.
  • Enregistre toutes les sorties de log stderr, stdout et log4j dans les logs du driver.
  • Impossible de convertir en ressource de compute multi-nœuds.

Sélection de nœud unique ou multiple​

Considérez votre cas d'utilisation lorsque vous choisissez entre un compute à nœud unique ou à nœuds multiples :

  • Le traitement de données à grande échelle épuisera les ressources d'une ressource de compute à nœud unique. Pour ces charges de travail, Databricks recommande d'utiliser le compute multi-nœuds.

  • Une ressource de compute multi-nœuds ne peut pas être mise à l'échelle à 0 worker. Utilisez plutôt un compute à nœud unique.

  • La planification GPU n’est pas activée sur le compute à nœud unique.

  • Sur un compute à nœud unique, Spark ne peut pas lire les fichiers Parquet avec une colonne UDT. Le message d'erreur suivant s'affiche :

    Console
    The Spark driver has stopped unexpectedly and is restarting. Your notebook will be automatically reattached.

    Pour contourner ce problème, désactivez le lecteur Parquet natif :

    Python
    spark.conf.set("spark.databricks.io.parquet.nativeReader.enabled", False)

Activer la mise à l'échelle automatique​

Lorsque Activer la mise à l'échelle automatique est cochée, vous pouvez spécifier un nombre minimal et maximal de Worker pour la ressource de compute. Databricks choisit ensuite le nombre de Worker approprié requis pour exécuter votre Job.

Pour définir le nombre minimum et maximum de workers entre lesquels votre ressource de compute s'adaptera automatiquement, utilisez les champs Min et Max à côté du menu déroulant Worker type .

Si vous n'activez pas la mise à l'échelle automatique, vous devez saisir un nombre fixe de workers dans le champ Workers , à côté du menu déroulant Worker type .

remarque

Lorsque la ressource de compute est en cours d'exécution, la page des détails compute affiche le nombre de Workers alloués. Vous pouvez comparer le nombre de Worker alloués avec la configuration du Worker et effectuer les ajustements nécessaires.

Avantages de la mise à l'échelle automatique​

Avec l'autoscaling, Databricks réalloue dynamiquement les workers pour tenir compte des caractéristiques de votre job. Certaines parties de votre pipeline peuvent être plus exigeantes en calcul que d'autres, et Databricks ajoute automatiquement des Workers supplémentaires pendant ces phases de votre Job (et les supprime lorsqu'ils ne sont plus nécessaires).

L'autoscaling facilite l'obtention d'une utilisation élevée, car vous n'avez pas besoin de provisionner le compute pour qu'il corresponde à une charge de travail. Cela s'applique particulièrement aux charges de travail dont les exigences changent au fil du temps (comme l'exploration d'un dataset au cours d'une journée), mais cela peut également s'appliquer à une charge de travail ponctuelle plus courte dont les exigences de provisionnement sont inconnues. Le dimensionnement automatique offre ainsi deux avantages :

  • Les charges de travail peuvent s'exécuter plus rapidement comparativement à une ressource de compute de taille constante sous-provisionnée.
  • L'autoscaling peut réduire les coûts globaux par rapport à une ressource de compute de taille statique.

Selon la taille constante de la ressource de compute et de la charge de travail, la mise à l'échelle automatique vous offre l'un ou l'autre de ces avantages en même temps. La taille du compute peut descendre en dessous du nombre minimal de Worker sélectionnés lorsque le fournisseur cloud met fin aux instances. Dans ce cas, Databricks tente continuellement de re-provisionner des instances afin de maintenir le nombre minimum de Workers.

remarque

L'autoscaling n'est pas disponible pour les spark-submit Jobs.

remarque

La mise à l’échelle automatique de compute présente des limites pour réduire la taille du cluster pour les charges de travail Structured Streaming. Databricks recommande d'utiliser Spark Declarative Pipelines sur Lakeflow avec une mise à l'échelle automatique améliorée pour les charges de travail de streaming. Voir Optimiser l’utilisation des clusters de LakeFlow Pipelines avec l’autoscaling.

Comment le dimensionnement automatique se comporte​

Autoscaling présente les caractéristiques suivantes :

  • Il commence par ajouter 8 nœuds. Ensuite, il monte en charge de manière exponentielle, en effectuant autant d'étapes que nécessaire pour atteindre le maximum.
  • Réduction de taille lorsque 90 % des nœuds ne sont pas occupés pendant 10 minutes et que le compute est inactif pendant au moins 30 secondes.
  • Réduit de façon exponentielle, à partir d'1 nœud.
attention

N'activez pas l'allocation dynamique Apache Spark (spark.dynamicAllocation.enabled) sur les ressources de compute qui utilisent le dimensionnement automatique de Databricks. Le dimensionnement automatique de Databricks gère les nœuds worker et le cycle de vie des exécuteurs au niveau de la plateforme. L'activation de l'allocation dynamique de Spark en parallèle peut entraîner des décisions de dimensionnement conflictuelles, ce qui peut entraîner un renouvellement fréquent des exécuteurs, des erreurs NODES_LOST et des tâches jamais prises en charge.

Dimensionnement automatique avec des Pools​

Si vous associez votre ressource de compute à un pool, veuillez prendre en compte les éléments suivants :

  • Assurez-vous que la taille de compute demandée est inférieure ou égale au nombre minimal d'instances inactives dans le pool. S'il est plus grand, le temps de Startup du compute sera équivalent à un compute qui n'utilise pas de Pool.

Exemple de dimensionnement automatique​

Si vous reconfigurez une ressource de compute statique pour la mise à l’échelle automatique, Databricks redimensionne immédiatement la ressource de compute dans les limites minimale et maximale, puis start la mise à l’échelle automatique. À titre d’exemple, le tableau suivant montre ce qui se produit pour une ressource de compute d’une certaine taille initiale si vous la reconfigurez pour une mise à l’échelle automatique entre 5 et 10 nœuds.

Taille initiale

Taille après reconfiguration

6

6

12

10

3

5

Taille initiale

Taille après reconfiguration

6

6

12

10

3

5

Paramètres de performances avancées​

Le paramètre suivant apparaît sous la section Performances avancées dans l’interface utilisateur de compute du formulaire simple.

Instances préemptables​

Une instance de VM préemptable est une instance que vous pouvez créer et exécuter à un prix bien inférieur à celui des instances normales. Cependant, Google Cloud peut arrêter (préempter) ces instances s’il a besoin d’accéder à ces Ressources pour d’autres tâches. Les instances préemptables utilisent la capacité excédentaire de Google compute Engine, de sorte que leur disponibilité varie en fonction de l’utilisation.

Lorsque vous créez une nouvelle ressource de compute, vous pouvez activer les instances de VM préemptables de deux manières différentes :

  1. Lorsque vous créez un compute à l'aide de l'interface utilisateur, cliquez sur la case à cocher Utiliser des instances préemptibles sous Performances avancées .
  2. Lorsque vous créez un Pool d'instances à l'aide de l'interface utilisateur, définissez À la demande/Préemptible sur Toutes les instances préemptibles , Préemptible avec fallback GCP ou À la demande GCP . Si les instances de machine virtuelle préemptibles ne sont pas disponibles, le compute reviendra par default à l'utilisation d'instances de machine virtuelle à la demande. Pour configurer le comportement de repli, définissez gcp_attributes.gcp_availability sur PREEMPTIBLE_GCP ou PREEMPTIBLE_WITH_FALLBACK_GCP. La valeur default est ON_DEMAND_GCP.
JSON
{
  "instance_pool_name": "Preemptible w/o fallback API test",
  "node_type_id": "n1-highmem-4",
  "gcp_attributes": {
    "availability": "PREEMPTIBLE_GCP"
  }
}

Ensuite, créez une nouvelle ressource de compute et définissez **Pool** sur un pool d'instances préemptives.

Arrêt automatique​

Vous pouvez définir l'arrêt automatique pour le compute dans la section Performances du formulaire de création de compute. Lors de la création de compute, spécifiez une période d’inactivité en minutes après laquelle la ressource de compute doit être arrêtée.

Si la différence entre l'heure actuelle et la dernière commande exécutée sur la ressource de compute est supérieure à la période d'inactivité spécifiée, Databricks met fin automatiquement à cette ressource de compute. Pour plus d'information sur la résiliation de compute, voir Mettre fin à un compute.

Type de Driver​

Vous pouvez sélectionner le type de Driver dans la section Performances avancées . Le nœud Driver gère les information d'état de tous les Notebook attachés à la ressource compute. Le nœud Driver gère également le SparkContext, interprète toutes les commandes que vous exécutez à partir d'un Notebook ou d'une bibliothèque sur la ressource compute, et exécute le maître Apache Spark qui se coordonne avec les exécuteurs Spark.

La valeur par default du type de nœud Driver est la même que celle du type de nœud Worker. Vous pouvez choisir un type de nœud Driver plus grand avec plus de mémoire si vous prévoyez de collect() de nombreuses données depuis les Worker Spark et de les analyser dans le Notebook.

astuce

Étant donné que le nœud driver maintient toutes les informations d'état des Notebooks attachés, assurez-vous de détacher les Notebooks inutilisés du nœud driver.

Tags​

Les tags vous permettent de surveiller facilement le coût des Ressources cloud utilisées par les différents groupes de votre organisation. Spécifiez les tags sous forme de paires clé-valeur lorsque vous créez le compute, et Databricks applique ces tags aux pods Databricks Runtime et aux volumes persistants sur le cluster GCE, ainsi qu'aux logs d'utilisation DBU.

Les graphiques d'utilisation facturable Databricks dans la console de compte peuvent agréger l'utilisation par balises individuelles. Les rapports CSV d'utilisation facturable download depuis la même page incluent également des tags default et personnalisés. Les tags se propagent également aux étiquettes GKE et GCE.

Pour des informations détaillées sur la façon dont les types de tags de pool et de compute fonctionnent ensemble, consultez Utiliser des tags pour attribuer et suivre l'utilisation.

Pour ajouter des tags à votre ressource de compute :

  1. Dans la section Tags , ajoutez une paire clé-valeur pour chaque tag personnalisé.
  2. Cliquez sur **Ajouter**.

Paramètres avancés​

Les paramètres suivants apparaissent sous la section **Avancé** de l'interface utilisateur de compute de formulaire simple :

Modes d'accès​

Le mode d'accès est une fonctionnalité de sécurité qui détermine qui peut utiliser la ressource de compute et les données auxquelles ils peuvent accéder en utilisant la ressource de compute. Chaque ressource de compute dans Databricks a un mode d'accès. Les paramètres du mode d'accès se trouvent sous la section **Avancé** de l'interface utilisateur de compute de formulaire simple.

La sélection du mode d'accès est **Auto** by default, ce qui signifie que le mode d'accès est automatiquement choisi pour vous en fonction de votre Databricks Runtime sélectionné. Auto correspond par défaut à **Standard**, sauf si un runtime de Machine Learning, un type d'instance GPU ou un Databricks Runtime inférieur à 14.3 est sélectionné, auquel cas **Dedicated** est utilisé.

Databricks recommande d'utiliser le mode d'accès standard, sauf si la fonctionnalité requise n'est pas prise en charge.

Mode d'accès

Description

Langues prises en charge

Standard

Peut être utilisé par plusieurs utilisateurs avec une isolation des données entre les utilisateurs.

Python, SQL, Scala

Dédié

Peut être attribué à et utilisé par un utilisateur unique ou un groupe.

Python, SQL, Scala, R

Mode d'accès

Description

Langues prises en charge

Standard

Peut être utilisé par plusieurs utilisateurs avec une isolation des données entre les utilisateurs.

Python, SQL, Scala

Dédié

Peut être attribué à et utilisé par un utilisateur unique ou un groupe.

Python, SQL, Scala, R

Pour des informations détaillées sur la prise en charge des fonctionnalités pour chacun de ces modes d’accès, consultez Exigences et limitations du compute standard et Exigences et limitations du compute dédié.

remarque

Dans Databricks Runtime 13.3 LTS et versions ultérieures, les scripts d'initialisation et les bibliothèques sont pris en charge par tous les modes d'accès. Les exigences et les niveaux de support varient. Voir Où les scripts d'initialisation peuvent-ils être installés ? et les bibliothèques Compute-scoped.

Compte de service Google​

Pour associer cette ressource de compute à un compte de service Google via Google Identity, cliquez sur Avancé , puis sur Compte de service Google , et ajoutez l'adresse e-mail de votre compte de service Google dans le champ Compte de service Google . Cette valeur est utilisée pour s'authentifier auprès des GCS et BigQuery sources de données.

important

Le compte de service que vous utilisez pour accéder aux sources de données GCS et BigQuery doit se trouver dans le même projet que le compte de service spécifié lors de la configuration de votre compte Databricks.

Zones de disponibilité​

Dans la page de configuration du compute, sous Avancé > Instances , sélectionnez la zone de disponibilité de la ressource de compute. Ce paramètre vous permet de spécifier la zone de disponibilité que la ressource de compute doit utiliser. Par default, le paramètre de zone de disponibilité est défini sur Automatique . Avec un paramètre **Auto**, une seule zone de disponibilité est automatiquement sélectionnée pour vous.

Vous pouvez également choisir une zone spécifique. Le choix d'une zone spécifique est principalement utile si votre organisation a acheté des instances réservées dans des zones de disponibilité spécifiques.

Zone de haute disponibilité​

Vous pouvez également sélectionner HA comme zone de disponibilité. La haute disponibilité (HA) est une fonctionnalité système conçue pour fournir un niveau de disponibilité cohérent pendant des périodes prolongées. L'utilisation d'une configuration de zone HA peut réduire la probabilité de problèmes de disponibilité en zone unique, tels que l'indisponibilité zonale ou l'incapacité à approvisionner la capacité d'instance dans une zone.

Lorsque HA est sélectionné comme zone de disponibilité, Databricks équilibre le placement des instances entre les zones d'une région. Cela pourrait entraîner une augmentation du prix en raison des frais de sortie de données interzones.

Activer la mise à l'échelle automatique du stockage local​

Les instances Google Cloud compute peuvent être complétées par un stockage additionnel au niveau du Worker à l'aide de disques persistants zonal à semi-conducteurs.

Avec le stockage local à mise à l’échelle automatique, Databricks surveille la quantité d’espace disque libre disponible sur les Worker Spark de votre compute. Si un Worker commence à manquer d'espace disque, Databricks redimensionne automatiquement le SSD PD zonal avant qu'il ne manque d'espace disque. Les volumes de SSD PD zonaux sont attachés jusqu'à une limite de 5 To d'espace disque total par instance (y compris le stockage local de l'instance).

Pour configurer Activer le dimensionnement automatique du stockage local , ouvrez la section Avancé et cliquez sur le tab Instances.

Chiffrement de disque local​

Les types d'instance dotés de SSD locaux sont chiffrés avec le chiffrement côté serveur Google Cloud par default. Consultez Types d'instances avec SSD locaux.

Configuration Spark​

Pour affiner les Jobs Spark, vous pouvez fournir des propriétés de configuration Spark personnalisées.

remarque

Dans le mode d'accès standard sur Databricks Runtime 19 et versions ultérieures, certaines propriétés de configuration Spark sont restreintes. La création ou la modification d'un cluster qui définit une propriété restreinte échoue avec une erreur. Consultez les limitations de configuration Spark.

  1. Sur la page de configuration du compute, cliquez sur le bouton bascule Avancé .

  2. Cliquez sur l'onglet Spark .

    Configuration Spark

  3. Dans **Configuration Spark**, saisissez les propriétés de configuration sous la forme d'une paire clé-valeur par ligne.

Lorsque vous configurez le compute à l’aide de l’ API Clusters, définissez les propriétés Spark dans le champ spark_conf de l’ API de création de cluster ou de l’ API de mise à jour de cluster.

Pour appliquer les configurations Spark sur le compute, les administrateurs de Workspace peuvent utiliser les politiques de compute.

Récupérer une propriété de configuration Spark à partir d'un secret​

Databricks recommande de stocker les informations sensibles, telles que les mots de passe, dans un secret au lieu du texte en clair. Pour référencer un secret dans la configuration Spark, utilisez la syntaxe suivante :

ini
spark.<property-name> {{secrets/<scope-name>/<secret-name>}}

Par exemple, pour définir une propriété de configuration Spark appelée password à la valeur du secret stocké dans secrets/acme_app/password:

ini
spark.password {{secrets/acme-app/password}}

Pour plus d'informations, consultez Gérer les secrets.

Livraison des log compute​

Lorsque vous créez du compute polyvalent ou des jobs, vous pouvez spécifier un emplacement pour les logs de cluster, y compris les logs du driver Spark, des nœuds worker et des événements. Les Logs sont livrés toutes les cinq minutes et archivés toutes les heures dans la destination sélectionnée. Databricks continue de livrer les Logs jusqu'à ce que la ressource de compute soit terminée.

Vous pouvez stocker les Logs dans l'un des emplacements suivants :

  • Volumes (recommandé) : stocke les journaux dans un chemin de volume Unity Catalog. C’est l’option recommandée et la plus sécurisée lors de l’utilisation des ressources compute compatibles avec Unity Catalog.

  • DBFS (hérité) : stocke les logs dans le chemin du système de fichiers Databricks (DBFS). Cette option n'est disponible que si la racine et les montages DBFS ne sont pas désactivés pour l'Workspace. Consultez Désactiver l'accès à la racine et aux montages DBFS dans votre Workspace Databricks existant.

Pour configurer l'emplacement de livraison des log :

  1. Sur la page du compute, cliquez sur le bouton bascule Avancé .
  2. Cliquez sur l'onglet tab .
  3. Sélectionnez un type de destination.
  4. Saisissez le Chemin d'accès du Log .

Pour stocker les logs, Databricks crée un sous-dossier dans le chemin d'accès aux logs que vous avez choisi, nommé d'après le cluster_id du compute.

Par exemple, si le chemin d'accès aux Logs spécifié est /Volumes/catalog/schema/volume, les Logs de 06308418893214 sont fournis à /Volumes/catalog/schema/volume/06308418893214.

remarque

La livraison des Logs vers un volume n'est prise en charge que sur le compute compatible Unity Catalog avec le mode d'accès Standard ou le mode d'accès Dédié attribué à un utilisateur. Ce n'est pas pris en charge avec le mode d'accès Dédié attribué à un groupe. Si vous sélectionnez un volume comme chemin d'accès, vérifiez que le propriétaire du compute ou l'utilisateur qui lui est attribué dispose des autorisations READ VOLUME et WRITE VOLUME sur le volume. Voir les privilèges pour les volumes Unity Catalog.

Variables d'environnement​

Configurez des variables d'environnement personnalisées auxquelles vous pouvez accéder à partir des scripts d'initialisation exécutés sur la ressource compute. Databricks fournit également des variables d'environnement prédéfinies que vous pouvez utiliser dans les scripts d'initialisation. Vous ne pouvez pas remplacer ces variables d'environnement prédéfinies.

remarque

En mode d'accès standard sur Databricks Runtime 19 et versions ultérieures, seul un ensemble prédéfini de variables d'environnement est disponible pour le moteur Spark et les scripts d'initialisation. Les autres variables que vous définissez sur un cluster restent disponibles pour votre code utilisateur, y compris les UDF. Voir les Limitations des variables d'environnement.

  1. Sur la page de configuration du compute, cliquez sur Avancé .

  2. Cliquez sur l'onglet Spark .

  3. Définissez les variables d'environnement dans le champ Variables d'environnement .

    Champ Variables d&#39;environnement

remarque

ENV est un mot réservé et ne peut pas être utilisé comme nom de variable d'environnement.

Vous pouvez également définir des variables d'environnement à l'aide du champ spark_env_vars dans l'API de création de clusters ou l'API de mise à jour de clusters.

Sur cette page