Gestire le librerie per Apache Spark in Azure Synapse Analytics
Le librerie forniscono codice riutilizzabile da includere nei programmi o nei progetti per Apache Spark in Azure Synapse Analytics (Azure Synapse Spark).
Potrebbe essere necessario aggiornare l'ambiente del pool di Apache Spark serverless per vari motivi. Ad esempio, è possibile che:
- Una delle dipendenze principali ha rilasciato una nuova versione.
- È necessario un pacchetto aggiuntivo per il training del modello di Machine Learning o la preparazione dei dati.
- È disponibile un pacchetto migliore e non è più necessario il pacchetto precedente.
- Il team ha creato un pacchetto personalizzato necessario nel pool di Apache Spark.
Per rendere disponibile codice di terze parti o creato localmente per le applicazioni, installare una libreria in uno dei pool di Apache Spark serverless o in una sessione di notebook.
Panoramica dei livelli di pacchetto
Esistono tre livelli di pacchetti installati in Azure Synapse Analytics:
Impostazione predefinita: i pacchetti predefiniti includono un'installazione completa di Anaconda, oltre a librerie di uso comune. Per un elenco completo delle librerie, vedere Supporto della versione di Apache Spark.
All'avvio di un'istanza di Spark, queste librerie vengono incluse automaticamente. È possibile aggiungere altri pacchetti ad altri livelli.
Pool di Spark: tutti gli artefatti in esecuzione possono usare pacchetti a livello di pool di Spark. Ad esempio, è possibile collegare definizioni di notebook e processi Spark ai pool di Spark corrispondenti.
È possibile caricare librerie personalizzate e una versione specifica di una libreria open source che si vuole usare nell'area di lavoro di Azure Synapse Analytics. I pacchetti dell'area di lavoro possono essere installati nei pool di Spark.
Sessione: un'installazione a livello di sessione crea un ambiente per una sessione di notebook specifica. La modifica delle librerie a livello di sessione non viene mantenuta tra le sessioni.
Nota
- La gestione delle librerie a livello di pool può richiedere tempo, a seconda delle dimensioni dei pacchetti e della complessità delle dipendenze necessarie, il tempo di aggiornamento massimo viene impostato su 50 minuti. Il processo di gestione delle librerie a livello di pool verrà annullato automaticamente se supera il limite massimo di 50 minuti. È consigliabile eseguire l'installazione a livello di sessione per scenari sperimentali e iterativi rapidi.
- La gestione delle librerie a livello di pool produrrà una dipendenza stabile per l'esecuzione dei notebook e delle definizioni dei processi Spark. L'installazione della libreria nel pool di Spark è altamente consigliata per le esecuzioni della pipeline.
- La gestione delle librerie a livello di sessione consente di eseguire un'iterazione rapida o di gestire le frequenti modifiche della libreria. Tuttavia, la stabilità dell'installazione a livello di sessione non è promessa. Inoltre, i comandi nella riga come %pip e %conda sono disabilitati nell'esecuzione della pipeline. Durante la fase di sviluppo è consigliabile gestire la libreria nella sessione notebook.
Gestire i pacchetti dell'area di lavoro
Quando il team sviluppa applicazioni o modelli personalizzati, è possibile sviluppare vari artefatti di codice, ad esempio .whl, .jar o .tar.gz file per creare un pacchetto del codice.
Importante
- tar.gz è supportato solo per il linguaggio R. Usare .whl come pacchetto personalizzato Python.
In Azure Synapse i pacchetti dell'area di lavoro possono essere file personalizzati o privati con estensione whl o .jar . È possibile caricare questi pacchetti nell'area di lavoro e assegnarli in un secondo momento a un pool di Apache Spark serverless specifico. Dopo aver assegnato questi pacchetti dell'area di lavoro, questi vengono installati automaticamente in tutte le sessioni del pool di Spark.
Per altre informazioni su come gestire le librerie delle aree di lavoro, vedere Gestire i pacchetti dell'area di lavoro.
Gestire i pacchetti del pool
In alcuni casi, è possibile standardizzare i pacchetti usati in un pool di Apache Spark. Questa standardizzazione può essere utile se più persone del team in genere installano gli stessi pacchetti.
Usando le funzionalità di gestione del pool di Azure Synapse Analytics, è possibile configurare il set predefinito di librerie da installare in un pool di Apache Spark serverless. Queste librerie vengono installate sopra il runtime di base.
Per le librerie Python, i pool di Azure Synapse Spark usano Conda per installare e gestire le dipendenze dei pacchetti Python. È possibile specificare le librerie Python a livello di pool fornendo un file requirements.txt o environment.yml . Questo file di configurazione dell'ambiente viene usato ogni volta che viene creata un'istanza di Spark da tale pool di Spark. È anche possibile collegare i pacchetti dell'area di lavoro ai pool.
Per altre informazioni su queste funzionalità, vedere Gestire i pacchetti del pool di Spark.
Importante
- Se il pacchetto che si sta installando è di grandi dimensioni o richiede molto tempo per l'installazione, potrebbe influire sul tempo di avvio dell'istanza di Spark.
- La modifica della versione di PySpark, Python, Scala/Java, .NET o Spark non è supportata.
Gestire le dipendenze per i pool di Azure Synapse Spark abilitati per DEP
Nota
L'installazione di pacchetti da un repository pubblico non è supportata nelle aree di lavoro abilitate per DEP. Caricare invece tutte le dipendenze come librerie dell'area di lavoro e installarle nel pool di Spark.
Se si verificano problemi di identificazione delle dipendenze necessarie, seguire questa procedura:
Eseguire lo script seguente per configurare un ambiente Python locale identico all'ambiente Azure Synapse Spark. Questo script richiede un file YAML contenente un elenco di tutte le librerie incluse nell'ambiente Python predefinito per Azure Synapse Spark. È possibile trovare questo file YAML nella documentazione per versioni di runtime specifiche, ad esempio Apache Spark 3.2 (fine del supporto annunciato) e Apache Spark 3.3 (GA).
# One-time Azure Synapse Python setup wget Synapse-Python38-CPU.yml sudo bash Miniforge3-Linux-x86_64.sh -b -p /usr/lib/miniforge3 export PATH="/usr/lib/miniforge3/bin:$PATH" sudo apt-get -yq install gcc g++ conda env create -n synapse-env -f Synapse-Python38-CPU.yml source activate synapse-env
Eseguire lo script seguente per identificare le dipendenze necessarie. Lo script può essere usato per passare il file requirements.txt , che include tutti i pacchetti e le versioni che si intende installare nel pool di Spark 3.1 o Spark 3.2. Verranno stampati i nomi dei nuovi file/dipendenze della rotellina per i requisiti della libreria di input.
# Command to list wheels needed for your input libraries. # This command will list only new dependencies that are # not already part of the built-in Azure Synapse environment. pip install -r <input-user-req.txt> > pip_output.txt cat pip_output.txt | grep "Using cached *"
Nota
Questo script elenca solo le dipendenze non già presenti nel pool di Spark per impostazione predefinita.
Gestire i pacchetti con ambito sessione
Quando si esegue l'analisi interattiva dei dati o l'apprendimento automatico, è possibile provare pacchetti più recenti oppure potrebbero essere necessari pacchetti attualmente non disponibili nel pool di Apache Spark. Anziché aggiornare la configurazione del pool, è possibile usare pacchetti con ambito sessione per aggiungere, gestire e aggiornare le dipendenze della sessione.
I pacchetti con ambito sessione consentono agli utenti di definire le dipendenze dei pacchetti all'inizio della sessione. Quando si installa un pacchetto con ambito sessione, solo la sessione corrente ha accesso ai pacchetti specificati. Di conseguenza, questi pacchetti con ambito sessione non influiscono su altre sessioni o processi che usano lo stesso pool di Apache Spark. Inoltre, queste librerie vengono installate sopra il runtime di base e i pacchetti a livello di pool.
Per altre informazioni su come gestire i pacchetti con ambito sessione, vedere gli articoli seguenti:
Pacchetti di sessioni Python: all'inizio di una sessione, fornire un file Conda environment.yml per installare più pacchetti Python dai repository più diffusi. In alternativa, è possibile usare
%pip
i comandi e%conda
per gestire le librerie nelle celle del codice del notebook.Importante
Non usare
%%sh
per provare e installare librerie con pip o conda. Il comportamento non è uguale a %pip o %conda.Pacchetti di sessione Scala/Java: all'inizio della sessione specificare un elenco di file di .jar da installare usando
%%configure
.Pacchetti di sessione R: all'interno della sessione è possibile installare pacchetti in tutti i nodi all'interno del pool di Spark usando
install.packages
odevtools
.
Automatizzare il processo di gestione delle librerie tramite i cmdlet di Azure PowerShell e le API REST
Se il team vuole gestire le librerie senza visitare le interfacce utente di gestione dei pacchetti, è possibile gestire i pacchetti dell'area di lavoro e gli aggiornamenti dei pacchetti a livello di pool tramite i cmdlet di Azure PowerShell o le API REST per Azure Synapse Analytics.
Per altre informazioni, vedere gli articoli seguenti:
- Gestire le librerie del pool di Spark tramite le API REST
- Gestire le librerie del pool di Spark tramite i cmdlet di Azure PowerShell