Domande frequenti su Amazon EMR

Amazon EMR è un servizio di elaborazione di big data che accelera i carichi di lavoro di analisi con flessibilità e scalabilità senza pari. EMR offre runtime ottimizzati per le prestazioni per Apache Spark, Trino, Apache Flink e Apache Hive, riducendo drasticamente costi e tempi di elaborazione.

Amazon EMR su Amazon EC2 fornisce il controllo sulla configurazione dei cluster e supporta cluster a lunga durata, rendendolo perfetto per attività di elaborazione continua dei dati che richiedono configurazioni hardware specifiche. Amazon EMR serverless permette di eseguire facilmente framework di analisi dei big data open source come Apache Spark, senza dover configurare, gestire e scalare cluster o server. Amazon EMR su Amazon Elastic Kubernetes Service (EKS) permette di inviare operazioni on demand su EKS, senza dover eseguire il provisioning dei cluster EMR.

Puoi implementare i carichi di lavoro su EMR utilizzando Amazon EC2, Amazon Elastic Kubernetes Service (EKS) o EMR Serverless. Puoi eseguire e gestire i carichi di lavoro con la console EMR, l'API, l'SDK o la CLI e orchestrarli utilizzando il servizio Flusso di lavoro gestito da Amazon per Apache Airflow (Amazon MWAA) o AWS Step Functions. 

Per registrarti ad Amazon EMR, seleziona il pulsante "Registrati ora"” nella pagina dei dettagli di Amazon EMR all'indirizzo http://aws.amazon.com/emr.  Una volta completata la registrazione, consulta la documentazione di Amazon EMR, che include una Guida alle operazioni di base, il modo migliore per imparare a utilizzare EMR su EC2, EMR Serverless, o EMR su EKS.

Consulta il Contratto sul livello di servizio (SLA).

Se cerchi codici di esempio, consulta questi articoli e tutorial. Se utilizzi EMR Studio, puoi esplorare le funzionalità tramite una serie di esempi di notebook.

Puoi sviluppare, visualizzare ed eseguire il debug di applicazioni di data science e data engineering scritte in R, Python, Scala e PySpark utilizzando Amazon EMR Studio. Puoi anche sviluppare un processo di elaborazione dati sul desktop, ad esempio utilizzando Eclipse, Spyder, PyCharm o RStudio, ed eseguirlo su Amazon EMR. Inoltre, puoi selezionare JupyterHub o Zeppelin nella configurazione software durante l'attivazione di un nuovo cluster e sviluppare l'applicazione su Amazon EMR utilizzando una o più istanze.

Gli strumenti a riga di comando e le API consentono di avviare e monitorare l'avanzamento di cluster in esecuzione in modo programmatico, creare funzionalità personalizzate aggiuntive relative ai cluster (ad esempio sequenze con più fasi di elaborazione, pianificazione, flusso di lavoro o monitoraggio) o di creare strumenti o applicazioni che migliorano l'esperienza per altri clienti di Amazon EMR. La Console di gestione AWS, invece, fornisce un'interfaccia grafica intuitiva per avviare e monitorare i cluster direttamente da un browser Web.

Sì. Quando un processo è stato avviato, se desideri puoi aggiungere altre fasi utilizzando l'API AddJobFlowSteps. L'API AddJobFlowSteps consentirà di aggiungere nuove fasi al termine della fase corrente. Questa API è ideale per implementare logica condizionale al cluster o per il debug.

Puoi registrarti ad Amazon SNS e impostarlo in modo che il cluster pubblichi un argomento in SNS quando ha terminato. Puoi anche monitorare l'avanzamento del cluster nella Console di gestione AWS, oppure utilizzare la riga di comando, SDK o le API per ottenere lo stato del cluster.

Sì. È possibile terminare automaticamente il cluster una volta completate tutte le fasi attivando il contrassegno di terminazione automatica.

Sì. Per installare pacchetti software di terze parti sul cluster consigliamo di usare delle bootstrap action. Puoi anche caricare eseguibili compilati in modo statico usando il meccanismo di cache distribuita di Hadoop. EMR 6.x supporta Hadoop 3, che consente a YARN NodeManager di avviare i container direttamente sull’host del cluster EMR o all’interno di un container Docker. Per ulteriori informazioni, consulta la documentazione.

Esistono diversi strumenti che possono essere utilizzati per raccogliere informazioni sul cluster e determinare cosa è andato storto. Se utilizzi Amazon EMR Studio, puoi avviare strumenti come l’interfaccia utente Spark e il servizio della sequenza temporale YARN per semplificare il debug. Dalla console Amazon EMR, puoi ottenere l'accesso fuori dal cluster alle interfacce utente delle applicazioni persistenti per Apache Spark, l'interfaccia utente Tez e il server della sequenza temporale YARN, diverse interfacce utente delle applicazioni sul cluster e una vista di riepilogo della cronologia dell'applicazione nella console Amazon EMR per tutte le applicazioni YARN. Puoi anche connetterti al tuo nodo principale tramite SSH e visualizzare le istanze cluster tramite queste interfacce Web. Per ulteriori informazioni, consulta la documentazione.

EMR Studio è un ambiente di sviluppo integrato (IDE) che semplifica lo sviluppo, la visualizzazione e il debug di applicazioni di data engineering e data science scritte in R, Python, Scala e PySpark per i data scientist e i data engineer.

Si tratta di un'applicazione completamente gestita con SSO (single sign-on), notebook Jupyter completamente gestiti, provisioning automatizzato dell'infrastruttura e la possibilità di eseguire il debug dei lavori senza accedere al cluster o alla console AWS. I data scientist e gli analisti possono installare librerie e kernel personalizzati, collaborare con i colleghi usando repository di codice come GitHub e BitBucket o eseguire notebook parametrizzati nell'ambito di flussi di lavoro programmati attraverso servizi di orchestrazione come Apache Airflow, AWS Step Functions e Amazon Managed Workflows for Apache Airflow. Troverai ulteriori informazioni nel post di blog Orchestrating analytics jobs on Amazon EMR notebooks using Amazon MWAA. Le applicazioni e i kernel di EMR Studio vengono eseguiti nei cluster EMR in modo da poter sfruttare i vantaggi dell'elaborazione dei dati distribuiti attraverso il runtime di Amazon EMR per Apache Spark a prestazioni ottimizzate. Gli amministratori possono configurare EMR Studio in modo che gli analisti possano eseguire le loro applicazioni sui cluster EMR esistenti oppure creare nuovi cluster utilizzando i modelli predefiniti di AWS CloudFormation per EMR.

EMR Studio permette di accedere direttamente ai notebook Jupyter completamente gestiti usando le proprie credenziali aziendali senza accedere alla console AWS, avviare i notebook in pochi secondi, eseguire l'onboarding con notebook di esempio ed eseguire l'esplorazione dei dati. È inoltre possibile personalizzare l'ambiente caricando propri kernel e librerie Python dai notebook. Le applicazioni e i kernel di EMR Studio vengono eseguiti nei cluster EMR in modo da poter sfruttare i vantaggi dell'elaborazione dei dati distribuiti tramite il runtime di Amazon EMR per Apache Spark a prestazioni ottimizzate. È possibile collaborare con i colleghi condividendo i notebook attraverso GitHub e altri repository. È anche possibile eseguire direttamente i notebook come pipeline di integrazione e distribuzione continue. Si possono trasferire diversi valori di parametri a un notebook, concatenare notebook e integrarli in flussi di lavoro programmati tramite servizi di orchestrazione dei flussi di lavoro come Apache Airflow. Inoltre, puoi eseguire il debug di cluster e processi utilizzando il minor numero di clic possibile con interfacce di applicazioni native come l'interfaccia utente Spark e il servizio YARN Timeline.

Esistono cinque differenze principali.

1. Con EMR Studio non è necessario accedere alla Console di gestione AWS. EMR Studio è esterno alla Console di gestione AWS. Ciò è utile se non si fornisce ai data scientist o agli ingegneri di dati l'accesso alla Console di gestione AWS.

2. Per accedere a EMR Studio, puoi usare le credenziali aziendali fornite dal gestore dell'identità digitale tramite AWS IAM Identity Center (in sostituzione di AWS SSO). 

3. EMR Studio consente di iniziare a usare il notebook. Le applicazioni e i kernel di EMR Studio vengono eseguiti nei cluster EMR in modo da poter sfruttare i vantaggi dell'elaborazione dei dati distribuiti tramite il runtime di Amazon EMR per Apache Spark a prestazioni ottimizzate. L'esecuzione del codice su un cluster è semplice come collegare il notebook a un cluster esistente o eseguire il provisioning di uno nuovo.

4. EMR Studio dispone di un’interfaccia utente semplificata e riassume le configurazioni hardware. Ad esempio, puoi configurare i modelli cluster una sola volta e utilizzarli quindi per avviare nuovi cluster. 

5. EMR Studio permette un'esperienza di debug semplificata in modo da poter accedere alle interfacce utente dell'applicazione nativa in un unico posto utilizzando il minor numero di clic possibile.

Con Amazon EMR si possono usare sia EMR Studio sia SageMaker Studio. EMR Studio offre un ambiente di sviluppo integrato (IDE) che semplifica lo sviluppo, la visualizzazione e il debug di applicazioni di data engineering e scienza dei dati scritte in scritte in R, Python, Scala e PySpark. Amazon SageMaker Studio fornisce un'interfaccia visuale unica basata sul Web in cui si possono eseguire tutte le fasi di sviluppo del machine learning. SageMaker Studio ti offre accesso, controllo e visibilità completi su ogni fase necessaria alla progettazione, la formazione e la distribuzione dei modelli. Puoi caricare rapidamente i dati, creare nuovi notebook, addestrare e configurare i modelli, andare avanti e indietro tra le fasi per modificare gli esperimenti, confrontare i risultati e distribuire i modelli in produzione in un unico luogo, aumentando molto la produttività. 

L’amministratore deve configurare EMR Studio. Una volta ricevuto un URL di accesso univoco per Amazon EMR Studio dall'amministratore, potrai accedere a Studio direttamente utilizzando le credenziali aziendali.

No. Dopo che l’amministratore ha configurato EMR Studio e ha fornito l’URL di accesso a Studio, il team potrà collegarsi utilizzando le credenziali aziendali. Non è necessario accedere alla Console di gestione AWS. In EMR Studio, il team può eseguire attività e accedere alle risorse configurate dall'amministratore.

Centro Identità AWS IAM (in sostituzione di AWS SSO) è il fornitore del servizio Single Sign-On per EMR Studio. Per un elenco di gestori dell'identità digitale supportati da AWS IAM, consulta la nostra documentazione.

Gli spazi di lavoro consentono di organizzare i notebook Jupyter. Tutti i notebook in un workspace sono salvati nella stessa posizione di Amazon S3 e sono eseguiti nello stesso cluster. Puoi anche collegare un repository di codice come un repository GitHub a tutti i notebook in un workspace. Puoi creare e configurare un workspace prima di collegarlo a un cluster, ma per eseguire un notebook è necessario essere collegati a un cluster.

Sì, puoi creare o aprire uno spazio di lavoro senza collegarlo a un cluster. Solo per l’esecuzione, è necessario collegarli a un cluster. Le applicazioni e i kernel di EMR Studio vengono eseguiti nei cluster EMR in modo da poter sfruttare i vantaggi dell'elaborazione dei dati distribuiti tramite il runtime di Amazon EMR per Apache Spark a prestazioni ottimizzate.

Tutte le query di Spark vengono eseguite all’interno del cluster EMR, pertanto devi istallare tutte le librerie di runtime che la tua applicazione Spark utilizza nel cluster. Puoi facilmente installare le librerie con ambito notebook all’interno di una cella del notebook. Puoi installare anche kernel notebook Jupyter e librerie Python su un nodo principale del cluster sia all’interno di una cella del notebook che con la connessione in essere tramite SSH al nodo principale del cluster. Per ulteriori informazioni, consulta la documentazione. Inoltre, puoi utilizzare una bootstrap action o un’AMI personalizzata per installare le librerie richieste al momento della creazione di un cluster. Per ulteriori informazioni, consulta le pagine Creazione di operazioni bootstrap per installare software aggiuntivi e Utilizzo di un'AMI personalizzata nella Guida alla gestione di Amazon EMR.

Lo spazio di lavoro e i file dei notebook presenti nello spazio di lavoro vengono salvati automaticamente ad intervalli regolari nel formato ipynb nella posizione Amazon S3 specificata al momento della creazione del notebook. Il file del notebook ha lo stesso nome del notebook in Amazon EMR Studio.

Puoi associare i repository basati su Git ai notebook Amazon EMR Studio per salvare i notebook in un ambiente controllato dalla versione.

Con EMR Studio è possibile eseguire il codice dei notebook su Amazon EMR in esecuzione su Amazon Elastic Compute Cloud (Amazon EC2) o Amazon EMR in esecuzione su Amazon Elastic Kubernetes Service (Amazon EKS). Si possono collegare i notebook a cluster nuovi o esistenti. Puoi creare i cluster EMR in due modi in EMR Studio: tramite un modello cluster preconfigurato con il Catalogo dei servizi AWS o specificando un nome per il cluster, il numero di istanze e il tipo di istanze.

Sì, puoi aprire il workspace, scegliere l'icona Cluster EMR a sinistra, fare clic sul pulsante Scollega, selezionare quindi un cluster dall'elenco a discesa Seleziona cluster e fare clic sul pulsante Esegui il collegamento.

In EMR Studio, puoi selezionare la scheda Workspace sulla sinistra e visualizzare tutti gli spazi di lavoro creati da e da altri utenti nello stesso account AWS.

Ogni EMR Studio ha bisogno di autorizzazioni per funzionare con altri servizi AWS. Per fornire a EMR Studio le autorizzazioni necessarie, gli amministratori devono creare un ruolo di servizio EMR con le policy fornite. Devono inoltre specificare un ruolo utente per EMR Studio che definisce le autorizzazioni a livello di Studio. Quando vengono aggiunti utenti e gruppi da AWS IAM Identity Center (in sostizione di AWS SSO) a EMR Studio, possono assegnare una policy di sessione a un utente o a un gruppo in modo da applicare controlli delle autorizzazioni granulari. Le policy di sessione consentono agli amministratori di rifinire le autorizzazioni utente senza dover creare più ruoli IAM. Per ulteriori informazioni sulle policy di sessione, consulta la sezione Policy e autorizzazioni nella Guida per l'utente di AWS Identity and Access Management (AWS IAM).

Sì. I cluster ad alta disponibilità (multi-master), i cluster con Kerberos e i cluster AWS Lake Formation al momento non sono supportati.

Non vi sono costi aggiuntivi per l’utilizzo di Amazon EMR Studio. Quando si utilizza EMR Studio, vengono applicate le tariffe applicabili per l’archiviazione di Amazon Simple Storage Service e per i cluster Amazon EMR. Per maggiori informazioni sulle opzioni di prezzi, consulta Prezzi di Amazon EMR.

Amazon EMR fornisce diversi modi per caricare i dati in un cluster. Il più comune consiste nel caricare i dati in Amazon S3 e utilizzare le funzionalità di Amazon EMR per caricare poi i dati nel cluster. Puoi utilizzare la funzionalità Cache distribuita di Hadoop per trasferire i file da un file system distribuito al file system locale. Per ulteriori informazioni, consulta la documentazione. In alternativa, se stai migrando i dati da un ambiente locale al cloud, puoi utilizzare uno dei servizi di migrazione dei dati al cloud di AWS.

I log di sistema Hadoop e i log dell'utente vengono memorizzati nel bucket Amazon S3 specificato al momento della creazione del cluster. Le interfacce utente delle applicazioni persistenti vengono eseguite fuori dal cluster. I log dei server di Spark History Server, dell'interfaccia utente Tez e della sequenza temporale YARN sono disponibili per 30 giorni dopo la chiusura di un'applicazione.

No. Al momento Amazon EMR non comprime i log prima di trasferirli in Amazon S3.

Sì. Puoi utilizzare AWS Direct Connect per stabilire una connessione di rete dedicate privata a AWS. In caso di grossi volumi di dati, puoi utilizzare AWS Import/Export. Per ulteriori dettagli, consulta la nostra documentazione.

No. I cluster e i dati di input possono variare, quindi non è possibile ottenere la stima della durata di un'operazione.

La fatturazione di Amazon EMR inizia nel momento in cui il cluster è pronto a eseguire delle operazioni. Termina invece quando si richiede l’arresto del cluster. Per ulteriori informazioni sull'inizio e sulla fine del periodo di fatturazione di Amazon EC2, consulta le Domande frequenti sulla fatturazione di Amazon EC2.

Per monitorare l'utilizzo dei servizi AWS, utilizza la console di gestione costi e fatturazione.

Nella Console di gestione AWS, ogni cluster dispone della colonna Normalized Istance Hours, in cui viene elencata un'approssimazione di ore di calolo utilizzate dal cluster, arrotondate per eccesso.

Le ore-istanza normalizzate corrispondono alle ore di calcolo in base all'equazione per cui 1 ora di utilizzo di un'istanza m1.small corrisponde a 1 ora di elaborazione normalizzata. Puoi consultare la nostra documentazione per visualizzare un elenco di dimensioni differenti all'interno di una famiglia di istanze e il corrispondente fattore di normalizzazione all'ora.

Ad esempio, se è in esecuzione un cluster da 10 nodi r3.8xlarge per un'ora, il numero totale di ore-istanza normalizzate nella console corrisponderà a 640 (10 (numero di nodi) x 64 (fattore di normalizzazione) x 1 (numero di ore di esecuzione del cluster) = 640).

Si tratta di un'approssimazione da non utilizzare a scopi di fatturazione. Per informazioni sull'utilizzo corretto e fatturabile di Amazon EMR, consulta la pagina Console di gestione costi e fatturazione.

Sì. Amazon EMR supporta le istanze on demand, le istanze Spot e le istanze riservate. Fai clic qui per ulteriori informazioni sulle istanze riservate di Amazon EC2. Fai clic qui per ulteriori informazioni sulle istanze spot di Amazon EC2. Fai clic qui per ulteriori informazioni sulle prenotazioni della capacità di Amazon EC2.

Amazon EMR avvia le istanze in due gruppi di sicurezza di Amazon EC2, uno per l’istanza principale e uno per gli altri nodi del cluster. Il gruppo di sicurezza master mantiene una porta aperta per comunicare con il servizio. Inoltre mantiene la porta SSH aperta per consentirti di accedere tramite SSH alle istanze tramite la chiave specificata all'avvio. Gli altri nodi sono avviati in un gruppo di sicurezza separato e possono comunicare esclusivamente con l'istanza master. Di default, entrambi i gruppi di sicurezza sono configurati per non consentire l'accesso dall'esterno, ad esempio da istanze Amazon EC2 di altri clienti. Poiché si tratta di gruppi di sicurezza all'interno del tuo account, puoi riconfigurarli utilizzando gli strumenti standard di EC2 o il pannello di controllo. Fai clic qui per ulteriori informazioni sui gruppi di sicurezza di EC2. Inoltre, puoi configurare il blocco dell'accesso pubblico di Amazon EMR in ogni regione utilizzata per impedire la creazione del cluster, se una regola consente l'accesso pubblico a qualsiasi porta che non è stata aggiunta a un elenco di eccezioni.

Amazon S3 fornisce meccanismi di autenticazione che proteggono i dati memorizzati da accessi non autorizzati. A meno che il cliente che carica i dati non modifichi la configurazione, solo lui può accedere ai dati. I clienti di Amazon EMR possono anche scegliere di inviare i dati in Amazon S3 utilizzando il protocollo HTTPS per maggiore sicurezza durante il trasferimento. Inoltre, Amazon EMR utilizza sempre il protocollo HTTPS per inviare dati tra Amazon S3 e Amazon EC2. Per maggiore sicurezza, i clienti possono crittografare i dati di input prima di caricarli in Amazon S3 (usando i comuni strumenti di crittografia dei dati); tuttavia dovranno aggiungere una fase di decrittografia all'inizio del cluster quando Amazon EMR carica i dati da Amazon S3.

Sì. AWS CloudTrail è un servizio Web che registra le chiamate alle API AWS e fornisce i relativi file di registro. Lo storico delle chiamate API AWS creato da CloudTrail rende possibile analisi di sicurezza, monitoraggio delle modifiche alle risorse e audit di conformità. Per ulteriori informazioni su CloudTrail, consulta la pagina dei dettagli di AWS CloudTrail, quindi attiva il servizio tramite la Console di gestione AWS di CloudTrail.

Per impostazione predefinita, i processi delle applicazioni di Amazon EMR utilizzano i profili dell'istanza EC2 quando chiamano altri servizi AWS. Per i cluster multi-tenant, Amazon EMR offre tre opzioni di gestione degli accessi degli utenti ai dati di Amazon S3.

1. L'integrazione con AWS Lake Formation permette di definire e gestire le policy di autorizzazione specifiche in AWS Lake Formation per accedere a database, tabelle e colonne nel Catalogo dati AWS Glue. Puoi applicare le policy di autorizzazione alle operazioni inviate tramite Notebook Amazon EMR e Apache Zeppelin per i carichi di lavoro interattivi di EMR Spark e inviare gli eventi di audit ad AWS CloudTrail. Abilitando questa integrazione, abiliti anche il single sign-on federato in EMR Notebooks o Apache Zeppelin dai sistemi di identità aziendale compatibili con lo standard Security Assertion Markup Language (SAML) 2.0.

2. L'integrazione nativa con Apache Ranger permette di impostare un server nuovo o esistente di Apache Ranger per definire e gestire le policy di autorizzazione specifiche per gli accessi degli utenti ai database, alle tabelle e alle colonne dei dati di Amazon S3 tramite Hive Metastore. Apache Ranger è uno strumento open source che abilita, monitora e gestisce la sicurezza dei dati in modo completo sulla piattaforma Hadoop.
   
   Questa integrazione nativa permette di definire tre tipi di policy di autorizzazione nel server di gestione delle policy di Apache Ranger. Puoi abilitare autorizzazioni a livello di tabella, colonna o riga per Hive, autorizzazioni a livello di tabella e colonna per Spark e autorizzazioni a livello di prefisso e oggetto per Amazon S3. Amazon EMR installa e configura automaticamente i plug-in di Apache Ranger corrispondenti nel cluster. Questi plug-in Ranger si sincronizzano con il server di gestione delle policy per le policy di autorizzazione, applicano il controllo degli accessi ai dati e inviano eventi di audit ad Amazon CloudWatch Logs.

3. Il mapper di ruoli utente per Amazon EMR permette di utilizzare le autorizzazioni di AWS IAM per gestire gli accessi alle risorse AWS. Puoi creare delle mappature tra utenti (o gruppi) o ruoli IAM personalizzati. Un utente o un gruppo può accedere solo ai dati permessi dal ruolo IAM personalizzato. Questa funzionalità al momento è disponibile tramite AWS Labs.

Amazon EMR avvia tutti i nodi di un cluster nella stessa zona di disponibilità di Amazon EC2. L’esecuzione di un cluster nella stessa zona migliora le prestazioni dei flussi dei processi. Di default, Amazon EMR avvia il cluster nella zona di disponibilità che offre la maggiore quantità di risorse. Tuttavia, se necessario, è possibile specificare una zona di disponibilità differente. Hai anche la possibilità di ottimizzare l'allocazione per le istanze on demand con il prezzo più basso e la capacità spot ottimale, oppure utilizzare le prenotazioni della capacità on demand.

Per un elenco completo delle regioni AWS supportate da Amazon EMR, consulta la tabella delle regioni AWS per l'infrastruttura globale AWS.

EMR supporta l'avvio di cluster all'interno della zona locale AWS di Los Angeles. Puoi utilizzare EMR nella regione degli Stati Uniti occidentali (Oregon) per avviare cluster in sottoreti associate alla zona locale AWS di Los Angeles.

Al momento della creazione di un cluster, consigliamo sempre di selezionare la regione in cui si trovano i dati.

Sì. Il trasferimento di dati tra regioni diverse sarà tuttavia soggetto alle tariffe per la larghezza di banda. Per informazioni sui prezzi della larghezza di banda, visita la sezione relativa ai prezzi della pagina dei dettagli di EC2.

La regione AWS GovCloud (Stati Uniti) è stata creata per le agenzie governative e altri clienti negli Stati Uniti. Soddisfa i requisiti delle norme ITAR negli USA. In GovCloud, EMR non supporta le istanze Spot né la funzione di abilitazione del debug. In GovCloud la console di gestione di EMR non è ancora disponibile.

Un cluster è una raccolta di istanze di Amazon Elastic Compute Cloud (Amazon EC2). Ogni istanza nel cluster è denominata nodo e ha un ruolo all'interno del cluster, denominato tipo di nodo. Amazon EMR installa inoltre diversi componenti software su ciascun tipo di nodo, assegnando a ciascun nodo un ruolo in un'applicazione distribuita come Apache Hadoop. Ogni cluster ha un identificatore univoco che inizia per "j-".

Un cluster Amazon EMR ha tre tipi di nodi:

1. Nodo master: un nodo che gestisce il cluster eseguendo componenti software per coordinare la distribuzione di dati e attività tra altri nodi per l'elaborazione. Il nodo master tiene traccia dello stato delle attività e monitora l'integrità del cluster stesso. Ogni cluster ha un nodo master ed è possibile creare un cluster a nodo singolo con solo il nodo master.

2. Nodo principale: un nodo con componenti software che eseguono attività e archiviano dati in Hadoop Distributed File System (HDFS) sul tuo cluster. I cluster multi-nodo hanno almeno un nodo principale.

3. Nodo attività: un nodo con i componenti software che eseguono solo attività e non archiviano dati in HDFS. I nodi attività sono facoltativi.

La fase del cluster è un'unità di elaborazione definita dall'utente, che viene mappata a grandi linee a un algoritmo per la manipolazione di dati. Ogni fase è un'applicazione Hadoop MapReduce implementata come JAR di Java o un programma di streaming scritto in Java, Ruby, Perl, Python, PHP, R o C++. Ad esempio, per calcolare la frequenza con cui compaiono tutte le parole di un documento e ordinarle in base al numero, la prima fase sarebbe un'applicazione MapReduce che conta le occorrenze di ogni parola e la seconda fase un'applicazione MapReduce che ordina i risultati della prima fase in base al numero.

STARTING: il cluster viene avviato configurando le istanze EC2.
BOOTSTRAPPING: le bootstrap action vengono eseguite sul cluster.
RUNNING: il cluster sta eseguendo una fase.
WAITING: il cluster è attivo ma non sono presenti fasi da eseguire.
TERMINATING: il cluster sta per essere terminato.
TERMINATED: il cluster è stato terminato senza errori.
TERMINATED_WITH_ERRORS: il cluster è stato terminato e si sono verificati degli errori.

PENDING: la fase è in attesa dell'esecuzione.

RUNNING: la fase è in esecuzione.

COMPLETED: la fase è stata completata correttamente.

CANCELLED: la fase è stata annullata prima dell'esecuzione perché una fase precedente non ha avuto esito positivo oppure il cluster è stato terminato prima della sua esecuzione.

FAILED: la fase non è stata eseguita correttamente.

Puoi avviare un cluster tramite la Console di gestione AWS, riempiendo l'apposito modulo di richiesta. In questo modulo, devi specificare il nome del cluster, il percorso in Amazon S3 dove si trovano i dati da utilizzare, l'applicazione per l'elaborazione, il percorso in cui salvare i dati in uscita e il numero e il tipo di istanze Amazon EC2 da utilizzare. Facoltativamente, puoi specificare un percorso in cui memorizzare i file di log del cluster e la chiave SSH per eseguire l'accesso al cluster mentre è in esecuzione. In alternativa, puoi avviare un cluster utilizzando l'API RunJobFlow oppure il comando “create” usando gli strumenti a riga di comando. Per avviare un cluster con EMR Studio, consulta la sezione dedicata a EMR Studio.

Puoi terminare un cluster in qualsiasi momento tramite la Console di gestione AWS selezionando un cluster e facendo clic sul pulsante “Terminate”. In alternativa, puoi usare l'API TerminateJobFlows. Se termini un cluster in esecuzione, i risultati non memorizzati in Amazon S3 andranno persi e tutte le istanze Amazon EC2 verranno interrotte.

Puoi avviare un numero indefinito di cluster. Tuttavia, all’inizio potrai usare solo 20 istanze su tutti i cluster. Se ti occorrono altre istanze, completa il form di richiesta di istanze Amazon EC2. Una volta aumentato il limite di istanze Amazon EC2, il nuovo limite verrà applicato direttamente ai cluster di Amazon EMR.

I dati di input e le applicazioni di elaborazione dei dati possono essere caricati in Amazon S3. Amazon EMR avvia quindi un certo numero di istanze Amazon EC2 specificate. Il servizio avvia l'esecuzione del cluster ed estrae i dati di input da Amazon S3 usando lo schema URI S3 nelle istanze Amazon EC2 avviate. Una volta terminata l'elaborazione del cluster, Amazon EMR trasferisce i dati risultanti in Amazon S3, da dove potrai recuperarli o utilizzarli come input in un altro cluster.

Amazon EMR usa il motore di elaborazione dei dati di Hadoop per l'elaborazione dei dati con il modello di programmazione MapReduce. Il cliente implementa il proprio algoritmo in termini di funzioni map() e reduce(). Il servizio avvia il numero di istanze Amazon EC2 richieste dal cliente, di cui una master e gli altri nodi. Amazon EMR esegue il software Hadoop in queste istanze. Il nodo master divide i dati in entrata in blocchi, distribuendone l'elaborazione in altri nodi. Ogni nodo esegue quindi la funzione map sui dati che gli sono stati allocati, generando dati intermedi. Questi dati intermedi vengono ordinati, partizionati e inviati ai processi che applicano la funzione riduttore localmente sui nodi. Infine, i dati di output provenienti dal processo reducer sono raccolti in file. Un singolo "cluster" può essere composto da una serie di queste fasi MapReduce.

Per informazioni sui tipi di istanza disponibili e sui relativi prezzi per regione, consulta la pagina dei prezzi di EMR.

La durata dell'elaborazione del cluster dipende da diversi fattori, tra cui il tipo di cluster, la quantità di dati di input e il numero e i tipi di istanze Amazon EC2 utilizzate dal cluster.

Sì. È possibile avviare un cluster EMR (versione 5.23 o successiva) con tre nodi master e supportare l'alta disponibilità di applicazioni come YARN Resource Manager, Name Node di HDFS, Spark, Hive e Ganglia. Amazon EMR esegue automaticamente il failover su un nodo master in standby in caso di errore del nodo master primario o di arresto anomalo di processi fondamentali come Resource Manager o Name Node. Poiché il nodo master non costituisce un singolo punto di errore, è possibile eseguire i cluster EMR a lungo termine senza interruzioni. In caso di failover, Amazon EMR sostituisce automaticamente il nodo principale che presenta un errore con un nuovo nodo principale dotato della stessa configurazione e delle stesse azioni bootstrap. 

Sì. Amazon EMR garantisce tolleranza ai guasti dei nodi e prosegue l'elaborazione anche quando uno di essi subisce un'interruzione. Il servizio effettua inoltre il provisioning di un nuovo nodo in caso di errore di un nodo principale. Tuttavia, Amazon EMR non eseguirà alcuna sostituzione se tutti i nodi di un cluster subiscono un'interruzione.

Sì. Puoi accedere tramite SSH ai nodi del cluster ed eseguire comandi Hadoop in modo diretto. Se desideri accedere a un nodo specifico tramite SSH, devi prima accedere nello stesso modo al nodo principale.

Bootstrap Actions è una funzionalità di Amazon EMR che consente agli utenti di eseguire configurazioni personalizzate prima di eseguire un cluster. Bootstrap Actions può essere usato per installare software o per configurare le istanze prima che il cluster venga avviato. Per ulteriori informazioni sulle bootstrap action consulta la Guida per gli sviluppatori.

Puoi scrivere uno script bootstrap action in qualsiasi linguaggio già installato sull'istanza del cluster, ad esempio Bash, Perl, Python, Ruby, C++ e Java. Sono disponibili diverse bootstrap action predefinite. Una volta completata la compilazione dello script, devi caricarlo in Amazon S3 e indicarne il percorso all'avvio del cluster. Per informazioni su come utilizzare le azioni bootstrap, consulta la Guida per sviluppatori.

La configurazione Hadoop di default di EMR è adatta a un'ampia gamma di carichi di lavoro. A seconda dei requisiti specifici di memoria e di elaborazione del cluster, tuttavia, potrebbe essere opportuno ottimizzarne le impostazioni. Ad esempio, se le attività assegnate al cluster hanno requisiti di memoria elevati, puoi scegliere di usare meno task per nodo principale e ridurre le dimensioni di heap del monitoraggio. In questo caso, è disponibile una bootstrap action predefinita per la configurazione del cluster all'avvio. Per informazioni sulla configurazione e istruzioni di utilizzo, consulta Configurazione di un'azione bootstrap con elevata quantità di memoria nella Guida per sviluppatori. È disponibile anche una bootstrap action predefinita che consente di personalizzare tutti i valori delle impostazioni del cluster. Consulta la sezione Configurazione di un'azione bootstrap nella Guida per sviluppatori per le istruzioni di utilizzo.

Sì. I nodi possono essere di due tipi: (1) nodi principali, che ospitano dati persistenti tramite file system distribuito di Hadoop (HDFS) ed eseguono attività di Hadoop e (2) nodi di task, che possono solo eseguire attività di Hadoop. Mentre un cluster è in esecuzione, puoi aumentare il numero di nodi principali e puoi aumentare o diminuire il numero di nodi di attività. Queste operazioni possono essere eseguite tramite l’API, SDK per Java oppure tramite il client da riga di comando. Per ulteriori informazioni su come modificare le dimensioni di un cluster in esecuzione, consulta la sezione Ridimensionamento dei cluster in esecuzione nella Guida per sviluppatori. Puoi utilizzare anche il dimensionamento gestito EMR.

I nodi principali possono ospitare dati persistenti in HDFS e non possono essere rimossi, quindi sono più adatti a offrire la capacità che occorre al cluster per l'elaborazione. I nodi di attività possono essere aggiunti e rimossi in qualsiasi momento e non contengono HDFS, perciò sono più idonei per offrire capacità temporanea. Puoi avviare parchi istanze di attività sulle istanze spot per aumentare la capacità riducendo al tempo stesso i costi.

Ci sono diversi scenari in cui può essere utile modificare il numero di nodi in un cluster in esecuzione. Se l'elaborazione del cluster è più lenta del previsto, oppure se cambia la scadenza entro la quale è necessario avere risultati, puoi aumentare il numero di nodi principali per migliorare le prestazioni del cluster. Se le diverse fasi di un cluster prevedono diversi requisiti di capacità, puoi iniziare con un numero non elevato di nodi principali, aumentando o diminuendo il numero di nodi di attività a seconda delle esigenze. Puoi utilizzare anche il dimensionamento gestito EMR.

Sì. Puoi includere nel flusso di lavoro una fase predefinita che determini automaticamente il ridimensionamento di un cluster tra due fasi con diversi requisiti di capacità. Poiché tutte le fasi vengono avviate in sequenza, potrai impostare il numero preciso di nodi per ogni fase del cluster.

Per creare un nuovo cluster che sia visibile a tutti gli utenti IAM, aggiungi il flag --visible-to-all-users nell'interfaccia a riga di comando di EMR al momento della creazione del cluster. Ad esempio: elastic-mapreduce --create --visible-to-all-users. Nella console di gestione, seleziona "Visible to all IAM Users" nel riquadro Advanced Options della procedura guidata Create cluster.

Per rendere un cluster esistente visibile a tutti gli utenti IAM, è necessario utilizzare l'interfaccia a riga di comando di EMR. Usa --set-visible-to-all-users e specifica l'identificatore del cluster. Ad esempio: elastic-mapreduce --set-visible-to-all-users true --jobflow j-xxxxxxx. Questa operazione può essere eseguita esclusivamente dal creatore del cluster.

Per ulteriori informazioni, consulta la sezione Configurazione delle autorizzazioni utente della Guida per sviluppatori di EMR.

È possibile aggiungere tag a un cluster Amazon EMR attivo. Un cluster di Amazon EMR è composto da istanze Amazon EC2, perciò un tag applicato a un cluster verrà propagato a tutte le istanze Amazon EC2 attive al suo interno. Non puoi aggiungere, modificare o rimuovere tag per cluster terminati o per istanze Amazon EC2 terminate che facevano parte di un cluster attivo.

No, Amazon EMR non supporta le autorizzazioni basate sulle risorse tramite tag. È importante tuttavia notare che i tag propagati alle istanze Amazon EC2 hanno gli stessi effetti dei comuni tag di Amazon EC2. Di conseguenza, una policy IAM per Amazon EC2 si comporterà con i tag propagati da Amazon EMR come se soddisfacessero le condizioni di tale policy.

Puoi applicare fino a dieci tag su un cluster Amazon EMR.

Sì, Amazon EMR propaga i tag aggiunti a un cluster anche alle relative istanze EC2. Pertanto, un tag aggiunto a un cluster Amazon EMR sarà applicato anche alle istanze Amazon EC2 ad esso associate. Analogamente, se viene rimosso un tag da un cluster Amazon EMR, verrà rimosso anche dalle relative istanze Amazon EC2. Tuttavia, se utilizzi le policy IAM per Amazon EC2 e desideri impiegare la funzionalità di applicazione di tag di Amazon EMR, assicurati di disporre dell'autorizzazione all'utilizzo delle API di applicazione di tag di Amazon EC2 CreateTags e DeleteTags.

Puoi selezionare i tag che desideri utilizzare nel report di fatturazione di AWS qui. Per visualizzare il costo complessivo delle risorse, puoi ordinare le informazioni di fatturazione raggruppando le risorse con gli stessi tag.

Un'istanza Amazon EC2 associata a un cluster Amazon EMR avrà due tag di sistema:

• aws:elasticmapreduce:instance-group-role=CORE

  • Chiave = ruolo istanza-gruppo ; Valore = [CORE o TASK];

• aws:elasticmapreduce:job-flow-id=j-12345678

  • Key = job-flow-id ; Value = [JobFlowID]

Sì, puoi aggiungere o rimuover tag direttamente sulle istanze Amazon EC2 che fanno parte di un cluster Amazon EMR. Tuttavia sconsigliamo di operare in questo modo: il sistema di tag di Amazon EMR non sincronizzerà direttamente le modifiche a un'istanza Amazon EC2 associata. Consigliamo invece di aggiungere e rimuovere i tag per i cluster Amazon EMR dalla console di Amazon EMR, dalla CLI oppure tramite API, per assicurare che al cluster e alle relative istanze Amazon EC2 siano applicati i tag corretti.

Amazon EMR serverless è una nuova opzione di distribuzione in Amazon EMR che consente di eseguire framework di big data come Apache Spark e Apache Hive senza dover configurare, gestire e dimensionare i cluster.

Data engineer, analisti e scienziati possono utilizzare EMR Serverless per creare applicazioni utilizzando framework open source come Apache Spark e Apache Hive. Possono utilizzare questi framework per trasformare i dati, eseguire query SQL interattive e carichi di lavoro di machine learning.

Puoi utilizzare EMR Studio, AWS CLI o le API per inviare lavori, monitorare lo stato dei lavori e costruire pipeline di dati da eseguire su EMR Serverless. Per iniziare a utilizzare EMR Studio, accedi alla Console di gestione AWS, vai ad Amazon EMR nella categoria Analytics (Analisi) e seleziona Amazon EMR Serverless. Segui le indicazioni riportate nella Console di gestione AWS, vai ad Amazon EMR nella categoria Analisi e seleziona Amazon EMR serverless. Segui le indicazioni riportate nella Guida alle operazioni di base per creare l'applicazione EMR Serverless e inviare le operazioni. Puoi consultare la pagina Interazione con l'applicazione nell'AWS CLI per avviare le applicazioni e inviare operazioni tramite la CLI. Gli esempi e il codice di esempio di EMR Serverless sono disponibili anche nel nostro Repository GitHub.

EMR Serverless supporta EMR 6.6 e versioni successive. Con EMR Serverless, si ottiene lo stesso runtime di EMR a prestazioni ottimizzate disponibile in altre opzioni di implementazione EMR, che è compatibile al 100% con le API dei framework open source standard.

Se la durata di esecuzione di un lavoratore è inferiore a 60 secondi, BilledResourceUtilization la conterà come 60 secondi, mentre TotalResourceUtilization la arrotonderà al secondo più vicino. Inoltre, BilledResourceUtilization esclude 20 GB di spazio di archiviazione gratuito dal calcolo.

Con Amazon EMR Serverless, puoi creare una o più applicazioni EMR Serverless che utilizzano framework di analisi open source. Per creare un'applicazione, devi specificare i seguenti attributi: 1) la versione di rilascio di Amazon EMR per la versione del framework open source che desideri utilizzare e 2) i motori di analisi specifici che l'applicazione deve utilizzare, come Apache Spark 3.1 o Apache Hive 3.0. Una volta creata l'applicazione, puoi iniziare a eseguire i lavori di elaborazione dei dati o inviare richieste interattive all'applicazione.

Un'applicazione EMR Serverless usa internamente i lavoratori per eseguire i carichi di lavoro. Quando viene inviato un lavoro, EMR Serverless calcola le risorse necessarie per eseguirlo e pianifica i worker. EMR Serverless suddivide i carichi di lavoro in attività, esegue il provisioning e configura i worker con il framework open source, quindi li disattiva quando il lavoro è completato. EMR Serverless aumenta o riduce automaticamente i worker a seconda del carico di lavoro e del parallelismo richiesto a ogni fase del lavoro, eliminando così la necessità di effettuare una stima del numero di worker necessari per eseguire i carichi di lavoro. Le dimensioni predefinite di questi worker si basano sul tipo di applicazione e sulla versione di rilascio di Amazon EMR. Puoi sostituire queste dimensioni quando pianifichi l'esecuzione di un'operazione.

Con EMR Serverless, puoi specificare il numero minimo e massimo di lavoratori simultanei, nonché la configurazione della vCPU e della memoria per i lavoratori. Inoltre, puoi impostare i limiti della capacità massima sulle risorse dell'applicazione per controllare i costi.

Considera la creazione di più applicazioni in uno dei seguenti casi:

1. Utilizzo di framework open source diversi

2. Utilizzo di framework open source con versioni diverse per differenti casi d'uso

3. Esecuzione di test comparativi durante l'aggiornamento da una versione all'altra

4. Conservazione di ambienti logici separati per scenari di test e produzione

5. Fornitura di ambienti logici separati per team differenti con controlli dei costi e monitoraggio dell'utilizzo indipendenti

6. Separazione di applicazioni di diverse linee di business

Sì, puoi modificare le proprietà dell'applicazione, come la capacità iniziale, i limiti di capacità massima e la configurazione di rete utilizzando EMR Studio o la chiamata API/CLI update-application.

Un'applicazione EMR Serverless senza lavoratori pre-inizializzati impiega fino a 120 secondi per determinare le risorse richieste e fornirle. EMR Serverless fornisce una funzionalità opzionale che mantiene i worker inizializzati e pronti a rispondere in pochi secondi, creando in modo efficace un pool di worker a chiamata per l'applicazione. Questa funzionalità è denominata capacità pre-inizializzata e può essere configurata per ogni applicazione impostando il parametro della capacità iniziale di un'applicazione.

La capacità pre-inizializzata consente di avviare i lavori immediatamente, il che è ideale per l'implementazione di lavori in cui il fattore tempo è essenziale. Puoi specificare il numero di worker da pre-inizializzare quando avvii un'applicazione EMR Serverless. Successivamente, quando gli utenti inviano i lavori, si possono utilizzare i worker pre-inizializzati per avviare immediatamente i lavori. Se il lavoro richiede più worker rispetto a quelli che hai scelto di pre-inizializzare, EMR Serverless li aggiunge automaticamente (fino al limite massimo di worker simultanei specificato). Al termine del lavoro, EMR Serverless torna automaticamente al numero di worker specificato. I worker vengono disattivati automaticamente se rimangono inattivi per 15 minuti. Puoi modificare il timeout di inattività predefinito dell'applicazione utilizzando l'API updateApplication o EMR Studio.

Per PySpark, puoi creare pacchetti di dipendenze Python utilizzando virtualenv e trasmettere il file di archivio con l'opzione --archives, che consente ai lavoratori di utilizzare le dipendenze durante l'esecuzione dell'operazione. Per Scala o Java, puoi creare pacchetti di dipendenze jar, caricarli in Amazon S3, e trasmetterli utilizzando le opzioni --jars o --packages con l'esecuzione dell'operazione EMR Serverless.

EMR Serverless supporta UDF basate su Java. Puoi creare pacchetti jar, caricarli in S3 e utilizzarli negli script Spark o HiveQL.

Sì, è possibile annullare un lavoro EMR Serverless in esecuzione da EMR Studio o chiamando l'API/CLI cancelJobRun.

È possibile aggiungere ulteriore spazio di archiviazione per i lavoratori in EMR Serverless selezionando l'opzione di archiviazione appropriata durante l'invio del lavoro. EMR Serverless offre due opzioni di archiviazione temporanea:

• Archiviazione standard: per impostazione predefinita, questa opzione include 20 GB di spazio di archiviazione temporanea per worker. È possibile personalizzarlo durante l'invio del lavoro e aumentare la capacità di archiviazione da 20 GB a 200 GB per worker.

• Archiviazione su disco ottimizzata per la riproduzione casuale: questa opzione fornisce fino a 2 TB di archiviazione temporanea per lavoratore, ottimizzata per carichi di lavoro ad alta intensità di riproduzione.

EMR Serverless offre due opzioni per i lavoratori: lavoratori on demand e lavoratori preinizializzati.

I worker on demand vengono avviati solo quando sono necessari per un processo e vengono rilasciati automaticamente al termine di tale processo. Ciò consente di risparmiare sui costi pagando solo le risorse utilizzate ed evitando costi aggiuntivi per la capacità inutilizzata. I worker on demand ridimensionano o riducono l'applicazione in base al carico di lavoro, così da non doversi preoccupare di sovradimensionare o sottodimensionare le risorse.

I worker preinizializzati sono una funzionalità opzionale che consente di mantenere i worker pronti a rispondere in pochi secondi. In questo modo si crea in modo efficace un bacino di worker a caldo per un'applicazione. Ciò consente l'avvio immediato delle operazioni, rendendo questa modalità ideale per applicazioni iterative e processi urgenti.

Sì, è possibile configurare le applicazioni EMR Serverless in più zone di disponibilità (AZ). Il processo per configurare più AZ dipende dal tipo di worker utilizzati.

Quando si utilizzano solo i worker on demand, EMR Serverless distribuisce i processi in più AZ per impostazione predefinita, ma ogni processo viene eseguito solo in una AZ. Puoi scegliere le AZ da usare associando le sottoreti alle stesse AZ. Se una AZ riporta un errore, EMR Serverless esegue automaticamente il processo in un'altra AZ integra.

Quando si utilizzano worker preinizializzati, EMR Serverless seleziona una AZ integra tra le sottoreti specificate. I processi vengono inviati in quella AZ fino a quando non viene arrestata l'applicazione. Se una AZ viene compromessa, sarà possibile riavviare l'applicazione per passare a un'altra AZ integra.

EMR Serverless può accedere a determinate risorse AWS nella stessa regione solo se configurato senza connettività VPC. Leggi le considerazioni. Per accedere alle risorse AWS in una regione diversa o a risorse non AWS, dovrai configurare l'accesso VPC e un gateway NAT per il routing verso gli endpoint pubblici per le risorse AWS.

I parametri a livello di applicazione e di operazione di Amazon EMR serverless vengono pubblicati ogni 30 secondi in Amazon CloudWatch.

Sì, puoi configurare le applicazioni Amazon EMR Serverless in modo che accedano al tuo VPC. Per ulteriori informazioni, consulta la sezione Configurazione dell'accesso VPC nella documentazione. 

Ogni applicazione EMR Serverless è isolata dalle altre e viene eseguita su un Amazon VPC sicuro.

Puoi visualizzare, gestire e richiedere un aumento della quota nella console di gestione AWS Service Quotas. Per ulteriori informazioni, consulta Richiesta di aumento delle quote nella Guida per l'utente di Service Quotas.

Se superi la quota di vCPU a livello di account, EMR Serverless smette di fornire ulteriore capacità. Se provi a creare una nuova applicazione dopo aver superato la quota, la creazione dell'applicazione ha esito negativo e viene generato il messaggio di errore "Application failed to create as you have exceeded the maximum concurrent vCPUs per account service quota. You can view and manage your service quota using AWS Service Quotas console" (Impossibile creare l'applicazione perché è stata superata la quota di servizio massima di vCPU simultanee per account. È possibile visualizzare e gestire le quote di servizio dalla console AWS Service Quotas). Se dopo aver superato la quota invii un nuovo lavoro, questo avrà esito negativo e verrà generato il messaggio di errore:"Job failed as you have exceeded the maximum concurrent vCPUs per account service quota. È possibile visualizzare e gestire le quote di servizio dalla console AWS Service Quotas.” Per ulteriori informazioni, consulta la documentazione.

Amazon EMR Serverless consente di risparmiare sui costi in tre modi diversi. In primo luogo, non ci sono costi operativi per la gestione, la protezione e il dimensionamento dei cluster. Secondariamente, EMR Serverless aumenta automaticamente i worker a ogni fase dell'elaborazione del lavoro e li riduce quando non sono necessari. Ti verranno addebitati i costi per la vCPU aggregata, la memoria e le risorse di archiviazione utilizzate a partire dall'avvio dell'esecuzione di un worker fino a quando non termina, arrotondando al secondo più vicino e considerando il tempo di un minuto come minimo. Ad esempio, il lavoro può richiedere 10 worker per i primi 10 minuti di elaborazione e 50 worker per i 5 minuti successivi. Con un dimensionamento automatico granulare, sosterrai i costi per soli 10 worker per 10 minuti e 50 worker per 5 minuti, pertanto non dovrai pagare per risorse sottoutilizzate. Terzo e ultimo modo, EMR Serverless include il runtime Amazon EMR a prestazioni ottimizzate per Apache Spark, Apache Hive e Presto. Il runtime Amazon EMR è compatibile con l'API e oltre due volte più veloce dei motori di analisi open source standard, quindi le operazioni vengono eseguite più rapidamente a costi di calcolo inferiori.

Dipende dall'attuale utilizzo di EMR sui cluster EC2. Se esegui i cluster EMR con istanze on demand EC2, EMR Serverless offrirà un costo totale di proprietà (TCO) più basso se l'attuale utilizzo dei cluster è inferiore al 70%. Se utilizzi i Savings Plans di EC2, EMR Serverless offrirà un TCO più basso se l'utilizzo dei cluster è inferiore al 50%. E se utilizzi le istanze spot EC2, Amazon EMR su EC2 e Amazon EMR su EKS saranno ancora più convenienti.

Sì, se non interrompi i lavoratori al termine di un'operazione, ti verranno addebitati i costi degli utenti pre-inizializzati.

Per PySpark, puoi creare pacchetti di dipendenze Python utilizzando virtualenv e trasmettere il file di archivio con l'opzione --archives, che consente ai lavoratori di usare le dipendenze durante l'esecuzione del lavoro. Per Scala o Java, puoi creare pacchetti di dipendenze jar, caricarli in Amazon S3, e trasmetterli utilizzando le opzioni --jars o --packages con l'esecuzione dell'operazione EMR Serverless.

Per PySpark, puoi creare pacchetti di dipendenze Python utilizzando virtualenv e trasmettere il file di archivio con l'opzione --archives, che consente ai lavoratori di usare le dipendenze durante l'esecuzione del lavoro. Per Scala o Java, puoi creare pacchetti di dipendenze jar, caricarli in Amazon S3, e trasmetterli utilizzando le opzioni --jars o --packages con l'esecuzione dell'operazione EMR Serverless.

Amazon EMR Serverless elimina il provisioning dell’archiviazione locale per i carichi di lavoro Apache Spark, riducendo i costi di elaborazione dei dati fino al 20% e prevenendo gli errori dei processi dovuti ai vincoli di capacità del disco. EMR Serverless gestisce automaticamente le operazioni di dati intermedie come lo shuffle senza richiedere alcuna decisione sull'infrastruttura. Gestendo automaticamente i dati intermedi indipendentemente dai lavoratori di calcolo, questa ottimizzazione consente alla Dynamic Resource Allocation (DRA) di Spark di rilasciare risorse di calcolo nel momento in cui non sono più necessarie per l'elaborazione, anziché mantenerle in esecuzione solo per preservare i dati locali temporanei. Questo miglioramento automatico offre una maggiore elasticità per carichi di lavoro di trasformazione di grandi dimensioni, come aggregazioni di grandi dimensioni, join e analisi complesse, consentendo alle risorse di calcolo di aumentare e ridurre verticalmente in modo dinamico tra le fasi dell'operazione senza essere vincolate dai dati archiviati localmente.

È sufficiente aderire quando si utilizza la versione EMR 7.12 o successiva. I tuoi lavori Spark trarranno automaticamente vantaggio da una gestione intermedia ottimizzata dei dati senza richiedere alcuna configurazione da parte tua. Puoi monitorare i tuoi lavori in tempo reale utilizzando l'interfaccia utente di Spark Live e visualizzare parametri dettagliati per shuffle e spill e per fase per i lavori completati nello Spark History Server.

I dati intermedi vengono archiviati solo mentre il processo è in esecuzione e vengono eliminati automaticamente una volta completato, assicurando che nessun dato persista oltre il ciclo di vita del lavoro.

Questa ottimizzazione automatica mantiene gli stessi standard di sicurezza di livello aziendale di EMR Serverless attraverso più livelli di protezione. Tutti i dati sono crittografati sia in transito tra l'applicazione EMR Serverless e il livello intermedio di elaborazione dei dati, sia a riposo mentre sono archiviati temporaneamente, utilizzando chiavi di crittografia gestite da AWS. Questa funzionalità impone un rigoroso isolamento dei dati e un controllo degli accessi archiviando i dati intermedi con identificatori specifici del lavoro all'interno del namespace, assicurando che i dati rimangano accessibili solo per il lavoro specifico. I controlli di accesso e le autorizzazioni EMR Serverless esistenti continuano ad essere applicati, quindi i dati regolati dalla tabella o dalle policy di Lake Formation rimangono completamente protetti. Per una maggiore sicurezza, EMR Serverless utilizza un ruolo di proprietà del servizio per gestire l'elaborazione intermedia dei dati anziché il ruolo di esecuzione del lavoro, impedendo l'escalation dei privilegi o l'accesso non autorizzato tra account. Se si verifica un errore durante il controllo di sicurezza, il lavoro si interrompe immediatamente per garantire che i dati rimangano protetti in ogni momento.