Rilascio 5.30.0 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

Aggiornamenti

• Aggiornato alla versione 1.11.759 AWS SDK for Java

• Amazon SageMaker Spark SDK aggiornato alla versione 1.3.0

• Aggiornato EMR Record Server alla versione 1.6.0

• Flink aggiornato alla versione 1.10.0

• Aggiornato Ganglia alla versione 3.7.2

• Aggiornato alla versione 1.4.13 HBase

• Aggiornato Hudi alla versione 0.5.2-incubating

• Hue aggiornato alla versione 4.6.0

• Aggiornato alla versione 1.1.0 JupyterHub

• Livy aggiornato alla versione 0.7.0-incubating

• Aggiornato Oozie alla versione 5.2.0

• Presto aggiornato alla versione 0.232

• Aggiornato Spark alla versione 2.4.5

• Connettori e driver aggiornati: connettore Amazon Glue 1.12.0; connettore Amazon Kinesis 3.5.0; connettore EMR DynamoDB 4.14.0

Nuove funzionalità

• EMR Notebooks: se utilizzato con cluster EMR creati con 5.30.0, i kernel di EMR Notebooks vengono eseguiti sul cluster. Ciò migliora le prestazioni dei notebook e consente di installare e personalizzare i kernel. Puoi anche installare librerie Python sul nodo primario del cluster. Per ulteriori informazioni, consulta l'argomento relativo all'installazione e l'utilizzo di kernel e librerie nella Guida alla gestione di EMR.

• Dimensionamento gestito: con la versione 5.30.0 e successive di Amazon EMR, puoi abilitare il dimensionamento gestito da EMR per aumentare o diminuire automaticamente il numero di istanze o unità nel cluster in base al carico di lavoro. Amazon EMR valuta continuamente i parametri dei cluster per prendere decisioni di dimensionamento che ottimizzano i cluster in termini di costi e velocità. Per maggiori informazioni, consulta Dimensionamento delle risorse del cluster nella Guida alla gestione di Amazon EMR.

• Crittografa i file di log archiviati in Amazon S3: con Amazon EMR versione 5.30.0 e successive, puoi crittografare i file di log archiviati in Amazon S3 con una chiave gestita dal cliente. AWS KMS Per ulteriori informazioni, consulta Crittografia dei file di log archiviati in Amazon S3 nella Guida alla gestione di Amazon EMR.

• Supporto di Amazon Linux 2: nella versione EMR 5.30.0 e successive, EMR utilizza il sistema operativo Amazon Linux 2. La nuova versione personalizzata AMIs (Amazon Machine Image) deve essere basata sull'AMI Amazon Linux 2. Per ulteriori informazioni, consulta Utilizzo di un AMI personalizzato.

• Scalabilità automatica Presto con tolleranza: i cluster EMR che usano 5.30.0 possono essere impostati con un periodo di timeout di scalabilità automatica che consente alle attività Presto di terminare l'esecuzione prima che il loro nodo venga disattivato. Per ulteriori informazioni, consulta Utilizzo della scalabilità automatica Presto con disattivazione con tolleranza.

• Creazione di parchi istanze con nuova opzione di strategia di allocazione: una nuova opzione di strategia di allocazione è disponibile in EMR versione 5.12.1 e successive. Offre un provisioning dei cluster più rapido, un'allocazione di istanze Spot più accurata e una minore interruzione delle istanze Spot. Sono necessari aggiornamenti ai ruoli di servizio EMR non predefiniti. Consulta Configurazione di parchi istanze.

• Comandi sudo systemctl stop e sudo systemctl start: nella versione EMR 5.30.0 e successive, le quali usano il sistema operativo Amazon Linux 2 OS, EMR utilizza i comandi sudo systemctl stop e sudo systemctl start per riavviare i servizi. Per ulteriori informazioni, consulta Come riavviare un servizio in Amazon EMR?.

Modifiche, miglioramenti e problemi risolti

• EMR versione 5.30.0 non installa Ganglia per impostazione predefinita. È possibile selezionare esplicitamente Ganglia da installare quando si crea un cluster.

• Ottimizzazione delle prestazioni di Spark.

• Ottimizzazione delle prestazioni di Presto.

• Python 3 è l'impostazione predefinita per Amazon EMR 5.30.0 e versioni successive.

• Il gruppo di sicurezza gestito predefinito per l'accesso al servizio nelle sottoreti private è stato aggiornato con nuove regole. Se si utilizza un gruppo di sicurezza personalizzato per l'accesso al servizio, è necessario includere le stesse regole del gruppo di sicurezza gestito predefinito. Per ulteriori informazioni, consulta Gruppo di sicurezza gestito da Amazon EMR per l'accesso al servizio (sottoreti private). Se si utilizza un ruolo di servizio personalizzato per Amazon EMR, è necessario concedere l'autorizzazione a ec2:describeSecurityGroups per consentire a EMR di convalidare se i gruppi di sicurezza sono stati creati correttamente. Se si utilizza EMR_DefaultRole, questa autorizzazione è già inclusa nella policy gestita di default.

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

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

• Il motore di database predefinito per Hue 4.6.0 è SQLite, che causa problemi quando si tenta di utilizzare Hue con un database esterno. Per risolvere questo problema, imposta engine nella tua classificazione di configurazione hue-ini su mysql. Questo problema è stato risolto nella versione 5.30.1 di Amazon EMR.

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