Considerazioni su EMR Studio - Amazon EMR

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

Considerazioni su EMR Studio

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

  • EMR Studio è disponibile nelle seguenti Regioni AWS: Stati Uniti orientali (Ohio, Virginia settentrionale), 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).

  • EMR Studio è compatibile con le versioni Amazon EMR 5.32.0 (Amazon EMR serie 5.x) o 6.2.0 (Amazon EMR serie 6.x) e successive.

  • Per consentire agli utenti di effettuare il provisioning di nuovi cluster EMR in esecuzione su Amazon EC2 per un'istanza 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 i modelli di cluster o nessuno di essi all'interno di uno Studio.

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

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

  • Utilizzare la AWS CLI per configurare cluster Amazon EMR su EKS. È quindi possibile utilizzare l'interfaccia Studio per collegare cluster a un'istanza 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 tramite %configure

    • Modifica di KERNEL_USERNAME tramite %env o %set_env

  • I cluster Amazon EMR su EKS non supportanoSparkMagiccomandi 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 dei proxy comeFoxyProxyoSwitchyOmeganel 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 l'istanza WorkSpace affinché il riavvio abbia effetto.

  • Se un'istanza 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 dell'istanza WorkSpace appare vuota e non funziona come previsto. Ti consigliamo di utilizzare una versione supportata diversa di Amazon EMR se desideri configurare la crittografia dei dati o l'autorizzazione Amazon S3 per EMRFS per un cluster. EMR Studio è compatibile con le versioni Amazon EMR 5.32.0 (Amazon EMR serie 5.x) o 6.2.0 (Amazon EMR serie 6.x) e 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 Spark History Server dall'elenco Clusters (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 pulisce i kernel inattivi sul nodo primario di un cluster nelle seguenti versioni di Amazon EMR: 5.32.0, 5.33.0, 6.2.0 e 6.3.0. I kernel inattivi consumano risorse di elaborazione e possono far fallire i 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 Esegui 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 politica di terminazione automatica con le versioni di Amazon EMR 5.32.0, 5.33.0, 6.2.0 o 6.3.0, Amazon EMR contrassegna un cluster come inattivo e può chiudere automaticamente il cluster anche se hai 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%%displayper visualizzare una SparkDataFramein una tabella, le tabelle molto ampie possono 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.

  • Avvio di un kernel basato su Spark, ad esempioPySpark, 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 suAWSGraviton2 per Amazon EMR 6.x rilasci precedenti alla 6.9.0 e versioni 5.x inferiori 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 Massimo 100 perAWSconto
Sottoreti Massimo 5 associati ad ogni EMR Studio
Gruppi IAM Identity Center Massimo 5 assegnati ad ogni EMR Studio
Utenti IAM Identity Center Massimo 100 assegnati ad ogni 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 nelle istanze WorkSpace di Studio. Puoi creare un cluster Amazon EKS e associarlo alle sottoreti che appartengono al tuo Studio, o creare uno Studio e specificare le sottoreti del cluster EKS..

  • Se prevedi di utilizzare Amazon Amazon EMR su EKS con EMR Studio, scegli lo stesso VPC dei nodi di lavoro 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 automaticamente questi requisiti.

  • Il cluster deve utilizzare le versioni Amazon EMR 5.32.0 (Amazon EMR serie 5.x) o 6.2.0 (Amazon EMR serie 6.x) o 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 cluster all'istanza WorkSpace.

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

  • Il cluster deve avere Spark, Livy e Jupyter Enterprise Gateway installati. 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 ospitati pubblicamente con EMR Studio.

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

  • Impostare la modalità di implementazione per le sessioni Spark sulla modalità cluster. La modalità cluster posiziona i processi master dell'applicazione sui nodi principali e non sul nodo primario di un cluster. In questo modo si allevia il nodo primario dalle potenziali pressioni sulla memoria. Per ulteriori informazioni, consulta Cluster Mode Overview 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, consultare 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. Configura 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'istanza 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 ospitati pubblicamente.

  • Evitare l'usoAMI Amazon Linux ottimizzate per Amazon EKS, che non sono supportati per Amazon EMR sugli endpoint gestiti da EKS.

  • Evitare di usare i cluster Amazon EKS solo AWS Fargate, che non sono supportati.