Seleziona le tue preferenze relative ai cookie

Utilizziamo cookie essenziali e strumenti simili necessari per fornire il nostro sito e i nostri servizi. Utilizziamo i cookie prestazionali per raccogliere statistiche anonime in modo da poter capire come i clienti utilizzano il nostro sito e apportare miglioramenti. I cookie essenziali non possono essere disattivati, ma puoi fare clic su \"Personalizza\" o \"Rifiuta\" per rifiutare i cookie prestazionali.

Se sei d'accordo, AWS e le terze parti approvate utilizzeranno i cookie anche per fornire utili funzionalità del sito, ricordare le tue preferenze e visualizzare contenuti pertinenti, inclusa la pubblicità pertinente. Per continuare senza accettare questi cookie, fai clic su \"Continua\" o \"Rifiuta\". Per effettuare scelte più dettagliate o saperne di più, fai clic su \"Personalizza\".

Configurazione avanzata: condivisione degli endpoint di sviluppo tra più utenti

Modalità Focus
Configurazione avanzata: condivisione degli endpoint di sviluppo tra più utenti - AWS Glue

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Questa sezione spiega come sfruttare gli endpoint di sviluppo con i notebook SageMaker in casi d'uso tipici per condividere gli endpoint di sviluppo tra più utenti.

Configurazione tenancy singola

Nei casi d'uso a tenant singolo, per semplificare l'esperienza degli sviluppatori ed evitare conflitti per le risorse, è consigliabile che ogni sviluppatore utilizzi il proprio endpoint di sviluppo per il progetto su cui sta lavorando. Ciò semplifica anche le decisioni relative al tipo di worker e al conteggio DPU, lasciandole a discrezione dello sviluppatore e del progetto su cui sta lavorando.

Non dovrai occuparti dell'allocazione delle risorse a meno che non vengano eseguiti simultaneamente più file notebook. Se esegui il codice in più file notebook contemporaneamente, verranno avviate contemporaneamente più sessioni Livy. Per separare le configurazioni del cluster Spark al fine di eseguire più sessioni Livy contemporaneamente, puoi seguire i passaggi introdotti nei casi d'uso multi-tenant.

Ad esempio, se l'endpoint di sviluppo ha 10 worker e il tipo di worker è G.1X, allora si avranno 9 executor Spark e l'intero cluster avrà 90G di memoria dell'executor, poiché ogni executor avrà 10G di memoria.

Indipendentemente dal tipo di worker specificato, verrà attivata l'allocazione dinamica delle risorse Spark. Se un set di dati è abbastanza grande, Spark potrebbe allocare tutti gli executor a una singola sessione Livy poiché spark.dynamicAllocation.maxExecutors non è configurata per impostazione predefinita. Ciò significa che altre sessioni Livy sullo stesso endpoint di sviluppo attenderanno per l'avvio di nuovi executor. Se il set di dati è piccolo, Spark sarà in grado di allocare gli esecutori a più sessioni Livy contemporaneamente.

Nota

Per ulteriori informazioni sull'allocazione delle risorse in diversi casi d'uso e su come impostare una configurazione che modifichi il funzionamento, consulta Configurazione avanzata: condivisione degli endpoint di sviluppo tra più utenti.

Configurazione tenancy multipla

Nota

Tieni presente che gli endpoint di sviluppo hanno lo scopo di emulare l'ambiente ETL AWS Glue come ambiente a tenant singolo. Sebbene l'utilizzo di multi-tenant sia possibile, si tratta di un caso d'uso avanzato e alla maggior parte degli utenti si consiglia di mantenere un modello di tenancy singolo per ogni endpoint di sviluppo.

Nei casi d'uso multi-tenant, potresti doverti occupare dell'allocazione delle risorse. Il fattore chiave è il numero di utenti che utilizzano contemporaneamente un notebook Jupyter. Se il tuo team lavora in un flusso di lavoro "follow-the-sun" con un solo utente Jupyter per ogni fuso orario, il numero di utenti simultanei è uno solo, quindi non dovrai preoccuparti dell'allocazione delle risorse. Tuttavia, se il notebook è condiviso tra più utenti e ogni utente invia il codice ad hoc, sarà necessario considerare i seguenti punti.

Per suddividere le risorse del cluster Spark tra più utenti, è possibile utilizzare le configurazioni di SparkMagic. È possibile configurare SparkMagic in due diversi modi.

(A) Utilizzo della direttiva %%configure -f

Se vuoi modificare la configurazione per sessione Livy dal notebook, puoi eseguire la direttiva %%configure -f sul paragrafo di notebook.

Ad esempio, se vuoi eseguire l'applicazione Spark su 5 executor, puoi eseguire il comando seguente nel paragrafo di notebook.

%%configure -f {"numExecutors":5}

Vedrai quindi solo 5 executor in esecuzione per il processo sull'interfaccia utente di Spark.

Si consiglia di limitare il numero massimo di executor per l'allocazione dinamica delle risorse.

%%configure -f {"conf":{"spark.dynamicAllocation.maxExecutors":"5"}}

(B) Modifica del file di configurazione di SparkMagic

SparkMagic funziona in base all'API Livy. SparkMagic crea sessioni Livy con configurazioni come driverMemory, driverCores, executorMemory, executorCores, numExecutors, conf, e così via. Questi sono i fattori chiave che determinano la quantità di risorse utilizzate dall'intero cluster Spark. SparkMagic consente di fornire un file di configurazione per specificare i parametri che vengono inviati a Livy. Puoi vedere un file di configurazione di esempio in questo repository Github.

Se vuoi modificare la configurazione di tutte le sessioni Livy da un notebook, puoi modificare /home/ec2-user/.sparkmagic/config.json per aggiungere session_config.

Per modificare il file di configurazione in un'istanza notebook di SageMaker, segui la seguente procedura.

  1. Apri un notebook SageMaker.

  2. Apri il kernel del terminale.

  3. Esegui i comandi seguenti:

    sh-4.2$ cd .sparkmagic sh-4.2$ ls config.json logs sh-4.2$ sudo vim config.json

    Ad esempio, puoi aggiungere queste righe a /home/ec2-user/.sparkmagic/config.json e riavviare il kernel Jupyter dal notebook.

    "session_configs": { "conf": { "spark.dynamicAllocation.maxExecutors":"5" } },

Linee guida e best practice

Per evitare questo tipo di conflitto di risorse, puoi utilizzare alcuni approcci di base come:

  • Avere un cluster Spark più grande aumentando il NumberOfWorkers (dimensionamento orizzontale) e aggiornando il workerType (dimensionamento verticale)

  • Allocare di meno risorse per utente (meno risorse per sessione Livy)

Il tuo approccio dipenderà dal caso d'uso. Se disponi di un endpoint di sviluppo più grande e non vi è una quantità enorme di dati, la possibilità di un conflitto di risorse diminuirà significativamente perché Spark può allocare risorse in base a una strategia di allocazione dinamica.

Come descritto sopra, il numero massimo di executor Spark viene calcolato automaticamente in base alla combinazione di DPU (o NumberOfWorkers) e il tipo di worker. Ogni applicazione Spark avvia un driver e più executor. Per il calcolo è necessario il NumberOfWorkers = NumberOfExecutors + 1. La matrice seguente illustra la capacità necessaria nell'endpoint di sviluppo in base al numero di utenti simultanei.

Numero di utenti simultanei del notebook Numero di executor Spark che vuoi allocare per utente Numero totale di worker per l'endpoint di sviluppo
3 5 18
10 5 60
50 5 300

Se vuoi allocare meno risorse per utente, spark.dynamicAllocation.maxExecutors (o numExecutors) è il parametro più semplice da configurare come parametro di sessione Livy. Impostando la seguente configurazione in /home/ec2-user/.sparkmagic/config.json, SparkMagic assegnerà un massimo di 5 executor per sessione Livy. Questo aiuterà a separare le risorse per sessione Livy.

"session_configs": { "conf": { "spark.dynamicAllocation.maxExecutors":"5" } },

Supponiamo che ci sia un endpoint di sviluppo con 18 worker (G.1X) e 3 utenti del notebook contemporaneamente. Se la configurazione della sessione ha spark.dynamicAllocation.maxExecutors=5, ogni utente può utilizzare 1 driver e 5 executor. Anche eseguendo più paragrafi di notebook simultaneamente, non si verificheranno conflitti di risorse.

Pro e contro

Con questa configurazione di sessione "spark.dynamicAllocation.maxExecutors":"5", potrai evitare errori di conflitto di risorse e non sarà necessario attendere l'allocazione delle risorse in caso di accessi utente simultanei. Tuttavia, anche quando ci sono molte risorse gratuite (ad esempio, non ci sono altri utenti simultanei), Spark non può assegnare più di 5 executor per la sessione Livy.

Altre note

È buona prassi interrompere il kernel Jupyter quando si smette di usare un notebook. Ciò consentirà di liberare risorse che altri utenti del notebook potranno utilizzare immediatamente, senza dover attendere la scadenza del kernel (spegnimento automatico).

Problemi comuni

Anche quando si seguono le linee guida, è possibile che si verifichino alcuni problemi.

Sessione non trovata

Se provi a eseguire un paragrafo del notebook anche se la sessione Livy è già stata terminata, verrà visualizzato il messaggio seguente. Per attivare la sessione Livy, devi riavviare il kernel Jupyter scegliendo Kernel >Restart (Riavvia) nel menu Jupyter, quindi eseguire nuovamente il paragrafo del notebook.

An error was encountered: Invalid status code '404' from http://localhost:8998/sessions/13 with error payload: "Session '13' not found."

Risorse YARN insufficienti

Se provi a eseguire un paragrafo del notebook anche se il cluster Spark non dispone di risorse sufficienti per avviare una nuova sessione Livy, verrà visualizzato il messaggio seguente. Seguendo le linee guida è spesso possibile evitare questo problema, tuttavia potrebbe verificarsi. Per risolvere il problema, puoi verificare se sono presenti sessioni Livy attive non necessarie. In caso affermativo, sarà necessario terminarle per liberare le risorse del cluster. Per ulteriori informazioni, consulta la prossima sezione.

Warning: The Spark session does not have enough YARN resources to start. The code failed because of a fatal error: Session 16 did not start up in 60 seconds.. Some things to try: a) Make sure Spark has enough available resources for Jupyter to create a Spark context. b) Contact your Jupyter administrator to make sure the Spark magics library is configured correctly. c) Restart the kernel.

Monitoraggio e debug

In questa sezione vengono descritte le tecniche per il monitoraggio delle risorse e delle sessioni.

Monitoraggio e debug dell'allocazione delle risorse nel cluster

È possibile visualizzare l'interfaccia utente di Spark per monitorare il numero di risorse allocate per ogni sessione Livy e quali sono le configurazioni Spark effettive sul processo. Per attivare l'interfaccia utente di Spark, consulta Abilitazione dell'interfaccia utente Web di Apache Spark per endpoint di sviluppo.

(Facoltativo) Se è necessaria una visualizzazione in tempo reale dell'interfaccia utente di Spark, puoi configurare un tunnel SSH sul server di cronologia Spark in esecuzione sul cluster Spark.

ssh -i <private-key.pem> -N -L 8157:<development endpoint public address>:18080 glue@<development endpoint public address>

Apri http://localhost:8157 nel browser per visualizzare l'interfaccia utente di Spark in locale.

Sessioni libere Livy non necessarie

Consulta queste procedure per arrestare le sessioni Livy non necessarie da un notebook o da un cluster Spark.

(a). Terminare le sessioni Livy da un notebook

Puoi chiudere il kernel su un notebook Jupyter per terminare sessioni Livy non necessarie.

(b). Terminare le sessioni Livy da un cluster Spark

Se sono ancora in esecuzione sessioni Livy non necessarie, puoi arrestare le sessioni Livy nel cluster Spark.

Come prerequisito per eseguire questa procedura, è necessario configurare la chiave pubblica SSH per l'endpoint di sviluppo.

Per accedere al cluster Spark, esegui il comando seguente:

$ ssh -i <private-key.pem> glue@<development endpoint public address>

Per visualizzare le sessioni attive Livy, esegui il comando seguente:

$ yarn application -list 20/09/25 06:22:21 INFO client.RMProxy: Connecting to ResourceManager at ip-255-1-106-206.ec2.internal/172.38.106.206:8032 Total number of applications (application-types: [] and states: [SUBMITTED, ACCEPTED, RUNNING]):2 Application-Id Application-Name Application-Type User Queue State Final-State Progress Tracking-URL application_1601003432160_0005 livy-session-4 SPARK livy default RUNNING UNDEFINED 10% http://ip-255-1-4-130.ec2.internal:41867 application_1601003432160_0004 livy-session-3 SPARK livy default RUNNING UNDEFINED 10% http://ip-255-1-179-185.ec2.internal:33727

Puoi quindi chiudere la sessione Livy con il seguente comando:

$ yarn application -kill application_1601003432160_0005 20/09/25 06:23:38 INFO client.RMProxy: Connecting to ResourceManager at ip-255-1-106-206.ec2.internal/255.1.106.206:8032 Killing application application_1601003432160_0005 20/09/25 06:23:39 INFO impl.YarnClientImpl: Killed application application_1601003432160_0005
PrivacyCondizioni del sitoPreferenze cookie
© 2025, Amazon Web Services, Inc. o società affiliate. Tutti i diritti riservati.