Rilascio 5.30.1 di Amazon EMR

• Versioni dell'applicazione nei rilasci di Amazon EMR 7.x

• Versioni dell'applicazione nei rilasci di Amazon EMR 6.x

• Versioni dell'applicazione nei rilasci di Amazon EMR 5.x

• Versioni dell'applicazione nei rilasci di Amazon EMR 4.x

Modifiche, miglioramenti e problemi risolti

• Le versioni più recenti di Amazon EMR risolvono il problema con un limite «Numero massimo di file aperti» inferiore rispetto alle versioni precedenti di Amazon EMR. AL2 Le versioni di Amazon EMR 5.30.1, 5.30.2, 5.31.1, 5.32.1, 6.0.1, 6.1.1, 6.2.1, 5.33.0, 6.3.0 e successive includono ora una correzione permanente con un'impostazione "Max open files" (Max. file aperti).

• Risolto il problema per cui il processo del controller di istanza generava un numero infinito di processi.

• Risolto un problema per cui Hue non era in grado di eseguire una query Hive, mostrando il messaggio "database is locked (database bloccato)" e impedendo l'esecuzione di query.

• Risolto un problema Spark per consentire l'esecuzione simultanea di più attività nel cluster EMR.

• Risolto un problema del notebook Jupyter che causava l'errore "too many open files (troppi file aperti)" nel server Jupyter.

• Corretto un problema relativo all'ora di inizio del cluster.

Nuove funzionalità

• Le interfacce utente delle applicazioni persistenti Timeline Server di YARN e Tez sono disponibili con Amazon EMR versioni 6.x ed EMR versione 5.30.1 e successive. L'accesso ai collegamenti One-Click alla cronologia dell'applicazione persistente consente di accedere rapidamente alla cronologia dei processi senza configurare un proxy Web tramite una connessione SSH. I log dei cluster attivi e terminati sono disponibili per 30 giorni dopo la fine dell'applicazione. Per ulteriori informazioni, consulta Visualizzazione delle interfacce utente delle applicazioni persistenti nella Guida alla gestione di Amazon EMR.

• EMR Notebook Execution APIs è disponibile per eseguire notebook EMR tramite uno script o una riga di comando. La possibilità di avviare, interrompere, elencare e descrivere le esecuzioni dei notebook EMR senza la AWS console consente di controllare a livello di programmazione un notebook EMR. Utilizzando una cella del notebook parametrizzata, è possibile passare diversi valori di parametro a un notebook senza doverne creare una copia per ogni nuovo set di valori dei parametri. Consulta Operazioni dell'API EMR. Per un codice di esempio, consulta Comandi di esempio per eseguire EMR Notebooks a livello di codice.

Problemi noti

• Limite «Numero massimo di file aperti» inferiore rispetto alle versioni precedenti AL2 [corretto nelle versioni più recenti]. Versioni di Amazon EMR: emr-5.30.x, emr-5.31.0, emr-5.32.0, emr-6.0.0, emr-6.1.0 ed emr-6.2.0 si basano su versioni precedenti di Amazon Linux 2 (), che hanno un'impostazione ulimit inferiore per «Max open files» quando i cluster Amazon EMR vengono creati con l'AMI predefinita. AL2 Le versioni di Amazon EMR 5.30.1, 5.30.2, 5.31.1, 5.32.1, 6.0.1, 6.1.1, 6.2.1, 5.33.0, 6.3.0 e successive includono una correzione permanente con un'impostazione "Max open files" (Max. file aperti). Le versioni con il limite minimo del file aperto causano l'errore "Too many open files" (Troppi file aperti) durante l'invio del processo Spark. Nelle versioni interessate, l'AMI predefinita di Amazon EMR ha un'impostazione ulimit di default di 4096 per "Max open files" (Max. file aperti), che è inferiore al limite di file 65536 nell'ultima AMI di Amazon Linux 2. L'impostazione ulimit inferiore per "Max open files (Max. file aperti)" causa il fallimento del processo Spark quando il driver e l'executor Spark tentano di aprire più di 4096 file. Per risolvere il problema, Amazon EMR dispone di uno script dell'operazione bootstrap (BA) che regola l'impostazione ulimit durante la creazione del cluster.

  Se utilizzi una versione di Amazon EMR meno recente che non ha la soluzione permanente per questo problema, la seguente soluzione alternativa consente di impostare esplicitamente l'ulimit del controller dell'istanza su un massimo di 65536 file.

  Impostazione di un ulimit esplicito dalla riga di comando

  1. Modifica /etc/systemd/system/instance-controller.service per aggiungere i seguenti parametri alla sezione Servizio.

     LimitNOFILE=65536

     LimitNPROC=65536

  2. Riavvia InstanceController

     $ sudo systemctl daemon-reload

     $ sudo systemctl restart instance-controller

  Impostazione di un ulimit usando l'operazione di bootstrap (BA)

  È inoltre possibile utilizzare uno script dell'operazione di bootstrap (BA) per configurare l'ulimit del controller di istanza a 65536 file durante la creazione del cluster.

  #!/bin/bash
  for user in hadoop spark hive; do
  sudo tee /etc/security/limits.d/$user.conf << EOF
  $user - nofile 65536
  $user - nproc 65536
  EOF
  done
  for proc in instancecontroller logpusher; do
  sudo mkdir -p /etc/systemd/system/$proc.service.d/
  sudo tee /etc/systemd/system/$proc.service.d/override.conf << EOF
  [Service]
  LimitNOFILE=65536
  LimitNPROC=65536
  EOF
  pid=$(pgrep -f aws157.$proc.Main)
  sudo prlimit --pid $pid --nofile=65535:65535 --nproc=65535:65535
  done
  sudo systemctl daemon-reload

• EMR Notebooks

  La caratteristica che consente di installare kernel e librerie Python aggiuntive sul nodo primario del cluster è disabilitata per impostazione predefinita in EMR versione 5.30.1. Per ulteriori informazioni su questa caratteristica, consulta la sezione Installing Kernels and Python Libraries on a Cluster Primary Node (Installazione di kernel e librerie Python su un nodo primario del cluster).

  Per abilitare questa funzione, procedi come segue:

  1. Assicurati che le policy di autorizzazione associate al ruolo di servizio per EMR Notebooks consentano l'operazione seguente:

     elasticmapreduce:ListSteps

     Per ulteriori informazioni, consultare il Ruolo del servizio per EMR Notebooks.

  2. Utilizzare AWS CLI per eseguire un passaggio sul cluster che configura EMR Notebooks, come illustrato nell'esempio seguente. Sostituisci us-east-1 con la regione in cui risiede il cluster. Per ulteriori informazioni, consulta Aggiunta di fasi a un cluster utilizzando la AWS CLI.

     aws emr add-steps  --cluster-id MyClusterID --steps Type=CUSTOM_JAR,Name=EMRNotebooksSetup,ActionOnFailure=CONTINUE,Jar=s3://us-east-1.elasticmapreduce/libs/script-runner/script-runner.jar,Args=["s3://awssupportdatasvcs.com/bootstrap-actions/EMRNotebooksSetup/emr-notebooks-setup.sh"]
                             

• Dimensionamento gestito

  Le operazioni di dimensionamento gestito su cluster 5.30.0 e 5.30.1 senza Presto installato possono causare errori delle applicazioni o far sì che un gruppo di istanze o un parco istanze uniforme mantenga lo stato ARRESTED, in particolare quando un'operazione di riduzione è seguita rapidamente da un'operazione di aumento.

  Come soluzione alternativa, scegli Presto come applicazione da installare quando crei un cluster con Amazon EMR rilasci 5.30.0 e 5.30.1, anche se il tuo processo non richiede Presto.

• Problema noto nei cluster con più nodi primari e autenticazione Kerberos

  Se esegui cluster con più nodi primari e autenticazione Kerberos nella versione 5.20.0 di Amazon EMR e successivi, è possibile che si verifichino problemi con le operazioni del cluster, quali la riduzione o l'invio di fasi, dopo che il cluster è rimasto in esecuzione per un certo periodo di tempo. Il periodo di tempo dipende dal periodo di validità del ticket Kerberos definito dall'utente. Il problema di dimensionamento verso il basso influisce sia sulle richieste di scalabilità automatica che sulle richieste esplicite di dimensionamento verso il basso inviate dall'utente. Possono essere influenzate anche le operazioni cluster aggiuntive.

  Soluzione alternativa:

  • Abilita SSH come utente hadoop al primo nodo primario del cluster EMR con più nodi primari.

  • Esegui il comando seguente per rinnovare il ticket Kerberos per l'utente hadoop.

    kinit -kt <keytab_file> <principal>

    In genere, il file keytab si trova in /etc/hadoop.keytab e l'entità principale si presenta nella forma di hadoop/<hostname>@<REALM>.

  Nota

  Questa soluzione alternativa sarà valida per il periodo di tempo in cui il ticket Kerberos è valido. La durata è di 10 ore per impostazione predefinita, ma può essere configurata dalle impostazioni Kerberos. È necessario eseguire nuovamente il comando sopra indicato una volta scaduto il ticket Kerberos.

• Se utilizzi Spark con la formattazione della posizione delle partizioni Hive per leggere i dati in Amazon S3 ed esegui Spark nei rilasci di Amazon EMR da 5.30.0 a 5.36.0 e da 6.2.0 a 6.9.0, potresti riscontrare un problema che impedisce al cluster di leggere correttamente i dati. Ciò può accadere se le partizioni presentano tutte le seguenti caratteristiche:

  • Due o più partizioni vengono scansionate dalla stessa tabella.

  • Almeno un percorso di directory di partizione è il prefisso di almeno un altro percorso della directory di partizione, ad esempio s3://bucket/table/p=a è un prefisso di s3://bucket/table/p=a b.

  • Il primo carattere che segue il prefisso nell'altra directory di partizione ha un valore UTF-8 inferiore al carattere / (U+002F). Ad esempio, rientra in questa categoria il carattere dello spazio (U+0020) che compare tra a e b in s3://bucket/table/p=a b. Tieni presente che esistono altri 14 caratteri non di controllo: !"#$%&‘()*+,-. Per ulteriori informazioni, consulta la sezione UTF-8 encoding table and Unicode characters (Tabella di codifica UTF-8 e caratteri Unicode).

  Per ovviare a questo problema, imposta la configurazione di spark.sql.sources.fastS3PartitionDiscovery.enabled su false nella classificazione di spark-defaults.