Aller au contenu principal
Dernière mise à jour le

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.

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.

Créer un cluster

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 .

Sélectionnez une règle de cluster

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​

remarque

Cet article décrit l'interface utilisateur des clusters hérités. Pour des informations concernant la nouvelle interface utilisateur des clusters (en préversion), consultez Référence de configuration du compute. Cela inclut des modifications terminologiques pour les types et modes d'accès aux clusters. Pour une comparaison des nouveaux types de clusters et des clusters hérités, consultez Modifications de l'interface utilisateur des clusters et modes d'accès aux clusters. Dans l'aperçu de l'interface utilisateur :

  • Les clusters en mode Standard sont désormais appelés clusters en mode d'accès « Sans isolement partagé » .
  • Les clusters High Concurrency avec ACL de tables sont désormais appelés clusters en mode d'accès partagé .

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

important
  • Si votre workspace est attribué à un metastore Unity Catalog, les clusters high concurrency ne sont pas disponibles. Au lieu de cela, vous utilisez le mode d'accès pour assurer l'intégrité des contrôles d'accès et appliquer de solides garanties d'isolation. Voir aussi Modes d'accès.
  • 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 High Concurrency sans paramètres de sécurité supplémentaires tels que les ACL de table ou la transmission d'identifiants , 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 .

Mode de cluster 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 .

Mode de cluster à 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 associer un cluster à un Pool prédéfini d'instances inactives, pour les nœuds Driver et Worker. Le cluster est créé à l'aide d'instances des pools. Si un Pool ne dispose pas de Ressources inactives suffisantes pour créer les nœuds Driver ou Worker demandés, le Pool s'étend en allouant de nouvelles instances auprès du fournisseur d'instances. Lorsqu'un cluster associé est arrêté, les instances qu'il utilisait sont renvoyées aux pools 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 des nœuds worker.

important

Si vous tentez de sélectionner un Pool pour le nœud Driver, mais pas pour les nœuds Worker, une erreur se produit et votre cluster n'est pas créé. Cette exigence évite une situation où le nœud du Driver doit attendre la création des nœuds Worker, ou vice versa.

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.

Sélectionner la version du Runtime

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.

Photon DAG

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​

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.

remarque

Databricks lance des nœuds Worker avec deux adresses IP privées chacun. L'adresse IP privée principale du nœud est utilisée pour héberger 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 clusters au sein du même workspace.

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'instances AWS Graviton​

Databricks prend en charge les clusters avec des processeurs AWS Graviton. Les instances AWS Graviton basées sur Arm sont conçues par AWS pour offrir un meilleur rapport prix/performances par rapport aux instances comparables de génération actuelle basées sur x86. Consultez les types d’instances AWS Graviton.

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 :

      Activer la mise à l'échelle automatique pour les clusters interactifs

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

      Activer le dimensionnement automatique pour les clusters de jobs

  2. Configurez le nombre minimal et maximal de workers.

    Configurez le nombre minimal et maximal de Worker

    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.
  • Assurez-vous que la taille maximale du cluster est inférieure ou égale à la capacité maximale du pool. Si elle est plus grande, la création du cluster échouera.

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

Chiffrement de disque local​

info

Aperçu

Cette fonctionnalité est en aperçu public.

Certains types d’instances que vous utilisez pour exécuter des clusters peuvent avoir des disques attachés localement. Databricks peut stocker les données de shuffle ou les données éphémères sur ces disques attachés localement. Pour garantir que toutes les données au repos sont chiffrées pour tous les types de stockage, y compris les données de lecture aléatoire qui sont stockées temporairement sur les disques locaux de votre cluster, vous pouvez activer le chiffrement des disques locaux.

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 depuis les volumes locaux.

Lorsque le chiffrement du disque local est activé, Databricks génère localement une clé de chiffrement unique pour chaque nœud de cluster et utilisée pour chiffrer toutes les données stockées sur les disques locaux. La portée de la clé est propre à chaque nœud du cluster et est détruite en même temps que le nœud du cluster lui-même. Pendant sa durée de vie, la clé réside en mémoire pour le chiffrement et le déchiffrement et est stockée chiffrée sur le disque.

Pour activer le chiffrement du disque local, vous devez utiliser l'API Clusters. Lors de la création ou de la modification de clusters, définissez :

JSON
{
  "enable_local_disk_encryption": true
}

Consultez l'API Clusters pour des exemples d'invocation de ces APIs.

Voici un exemple d'appel de création de cluster qui active le chiffrement de disque local :

JSON
{
  "cluster_name": "my-cluster",
  "spark_version": "7.3.x-scala2.12",
  "node_type_id": "r3.xlarge",
  "enable_local_disk_encryption": true,
  "spark_conf": {
    "spark.speculation": true
  },
  "num_workers": 25
}

Mode de sécurité​

Si votre Workspace est attribué à un métastore Unity Catalog, vous utilisez le mode de sécurité au lieu du mode de cluster High Concurrency pour garantir l'intégrité des contrôles d'accès et appliquer de solides garanties d'isolation. Le mode de cluster high concurrency n'est pas disponible avec Unity Catalog.

Sous Options avancées , choisissez parmi les modes de sécurité de cluster suivants :

  • **Aucun** : Aucune isolation. N'applique pas le contrôle d'accès aux tables au niveau du Workspace ou la transmission des identifiants. Impossible d'accéder aux données de Unity Catalog.
  • Utilisateur unique : Ne peut être utilisé que par un seul utilisateur (par default, l'utilisateur qui a créé le cluster). Les autres utilisateurs ne peuvent pas s'associer au cluster. Lors de l'accès à une vue à partir d'un cluster avec le mode de sécurité Utilisateur unique , la vue est exécutée avec les autorisations de l'utilisateur. Les clusters à utilisateur unique prennent en charge les charges de travail utilisant Python, Scala et R. Les scripts d'initialisation, l'installation de bibliothèques et les montages DBFS sont pris en charge sur les clusters à utilisateur unique. Les automated jobs doivent utiliser des clusters à utilisateur unique.
  • **Isolement des utilisateurs** : Peut être partagé par plusieurs utilisateurs. Seules les charges de travail SQL sont prises en charge. L'installation de bibliothèques, les scripts d'initialisation et les montages DBFS sont désactivés pour appliquer une isolation stricte entre les utilisateurs des clusters.
  • ACL de table uniquement (hérité) : applique le contrôle d'accès aux tables local au workspace, mais ne peut pas accéder aux données Unity Catalog.
  • Transmission uniquement (héritée) : Applique le passthrough d’identifiants local au Workspace, mais ne peut pas accéder aux données Unity Catalog.

Les seuls modes de sécurité pris en charge pour les workloads Unity Catalog sont **Utilisateur unique** et **Isolation des utilisateurs**.

Pour plus d’informations, consultez Modes d’accès.

Configurations AWS​

Lorsque vous configurez les instances AWS d'un cluster, vous pouvez choisir la zone de disponibilité, le prix spot maximal, le type et la taille du volume EBS, ainsi que les profils d'instance. Pour spécifier les configurations,

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

  2. En bas de la page, cliquez sur l’onglet tab .

    tab Instances

Zones de disponibilité​

Ce paramètre vous permet de spécifier la zone de disponibilité (AZ) que vous souhaitez que le cluster utilise. Par défaut, ce paramètre est défini sur **auto** (Auto-AZ), où la AZ est automatiquement sélectionnée en fonction des adresses IP disponibles dans les sous-réseaux du Workspace. Auto-AZ relance dans d'autres zones de disponibilité si AWS renvoie des erreurs de capacité insuffisante.

Le choix d'une zone de disponibilité spécifique pour un cluster est utile principalement si votre organisation a acheté des instances réservées dans des zones de disponibilité spécifiques. En savoir plus sur les zones de disponibilité AWS.

Instances Spot​

Vous pouvez spécifier si vous souhaitez utiliser des instances spot et le prix spot maximal à utiliser lors du lancement d'instances spot, en pourcentage du prix à la demande correspondant. By default, the max price is 100 % du prix à la demande. Voir les Tarifs spot AWS.

Volumes EBS​

Cette section décrit les paramètres par défaut du volume EBS pour les nœuds worker, comment ajouter des volumes de brassage et comment configurer un cluster afin que Databricks alloue automatiquement des volumes EBS.

Pour configurer les volumes EBS, cliquez sur l'onglet Instances dans la configuration des clusters et sélectionnez une option dans la liste déroulante Type de volume EBS .

default EBS volumes​

Databricks provisionne des volumes EBS pour chaque nœud worker comme suit :

  • Un volume racine d'instance EBS chiffré de 30 Go utilisé uniquement par le système d'exploitation hôte et les services internes Databricks.
  • Un volume racine de conteneur EBS chiffré de 150 Go utilisé par le Worker Spark. Ceci héberge les services Spark et les Logs.
  • (HIPAA uniquement) un volume de Logs Worker EBS chiffré de 75 Go qui stocke les Logs des services internes de Databricks.

Ajouter des volumes de brassage EBS​

Pour ajouter des volumes de brassage, sélectionnez SSD à usage général dans la liste déroulante Type de volume EBS :

Type de volume EBS

By default, les sorties de shuffle Spark vont sur le disque local de l'instance. Pour les types d'instance qui n'ont pas de disque local, ou si vous souhaitez augmenter votre espace de stockage de shuffle Spark, vous pouvez spécifier des volumes EBS supplémentaires. Ceci est particulièrement utile pour éviter les erreurs de manque d'espace disque lorsque vous exécutez des Jobs Spark qui produisent de grandes sorties de brassage.

Databricks chiffre ces volumes EBS pour les instances à la demande et les instances Spot. En savoir plus sur les volumes AWS EBS.

Chiffrez éventuellement les volumes EBS de Databricks avec une clé gérée par le client​

Vous pouvez éventuellement chiffrer les volumes EBS des clusters avec une clé gérée par le client.

Voir Clés gérées par le client pour le chiffrement

Limites AWS EBS​

Assurez-vous que vos limites AWS EBS sont suffisamment élevées pour satisfaire les exigences d'exécution pour tous les Workers de tous les clusters. Pour des informations sur les limites EBS par default et comment les modifier, consultez Amazon Elastic Block Store (EBS) Limits.

Type de volume SSD AWS EBS​

Vous pouvez sélectionner gp2 ou gp3 pour votre type de volume SSD AWS EBS. Pour ce faire, consultez Gérer le stockage SSD. Databricks vous recommande de passer à gp3 pour ses économies par rapport à gp2. Pour des informations techniques sur gp2 et gp3, consultez Types de volumes Amazon EBS.

Dimensionnement automatique du stockage local​

Si vous ne souhaitez pas allouer un nombre fixe de volumes EBS au moment de la création du cluster, utilisez le dimensionnement automatique du stockage local. Avec le stockage local à mise à l'échelle automatique, Databricks surveille la quantité d'espace disque disponible sur les Workers Spark de votre cluster. Si un Worker commence à manquer d'espace disque, Databricks attache automatiquement un nouveau volume EBS au Worker avant qu'il ne soit à court d'espace disque. Les volumes EBS 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 le dimensionnement automatique du stockage, sélectionnez Activer le dimensionnement automatique du stockage local dans la boîte Options Autopilot :

Activer le dimensionnement automatique du stockage local

Les volumes EBS attachés à une instance ne sont détachés que lorsque l'instance est renvoyée à AWS. Autrement dit, les volumes EBS ne sont jamais détachés d'une instance tant qu'elle fait partie d'un cluster en cours d'exécution. Pour réduire l'utilisation d'EBS, Databricks vous recommande d'utiliser cette fonctionnalité dans un cluster configuré avec Taille du cluster et mise à l'échelle automatique ou Arrêt automatique.

remarque

Databricks utilise un disque dur Throughput Optimized HDD (st1) pour étendre le stockage local d'une instance. La limite de capacité AWS par default pour ces volumes est de 20 TiB. Pour éviter d'atteindre cette limite, les administrateurs doivent demander une augmentation de cette limite en fonction de leurs besoins d'utilisation.

remarque

Si vous avez créé votre compte Databricks avant la version 2.44 (avant le 27 avril 2017) et que vous souhaitez utiliser le stockage local à mise à l'échelle automatique (activé par default dans les clusters High Concurrency), vous devez ajouter des autorisations de volume au rôle IAM ou aux clés utilisées pour créer votre compte. En particulier, vous devez ajouter les autorisations ec2:AttachVolume, ec2:CreateVolume, ec2:DeleteVolume et ec2:DescribeVolumes. Pour la liste complète des autorisations et les instructions sur la manière de mettre à jour votre rôle ou vos clés IAM existants, consultez Créer une configuration d'identifiants.

Profils d'instance​

Pour accéder en toute sécurité aux ressources AWS sans utiliser de clés AWS, vous pouvez lancer des clusters Databricks avec des profils d'instance. Reportez-vous à Tutoriel : Configurer l'accès S3 avec un profil d'instance pour savoir comment créer et configurer des profils d'instance. Une fois que vous avez créé un profil d'instance, vous le sélectionnez dans la liste déroulante Profil d'instance :

Profil d'instance

remarque

Une fois qu'un cluster est lancé avec un profil d'instance, toute personne disposant des autorisations d'association à ce cluster peut accéder aux ressources sous-jacentes contrôlées par ce rôle. Pour vous prémunir contre les accès indésirables, vous pouvez utiliser les autorisations de compute pour restreindre les autorisations sur le cluster.

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.

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:

Scala
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 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 .

    Champ Variables d&#39;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 à des ressources cloud comme les VM et les volumes de disque, ainsi qu’aux rapports d’utilisation de DBU.

Pour les clusters lancés à partir de pools, les Cluster Tags personnalisés sont uniquement appliqués aux rapports d’utilisation des DBU et ne sont pas propagés aux ressources cloud.

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.

Sur les ressources utilisées par Databricks SQL, Databricks applique également la balise default SqlWarehouseId.

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 .

    Onglet Tags tab

  3. Ajoutez une paire clé-valeur pour chaque tag personnalisé. Vous pouvez ajouter jusqu'à 45 tags personnalisés.

Appliquer des tags obligatoires​

Pour garantir que certains tags sont toujours renseignés lors de la création de clusters, vous pouvez appliquer une politique IAM spécifique au rôle IAM principal de votre compte (celui créé lors de la configuration du compte ; contactez votre administrateur AWS si vous avez besoin d'un accès). La politique IAM devrait inclure des déclarations de refus explicites pour les clés de tag obligatoires et les valeurs facultatives. La création de clusters échouera si les tags obligatoires avec l'une des valeurs autorisées ne sont pas fournis.

Par exemple, si vous souhaitez appliquer des tags Department et Project, avec des valeurs spécifiées uniquement autorisées pour le premier et une valeur de forme libre non vide pour le second, vous pourriez appliquer une politique IAM comme celle-ci :

JSON
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "MandateLaunchWithTag1",
      "Effect": "Deny",
      "Action": ["ec2:RunInstances", "ec2:CreateTags"],
      "Resource": "arn:aws:ec2:region:accountId:instance/*",
      "Condition": {
        "StringNotEqualsIgnoreCase": {
          "aws:RequestTag/Department": ["Deptt1", "Deptt2", "Deptt3"]
        }
      }
    },
    {
      "Sid": "MandateLaunchWithTag2",
      "Effect": "Deny",
      "Action": ["ec2:RunInstances", "ec2:CreateTags"],
      "Resource": "arn:aws:ec2:region:accountId:instance/*",
      "Condition": {
        "StringNotLike": {
          "aws:RequestTag/Project": "?*"
        }
      }
    }
  ]
}

Les actions ec2:RunInstances et ec2:CreateTags sont toutes deux requises pour chaque balise pour une couverture efficace des scénarios dans lesquels il existe des clusters qui ont uniquement des instances à la demande, uniquement des instances spot, ou les deux.

astuce

Databricks vous recommande d’ajouter une instruction de politique distincte pour chaque tag. La politique globale peut devenir longue, mais elle est plus facile à déboguer. Consultez la Référence des opérateurs de conditions de politique IAM pour obtenir la liste des opérateurs pouvant être utilisés dans une politique.

remarque

Les erreurs de création de cluster dues à une politique IAM affichent un encoded error message, commençant par :

Console
Cloud Provider Launch Failure: A cloud provider error was encountered while setting up the cluster.

Le message est encodé car les détails du statut d'autorisation peuvent constituer des informations privilégiées que l'utilisateur ayant demandé l'action ne devrait pas voir. Consultez l'API DecodeAuthorizationMessage (ou la CLI) pour plus d'informations sur la façon de décoder de tels messages.

Accès SSH aux clusters​

remarque

Vous ne pouvez pas utiliser SSH pour vous connecter à un cluster pour lequel la connectivité de cluster sécurisée est activée.

SSH vous permet de vous connecter à distance aux clusters Apache Spark pour un dépannage avancé et l'installation de logiciel personnalisé.

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

Cette section décrit comment configurer votre compte AWS pour activer l'accès entrant à votre cluster avec votre clé publique, et comment ouvrir une connexion SSH aux nœuds de cluster.

Configurer le groupe de sécurité​

Vous devez mettre à jour le groupe de sécurité Databricks dans votre compte AWS pour autoriser l'accès entrant à l'adresse IP à partir de laquelle vous allez initier la connexion SSH. Vous pouvez configurer cela pour une seule adresse IP ou fournir une plage qui représente l'ensemble de la plage d'adresses IP de votre bureau.

  1. Dans votre console AWS, recherchez le groupe de sécurité Databricks. Il aura une étiquette similaire à <databricks-instance>-worker-unmanaged. (Exemple : dbc-fb3asdddd3-worker-unmanaged)

  2. Modifiez le groupe de sécurité et ajoutez une règle TCP entrante pour autoriser le port 2200 aux machines Worker. Il peut s’agir d’une adresse IP unique ou d’une plage.

    Groupe de sécurité SSH

  3. Assurez-vous que votre ordinateur et votre bureau vous permettent d'envoyer du trafic TCP sur le port 2200.

Générer une paire de clés SSH​

Créez une paire de clés SSH en exécutant cette commande dans une session de terminal :

Bash
ssh-keygen -t rsa -b 4096 -C "email@example.com"

Vous devez fournir le chemin d'accès au répertoire où vous souhaitez enregistrer la clé publique et privée. La clé publique est enregistrée avec l'extension .pub.

Configurer un nouveau cluster avec votre clé publique​

  1. Copiez l'intégralité du contenu du fichier de clé publique.

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

  3. Au bas de la page, cliquez sur le SSH tab.

  4. Collez la clé que vous avez copiée dans le champ Clé publique SSH .

    Saisie SSH

Configurez un cluster existant avec votre clé publique​

Si vous disposez d'un cluster et que vous n’avez pas fourni la clé publique lors de la création du cluster, vous pouvez injecter la clé publique en exécutant ce code depuis n'importe quel notebook attaché au cluster :

Scala
val publicKey = " put your public key here "

def addAuthorizedPublicKey(key: String): Unit = {
  val fw = new java.io.FileWriter("/home/ubuntu/.ssh/authorized_keys", /* append */ true)
  fw.write("\n" + key)
  fw.close()
}

val numExecutors = sc.getExecutorMemoryStatus.keys.size
sc.parallelize(0 until numExecutors, numExecutors).foreach { i =>
  addAuthorizedPublicKey(publicKey)
}
addAuthorizedPublicKey(publicKey)

Se connecter via SSH au nœud du Driver Spark​

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

  2. Cliquez sur l’onglet **tab**. Copiez le Hostname du nœud Driver.

  3. Exécutez la commande suivante en remplaçant le Hostname et le chemin d’accès au fichier de clé privée.

    Bash
    ssh ubuntu@<hostname> -p 2200 -i <private-key-file-path>

Se connecter en SSH aux nœuds worker Spark​

Vous vous connectez en SSH aux nœuds worker de la même manière que vous vous connectez en SSH au nœud driver.

  1. Sur la page des détails du cluster, cliquez sur l'onglet Spark Cluster UI - Master .

  2. Dans la table Workers, cliquez sur le Worker auquel vous souhaitez vous connecter via SSH. Copiez le champ Hostname.

    Hostname SSH

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 .

    Livraison des logs de cluster

  3. Sélectionnez un type de destination.

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

Destinations du compartiment S3​

Si vous choisissez une destination S3, vous devez configurer le cluster avec un profil d'instance qui peut accéder au compartiment. Ce profil d'instance doit avoir les autorisations PutObject et PutObjectAcl. Un exemple de profil d'instance a été inclus pour votre commodité. Reportez-vous au Tutoriel : Configurer l'accès S3 avec un profil d'instance pour obtenir des instructions sur la configuration d'un profil d'instance.

JSON
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": ["arn:aws:s3:::<my-s3-bucket>"]
    },
    {
      "Effect": "Allow",
      "Action": ["s3:PutObject", "s3:PutObjectAcl", "s3:GetObject", "s3:DeleteObject"],
      "Resource": ["arn:aws:s3:::<my-s3-bucket>/*"]
    }
  ]
}
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 ?.

Sur cette page