Configurer des clusters
Remarque
Il s’agit d’instructions pour l’interface de création de cluster UI,et elles ne sont incluses que pour la précision historique. Tous les clients devraient utiliser l’interface de création de cluster mise à jour.
Cet article explique les options de configuration disponibles lorsque vous créez et modifiez des clusters Azure Databricks. Il se concentre sur la création et la modification de clusters à l’aide de l’interface utilisateur. Pour d’autres méthodes, consultez l’interface CLI Databricks, l’API de clusters et le fournisseur Databricks Terraform.
Pour vous aider à choisir la combinaison d’options de configuration adaptée à vos besoins, consultez meilleures pratiques en matière de configuration de cluster.
Stratégie de cluster
Une stratégie de cluster limite la possibilité de configurer des clusters en fonction d'un ensemble de règles. Les règles de stratégie limitent les attributs ou les valeurs d’attributs disponibles pour la création du cluster. Les stratégies de cluster ont des listes de contrôle d’accès qui limitent leur utilisation à des utilisateurs et des groupes spécifiques et limitent donc les stratégies que vous pouvez sélectionner lorsque vous créez un cluster.
Pour configurer une stratégie de cluster, sélectionnez la stratégie de cluster dans la liste déroulante Stratégie .
Remarque
Si aucune stratégie n’a été créée dans l’espace de travail, la liste déroulante des stratégies ne s’affiche pas.
Si vous avez :
- Autorisation de créer des clusters, vous pouvez sélectionner la politique Non-restreinte et créer des clusters entièrement configurables. La stratégie Non restreinte ne limite pas les attributs de cluster ou les valeurs d’attribut.
- Tant pour l'autorisation de création de cluster que pour l'accès aux politiques de cluster, vous pouvez sélectionner la politique Non restreinte et les politiques auxquelles vous avez accès.
- Accès aux stratégies de cluster uniquement, vous pouvez sélectionner les stratégies auxquelles vous avez accès.
Mode Cluster
Remarque
Cet article décrit l’interface utilisateur des clusters héritée. Pour plus d’informations sur la nouvelle interface utilisateur des clusters (en préversion), consultez Informations de référence sur la configuration de calcul. Cela inclut certaines modifications terminologiques pour les types et modes d’accès au cluster. Pour une comparaison des nouveaux types de cluster hérités, consultez Modifications apportées à l’interface utilisateur des clusters et aux modes d’accès au cluster. Dans l’interface utilisateur en préversion :
- Les clusters en mode standard sont désormais appelés clusters sans isolation en mode d’accès partagé.
- La haute concurrence avec les listes de contrôle d’accès des tables est désormais appelée clusters en mode d’accès partagé.
Azure Databricks prend en charge trois modes de cluster : standard, haute concurrence et nœud unique. Le mode de cluster par défaut est Standard.
Important
- Si votre espace de travail est attribué à un metastore Unity Catalog, aucun cluster à fort accès concurrentiel n’est disponible. Au lieu de cela, vous utilisez le mode d’accès pour assurer l’intégrité des contrôles d’accès et appliquer des garanties d’isolation fortes. Consultez également les modes d’accès.
- Vous ne pouvez pas modifier le mode de cluster après la création d’un cluster. Si vous souhaitez utiliser un autre mode de cluster, vous devez créer un nouveau cluster.
La configuration du cluster comprend un paramètre de terminaison automatique dont la valeur par défaut dépend du mode de cluster :
- Les clusters standard et à nœud unique se terminent automatiquement après 120 minutes par défaut.
- Les clusters à concurrence élevée ne se terminent pas automatiquement par défaut.
Clusters Standard
Avertissement
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 cluster haute concurrence sans paramètres de sécurité supplémentaires tels que les listes de contrôle d’accès de tableau ou la passe d’informations d’identification, les mêmes paramètres sont utilisés comme clusters en mode standard. Les administrateurs de compte peuvent empêcher la génération automatique des informations d’identification internes pour les administrateurs de l’espace de travail Databricks sur ces types de cluster. Pour des options plus sécurisées, Databricks recommande des alternatives telles que des clusters haute concurrence avec des listes de contrôle d’accès de table.
Un cluster standard est recommandé pour un seul utilisateur. Les clusters standard peuvent exécuter des charges de travail développées en Python, SQL, R et Scala.
Clusters à haute concurrence
Un cluster à concurrence élevée est une ressource Cloud gérée. Les principaux avantages des clusters à concurrence élevée sont qu’ils fournissent un partage affiné pour une utilisation maximale des ressources et des latences de requête minimales.
Les clusters à concurrence élevée peuvent exécuter des charges de travail développées dans SQL, Python et R. Les performances et la sécurité des clusters à haute concurrence sont assurées par l’exécution de code utilisateur dans des processus distincts, ce qui n’est pas possible dans Scala.
En outre, seuls les clusters avec un haut niveau de concurrence prennent en charge le contrôle d’accès aux tables.
Pour créer un cluster à concurrence élevée, définissez le mode de cluster à concurrentiel élevé.
Clusters à nœud unique
Un cluster à nœud unique n’a aucun travail et exécute des tâches Spark sur le nœud du pilote.
En revanche, un cluster standard nécessite au moins un nœud Worker Spark en plus du nœud Driver pour exécuter les travaux Spark.
Pour créer un cluster à nœud unique, définissez le mode cluster sur un mononœud.
Pour en savoir plus sur l’utilisation de clusters à nœud unique, consultez Calcul à nœud unique ou à nœuds multiples.
Pools
Pour réduire l’heure de début du cluster, vous pouvez attacher un cluster à un pool prédéfini d’instances inactives, pour les nœuds de pilote et de travail. Le cluster est créé à l’aide d’instances dans les pools. Si un pool ne dispose pas de suffisamment de ressources inactives pour créer le pilote ou les nœuds de travail demandés, le pool s'étend en allouant de nouvelles instances à partir du fournisseur d'instances. Quand 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.
Si vous sélectionnez un pool pour les nœuds Worker, mais pas pour le nœud Driver, le nœud Driver hérite du pool de la configuration du nœud Worker.
Important
Si vous tentez de sélectionner un pool pour le nœud de pilote mais pas pour les nœuds Worker, une erreur se produit et votre cluster n’est pas créé. Cette exigence empêche une situation où le nœud de pilote doit attendre la création de nœuds Worker, ou vice versa.
Pour en savoir plus sur l’utilisation des pools dans Azure Databricks, consultez Informations de référence sur la configuration de pool.
Databricks Runtime
Les runtimes Databricks sont l'ensemble des composants de base qui s'exécutent sur vos clusters. Tous les runtimes Databricks incluent des 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, consultez Notes de publication de Databricks Runtime, versions et compatibilité.
Azure Databricks offre plusieurs types de runtimes et plusieurs versions de ces types de Runtime dans la liste déroulante de la Version Databricks Runtime lorsque vous créez ou modifiez un cluster.
Accélération Photon
Photon est disponible pour les clusters exécutant Databricks Runtime 9.1 LTS et ultérieur.
Pour activer l’accélération Photon, cochez la case 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 pilote.
Databricks recommande les types d’instances suivants pour un prix optimal et des performances optimales :
- Standard_E4ds_v4
- Standard_E8ds_v4
- Standard_E16ds_v4
Vous pouvez afficher l’activité de photons dans l' interface utilisateur Spark. La capture d’écran suivante montre les détails de la requête DAG. Il existe deux indications de photons dans le DAG. Tout d’abord, les opérateurs de photons commencent par « photons », par exemple, PhotonGroupingAgg . Deuxièmement, dans le DAG, les opérateurs et les phases de photons sont des pêches de couleur, tandis que les autres sont bleus.
Images Docker
Pour certaines versions de Databricks Runtime, vous pouvez spécifier une image d’ancrage lorsque vous créez un cluster. Les exemples de cas d’usage incluent la personnalisation de bibliothèque, un environnement de conteneur Golden qui ne change pas et l’intégration d’intégration continue/de CD.
Vous pouvez également utiliser des images Docker pour créer des environnements personnalisés de deep learning (apprentissage profond) sur des clusters avec des périphériques GPU.
Pour obtenir des instructions, consultez Personnaliser des conteneurs avec les services de conteneur Databricks et Databricks Container Services sur un calcul GPU.
Type de nœud de cluster
Un cluster se compose d’un nœud de pilote et de zéro ou plusieurs nœuds de travail.
Vous pouvez choisir des types d’instances de fournisseur de Cloud distincts pour les nœuds de pilote et de travail, bien que le nœud de pilote utilise par défaut le même type d’instance que le nœud Worker. Différentes familles de types d'instances correspondent à différents cas d'utilisation, tels que les charges de travail à forte intensité de mémoire ou de calcul.
Remarque
Si vos exigences de sécurité incluent l’isolation de calcul, sélectionnez une instance Standard_F72s_V2 comme type de Worker. Ces types d'instance représentent des machines virtuelles isolées qui consomment la totalité de l'hôte physique et fournissent le niveau d'isolation nécessaire pour prendre en charge, par exemple, les charges de travail de niveau d'impact 5 (IL5) du ministère américain de la Défense.
Nœud de pilote
Le nœud de pilote conserve les informations d’état de tous les blocs-notes attachés au cluster. Le nœud de pilote gère é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 coordonne avec les exécuteurs Spark.
La valeur par défaut du type de nœud du pilote est identique à celle du type de nœud Worker. Vous pouvez choisir un plus grand type de nœud de pilote avec davantage de mémoire si vous envisagez collect() de nombreuses données des Workers Spark et de les analyser dans le bloc-notes.
Conseil
Étant donné que le nœud pilote conserve toutes les informations d’état des blocs-notes attachés, veillez à détacher les blocs-notes inutilisés du nœud pilote.
Nœud Worker
Azure Databricks nœuds Worker exécutent les exécuteurs Spark et d’autres services requis pour le bon fonctionnement des clusters. Lorsque vous distribuez votre charge de travail avec Spark, tout le traitement distribué se produit sur les nœuds Worker. Azure Databricks exécute un exécuteur par nœud de travail ; par conséquent, les termes executor et Worker sont utilisés de manière interchangeable dans le contexte de l’architecture Azure Databricks.
Conseil
Pour exécuter un travail Spark, vous avez besoin d’au moins un nœud Worker. Si un cluster ne possède aucun Worker, vous pouvez exécuter des commandes non-Spark sur le pilote, mais les commandes Spark échouent.
Types d’instances GPU
Pour les tâches nécessitant de nombreuses ressources de calcul qui exigent des performances élevées, comme celles associées à l’apprentissage profond, Azure Databricks prend en charge les clusters accélérés avec des unités de traitement graphique (GPU). Pour plus d’informations, consultez Calcul avec GPU.
Instances spot
Pour réduire les coûts, vous pouvez choisir d’utiliser des instances de points, également appelées machines virtuelles Azure, en cochant la case instances de points .
La première instance est toujours à la demande (le nœud de pilote est toujours à la demande) et les instances suivantes sont des instances de place. Si des instances ponctuelles sont évincées pour cause d'indisponibilité, des instances à la demande sont déployées pour remplacer les instances évincées.
Taille de cluster et mise à l’échelle automatique
Lorsque vous créez un cluster Azure Databricks, vous pouvez fournir un nombre fixe de workers pour le cluster ou fournir un nombre minimal et maximal de workers pour le cluster.
Lorsque vous fournissez un cluster de taille fixe, Azure Databricks garantit que votre cluster a le nombre spécifié de threads de travail. Lorsque vous fournissez une plage pour le nombre de Workers, Azure Databricks choisit le nombre approprié de Workers requis pour exécuter votre travail. C’est ce que l’on appelle la mise à l’échelle automatique.
Avec la mise à l'échelle automatique, Azure Databricks réaffecte dynamiquement les workers pour tenir compte des caractéristiques de votre travail. Certaines parties de votre pipeline peuvent être plus exigeantes en termes de calcul que d’autres, et Databricks ajoute automatiquement des Workers supplémentaires pendant ces phases de votre travail (et les supprime lorsqu’ils ne sont plus nécessaires).
La mise à l’échelle automatique facilite l’optimisation de l’utilisation du cluster, car vous n’avez pas besoin de provisionner le cluster en fonction d’une charge de travail. Cela s’applique en particulier aux charges de travail dont les exigences changent au fil du temps (comme l’exploration d’un jeu de données au cours d’une journée), mais elle peut également s’appliquer à une charge de travail unique plus rapide dont les exigences de provisionnement sont inconnues. La mise à l’échelle automatique offre donc deux avantages :
- Les charges de travail peuvent s’exécuter plus rapidement qu’avec un cluster sous-approvisionné de taille constante.
- La mise à l’échelle automatique des clusters peut réduire les coûts globaux par rapport à un cluster de taille statique.
En fonction de la taille constante du cluster 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 cluster peut être inférieure au nombre minimal de Workers sélectionnés lorsque le fournisseur de Cloud met fin aux instances. Dans ce cas, Azure Databricks tente continuellement de réapprovisionner les instances afin de conserver le nombre minimal de threads de travail.
Notes
La mise à l’échelle automatique n’est pas disponible pour les travaux spark-submit.
Comportement de la mise à l'échelle automatique
- La mise à l’échelle est comprise entre min et Max en 2 étapes.
- Peut monter en puissance même si le cluster n’est pas inactif en examinant l’état de lecture aléatoire des fichiers.
- Met à l’échelle en fonction d’un pourcentage de nœuds actuels.
- Sur les clusters de travail, descend en charge si le cluster est sous-exploité au cours des 40 dernières secondes.
- Sur les clusters polyvalents, réduit l'échelle si le cluster est sous-utilisé au cours des 150 dernières secondes.
- La propriété de configuration Spark
spark.databricks.aggressiveWindowDownSspécifie, en secondes, la fréquence à laquelle un cluster prend les décisions de mise à l’échelle. Si vous augmentez la valeur, un cluster est plus lent. La valeur maximale est 600.
Activer et configurer la mise à l'échelle automatique
Pour permettre à Azure Databricks de redimensionner automatiquement votre cluster, vous activez la mise à l’échelle automatique pour le cluster et fournissez la plage de travail minimale et maximale.
Activez la mise à l’échelle automatique.
All-Purpose cluster : sur la page créer un cluster, activez la case à cocher activer la mise à l’échelle automatique dans la zone options AutoPilot :
Cluster de travail - dans la page Configurer le cluster, activez la case à cocher Mise à l’échelle automatique dans la zone options AutoPilot :
Configurez les Workers min et max.
Lorsque le cluster est en cours d’exécution, la page Détails du cluster affiche le nombre de travailleurs alloués. Vous pouvez comparer le nombre de Workers alloués à la configuration du Worker et effectuer les ajustements nécessaires.
Important
Si vous utilisez un pool d’instances :
- Assurez-vous que la taille de cluster demandée est inférieure ou égale au nombre minimal d’instances inactives dans le pool. Si elle est supérieure, le temps de démarrage d’un cluster correspond à celui d’un cluster qui n’utilise pas de pool.
- Assurez-vous que la taille de cluster maximale est inférieure ou égale à la capacité maximale du pool. Si elle est supérieure, la création du cluster échoue.
Exemple de mise à l’échelle automatique
Si vous reconfigurez un cluster statique pour qu’il soit un cluster de mise à l’échelle automatique, Azure Databricks redimensionne immédiatement le cluster dans les limites minimale et maximale, puis démarre la mise à l’échelle automatique. Par exemple, le tableau suivant montre ce qui se passe aux clusters avec une certaine taille initiale si vous reconfigurez un cluster pour la mise à l’échelle automatique entre 5 et 10 nœuds.
| Taille initiale | Taille après reconfiguration |
|---|---|
| 6 | 6 |
| 12 | 10 |
| 3 | 5 |
Mise à l’échelle automatique du stockage local
Il est souvent difficile d'estimer l'espace disque que prendra une tâche particulière. Pour vous éviter d'avoir à estimer le nombre de gigaoctets de disque géré à joindre à votre cluster au moment de la création, Azure Databricks active automatiquement le stockage local à mise à l'échelle automatique sur tous les clusters Azure Databricks.
Avec le stockage local à mise à l'échelle automatique, Azure Databricks surveille la quantité d'espace disque libre disponible sur les workers Spark de votre cluster. Si un Worker commence à s’exécuter trop peu sur le disque, Databricks joint automatiquement un nouveau disque géré au Worker avant que l’espace disque soit insuffisant. Les disques sont attachés dans la limite de 5 To d’espace disque par machine virtuelle (y compris le stockage local initial de la machine virtuelle).
Les disques managés attachés à une machine virtuelle sont détachés uniquement quand la machine virtuelle est retournée à Azure. En d'autres termes, les disques gérés ne sont jamais détachés d'une machine virtuelle tant qu'elle fait partie d'un cluster en cours d'exécution. Pour réduire l'utilisation du disque managé, Azure Databricks recommande d'utiliser cette fonctionnalité dans un cluster configuré avec Taille du cluster et mise à l'échelle automatique ou Arrêt inattendu.
Chiffrement de disque local
Important
Cette fonctionnalité est disponible en préversion publique.
Certains types d’instances que vous utilisez pour exécuter des clusters peuvent avoir des disques attachés localement. Azure Databricks pouvez stocker des données de lecture aléatoire ou des données éphémères sur ces disques attachés localement. Pour vous assurer que toutes les données au repos sont chiffrées pour tous les types de stockage, y compris les données aléatoires stockées temporairement sur les disques locaux de votre cluster, vous pouvez activer le chiffrement de disque local.
Important
Vos charges de travail peuvent s’exécuter plus lentement en raison de l’impact sur les performances de la lecture et de l’écriture de données chiffrées vers et à partir des volumes locaux.
Lorsque le chiffrement de disque local est activé, Azure Databricks génère une clé de chiffrement localement qui est unique pour chaque nœud de cluster et est utilisée pour chiffrer toutes les données stockées sur les disques locaux. La portée de la clé est locale pour chaque nœud de cluster et est détruite en même temps que le nœud de cluster lui-même. Pendant sa durée de vie, la clé se trouve dans la mémoire pour le chiffrement et le déchiffrement et est stockée chiffrée sur le disque.
Pour activer le chiffrement de disque local, vous devez utiliser l’API Clusters. Lors de la création ou de la modification d’un cluster, définissez :
{
"enable_local_disk_encryption": true
}
Pour des exemples sur la façon d’invoquer ces API, consultez API Clusters.
Voici un exemple d’un appel de création de cluster qui active le chiffrement de disque local :
{
"cluster_name": "my-cluster",
"spark_version": "7.3.x-scala2.12",
"node_type_id": "Standard_D3_v2",
"enable_local_disk_encryption": true,
"spark_conf": {
"spark.speculation": true
},
"num_workers": 25
}
Mode de sécurité
Si votre espace de travail est attribué à un metastore Unity Catalog, vous utilisez un mode de sécurité au lieu d’un mode de cluster à fort accès concurrentiel pour garantir l’intégrité des contrôles d’accès et appliquer des garanties d’isolation forte. Le mode de cluster à concurrence élevée n’est pas disponible avec Unity Catalog.
Sous Options avancées, sélectionnez parmi les modes de sécurité de cluster suivants :
- None : aucune isolation. N’applique ni le contrôle d’accès aux tables à l’échelle de l’espace de travail, ni le passage directe des informations d’identification. Ne peut pas accéder aux données Unity Catalog.
- Single User : ne peut être utilisé que par un seul utilisateur (par défaut, l’utilisateur qui a créé le cluster). Les autres utilisateurs ne peuvent pas s’attacher au cluster. Lorsque vous accédez à une vue à partir d’un cluster en mode de sécurité Single User, la vue est exécutée avec les autorisations de l’utilisateur. Les clusters à utilisateur unique prennent en charge les charges de travail à l’aide de Python, Scala et R. Les scripts d’initialisation, l’installation de bibliothèque et les montages DBFS FUSE sont pris en charge sur les clusters à utilisateur unique. Les travaux automatisés doivent utiliser des clusters à utilisateur unique.
- User Isolation : peut être partagé par plusieurs utilisateurs. Seules les charges de travail SQL sont prises en charge. L’installation de bibliothèque, les scripts d’initialisation et les montages DBFS sont désactivés afin d’appliquer une isolation stricte entre les utilisateurs du cluster.
- Table ACL only (Legacy) : applique un contrôle d’accès aux tables à l’échelle de l’espace de travail, mais ne peut pas accéder aux données Unity Catalog.
- Passthrough only (Legacy) : applique le passage directe des informations d'identification à l’échelle de l’espace de travail, mais ne peut pas accéder aux données Unity Catalog.
Les seuls modes de sécurité pris en charge pour les charges de travail Unity Catalog sont Single User et User Isolation.
Pour plus d’informations, consultez les modes d’accès.
Configuration Spark
Pour affiner les travaux Spark, vous pouvez fournir des Propriétés de configuration Spark personnalisées dans une configuration de cluster.
Dans la page de configuration de cluster, cliquez sur le bouton bascule Options avancées.
Cliquez sur l’onglet Spark.
Dans la configuration Spark, entrez 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 sur Créer une nouvelle API de cluster ou Mettre à jour l'API de configuration du cluster.
Databricks ne recommande pas d'utiliser des scripts d'initialisation globaux.
Pour définir les propriétés Spark pour tous les clusters, créez un script d’initialisation global:
dbutils.fs.put("dbfs:/databricks/init/set_spark_params.sh","""
|#!/bin/bash
|
|cat << 'EOF' > /databricks/driver/conf/00-custom-spark-driver-defaults.conf
|[driver] {
| "spark.sql.sources.partitionOverwriteMode" = "DYNAMIC"
|}
|EOF
""".stripMargin, true)
Récupérer une propriété de configuration Spark à partir d’un secret
Databricks recommande de stocker des informations sensibles, telles que des mots de passe, dans un secret et non en texte clair. Pour référencer une clé secrète dans la configuration Spark, utilisez la syntaxe suivante :
spark.<property-name> {{secrets/<scope-name>/<secret-name>}}
Par exemple, pour définir une propriété de configuration Spark appelée password sur la valeur du secret stocké dans secrets/acme_app/password :
spark.password {{secrets/acme-app/password}}
Pour plus d’informations, consultez Syntaxe pour référencer des secrets dans une variable d’environnement ou une propriété de configuration Spark.
Variables d’environnement
Vous pouvez configurer des variables d’environnement personnalisées auxquelles vous pouvez accéder à partir de scripts init exécutés sur un cluster. Databricks fournit également des variables d’environnement prédéfinies que vous pouvez utiliser dans des scripts init. Vous ne pouvez pas remplacer ces variables d’environnement prédéfinies.
Dans la page de configuration de cluster, cliquez sur le bouton bascule Options avancées.
Cliquez sur l’onglet Spark .
Définissez les variables d’environnement dans le champ variables d’environnement .
Vous pouvez également définir des variables d’environnement à l’aide du champ spark_env_vars dans l’API Créer un cluster ou de l’API Mettre à jour la configuration du cluster.
Étiquettes de cluster
Les étiquettes de cluster vous permettent de superviser facilement le coût des ressources cloud utilisées par différents groupes de votre organisation. Vous pouvez spécifier des étiquettes sous forme de paires clé-valeur lorsque vous créez un cluster, et Azure Databricks applique ces étiquettes aux ressources du cloud telles que les VM et les volumes de disque, ainsi qu'aux rapports d'utilisation des DBU.
Pour les clusters lancés à partir de pools, les balises de cluster personnalisées sont appliquées uniquement aux rapports d’utilisation DBU et ne se propagent pas aux ressources Cloud.
Pour plus d’informations sur la manière dont les types d’étiquettes de pool et de cluster fonctionnent ensemble, consultez Superviser l’utilisation à l’aide d’étiquettes.
Pour plus de commodité, Azure Databricks applique des étiquettes par défaut à chaque cluster : Vendor, Creator, ClusterName et ClusterId.
En outre, sur les clusters de travail, Azure Databricks applique deux balises par défaut : RunName et JobId .
Sur les ressources utilisées par Databricks SQL, Azure Databricks applique également l’étiquette par défaut suivante SqlWarehouseId:
Avertissement
N’assignez pas de balise personnalisée avec la clé Name à un cluster. Chaque cluster possède une balise Name dont la valeur est définie par Azure Databricks. Si vous modifiez la valeur associée à la clé Name , le suivi du cluster ne peut plus être effectué par Azure Databricks. Par conséquent, il se peut que le cluster ne se termine pas après avoir été inactif et continue à entraîner des coûts d’utilisation.
Vous pouvez également ajouter des étiquettes personnalisées lors de la création d’un cluster. Pour configurer des étiquettes de cluster :
Dans la page de configuration de cluster, cliquez sur le bouton bascule Options avancées.
En bas de la page, cliquez sur l'onglet Balises.
Ajoutez une paire clé-valeur pour chaque balise personnalisée. Vous pouvez ajouter jusqu’à 43 étiquettes personnalisées.
Accès SSH aux clusters
Pour des raisons de sécurité, dans Azure Databricks le port SSH est fermé par défaut. Si vous souhaitez activer l’accès SSH à vos clusters Spark, contactez le support technique Azure Databricks.
Remarque
SSH ne peut être activé que si votre espace de travail est déployé dans votre propre réseau virtuel Azure.
Remise de journal de cluster
Lorsque vous créez un cluster, vous pouvez spécifier un emplacement pour la remise des journaux du nœud du pilote Spark, des nœuds de travail et des événements. Les journaux sont remis toutes les cinq minutes à la destination choisie. Lorsqu’un cluster est terminé, Azure Databricks garantit la remise de tous les journaux générés jusqu’à la fin du cluster.
La destination des journaux dépend de l’ID du cluster. Si la destination spécifiée est dbfs:/cluster-log-delivery, les journaux de cluster pour 0630-191345-leap375 sont remis à dbfs:/cluster-log-delivery/0630-191345-leap375.
Pour configurer l’emplacement de remise des journaux :
Dans la page de configuration de cluster, cliquez sur le bouton bascule Options avancées.
Cliquez sur l'onglet Journalisation.
Sélectionnez un type de destination.
Entrez le mot de passe de connexion au cluster.
Notes
Cette fonctionnalité est également disponible dans l’API REST. Consultez l’API Clusters.
Scripts d'initialisation
L’initialisation d’un nœud de cluster - ou init - est un script shell qui s’exécute au démarrage de chaque nœud du cluster avant le démarrage du pilote Spark ou de la machine virtuelle Java (JVM) worker. Vous pouvez utiliser des scripts init pour installer des packages et des bibliothèques qui ne sont pas inclus dans le runtime Databricks, modifier le classpath du système JVM, définir les propriétés système et les variables d’environnement utilisées par JVM, ou modifier les paramètres de configuration Spark, parmi d’autres tâches de configuration.
Vous pouvez attacher des scripts init à un cluster en développant la section Options avancées et en cliquant sur l’onglet init scripts .
Pour des instructions détaillées, consultez Que sont les scripts d'initialisation ?.
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour