Configurare il calcolo (legacy)

Nota

Queste sono istruzioni per l'interfaccia utente del cluster di creazione legacy e sono incluse solo per l'accuratezza cronologica. Tutti i clienti devono usare l'interfaccia utente del cluster di creazione aggiornata.

Questo articolo illustra le opzioni di configurazione disponibili quando si creano e si modificano cluster di Azure Databricks. È incentrato sulla creazione e la modifica di cluster tramite l'interfaccia utente. Per altri metodi, vedere l'interfaccia della riga di comando di Databricks, l'API Clusters e il provider Terraform di Databricks.

Per informazioni sulla scelta della combinazione di opzioni di configurazione più adatta alle proprie esigenze, vedere Procedure consigliate per la configurazione del cluster.

Criteri per i cluster

I criteri del cluster limitano la possibilità di configurare i cluster in base a un set di regole. Le regole dei criteri limitano gli attributi o i valori degli attributi disponibili per la creazione del cluster. I criteri del cluster hanno elenchi di controllo di accesso che limitano l'uso a utenti e gruppi specifici e quindi limitano i criteri che è possibile selezionare quando si crea un cluster.

Per configurare un criterio cluster, selezionare i criteri del cluster nell'elenco a discesa Criteri .

Nota

Se nell'area di lavoro non sono stati creati criteri, l'elenco a discesa Criteri non viene visualizzato.

Se si dispone di:

• Autorizzazione di creazione cluster, è possibile selezionare i criteri Senza restrizioni e creare cluster completamente configurabili. I criteri senza restrizioni non limitano gli attributi del cluster o i valori degli attributi.
• Sia l'autorizzazione di creazione del cluster che l'accesso ai criteri del cluster, è possibile selezionare i criteri senza restrizioni e i criteri a cui si ha accesso.
• Solo l'accesso ai criteri del cluster consente di selezionare i criteri a cui si ha accesso.

Modalità cluster

Nota

Questo articolo descrive l'interfaccia utente dei cluster legacy. Per informazioni sull'interfaccia utente dei nuovi cluster (in anteprima), vedere Informazioni di riferimento sulla configurazione di calcolo. Sono incluse alcune modifiche alla terminologia per i tipi e le modalità di accesso ai cluster. Per un confronto tra i tipi di cluster nuovi e legacy, vedere Modifiche dell'interfaccia utente dei cluster e modalità di accesso al cluster. Nell'interfaccia utente di anteprima:

• I cluster in modalità standard sono ora denominati cluster in modalità di accesso condiviso senza isolamento.
• La concorrenza elevata con gli elenchi di controllo di accesso alle tabelle è ora denominata cluster in modalità di accesso condiviso.

Azure Databricks supporta tre modalità del cluster: Standard, Concorrenza elevata e Nodo singolo. La modalità cluster predefinita è Standard.

Importante

• Se l'area di lavoro viene assegnata a un metastore del catalogo Unity, i cluster di concorrenza elevata non sono disponibili. Si usa invece la modalità di accesso per garantire l'integrità dei controlli di accesso e applicare garanzie di isolamento avanzate. Vedere anche Modalità di accesso.
• Non è possibile modificare la modalità cluster dopo la creazione di un cluster. Se si vuole una modalità cluster diversa, è necessario creare un nuovo cluster.

La configurazione del cluster include un'impostazione di terminazione automatica il cui valore predefinito dipende dalla modalità cluster:

• I cluster a nodo singolo e standard terminano automaticamente dopo 120 minuti per impostazione predefinita.
• I cluster con concorrenza elevata non terminano automaticamente per impostazione predefinita.

Cluster standard

Avviso

I cluster in modalità standard (talvolta denominati No Isolation Shared clusters) possono essere condivisi da più utenti, senza isolamento tra gli utenti. Se si usa la modalità cluster a concorrenza elevata senza impostazioni di sicurezza aggiuntive, ad esempio ACL tabella o Pass-through delle credenziali, le stesse impostazioni vengono usate come cluster in modalità Standard. Gli amministratori dell'account possono impedire la generazione automatica delle credenziali interne per gli amministratori dell'area di lavoro di Databricks in questi tipi di cluster. Per opzioni più sicure, Databricks consiglia alternative, ad esempio cluster a concorrenza elevata con ACL di tabella.

Un cluster Standard è consigliato solo per utenti singoli. I cluster standard possono eseguire carichi di lavoro sviluppati in Python, SQL, R e Scala.

Cluster con concorrenza elevata

Un cluster a concorrenza elevata è una risorsa cloud gestita. I principali vantaggi dei cluster a concorrenza elevata sono che forniscono una condivisione con granularità fine per l'utilizzo massimo delle risorse e latenze minime delle query.

I cluster con concorrenza elevata possono eseguire carichi di lavoro sviluppati in SQL, Python e R. Le prestazioni e la sicurezza dei cluster a concorrenza elevata vengono fornite eseguendo il codice utente in processi separati, che non è possibile in Scala.

Inoltre, solo i cluster a concorrenza elevata supportano il controllo di accesso alle tabelle.

Per creare un cluster a concorrenza elevata, impostare Modalità cluster su Concorrenza elevata.

Cluster a nodo singolo

Un cluster a nodo singolo non dispone di ruoli di lavoro ed esegue processi Spark nel nodo driver.

Al contrario, un cluster Standard richiede almeno un nodo del ruolo di lavoro Spark oltre al nodo driver per eseguire processi Spark.

Per creare un cluster a nodo singolo, impostare Modalità cluster su Nodo singolo.

Per altre informazioni sull'uso dei cluster a nodo singolo, vedere Calcolo a nodo singolo o multinodo.

Pool

Per ridurre l'ora di avvio del cluster, è possibile collegare un cluster a un pool predefinito di istanze inattive per i nodi driver e di lavoro. Il cluster viene creato usando le istanze nei pool. Se un pool non dispone di risorse inattive sufficienti per creare il driver o i nodi di lavoro richiesti, il pool si espande allocando nuove istanze dal provider di istanze. Quando un cluster collegato viene terminato, le istanze usate vengono restituite ai pool e possono essere riutilizzate da un cluster diverso.

Se si seleziona un pool per i nodi di lavoro ma non per il nodo driver, il nodo driver eredita il pool dalla configurazione del nodo di lavoro.

Importante

Se si tenta di selezionare un pool per il nodo driver ma non per i nodi di lavoro, si verifica un errore e il cluster non viene creato. Questo requisito impedisce una situazione in cui il nodo driver deve attendere la creazione dei nodi di lavoro o viceversa.

Per altre informazioni sull'uso dei pool in Azure Databricks, vedere Informazioni di riferimento sulla configurazione del pool.

Databricks Runtime

I runtime di Databricks sono il set di componenti di base eseguiti nei cluster. Tutti i runtime di Databricks includono Apache Spark e aggiungono componenti e aggiornamenti che migliorano l'usabilità, le prestazioni e la sicurezza. Per informazioni dettagliate, vedere Versioni e compatibilità delle note sulla versione di Databricks Runtime.

Azure Databricks offre diversi tipi di runtime e diverse versioni di questi tipi di runtime nell'elenco a discesa Versione di Databricks Runtime quando si crea o si modifica un cluster.

Accelerazione foton

Photon è disponibile per i cluster che eseguono Databricks Runtime 9.1 LTS e versioni successive.

Per abilitare l'accelerazione Photon, selezionare la casella di controllo Usa accelerazione foton.

Se necessario, è possibile specificare il tipo di istanza nell'elenco a discesa Tipo di lavoro e Tipo di driver.

Databricks consiglia i tipi di istanza seguenti per ottenere prezzi e prestazioni ottimali:

• Standard_E4ds_v4
• Standard_E8ds_v4
• Standard_E16ds_v4

È possibile visualizzare l'attività Photon nell'interfaccia utente di Spark. Lo screenshot seguente mostra il DAG dei dettagli della query. Ci sono due indicazioni di Photon nel DAG. Prima di tutto, gli operatori Photon iniziano con "Photon", ad esempio PhotonGroupingAgg. In secondo luogo, nel DAG, gli operatori Photon e le fasi sono pesca colorata, mentre quelli non fotoni sono blu.

Immagini Docker

Per alcune versioni di Databricks Runtime, è possibile specificare un'immagine Docker quando si crea un cluster. I casi d'uso di esempio includono la personalizzazione della libreria, un ambiente contenitore di riferimento che non cambia e l'integrazione di CI/CD Docker.

È anche possibile usare le immagini Docker per creare ambienti di Deep Learning personalizzati nei cluster con dispositivi GPU.

Per istruzioni, vedere Personalizzare i contenitori con Il servizio contenitore Databricks e Databricks Container Services nel calcolo GPU.

Tipo di nodo del cluster

Un cluster è costituito da un nodo driver e da zero o più nodi di lavoro.

È possibile selezionare tipi di istanza del provider di servizi cloud separati per i nodi driver e di lavoro, anche se per impostazione predefinita il nodo driver utilizza lo stesso tipo di istanza del nodo di lavoro. Diverse famiglie di tipi di istanza si adattano a casi d'uso diversi, ad esempio carichi di lavoro a elevato utilizzo di memoria o a elevato utilizzo di calcolo.

Nota

Se i requisiti di sicurezza includono l'isolamento dell’ambiente di calcolo, selezionare un'istanza Standard_F72s_V2 come tipo di lavoro. Questi tipi di istanza rappresentano macchine virtuali isolate che consumano l'intero host fisico e forniscono il livello di isolamento necessario per supportare, ad esempio, i carichi di lavoro del Dipartimento della Difesa degli Stati Uniti di livello di impatto 5 (IL5).

• Nodo del driver
• Nodo del ruolo di lavoro
• Tipi di istanza GPU
• Istanze spot

Nodo del driver

Il nodo driver gestisce le informazioni sullo stato di tutti i notebook collegati al cluster. Il nodo driver gestisce anche SparkContext e interpreta tutti i comandi eseguiti da un notebook o da una libreria nel cluster ed esegue il master Apache Spark che si coordina con gli executor Spark.

Il valore predefinito del tipo di nodo driver corrisponde a quello del tipo di nodo di lavoro. È possibile scegliere un tipo di nodo driver più grande con maggiore memoria se si prevede di collect() per molti dati dai ruoli di lavoro Spark e di analizzarli nel notebook.

Suggerimento

Poiché il nodo driver gestisce tutte le informazioni sullo stato dei notebook collegati, assicurarsi di scollegare i notebook inutilizzati dal nodo driver.

Nodo di lavoro

I nodi di lavoro di Azure Databricks eseguono gli executor Spark e altri servizi necessari per il corretto funzionamento dei cluster. Quando si distribuisce il carico di lavoro con Spark, tutte le attività di elaborazione distribuita vengono eseguite nei nodi di lavoro. Azure Databricks esegue un executor per nodo di lavoro; pertanto i termini executor e worker vengono usati in modo intercambiabile nel contesto dell'architettura di Azure Databricks.

Suggerimento

Per eseguire un processo Spark, è necessario almeno un nodo di lavoro. Se un cluster non ha nodi di lavoro, è possibile eseguire comandi non Spark nel nodo driver, ma i comandi di Spark avranno esito negativo.

Tipi di istanza GPU

Per attività complesse dal livello di calcolo che richiedono prestazioni elevate, ad esempio quelle associate all'apprendimento avanzato, Azure Databricks supporta i cluster accelerati con unità di elaborazione grafica (GPU). Per altre informazioni, si veda Risorse di calcolo con GPU.

Istanze Spot

Per risparmiare sui costi, è possibile scegliere di usare istanze spot, note anche come macchine virtuali spot di Azure selezionando la casella di controllo Istanze spot.

La prima istanza sarà sempre su richiesta (il nodo driver è sempre su richiesta) e le istanze successive saranno istanze spot. Se le istanze spot vengono rimosse a causa di un'indisponibilità, le istanze su richiesta vengono distribuite per sostituire le istanze rimosse.

Dimensioni del cluster e scalabilità automatica

Quando si crea un cluster Di Azure Databricks, è possibile fornire un numero fisso di ruoli di lavoro per il cluster o fornire un numero minimo e massimo di ruoli di lavoro per il cluster.

Quando si fornisce un cluster di dimensioni fisse, Azure Databricks garantisce che il cluster disponga del numero specificato di ruoli di lavoro. Quando si specifica un intervallo per il numero di ruoli di lavoro, Databricks sceglie il numero appropriato di ruoli di lavoro necessari per eseguire il processo. Questa operazione viene definita scalabilità automatica.

Con la scalabilità automatica, Azure Databricks rialloca dinamicamente i ruoli di lavoro in base alle caratteristiche del processo. Alcune parti della pipeline possono essere più esigenti dal punto di vista computazionale di altre e Databricks aggiunge automaticamente altri ruoli di lavoro durante tali fasi del processo e (li rimuove quando non sono più necessari).

Con la scalabilità automatica è più facile ottenere un utilizzo del cluster elevato, perché non è necessario effettuare il provisioning del cluster per soddisfare un carico di lavoro. Questo vale soprattutto per i carichi di lavoro i cui requisiti cambiano nel tempo, ad esempio l'esplorazione di un set di dati durante il corso di un giorno, ma possono essere applicati anche a un carico di lavoro monouso più breve i cui requisiti di provisioning sono sconosciuti. La scalabilità automatica offre dunque due vantaggi:

• I carichi di lavoro possono essere eseguiti più velocemente rispetto a un cluster sottoposto a provisioning costante.
• La scalabilità automatica dei cluster può ridurre i costi complessivi rispetto a un cluster di dimensioni statiche.

A seconda delle dimensioni costanti del cluster e del carico di lavoro, la scalabilità automatica offre uno o entrambi questi vantaggi contemporaneamente. Le dimensioni del cluster possono superare il numero minimo di ruoli di lavoro selezionati quando il provider di servizi cloud termina le istanze. In questo caso, Azure Databricks ritenta continuamente il provisioning delle istanze per mantenere il numero minimo di ruoli di lavoro.

Nota

La scalabilità automatica non è disponibile per i processi spark-submit.

Comportamento del ridimensionamento automatico

• Aumenta da min a max in 2 passaggi.
• Può ridurre le prestazioni anche se il cluster non è inattivo esaminando lo stato del file casuale.
• Riduce le prestazioni in base a una percentuale di nodi correnti.
• Nei cluster di processo, riduce le prestazioni se il cluster è sottoutilizzato negli ultimi 40 secondi.
• Nei cluster di tutti gli scopi, riduce le prestazioni se il cluster è sottoutilizzato negli ultimi 150 secondi.
• La spark.databricks.aggressiveWindowDownS proprietà di configurazione di Spark specifica in secondi la frequenza con cui un cluster prende decisioni di ridimensionamento. Aumentando il valore, un cluster viene ridimensionato più lentamente. Il valore massimo è 600.

Abilitare e configurare il ridimensionamento automatico

Per consentire ad Azure Databricks di ridimensionare automaticamente il cluster, abilitare la scalabilità automatica per il cluster e fornire il numero minimo e massimo di ruoli di lavoro.

1. Abilitare la scalabilità automatica.

   • Cluster all-purpose : nella pagina Crea cluster selezionare la casella di controllo Abilita scalabilità automatica nella casella Opzioni di Autopilot:

     

   • Cluster processo : nella pagina Configura cluster selezionare la casella di controllo Abilita scalabilità automatica nella casella Opzioni di Autopilot:

     

2. Configurare i ruoli di lavoro min e max.

   

   Quando il cluster è in esecuzione, nella pagina dei dettagli del cluster viene visualizzato il numero di ruoli di lavoro allocati. È possibile confrontare il numero di ruoli di lavoro assegnati con la configurazione del ruolo di lavoro e apportare modifiche in base alle esigenze.

Importante

Se si usa un pool di istanze:

• Assicurarsi che le dimensioni del cluster richieste siano minori o uguali al numero minimo di istanze inattive nel pool. Se sono maggiori, il tempo di avvio del cluster sarà equivalente a un cluster che non usa un pool.

• Assicurarsi che le dimensioni massime del cluster siano minori o uguali alla capacità massima del pool. Se sono maggiori, la creazione del cluster non riuscirà.

Esempio di scalabilità automatica

Se si riconfigura un cluster statico in modo che sia un cluster con scalabilità automatica, Azure Databricks ridimensiona immediatamente il cluster entro i limiti minimo e massimo e quindi avvia la scalabilità automatica. Ad esempio, la tabella seguente illustra cosa accade ai cluster con una determinata dimensione iniziale se si riconfigura un cluster per la scalabilità automatica tra 5 e 10 nodi.

Dimensioni iniziali	Dimensioni dopo la riconfigurazione
6	6
12	10
3	5

Ridimensionamento automatico delle risorse di archiviazione locali

Spesso può essere difficile stimare la quantità di spazio su disco che un determinato processo richiederà. Per evitare di dover stimare il numero di gigabyte di disco gestito da collegare al cluster in fase di creazione, Azure Databricks abilita automaticamente la scalabilità automatica dell'archiviazione locale in tutti i cluster Azure Databricks.

Con la scalabilità automatica dell'archiviazione locale, Azure Databricks monitora la quantità di spazio disponibile su disco nei ruoli di lavoro Spark del cluster. Se un ruolo di lavoro inizia a essere troppo basso su disco, Databricks collega automaticamente un nuovo disco gestito al ruolo di lavoro prima che esaurisca lo spazio su disco. I dischi vengono collegati fino a un limite di 5 TB di spazio totale su disco per macchina virtuale (inclusa l'archiviazione locale iniziale della macchina virtuale).

I dischi gestiti collegati a una macchina virtuale vengono scollegati solo quando la macchina virtuale viene restituita ad Azure. Ovvero, i dischi gestiti non vengono mai scollegati da una macchina virtuale, purché faccia parte di un cluster in esecuzione. Per ridurre l'utilizzo del disco gestito, Azure Databricks consiglia di usare questa funzionalità in un cluster configurato con dimensioni del cluster e scalabilità automatica o Terminazione imprevista.

Crittografia del disco locale

Importante

Questa funzionalità è disponibile in anteprima pubblica.

Alcuni tipi di istanza usati per eseguire i cluster possono avere dischi collegati localmente. Azure Databricks può archiviare dati casuali o dati temporanei in questi dischi collegati localmente. Per assicurarsi che tutti i dati inattivi siano crittografati per tutti i tipi di archiviazione, inclusi i dati casuali archiviati temporaneamente nei dischi locali del cluster, è possibile abilitare la crittografia del disco locale.

Importante

I carichi di lavoro potrebbero essere più lenti a causa dell'impatto sulle prestazioni della lettura e della scrittura di dati crittografati da e verso i volumi locali.

Quando la crittografia del disco locale è abilitata, Azure Databricks genera una chiave di crittografia in locale univoca per ogni nodo del cluster e viene usata per crittografare tutti i dati archiviati nei dischi locali. L'ambito della chiave è locale per ogni nodo del cluster e viene eliminato definitivamente insieme al nodo del cluster stesso. Nel corso della sua durata operativa, la chiave risiede in memoria per la crittografia e la decrittografia e viene memorizzata crittografata sul disco.

Per abilitare la crittografia del disco locale, è necessario usare l'API Clusters. Durante la creazione o la modifica del cluster, impostare:

{
  "enable_local_disk_encryption": true
}

Vedere l'API Clusters per esempi di come richiamare queste API.

Di seguito è riportato un esempio di chiamata di creazione del cluster che abilita la crittografia del disco locale:

{
  "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
}

Modalità di sicurezza

Se l'area di lavoro viene assegnata a un metastore del catalogo Unity, si usa la modalità di sicurezza anziché la modalità cluster a concorrenza elevata per garantire l'integrità dei controlli di accesso e applicare garanzie di isolamento avanzate. La modalità cluster con concorrenza elevata non è disponibile con Il catalogo Unity.

In Opzioni avanzate selezionare tra le modalità di sicurezza del cluster seguenti:

• Nessuno: nessun isolamento. Non impone il controllo di accesso alle tabelle locali dell'area di lavoro o il pass-through delle credenziali. Impossibile accedere ai dati di Unity Catalog.
• Utente singolo: può essere usato solo da un singolo utente (per impostazione predefinita, l'utente che ha creato il cluster). Altri utenti non possono connettersi al cluster. Quando si accede a una visualizzazione da un cluster con modalità di sicurezza utente singolo, la visualizzazione viene eseguita con le autorizzazioni dell'utente. I cluster utente singolo supportano i carichi di lavoro con Python, Scala e R. Gli script init, l'installazione della libreria e i montaggi DBFS sono supportati nei cluster a utente singolo. I processi automatizzati devono usare cluster a utente singolo.
• Isolamento utente: può essere condiviso da più utenti. Sono supportati solo i carichi di lavoro SQL. L'installazione della libreria, gli script init e i montaggi DBFS sono disabilitati per applicare un isolamento rigoroso tra gli utenti del cluster.
• Solo ACL di tabella (legacy): applica il controllo di accesso alle tabelle locali dell'area di lavoro, ma non può accedere ai dati di Unity Catalog.
• Solo pass-through (legacy): applica il pass-through delle credenziali locali dell'area di lavoro, ma non può accedere ai dati di Unity Catalog.

Le uniche modalità di sicurezza supportate per i carichi di lavoro del catalogo Unity sono Single User (Utente singolo) e User Isolation (Isolamento utenti singoli).

Per altre informazioni, vedere Modalità di accesso.

Configurazione di Spark

Per ottimizzare i processi Spark, è possibile fornire proprietà di configurazione Spark personalizzate in una configurazione del cluster.

1. Nella pagina di configurazione del cluster fare clic sull'interruttore Opzioni avanzate.

2. Fare clic sulla scheda Spark.

   

   Nella configurazione di Spark immettere le proprietà di configurazione come una coppia chiave-valore per riga.

Quando si configura un cluster usando l'API cluster, impostare le proprietà Spark nel spark_conf campo creare una nuova API del cluster o aggiornare l'API di configurazione del cluster.

Databricks non consiglia l'uso di script init globali.

Per impostare le proprietà di Spark per tutti i cluster, creare uno script init globale:

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)

Recuperare una proprietà di configurazione spark da un segreto

Databricks consiglia di archiviare informazioni riservate, ad esempio password, in un segreto anziché in testo non crittografato. Per fare riferimento a un segreto nella configurazione di Spark, usare la seguente sintassi:

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

Ad esempio, per impostare una proprietà di configurazione Spark denominata password sul valore del segreto archiviato in secrets/acme_app/password:

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

Per altre informazioni, vedere Gestire i segreti.

Variabili di ambiente

È possibile configurare variabili di ambiente personalizzate a cui è possibile accedere dagli script init in esecuzione in un cluster. Databricks fornisce anche variabili di ambiente predefinite che è possibile usare negli script init. Non è possibile eseguire l'override di queste variabili di ambiente predefinite.

1. Nella pagina di configurazione del cluster fare clic sull'interruttore Opzioni avanzate.

2. Fare clic sulla scheda Spark.

3. Impostare le variabili di ambiente nel campo Variabili di ambiente.

   

È anche possibile impostare le variabili di ambiente usando il spark_env_vars campo nella pagina Creare una nuova API del cluster o aggiornare l'API di configurazione del cluster.

Tag del cluster

I tag del cluster consentono di monitorare facilmente il costo delle risorse cloud usate da vari gruppi nell'organizzazione. È possibile specificare i tag come coppie chiave-valore quando si crea un cluster e Azure Databricks applica questi tag alle risorse cloud, ad esempio macchine virtuali e volumi di dischi, nonché report sull'utilizzo DBU.

Per i cluster avviati dai pool, i tag del cluster personalizzati vengono applicati solo ai report di utilizzo DBU e non vengono propagati alle risorse cloud.

Per informazioni dettagliate sul funzionamento dei tipi di tag del pool e del cluster, vedere Monitorare l'uso dei tag.

Per praticità, Azure Databricks applica quattro tag predefiniti a ogni cluster: Vendor, Creator, ClusterNamee ClusterId.

Inoltre, nei cluster di processo, Azure Databricks applica due tag predefiniti: RunName e JobId.

Nelle risorse usate da Databricks SQL, Azure Databricks applica anche il tag SqlWarehouseIdpredefinito .

Avviso

Non assegnare un tag personalizzato con la chiave Name a un cluster. Ogni cluster ha un tag Name il cui valore è impostato da Azure Databricks. Se si modifica il valore associato alla chiave Name, il cluster non può più essere rilevato da Azure Databricks. Di conseguenza, il cluster potrebbe non essere terminato dopo essere diventato inattiva e continuerà a comportare costi di utilizzo.

È possibile aggiungere tag personalizzati quando si crea un cluster. Per configurare i tag del cluster:

1. Nella pagina di configurazione del cluster fare clic sull'interruttore Opzioni avanzate.

2. Nella parte inferiore della pagina fare clic sulla scheda Tag .

   

3. Aggiungere una coppia chiave-valore per ogni tag personalizzato. È possibile aggiungere fino a 43 tag personalizzati.

Accesso SSH ai cluster

Per motivi di sicurezza, in Azure Databricks la porta SSH viene chiusa per impostazione predefinita. Per abilitare l'accesso SSH ai cluster Spark, contattare il supporto tecnico di Azure Databricks.

Nota

SSH può essere abilitato solo se l'area di lavoro viene distribuita nella propria rete virtuale di Azure.

Fornire registri cluster

Quando si crea un cluster, è possibile specificare un percorso in cui recapitare i log per il nodo del driver, i nodi di lavoro e gli eventi Spark. I log vengono recapitati ogni cinque minuti alla destinazione scelta. Quando un cluster viene terminato, Azure Databricks garantisce di recapitare tutti i log generati fino al termine del cluster.

La destinazione dei log dipende dall'ID cluster. Se la destinazione specificata è dbfs:/cluster-log-delivery, i log del cluster per 0630-191345-leap375 vengono recapitati a dbfs:/cluster-log-delivery/0630-191345-leap375.

Per configurare il percorso di recapito dei log:

1. Nella pagina di configurazione del cluster fare clic sull'interruttore Opzioni avanzate.

2. Fare clic sulla scheda Accedi.

   

3. Selezionare un tipo di destinazione.

4. Immettere il percorso del log del cluster.

Nota

Questa funzionalità è disponibile anche nell'API REST. Vedere l'API Cluster.

Script init

L'inizializzazione o l'inizializzazione di un nodo del cluster è uno script della shell eseguito durante l'avvio per ogni nodo del cluster prima dell'avvio del driver Spark o della JVM del ruolo di lavoro. È possibile usare script init per installare pacchetti e librerie non inclusi nel runtime di Databricks, modificare il classpath di sistema JVM, impostare le proprietà di sistema e le variabili di ambiente usate dalla JVM o modificare i parametri di configurazione di Spark, tra le altre attività di configurazione.

È possibile collegare script init a un cluster espandendo la sezione Opzioni avanzate e facendo clic sulla scheda Script init.

Per istruzioni dettagliate, vedere Che cosa sono gli script init?.