Apache Spark in Azure Machine Learning

Articolo
09/06/2024

L'integrazione di Azure Machine Learning con Azure Synapse Analytics consente di accedere facilmente alle risorse di calcolo distribuite tramite il framework Apache Spark. Questa integrazione offre queste esperienze di calcolo Apache Spark:

Calcolo Spark serverless
Pool di Spark Synapse collegato

Calcolo Spark serverless

Con il framework Apache Spark, l'ambiente di calcolo Spark serverless di Azure Machine Learning è il modo più semplice per eseguire attività di calcolo distribuite nell'ambiente di Azure Machine Learning. Azure Machine Learning offre un cluster di calcolo Apache Spark completamente gestito, serverless e su richiesta. Gli utenti possono evitare la necessità di creare sia un'area di lavoro di Azure Synapse che un pool di Spark Synapse.

Gli utenti possono definire risorse, tra cui il tipo di istanza e la versione del runtime di Apache Spark. Possono quindi usare tali risorse per accedere al calcolo Spark serverless, nei notebook di Azure Machine Learning, per:

Elementi da considerare:

L'ambiente di calcolo Spark serverless funziona bene per la maggior parte degli scenari utente che richiedono un accesso rapido alle risorse di calcolo distribuite tramite Apache Spark. Tuttavia, per prendere una decisione informata, gli utenti devono considerare i vantaggi e gli svantaggi di questo approccio.

Vantaggi:

Nessuna dipendenza dalla creazione di altre risorse di Azure per Apache Spark (l'infrastruttura di Azure Synapse funziona dietro le quinte).
Nessuna autorizzazione di sottoscrizione necessaria per creare risorse correlate ad Azure Synapse.
Non sono necessarie quote del pool SQL.

Svantaggi:

Manca un metastore Hive persistente. L'ambiente di calcolo Spark serverless supporta solo SPARK SQL in memoria.
Nessuna tabella o database disponibile.
Integrazione di Azure Purview mancante.
Nessun servizio collegato disponibile.
Meno origini dati e connettori.
Nessuna configurazione a livello di pool.
Nessuna gestione delle librerie a livello di pool.
Supporto parziale solo per mssparkutils.

Configurazione di rete

Per usare l'isolamento di rete con il calcolo di Azure Machine Learning e Spark serverless, usare una rete virtuale gestita .

Periodi di inattività e meccanismo di disinstallazione

Al primo avvio, una risorsa di calcolo Spark serverless (avvio a freddo) potrebbe richiedere da tre a cinque minuti per avviare la sessione Spark stessa. Il provisioning della risorsa di calcolo Spark serverless automatizzata, supportato da Azure Synapse, causa questo ritardo. Dopo il provisioning del calcolo Spark serverless e dopo l'avvio di una sessione Apache Spark, le esecuzioni di codice successive (avvio a caldo) non riscontrano questo ritardo.

La configurazione della sessione Spark offre un'opzione che definisce un timeout della sessione (in minuti). La sessione Spark terminerà dopo un periodo di inattività che supera il timeout definito dall'utente. Se un'altra sessione di Spark non viene avviata nei 10 minuti seguenti, le risorse di cui è stato effettuato il provisioning per l'ambiente di calcolo Spark serverless vengono eliminate.

Quando si verifica la disinstallazione della risorsa di calcolo Spark serverless, l'invio del processo successivo richiederà un avvio a freddo. La visualizzazione successiva mostra alcuni scenari di inattività della sessione e di disinstallazione del cluster.

Pacchetti Conda a livello di sessione

Un file YAML di dipendenza Conda può definire molti pacchetti Conda a livello di sessione in una configurazione di sessione. Se sono necessari più di 15 minuti per installare i pacchetti Conda definiti nel file YAML, si verifica il timeout di una sessione. Diventa importante verificare prima di tutto se un pacchetto obbligatorio è già disponibile nell'immagine di base di Azure Synapse. A tale scopo, gli utenti devono vedere queste risorse per determinare i pacchetti disponibili nell'immagine di base per la versione di Apache Spark in uso:

Importante

Runtime di Azure Synapse per Apache Spark: annunci

Runtime di Azure Synapse per Apache Spark 3.2:
- Data annuncio EOLA: 8 luglio 2023
- Data di fine supporto: 8 luglio 2024. Dopo questa data il runtime sarà disabilitato.
Per un supporto continuo e prestazioni ottimali, è consigliabile eseguire la migrazione ad Apache Spark 3.4

Nota

Per un pacchetto Conda a livello di sessione:

l’avvio a freddo richiederà circa 10-15 minuti.
l’avvio a caldo, usando lo stesso pacchetto Conda, richiederà circa un minuto.
l’avvio a caldo, con un pacchetto Conda diverso, richiederà anch’esso circa dieci-quindici minuti.
Se si installa un pacchetto di grandi dimensioni o che richiede molto tempo per l’installazione, ciò potrebbe influire sul tempo di avvio dell'istanza di Spark.
La modifica della versione di PySpark, Python, Scala/Java, .NET o Spark non è supportata.
Le immagini Docker non sono supportate.

Miglioramento dell'ora di avvio a freddo della sessione durante l'uso di pacchetti Conda a livello di sessione

È possibile impostare la variabile di configurazione spark.hadoop.aml.enable_cache su true per migliorare il tempo di avvio a freddo della sessione di Spark. Con i pacchetti Conda a livello di sessione, l'avvio a freddo della sessione in genere richiede da 10 a 15 minuti quando la sessione viene avviata per la prima volta. Tuttavia, la sessione successiva di avvio a freddo richiede da tre a cinque minuti. Definire la variabile di configurazione nell’interfaccia utente Configura sessione in Impostazioni di configurazione.

Pool di Spark Synapse collegato

Un pool di Spark creato in un'area di lavoro di Azure Synapse diventa disponibile nell'area di lavoro di Azure Machine Learning con il pool di Spark synapse collegato. Questa opzione può essere adatta agli utenti che vogliono riutilizzare un pool di Spark Synapse esistente.

Il collegamento di un pool di Spark per Synapse a un'area di lavoro di Azure Machine Learning richiede altri passaggi prima che sia possibile usare il pool in Azure Machine Learning per:

Un pool di Spark Synapse collegato consente l'accesso alle funzionalità native di Azure Synapse. L'utente è responsabile del provisioning, del collegamento, della configurazione e della gestione del pool di Spark per Synapse.

La configurazione della sessione Spark per un pool di Spark collegato offre anche un'opzione per definire un timeout di sessione (in minuti). Il comportamento di timeout della sessione è simile alla descrizione nella sezione precedente, ad eccezione del fatto che le risorse associate non vengono mai eliminate dopo il timeout della sessione.

Definizione delle dimensioni del cluster Spark

Nei processi Spark di Azure Machine Learning è possibile definire le dimensioni del cluster Spark con tre valori di parametro:

Numero di executor
Core dell'executor
Memoria dell'executor

È consigliabile considerare un executor Apache Spark di Azure Machine Learning come equivalente ai nodi di lavoro di Azure Spark. Un esempio può spiegare questi parametri. Si supponga di aver definito il numero di executor come 6 (equivalenti a sei nodi di lavoro), il numero di core executor come 4 e la memoria dell'executor come 28 GB. Il processo Spark può quindi accedere a un cluster con 24 core in totale e 168 GB di memoria.

Garantire l'accesso alle risorse per i processi Spark

Per accedere ai dati e ad altre risorse, un processo Spark pu?o usare un'identità gestita o un pass-through identità utente. Questa tabella riepiloga i meccanismi usati dai processi Spark per accedere alle risorse.

Pool Spark	Identità supportate	Identità predefinita
Calcolo Spark serverless	Identità utente, identità gestita assegnata dall'utente collegata all'area di lavoro	Identità utente
Pool di Spark Synapse collegato	Identità utente, identità gestita assegnata dall'utente collegata al pool di Synapse Spark collegato, identità gestita assegnata dal sistema del pool di Spark Synapse collegato	Identità gestita assegnata dal sistema del pool di Spark Synapse collegato

Questo articolo descrive l'accesso alle risorse per i processi Spark. In una sessione del notebook, sia il calcolo Spark serverless sia il pool di Spark collegato si basano sul pass-through dell'identità utente per l'accesso ai dati durante il data wrangling interattivo.