Considerazioni su EMR Studio - Amazon EMR
ConsiderazioniProblemi notiLimitazioni delle caratteristicheLimiti del servizioBest practice per VPC e sottoretiRequisiti del cluster

Considerazioni su EMR Studio

Considerazioni

Quando lavori con EMR Studio, tieni in considerazione i seguenti aspetti:

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

  • Per consentire agli utenti di effettuare il provisioning di nuovi cluster EMR in esecuzione su Amazon EC2 per un Workspace, puoi associare un EMR Studio a un set di modelli di cluster. Gli amministratori possono definire modelli di cluster con Service Catalog e scegliere se un utente o un gruppo può accedere ai modelli o a nessuno dei modelli all'interno di uno Studio.

  • Quando definisci le autorizzazioni di accesso ai file notebook archiviati in Amazon S3 o leggi segreti da AWS Secrets Manager, utilizza il ruolo di servizio Amazon EMR. Le politicy di sessione non sono supportate con queste autorizzazioni.

  • Puoi creare più EMR Studio per controllare l'accesso ai cluster EMR in VPC diversi.

  • Utilizza la AWS CLI per configurare cluster Amazon EMR su EKS. È quindi possibile utilizzare l'interfaccia Studio per collegare cluster ai Workspace con un endpoint gestito per eseguire processi notebook.

  • EMR Studio non supporta i seguenti comandi magic Python:

    • %alias

    • %alias_magic

    • %automagic

    • %macro

    • %%js

    • %%javascript

    • Modifica di proxy_user mediante %configure

    • Modifica di KERNEL_USERNAME mediante %env o %set_env

  • I cluster Amazon EMR su EKS non supportano i comandi SparkMagic per EMR Studio.

  • Per scrivere istruzioni Scala a più righe nelle celle del notebook, assicurarsi che tutte le righe tranne l'ultima finiscano con un punto. Nell'esempio seguente viene utilizzata la sintassi corretta per le istruzioni Scala a più righe.

    val df = spark.sql("SELECT * from table_name).
        filter("col1=='value'").
        limit(50)

Problemi noti

  • Assicurati di disattivare gli strumenti di gestione proxy come FoxyProxy o SwitchyOmega nel browser prima di creare uno Studio. I proxy attivi possono causare errori quando scegli Create Studio (Crea Studio) e tradursi in un messaggio di errore Network Failure (Errore di rete).

  • I kernel che vengono eseguiti su cluster Amazon EMR su EKS possono non avviarsi a causa di problemi di timeout. Se si verifica un errore o un problema durante l'avvio del kernel, è necessario chiudere il file notebook, arrestare il kernel e in seguito riaprire il file notebook.

  • L'operazione Restart kernel (Riavvia kernel) non funziona come previsto quando si usa un cluster Amazon EMR su EKS. Dopo aver selezionato Restart kernel (Riavvia kernel), aggiorna il Workspace affinché il riavvio abbia effetto.

  • Se un Workspace non è collegato a un cluster, viene visualizzato un messaggio di errore quando un utente dello Studio apre un file notebook e tenta di selezionare un kernel. Puoi ignorare questo messaggio di errore scegliendo Ok, ma è necessario collegare il Workspace a un cluster e selezionare un kernel prima di poter eseguire il codice del notebook.

  • Quando utilizzi Amazon EMR 6.2.0 con una configurazione di sicurezza per impostare la protezione del cluster, l'interfaccia del Workspace appare vuota e non funziona come previsto. Se desideri configurare la crittografia dei dati o l'autorizzazione Amazon S3 per EMRFS per un cluster, consigliamo di utilizzare un'altra versione di Amazon EMR supportata. EMR Studio funziona con Amazon EMR versione 5.32.0 (Amazon EMR serie 5.x) o 6.2.0 (Amazon EMR serie 6.x) e versioni successive.

  • Quando avvii l'interfaccia utente Spark sul cluster da un file notebook, puoi visualizzare le informazioni su un processo dopo l'esecuzione del codice del notebook. Tuttavia, quando avvii il server della cronologia Spark dall'elenco Cluster dello Studio, il processo potrebbe non essere visualizzato per un massimo di due minuti.

  • Quando Esecuzione del debug di Amazon EMR su processi Amazon EC2, i collegamenti all'interfaccia utente Spark sul cluster potrebbero non funzionare o non essere visualizzati. Per rigenerare i collegamenti, crea una nuova cella del notebook ed esegui il comando %%info.

  • Jupyter Enterprise Gateway non elimina i kernel inattivi sul nodo primario di un cluster nelle seguenti versioni Amazon EMR: 5.32.0, 5.33.0, 6.2.0 e 6.3.0. I kernel inattivi consumano risorse di elaborazione e possono causa l'interruzione dei cluster a esecuzione prolungata. È possibile configurare l'eliminazione del kernel inattivo per Jupyter Enterprise Gateway utilizzando il seguente script di esempio. Puoi Connessione al nodo primario tramite SSH oppure inviare lo script come fase. Per ulteriori informazioni, consulta Esecuzione di comandi e script su un cluster Amazon EMR.

    #!/bin/bash
sudo tee -a /emr/notebook-env/conf/jupyter_enterprise_gateway_config.py << EOF
c.MappingKernelManager.cull_connected = True
c.MappingKernelManager.cull_idle_timeout = 10800
c.MappingKernelManager.cull_interval = 300
EOF
sudo systemctl daemon-reload
sudo systemctl restart jupyter_enterprise_gateway

  • Quando utilizzi una policy di terminazione automatica con Amazon EMR versioni 5.32.0, 5.33.0, 6.2.0 o 6.3.0, Amazon EMR contrassegna un cluster come inattivo e potrebbe terminarlo in automatico anche se disponi di un kernel Python3 attivo. Questo perché l'esecuzione di un kernel Python3 non invia un processo Spark sul cluster. Per utilizzare la terminazione automatica con un kernel Python3, consigliamo di utilizzare Amazon EMR versione 6.4.0 o successive. Per ulteriori informazioni sulla terminazione automatica, consulta Utilizzo di una policy di terminazione automatica.

  • Quando si utilizza %%display per visualizzare un DataFrame Spark in una tabella, le tabelle molto ampie potrebbero essere troncate. È possibile fare clic con il pulsante destro del mouse sull'output e selezionare Creare nuova vista per l'output per ottenere una schermata scorrevole dell'output.

  • L'avvio di un kernel basato su Spark, come PysPark, Spark o SparkR, avvia una sessione Spark e l'esecuzione di una cella in un notebook mette in coda i processi Spark in quella sessione. Quando interrompi una cella in esecuzione, il processo Spark continua a essere eseguito. Per interrompere il processo Spark, è necessario utilizzare l'interfaccia utente Spark sul cluster. Per istruzioni sulla modalità di connessione all'interfaccia utente di Spark, consulta Debug di applicazioni e processi con EMR Studio.

Limitazioni delle caratteristiche

Amazon EMR Studio non supporta le seguenti caratteristiche di Amazon EMR:

  • Collegamento ed esecuzione di processi su cluster EMR con una configurazione di sicurezza che specifica l'autenticazione Kerberos

  • Cluster con più nodi primari

  • Cluster che utilizzano istanze Amazon EC2 basate su AWS Graviton2 per versioni di Amazon EMR 6.x precedenti alla 6.9.0 e versioni 5.x precedenti alla 5.36.1

Limiti del servizio per EMR Studio

La tabella seguente mostra i limiti del servizio per EMR Studio.

Elemento Limite
EMR Studio Un massimo di 100 per ciascun account AWS
Sottoreti Un massimo di 5 associate a ciascun EMR Studio
Gruppi IAM Identity Center Un massimo di 5 assegnati a ciascun EMR Studio
Utenti IAM Identity Center Un massimo di 100 assegnati a ciascun EMR Studio

Best practice per VPC e sottoreti

Utilizzare le seguenti best practice per configurare un Amazon Virtual Private Cloud (Amazon VPC) con sottoreti per EMR Studio:

  • È possibile specificare un massimo di cinque sottoreti in un VPC da associare allo Studio. Si consiglia di fornire più sottoreti in diverse zone di disponibilità per supportare la disponibilità di Workspace e consentire agli utenti di Studio l'accesso ai cluster in diverse zone di disponibilità. Per ulteriori informazioni sul funzionamento di VPC, sottoreti e zone di disponibilità, consulta VPC e sottoreti nella Amazon Virtual Private CloudGuida per l'utente.

  • Le sottoreti specificate dovrebbero essere in grado di comunicare tra loro.

  • Per consentire agli utenti di collegare un Workspace a repository Git ospitati pubblicamente, è necessario specificare solo sottoreti private che hanno accesso a Internet tramite Network Address Translation (NAT). Per ulteriori informazioni sulla configurazione di una sottorete privata per Amazon EMR, consulta Sottoreti private.

  • Quando si utilizza Amazon EMR su EKS con EMR Studio, deve esserci almeno una sottorete in comune tra Studio e il cluster Amazon EKS utilizzato per registrare il cluster virtuale. In caso contrario, l'endpoint gestito non verrà visualizzato come opzione nei Workspace Studio. Puoi creare un cluster Amazon EKS e associarlo a una sotterete appartenente allo Studio o creare uno Studio e specificare le sottoreti del tuo cluster EKS.

  • Se intendi utilizzare Amazon EMR su EKS con EMR Studio, scegli lo stesso VPC dei nodi worker del cluster Amazon EKS.

Requisiti del cluster per Amazon EMR Studio

Cluster Amazon EMR in esecuzione su Amazon EC2

Tutti i cluster Amazon EMR in esecuzione su Amazon EC2 creati per un Workspace EMR Studio devono soddisfare i seguenti requisiti. I cluster creati utilizzando l'interfaccia di EMR Studio soddisfano in automatico questi requisiti.

  • Il cluster deve utilizzare Amazon EMR versione 5.32.0 (Amazon EMR serie 5.x) o 6.2.0 (Amazon EMR serie 6.x) o versioni successive. Puoi creare un cluster utilizzando la console Amazon EMR, la AWS Command Line Interface o l'SDK, per poi collegarlo a un Workspace EMR Studio. Gli utenti dello Studio possono anche creare e allegare un cluster durante la creazione o l'utilizzo di un Workspace Amazon EMR. Per ulteriori informazioni, consulta Collegamento di un calcolo a un WorkSpace EMR Studio.

  • Il cluster deve essere all'interno di Amazon Virtual Private Cloud. La piattaforma EC2-Classic non è supportata.

  • Sul cluster devono essere installati Spark, Livy e Jupyter Enterprise Gateway. Se prevedi di utilizzare il cluster per SQL Explorer, devi installare sia Presto che Spark.

  • Per utilizzare SQL Explorer, il cluster deve utilizzare Amazon EMR versione 5.34.0 o successive oppure versione 6.4.0 e disporre di Presto installato. Se desideri specificare AWS Glue Data Catalog come metastore Hive per Presto, devi configurarlo sul cluster. Per ulteriori informazioni, consulta Utilizzo di Presto con AWS Glue Data Catalog.

  • Il cluster deve trovarsi in una sottorete privata con Network Address Translation (NAT) per utilizzare repository Git in hosting pubblico con EMR Studio.

Quando si lavora con EMR Studio, si consigliano le seguenti configurazioni del cluster.

  • Imposta la modalità di implementazione per le sessioni Spark nella modalità cluster. La modalità cluster posiziona i processi principali dell'applicazione sui nodi principali e non sul nodo primario di un cluster. Così facendo, si alleggerisce il nodo primario delle potenziali pressioni in termini di memoria. Per ulteriori informazioni, consulta Panoramica della modalità cluster nella documentazione di Apache Spark.

  • Modificare il timeout Livy dall'impostazione predefinita di un'ora a sei ore come nella seguente configurazione di esempio.

    {
    "classification":"livy-conf",
        "Properties":{
            "livy.server.session.timeout":"6h",
            "livy.spark.deploy-mode":"cluster"
        }
}

  • Creare flotte di istanze diverse con un massimo di 30 istanze e selezionare più tipi di istanza nel parco istanze Spot. Ad esempio, è possibile specificare i seguenti tipi di istanza ottimizzati per la memoria per i carichi di lavoro Spark: r5.2x, r5.4x, r5.8x, r5.12x, r5.16x, r4.2x, r4.4x, r4.8x, r4.12, ecc. Per ulteriori informazioni, consulta Configurazione di parchi istanze.

  • Utilizzare la strategia di allocazione ottimizzata per la capacità per le istanze Spot per aiutare Amazon EMR a effettuare selezioni efficaci delle istanze basate su informazioni dettagliate sulla capacità in tempo reale di Amazon EC2. Per ulteriori informazioni, consulta Strategia di allocazione per parchi istanze.

  • Abilita il dimensionamento gestito sul cluster. Impostare il parametro dei nodi principali massimi sulla capacità minima persistente che si prevede di utilizzare e configurare la scalabilità su un parco istanze di processi ben diversificato in esecuzione su istanze Spot per risparmiare sui costi. Per ulteriori informazioni, consulta Utilizzo del dimensionamento gestito in Amazon EMR.

Ti invitiamo a mantenere abilitato Amazon EMR Block Public Access e questo per limitare il traffico SSH in entrata a fonti attendibili. L'accesso in ingresso a un cluster consente agli utenti di eseguire notebook sul cluster. Per ulteriori informazioni, consulta Utilizzo del blocco dell'accesso pubblico di Amazon EMR e Controllo del traffico di rete con gruppi di sicurezza.

Cluster Amazon EMR su EKS

Oltre ai cluster EMR in esecuzione su Amazon EC2, puoi configurare e gestire cluster Amazon EMR su EKS per EMR Studio utilizzando la AWS CLI. Imposta Amazon EMR sui cluster EKS utilizzando le seguenti linee guida:

  • Crea un endpoint HTTPS gestito per Amazon EMR su cluster EKS. Gli utenti collegano un Workspace a un endpoint gestito. Il cluster Amazon Elastic Kubernetes Service (EKS) utilizzato per registrare il cluster virtuale deve disporre di una sottorete privata per supportare gli endpoint gestiti.

  • Utilizza un cluster Amazon EKS con almeno una sottorete privata e una Network Address Translation (NAT) quando desideri utilizzare i repository Git in hosting pubblico.

  • Evita l'uso di AMI Arm Amazon Linux ottimizzate per Amazon EKS non supportate per gli endpoint gestiti di Amazon EMR su EKS.

  • Evita l'uso di cluster Amazon EKS solo per AWS Fargate, che non sono supportati.