Configurer compute (ancienne version)

remarque

Il s'agit d'instructions pour l'ancienne interface utilisateur de création de cluster, et elles ne sont incluses qu'à des fins de précision historique. Tous les clients devraient utiliser l'interface utilisateur de création de clusters mise à jour.

remarque

La fonctionnalité CLI est indisponible sur Databricks sur Google Cloud à compter de cette version.

Cet article explique les options de configuration disponibles lorsque vous créez et modifiez des clusters Databricks. Il se concentre sur la création et la modification de clusters à l'aide de l'interface utilisateur. Pour les autres méthodes, consultez la CLI Databricks, l'API Clusters et le fournisseur Databricks Terraform.

Pour vous aider à décider quelle combinaison d'options de configuration répond le mieux à vos besoins, consultez les bonnes pratiques de configuration de clusters.

Règle de cluster

Une politique de clusters limite la capacité de configurer des clusters selon un ensemble de règles. Les règles de la politique limitent les attributs ou les valeurs d'attributs disponibles pour la création de clusters. Les règles de cluster ont des ACL qui limitent leur utilisation à des utilisateurs et groupes spécifiques et limitent ainsi les règles que vous pouvez sélectionner lorsque vous créez un cluster.

Pour configurer une règle de cluster, sélectionnez la règle de cluster dans le menu déroulant Règle .

remarque

Si aucune politique n'a été créée dans le Workspace, la liste déroulante Politique ne s'affiche pas.

Si vous avez :

• Avec l'autorisation de création de cluster, vous pouvez sélectionner la politique Non restreint et créer des clusters entièrement configurables. La politique non restreinte ne limite pas les attributs de cluster ou les valeurs d'attribut.
• Grâce à l'autorisation de création de cluster et à l'accès aux politiques de cluster, vous pouvez sélectionner la politique Sans restriction et les politiques auxquelles vous avez accès.
• Accès aux politiques de clusters uniquement ; vous pouvez sélectionner les politiques auxquelles vous avez accès.

Mode de cluster

Databricks prend en charge trois modes de clusters : Standard, High Concurrency et Nœud unique. Le mode de cluster par default est Standard.

important

Vous ne pouvez pas changer le mode du cluster après sa création. Si vous souhaitez un mode de cluster différent, vous devez créer un nouveau cluster.

La configuration du cluster inclut un paramètre d'arrêt automatique dont la valeur par default dépend du mode de cluster :

• Les clusters Standard et Single Node se terminent automatiquement après 120 minutes par default.
• Les high concurrency clusters ne se terminent pas automatiquement par default.

Clusters standard

attention

Les clusters en mode standard (parfois appelés clusters partagés sans isolation) peuvent être partagés par plusieurs utilisateurs, sans isolation entre les utilisateurs. Si vous utilisez le mode de cluster à haute simultanéité sans ACL de table , les mêmes paramètres sont utilisés que pour les clusters en mode Standard. Les administrateurs de compte peuvent empêcher la génération automatique d'identifiants internes pour les administrateurs de workspace Databricks sur ces types de clusters. Pour des options plus sécurisées, Databricks recommande des alternatives telles que des clusters high concurrency avec des listes de contrôle d'accès de table.

Un cluster Standard est recommandé uniquement pour les utilisateurs mono-utilisateurs. Les clusters standard peuvent exécuter des workloads développés en Python, SQL, R et Scala.

high concurrency clusters

Un cluster High Concurrency est une ressource cloud gérée. Les principaux avantages des clusters High Concurrency sont qu'ils offrent un partage granulaire pour une utilisation maximale des ressources et des latences de query minimales.

Les clusters High Concurrency peuvent exécuter des charges de travail développées en SQL, Python et R. Les performances et la sécurité des clusters High Concurrency sont assurées par l'exécution du code utilisateur dans des processus séparés, ce qui n'est pas possible en Scala.

De plus, seuls les clusters high concurrency prennent en charge le contrôle d'accès aux tables.

Pour créer un cluster High Concurrency, définissez le Mode de cluster sur High Concurrency .

clusters Single Node

Un cluster à nœud unique n'a pas de Worker et exécute des Jobs Spark sur le nœud Driver.

En revanche, un cluster Standard requiert *au moins un* nœud worker Spark en plus du nœud driver pour exécuter des jobs Spark.

Pour créer un cluster à nœud unique, définissez le Mode de cluster sur Nœud unique .

Pour en savoir plus sur l'utilisation des clusters à nœud unique, consultez Compute à nœud unique.

Pool

Pour réduire le temps de start du cluster, vous pouvez attacher un cluster à un pool prédéfini d'instances inactives. Le cluster est créé à l'aide d'instances dans le pool. Si un Pool ne dispose pas de Ressources inactives suffisantes pour créer le Driver ou les Worker demandés, le Pool s'agrandit en allouant de nouvelles instances auprès du fournisseur d'instances. Lorsqu'un cluster attaché est arrêté, les instances qu'il utilisait sont retournées au pool et peuvent être réutilisées par un autre cluster.

Consultez la référence de configuration des Pools pour en savoir plus sur l’utilisation des Pools dans Databricks.

Databricks Runtime

Les runtimes Databricks sont l'ensemble des composants principaux qui s'exécutent sur vos clusters. Tous les runtimes Databricks incluent Apache Spark et ajoutent des composants et des mises à jour qui améliorent la convivialité, les performances et la sécurité. Pour plus de détails, voir versions et compatibilité des notes de version de Databricks Runtime.

Databricks propose plusieurs types d'environnements d'exécution et plusieurs versions de ces types d'environnements d'exécution dans la liste déroulante Databricks Runtime Version lorsque vous créez ou modifiez un cluster.

Accélération de Photon

Photon est disponible pour les clusters exécutant Databricks Runtime 9.1 LTS et versions ultérieures.

Pour activer l'accélération Photon, sélectionnez la case à cocher Utiliser l'accélération Photon .

Si vous le souhaitez, vous pouvez spécifier le type d'instance dans la liste déroulante Type de Worker et Type de Driver.

Vous pouvez afficher l'activité Photon dans la Spark UI. La capture d'écran suivante montre le DAG des détails de la query. Il existe deux indications de Photon dans le DAG. Tout d'abord, les opérateurs Photon start par « Photon », par exemple, PhotonGroupingAgg. Deuxièmement, dans le DAG, les opérateurs et les étapes Photon sont colorés en pêche, tandis que ceux qui ne sont pas Photon sont bleus.

Images Docker

Pour certaines versions de Databricks Runtime, vous pouvez spécifier une image Docker lorsque vous créez un cluster. Les exemples de cas d'utilisation incluent la personnalisation de la bibliothèque, un environnement de conteneur de référence qui ne change pas et l'intégration Docker CI/CD.

Vous pouvez également utiliser des images Docker pour créer des environnements de deep learning personnalisés sur des clusters avec des appareils GPU.

Pour obtenir des instructions, consultez Databricks Container Services pour compute dédié et Databricks Container Services sur compute GPU.

Type de nœud de cluster

Un cluster 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. Différentes familles de types d'instances conviennent à différents cas d'utilisation, tels que les charges de travail gourmandes en mémoire ou gourmandes en compute.

• Nœud Driver
• Nœud worker
• Types d'instances GPU
• Types d'instances de clusters avec des SSD locaux

Nœud Driver

Le nœud Driver maintient les informations d'état de tous les Notebooks attachés au cluster. Le nœud Driver maintient également le SparkContext et interprète toutes les commandes que vous exécutez à partir d'un Notebook ou d'une bibliothèque sur le cluster, 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.

Nœud Worker

Les nœuds Worker Databricks exécutent les exécuteurs Spark et d'autres services nécessaires au bon fonctionnement des clusters. 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 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 un cluster a zéro Workers, vous pouvez exécuter des commandes non-Spark sur le nœud du Driver, mais les commandes Spark échoueront.

Types d'instances GPU

Pour les tâches exigeantes en calcul qui requièrent des performances élevées, comme celles associées à l'apprentissage profond, Databricks prend en charge les clusters accélérés par des unités de traitement graphique (GPU). Pour plus d'informations, voir compute compatible GPU.

Types d'instance de cluster 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 dotées de SSD locaux sont chiffrés avec le chiffrement default côté serveur de Google Cloud.

Les types d'instance avec des SSD locaux utilisent automatiquement la mise en cache du disque pour de meilleures performances. 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.

Taille du cluster et mise à l'échelle automatique

Lorsque vous créez un cluster Databricks, vous pouvez soit fournir un nombre fixe de workers pour le cluster, soit un nombre minimal et maximal de workers pour le cluster.

Lorsque vous fournissez un cluster de taille fixe, Databricks s'assure que votre cluster dispose du nombre spécifié de workers. Lorsque vous fournissez une plage pour le nombre de workers, Databricks choisit le nombre de workers approprié requis pour exécuter votre Job. C'est ce qu'on appelle le dimensionnement 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'atteinte d'un taux d'utilisation élevé des clusters, car vous n'avez pas besoin de provisionner le cluster pour correspondre à 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 workloads peuvent s'exécuter plus rapidement par rapport à un cluster sous-provisionné de taille constante.
• Les clusters à mise à l'échelle automatique peuvent réduire les coûts globaux par rapport à un cluster de taille statique.

Selon la taille constante du cluster et de la charge de travail, l’autoscaling vous offre un ou les deux de ces avantages simultanément. La taille du cluster peut descendre en dessous du nombre minimal de Worker sélectionné lorsque le fournisseur cloud arrête les 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.

Comment le dimensionnement automatique se comporte

• Il passe de min. à max. en 2 étapes.
• Peut réduire même si le cluster n'est pas inactif en examinant l'état du fichier de brassage.
• Se réduit en fonction d'un pourcentage de nœuds actuels.
• Sur les clusters de job, diminue sa taille si le cluster est sous-utilisé au cours des 40 dernières secondes.
• Sur les clusters à usage général, sa taille est réduite si le cluster est sous-utilisé au cours des 150 dernières secondes.
• La propriété de configuration Spark spark.databricks.aggressiveWindowDownS spécifie en secondes la fréquence à laquelle un cluster prend des décisions de réduction d'échelle. L’augmentation de la valeur entraîne une réduction plus lente de l’échelle d’un cluster. La valeur maximale est de 600.

Activez et configurez la mise à l'échelle automatique

Pour permettre à Databricks de redimensionner votre cluster automatiquement, vous activez la mise à l’échelle automatique pour le cluster et fournissez la plage minimale et maximale de Workers.

1. Activez la mise à l'échelle automatique.

   • Cluster polyvalent - Sur la page Créer un cluster, cochez la case Activer la mise à l'échelle automatique dans la zone Options de pilote automatique :

     

   • Cluster Job — Sur la page Configurer le cluster, cochez la case Activer la mise à l'échelle automatique dans le cadre Options de pilote automatique :

     

2. Configurez le nombre minimal et maximal de workers.

   

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

important

Si vous utilisez un pool d'instances:

• Assurez-vous que la taille des clusters 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 cluster sera équivalent à un cluster qui n'utilise pas de Pool.

Exemple de dimensionnement automatique

Si vous reconfigurez un cluster statique en un cluster à mise à l'échelle automatique, Databricks redimensionne immédiatement le cluster dans les limites minimale et maximale, puis start la mise à l'échelle automatique. À titre d'exemple, le tableau suivant illustre ce qui arrive aux clusters d'une certaine taille initiale si vous reconfigurez un cluster 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

Configurations Google Cloud

Lorsque vous configurez les instances Google Cloud d'un cluster, vous pouvez spécifier des options spécifiques à Google Cloud.

Utiliser des 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 un nouveau cluster, vous pouvez activer des instances de VM préemptibles de deux manières différentes :

1. Lorsque vous créez un cluster à l'aide de l'UI, vous pouvez cliquer sur **instances préemptables** à côté des détails du **Type de Worker**.
2. Lorsque vous créez un pool d'instances via l'interface utilisateur, vous pouvez définir À la demande/Préemptible sur Toutes les instances préemptibles , Préemptible avec fallback GCP , ou À la demande GCP . Si les instances de machines virtuelles (VM) préemptibles ne sont pas disponibles, le cluster utilisera par default des instances de machines virtuelles (VM) à 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": {
    "gcp_availability": "PREEMPTIBLE_GCP"
  }
}

Ensuite, créez un nouveau cluster et définissez **Pool** sur un pool d'instances préemptives.

Compte de service Google

Pour associer ce cluster à un compte de service Google à l'aide de Google Identity, cliquez sur Options avancées 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.

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. Voir Types d'instances de cluster avec SSD locaux.

Configuration Spark

Pour affiner les jobs Spark, vous pouvez fournir des propriétés de configuration Spark personnalisées dans une configuration de cluster.

1. Sur la page de configuration du cluster, cliquez sur le bouton bascule **Options avancées**.

2. Cliquez sur l'onglet Spark .

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

Lorsque vous configurez un cluster à l'aide de l'API de cluster, 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 la configuration de cluster.

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.

Variables d'environnement

Vous pouvez configurer des variables d'environnement personnalisées auxquelles vous pouvez accéder à partir des scripts d'initialisation s'exécutant sur un cluster. 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.

1. Sur la page de configuration du cluster, cliquez sur le bouton bascule **Options avancées**.

2. Cliquez sur l'onglet Spark .

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

   

Vous pouvez également définir des variables d'environnement en utilisant le champ spark_env_vars dans l'API de création de nouveau cluster ou l'API de mise à jour de la configuration de cluster.

Cluster Tag

Les Cluster Tag vous permettent de surveiller facilement le coût des ressources cloud utilisées par les différents groupes de votre organisation. Vous pouvez spécifier des tags sous forme de paires clé-valeur lorsque vous créez un cluster, et Databricks applique ces tags aux pods Databricks Runtime et aux volumes persistants sur le cluster GCE et pour une utilisation dans les rapports d'utilisation DBU de Databricks.

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 Pool et de Cluster Tag fonctionnent ensemble, consultez Utiliser des tags pour attribuer et suivre l'utilisation.

Par commodité, Databricks applique quatre balises default à chaque cluster : Vendor, Creator, ClusterName et ClusterId.

De plus, sur les clusters de Job, Databricks applique deux balises par default : RunName et JobId.

attention

N'attribuez pas de tag personnalisé avec la clé Name à un cluster. Chaque cluster possède un tag Name dont la valeur est définie par Databricks. Si vous modifiez la valeur associée à la clé Name, le cluster ne peut plus être suivi par Databricks. En conséquence, le cluster pourrait ne pas être arrêté après être devenu inactif et continuera d'engendrer des coûts d'utilisation.

Vous pouvez ajouter des tags personnalisés lorsque vous créez un cluster. Pour configurer les Cluster tags :

1. Sur la page de configuration du cluster, cliquez sur le bouton bascule **Options avancées**.

2. En bas de la page, cliquez sur la tab Tags .

   

3. Ajoutez une paire clé-valeur pour chaque tag personnalisé. Vous pouvez ajouter jusqu'à 54 balises personnalisées.

Accès SSH aux clusters

Le SSH des clusters n'est pas pris en charge dans cette version.

Pour une fonctionnalité connexe, consultez Exécuter des commandes shell dans le terminal web Databricks.

Cluster log delivery

Lorsque vous créez un cluster, vous pouvez spécifier un emplacement pour livrer les logs du nœud Driver Spark, des nœuds Worker et des événements. Les Logs sont livrés toutes les cinq minutes à la destination que vous avez choisie. Lorsqu'un cluster est arrêté, Databricks garantit la livraison de tous les Logs générés jusqu'à l'arrêt du cluster.

La destination des logs dépend de l'ID de cluster. Si la destination spécifiée est dbfs:/cluster-log-delivery, les Logs de cluster pour 0630-191345-leap375 sont livrés à dbfs:/cluster-log-delivery/0630-191345-leap375.

Pour configurer l'emplacement de livraison des log :

1. Sur la page de configuration du cluster, cliquez sur le bouton bascule **Options avancées**.

2. Cliquez sur l'onglet tab .

3. Sélectionnez un type de destination.

4. Saisissez le chemin d'accès aux Logs du cluster.

   Le chemin des logs doit être un chemin DBFS qui commence par dbfs:/.

remarque

Cette fonctionnalité est également disponible dans l'API REST. Consultez l'API Clusters.

Scripts d'initialisation

Un script d'initialisation – ou init – de nœud de cluster est un script Shell qui s'exécute au Startup de chaque nœud de cluster avant le start du Driver ou du Worker Spark JVM. Vous pouvez utiliser des scripts d'initialisation pour installer des packages et des bibliothèques non inclus dans le Databricks Runtime, modifier le classpath système de la JVM, définir les propriétés système et les variables d'environnement utilisées par la JVM, ou modifier les parameters de configuration Spark, entre autres tâches de configuration.

Vous pouvez attacher des scripts d'initialisation à un cluster en développant la section **Options avancées** et en cliquant sur l'onglet **tab**.

Pour des instructions détaillées, consultez Que sont les scripts d'initialisation ?.