Domande frequenti su Amazon EMR

Amazon EMR è la piattaforma cloud di big data leader del settore per l'elaborazione di dati, l’analisi interattiva e il machine learning tramite framework open source come Apache Spark, Apache Hive e Presto. EMR consente di eseguire analisi su scala petabyte a meno della metà del costo delle tradizionali soluzioni on-premises e con una velocità 1,7 volte superiore rispetto a quella della versione standard di Apache Spark.

Amazon EMR consente di concentrarsi sulla trasformazione e l’analisi dei dati senza doversi preoccupare della gestione della capacità di calcolo o delle applicazioni open-source, risparmiando in questo modo tempo e denaro. Utilizzando EMR, puoi fornire immediatamente la capacità che desideri su Amazon EC2 e impostare regole di scalabilità per gestire la domanda di elaborazione in continua evoluzione. Puoi impostare avvisi CloudWatch per ricevere una notifica dei cambiamenti nell’infrastruttura e intraprendere immediatamente le azioni appropriate. Se si utilizza Kubernetes, puoi utilizzare EMR anche per inviare i carichi di lavoro ai cluster Amazon EKS. Utilizzando EC2 o EKS, si trae vantaggio dai tempi di esecuzione ottimizzati di EMR che velocizzano l’analisi e fanno risparmiare tempo e denaro.

Puoi implementare i tuoi carichi di lavoro su EMR utilizzando Amazon EC2, Amazon Elastic Kubernetes Service (EKS) o AWS Outposts on-premises. Puoi eseguire e gestire i carichi di lavoro con la console EMR, l’API, l’SDK o la CLI e orchestrarli utilizzando Amazon Managed Workflows for Apache Airflow (MWAA) o AWS Step Functions. Per un’esperienza interattiva, è possibile utilizzare EMR Studio o SageMaker Studio.

Per registrarti ad Amazon EMR, fai clic sul pulsante “Registrati ora” nella pagina dei dettagli di Amazon EMR all’indirizzo http://aws.amazon.com/emr. Per accedere ad Amazon EMR devi essere registrato ad Amazon EC2 e ad Amazon S3; in caso contrario, ti verrà chiesto di farlo durante la procedura di registrazione ad Amazon EMR. Dopo esserti registrato, consulta la documentazione di Amazon EMR, che include una Guida alle operazioni di base, il modo migliore per imparare a usare il servizio.

Fai riferimento al 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 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ì. Puoi terminare automaticamente il cluster alla fine di tutti i passaggi attivando il contrassegno di terminazione automatica.

Amazon EMR 5.30.0 e successivo e la serie Amazon EMR 6.x sono basati su Amazon Linux 2. Puoi specificare un'AMI personalizzata creata basandosi su Amazon Linux 2. Praticamente ciò consente di eseguire sofisticate pre-configurazioni per qualsiasi applicazione. Per ulteriori informazioni, consulta Utilizzo di un'AMI personalizzata.

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 attraverso 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 attraverso 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 consente 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. È possibile caricare 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 implementare i modelli per la produzione in un unico luogo e rapidamente, così da aumentare 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 tue 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 tuo 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 uno spazio di lavoro 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 Crea bootstrap action per installare software aggiuntivo 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 fine del notebook ha lo stesso nome del tuo notebook in Amazon EMR Studio.

Puoi associare i repository basati su Git ai notebook Amazon EMR Studio per salvare i tuoi 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 lo spazio di lavoro, scegliere l’icona Cluster EMR sulla sinistra, fare clic sul pulsante Scollega, selezionare quindi un cluster dall’elenco a discesa Seleziona cluster e fare clic sul pulsante Allega.

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 maggiori informazioni sulle policy di sessione, fai riferimento a Policy e autorizzazioni nella Guida per l'utente di AWS Identity and Access Management.

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.

Ai nuovi utenti consigliamo di utilizzare Amazon EMR Studio e non gli EMR Notebooks. Gli EMR Notebooks forniscono un ambiente gestito, basato sui notebook Jupyter, che permette ai data scientist, agli analisti e agli sviluppatori di preparare e visualizzare dati, di collaborare con i peer, di creare applicazioni e realizzare analisi attraverso i cluster EMR. Nonostante consigliamo ai nuovi clienti di utilizzare EMR Studio, gli EMR Notebooks sono supportati per la compatibilità.

Puoi utilizzare gli EMR notebook per creare applicazioni Apache Spark ed eseguire query interattive sui tuoi cluster EMR con il minimo sforzo. I diversi utenti possono creare notebook senza server direttamente dalla console, collegarli ad un cluster EMR condiviso esistente o effettuare il provisioning di un cluster direttamente dalla console e cominciare subito a sperimentare con Spark. Puoi scollegare i notebook e ricollegarli a nuovi cluster. I notebook vengono salvati automaticamente nei bucket di S3: è possibile recuperare i notebook salvati dalla console per ripristinare il lavoro. I EMR notebook sono preconfigurati alle librerie all’interno del repository di Anaconda, permettendoti di importare e utilizzare queste librerie nel tuo codice di notebook e servirtene per manipolare dati e visualizzare risultati. Inoltre, i EMR notebook hanno funzionalità di monitoraggio di Spark integrate, che possono essere utilizzate per controllare i progressi dei tuoi lavori di Spark ed seguire il debug del codice all’interno del notebook.

Per iniziare ad utilizzare i notebook EMR, apri la console EMR e seleziona Notebooks dal riquadro di navigazione. Seleziona poi Create Notebook (Crea un notebook), inserisci un nome per il tuo notebook, scegli un cluster EMR o creane uno istantaneamente, assegna al notebook un ruolo di servizio che può utilizzare, seleziona un bucket S3 dove desideri salvare i file del tuo notebook e, infine, clicca su Create Notebook. Una volta che lo stato del notebook sarà passato a Ready (pronto), clicca su Open (apri) per avviare l’editor del notebook.

Gli EMR Notebooks possono essere collegati a cluster EMR con la versione di rilascio 5.18.0 o successiva.

Non vi sono costi aggiuntivi per l’utilizzo degli EMR Notebooks. Pagherai i cluster EMR collegati nel tuo account come al solito. Per ulteriori informazioni sui prezzi dei tuoi cluster, visita la pagina https://aws.amazon.com/emr/pricing/ 

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 maggiori dettagli, consulta la documentazione. In alternativa, se stai migrando i dati da locale al cloud, puoi utilizzare uno dei servizi di Migrazione dei dati nel cloud da 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 Spark History Server, dell’interfaccia utente Tez e della sequenza temporale YARN sono disponibili per 30 giorni dopo la chiusura di un'applicazione.

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

D: I log vengono compressi?

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. Poiché i cluster e i dati di input possono variare, non è possibile ottenere la stima della durata di un processo.

I prezzi di Amazon EMR sono chiari e semplici da calcolare: si paga una tariffa per ogni secondo utilizzato, con una tariffa minima di 1 minuto. Puoi stimare la tua fattura con il Calcolatore dei prezzi AWS. L'utilizzo per altri servizi AWS, tra cui Amazon EC2, viene fatturato separatamente da Amazon EMR.

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 maggiori dettagli sull’inizio e sulla fine della fatturazione di Amazon EC2, fai riferimento alle Domande frequenti sulla fatturazione di Amazon EC2.

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

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. Consulta la Console di gestione di fatturazione e costi se desideri conoscere utilizzo fatturabile di Amazon EMR.

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 di capacità di Amazon EC2.

Salvo diversamente specificato, i prezzi sono al netto di eventuali tasse e imposte doganali, inclusa l'IVA ed eventuali imposte sulle vendite. Per i clienti con indirizzo di fatturazione in Giappone, l'utilizzo dei servizi AWS è soggetto all'imposta sul consumo giapponese. Ulteriori informazioni. 

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 su 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 procedimenti delle applicazioni di Amazon EMR utilizzano i profili dell'istanza EC2 quando richiamano 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 granulari in AWS Lake Formation per accedere a database, tabelle e colonne nel Catalogo dati AWS Glue. Puoi applicare le policy di autorizzazione ai processi inviati 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 granulare 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 mappatore di ruoli utente per Amazon EMR consente di sfruttare 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, la capacità spot ottimale o utilizzare le prenotazioni di 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.

Amazon EMR su Amazon EC2

Amazon EMR su Amazon EKS

Amazon EMR su AWS Outposts

Avvio

Gestione

Applicazione di tag

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, fai riferimento alla sezione relativa a EMR Studio di seguito.

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 nei tuoi 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 richiamarli o usarli 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.

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

La durata dell'elaborazione del cluster dipende da diversi fattori, tra cui il tipo di cluster, la quantità di dati da elaborare 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 in errore con un nuovo nodo principale dotato della stessa configurazione e delle stesse bootstrap action. 

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. Fai riferimento alla Guida per sviluppatori per i dettagli su come utilizzare le bootstrap action.

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. Consulta Configure Memory Intensive Bootstrap Action nella Guida per sviluppatori per informazioni sulla configurazione e istruzioni di utilizzo. È disponibile anche una bootstrap action predefinita che consente di personalizzare tutti i valori delle impostazioni del cluster. Consulta Configure Hadoop Bootstrap Action 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. Consulta la sezione Ridimensionamento dei cluster in esecuzione nella Guida per sviluppatori per ulteriori informazioni su come modificare le dimensioni di un cluster in esecuzione. 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 lo scaling 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 è possibile 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 usi 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 tag di Amazon EC2 CreateTags e DeleteTags.

Puoi selezionare i tag che desideri usare nel report di fatturazione di AWS qui. Per vedere quindi 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

  • Chiave = ID flusso lavoro ; Valore = [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 implementazione 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 Analytics (Analisi) e seleziona Amazon EMR Serverless. Segui le indicazioni riportate nella Guida alle operazioni di base per creare l'applicazione EMR Serverless e inviare i lavori. Puoi consultare la pagina Interacting with your application on the AWS CLI (Interazione con l'applicazione nell'AWS CLI) per avviare le applicazioni e inviare lavori tramite la CLI. Gli esempi e il codice di esempio di EMR Serverless sono disponibili anche nel nostro Repository GitHub.

Attualmente EMR Serverless supporta i motori Apache Spark e Apache Hive. Se è necessario il supporto per framework aggiuntivi, come Apache Presto o Apache Flink, invia una richiesta a emr-feedback@amazon.com.

EMR Serverless è disponibile nelle seguenti regioni AWS: Asia Pacifico (Mumbai), Asia Pacifico (Seoul), Asia Pacifico (Singapore), Asia Pacifico (Sydney), Asia Pacifico (Tokyo), Canada (Centrale), Europa (Francoforte), Europa (Irlanda), Europa (Londra), Europa (Parigi), Europa (Stoccolma), Sud America (San Paolo), Stati Uniti orientali (Virginia settentrionale), Stati Uniti orientali (Ohio), Stati Uniti occidentali (California settentrionale) e Stati Uniti occidentali (Oregon).

Amazon EMR consente di eseguire applicazioni su cluster basati su EC2, cluster EKS, Outposts o Serverless. I cluster EMR su EC2 sono adatti per i clienti che necessitano di massimo controllo e flessibilità nell'esecuzione della loro applicazione. Con EMR su cluster EC2, i clienti possono scegliere il tipo di istanza EC2 per ottenere prestazioni specifiche per l'applicazione, personalizzare l'AMI Linux, personalizzare la configurazione dell'istanza EC2, personalizzare ed estendere i framework open source e installare ulteriore software personalizzato sulle istanze cluster. Amazon EMR su EKS è adatto per i clienti che desiderano standardizzare su EKS per gestire i cluster nelle applicazioni o utilizzare diverse versioni di un framework open source sullo stesso cluster. Amazon EMR su AWS Outposts è adatto ai clienti che desiderano eseguire EMR più in prossimità del proprio data center, in un Outpost. EMR Serverless è adatto per i clienti che desiderano evitare di gestire e far funzionare i cluster e preferiscono eseguire le applicazioni utilizzando framework open source.

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.

BilledResourceUtilization tiene conto esclusivamente della durata in cui la capacità preinizializzata è stata utilizzata per il processo e non tiene conto dei relativi tempi di inattività.

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 lavoro.

Con EMR Serverless, puoi specificare il numero minimo e massimo di lavoratori simultanei, nonché la configurazione della vCPU e della memoria per i lavoratori. Puoi inoltre 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.

Puoi inviare e gestire lavori EMR Serverless utilizzando EMR Studio, SDK/CLI o i nostri connettori Apache Airflow.

Per PySpark, puoi creare pacchetti di dipendenze Python utilizzando virtualenv e trasmettere il file di archivio con l'opzione --archives, che consente ai worker 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 del lavoro EMR Serverless.

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

Per i dettagli, consulta Supported Worker Configuration (Configurazione dei worker supportata).

Sì, puoi 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.

I codici di esempio di EMR Serverless sono disponibili nel nostro Repository GitHub.

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 dei processi, 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 lavoro di Amazon EMR Serverless vengono pubblicati ogni 30 secondi in Amazon CloudWatch.

Da EMR Studio puoi selezionare un lavoro EMR Serverless in esecuzione o completato e fare clic sul pulsante Spark UI (Interfaccia utente Spark) o Tez UI (UI Tez) per avviarle.

Sì, puoi configurare le applicazioni Amazon EMR Serverless in modo che accedano al tuo VPC. Consulta la sezione Configuring VPC access (Configurazione dell'accesso VPC) nella documentazione per ulteriori informazioni. 

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

Amazon EMR Serverless introduce una nuova quota di servizio denominata Max concurrent vCPUs per account (N. massimo di vCPU simultanee per account). Questa quota basata su vCPU consente di impostare il numero massimo di vCPU aggregate che le tue applicazioni sono in grado di aumentare in una regione. Le quote esistenti a livello di applicazione, basate su lavoratori (numero massimo di lavoratori attivi), non saranno più supportate a partire dal 1° febbraio 2023.

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.

EMR Serverless fornisce due controlli dei costi: 1/ La quota massima di vCPU simultanee per account viene applicata in tutte le applicazioni EMR Serverless di una regione nel tuo account. 2/ Il parametro maximumCapacity limita la vCPU di un'applicazione EMR Serverless specifica. Si consiglia di utilizzare la quota basata su vCPU per limitare le vCPU massime simultanee utilizzate da tutte le applicazioni in una regione e la proprietà maximumCapacity per limitare le risorse utilizzate da un'applicazione specifica. Ad esempio, nel caso di 5 applicazioni, dove ognuna delle quali può aumentare verticalmente fino a 1000 vCPU, imposta la proprietà maximumCapacity a 1000 vCPU per ogni applicazione e configura la quota basata su vCPU a livello di account a 5 * 1000 = 5000 vCPU.

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 maggiori dettagli, 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 due volte più veloce dei motori di analisi open source standard, quindi i lavori vengono eseguiti 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 dopo il completamento di un lavoro, ti verranno addebitati i costi dei lavoratori 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 del lavoro 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 del lavoro 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 scalare dinamicamente verso l'alto e verso il basso tra le fasi del lavoro 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 al termine del processo, 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 un controllo di sicurezza fallisce, il tuo lavoro si interrompe immediatamente per garantire che i tuoi dati rimangano protetti in ogni momento.