Amazon EMR versione 6.2.0

• Versioni delle applicazioni nelle versioni 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

Applicazioni supportate

• AWS SDK for Java versione 1.11.828

• emr-record-server versione 1.7.0

• Flink versione 1.11.2

• Ganglia versione 3.7.2

• Hadoop versione 3.2.1-amzn-1

• HBaseversione 2.2.6-amzn-0

• HBase-operator-tools 1.0.0

• HCatalogversione 3.1.2-amzn-0

• Hive versione 3.1.2-amzn-3

• Hudi versione 0.6.0-amzn-1

• Hue versione 4.8.0

• JupyterHub versione 1.1.0

• Livy versione 0.7.0

• MXNetversione 1.7.0

• Oozie versione 5.2.0

• Phoenix versione 5.0.0

• Pig versione 0.17.0

• Presto versione 0.238.3-amzn-1

• Presto versione 3.4.3 SQL

• Spark versione 3.0.1-amzn-0

• spark-rapids 0.2.0

• TensorFlow versione 2.3.1

• Zeppelin versione 0.9.0-preview1

• Zookeeper versione 3.4.14

• Connettori e driver: DynamoDB Connector 4.16.0

Nuove funzionalità

• HBase: è stata rimossa la ridenominazione in fase di commit e aggiunto il tracciamento persistenteHFile. Vedi Persistent HFile Tracking nella Amazon EMR Release Guide.

• HBase: Backported Crea una configurazione che impone la memorizzazione nella cache dei blocchi durante la compattazione.

• PrestoDB: miglioramenti all'eliminazione delle partizioni dinamiche. Join Reorder basato su regole funziona su dati non partizionati.

• Policy gestite con ambito: per allinearsi alle AWS migliori pratiche, Amazon EMR ha introdotto politiche gestite predefinite con EMR ambito v2 in sostituzione delle politiche che verranno obsolete. Vedi Amazon EMR Managed Policies.

• Stato del supporto di Instance Metadata Service (IMDS) V2: per Amazon EMR 6.2 o versioni successive, EMR i componenti Amazon vengono utilizzati IMDSv2 per tutte le chiamate. IMDS Per IMDS le chiamate nel codice dell'applicazione, puoi utilizzare entrambi IMDSv1 e IMDSv2 oppure configurarle in modo che vengano utilizzate solo IMDSv2 per una maggiore sicurezza. IMDS La disattivazione IMDSv1 nelle versioni precedenti di Amazon EMR 6.x causa un errore di avvio del cluster.

Modifiche, miglioramenti e problemi risolti

• Questa è una versione per risolvere i problemi di Amazon EMR Scaling quando non riesce a scalare/ridimensionare correttamente un cluster o causa errori delle applicazioni.

• È stato risolto un problema a causa del quale le richieste di scalabilità non andavano a buon fine per un cluster di grandi dimensioni e altamente utilizzato quando i demoni Amazon EMR on-cluster eseguivano attività di controllo dello stato del nodo, come la raccolta dello stato e dello stato del YARN nodo. HDFS Ciò accadeva perché i demoni on-cluster non erano in grado di comunicare i dati sullo stato di salute di un nodo ai componenti interni di Amazon. EMR

• Demoni EMR sul cluster migliorati per tracciare correttamente gli stati dei nodi quando gli indirizzi IP vengono riutilizzati per migliorare l'affidabilità durante le operazioni di scalabilità.

• SPARK-29683. È stato risolto il problema per cui si verificavano errori di processo durante la riduzione del cluster poiché Spark presupponeva che tutti i nodi disponibili fossero negati.

• YARN-9011. È stato risolto un problema a causa del quale si verificavano errori di lavoro a causa di una situazione di emergenza durante la YARN disattivazione quando il cluster tentava di aumentare o ridurre la scalabilità.

• È stato risolto il problema relativo agli errori di passaggi o processi durante la scalabilità del cluster assicurando che gli stati dei nodi fossero sempre coerenti tra i demoni Amazon EMR on-cluster e/. YARN HDFS

• È stato risolto un problema a causa del quale le operazioni di cluster come la scalabilità verso il basso e l'invio di passaggi non funzionavano per EMR i cluster Amazon abilitati con l'autenticazione Kerberos. Questo perché il EMR daemon Amazon on-cluster non ha rinnovato il ticket Kerberos, necessario per comunicare in modo sicuro conHDFS/in esecuzione sul nodo primario. YARN

• Le EMR versioni più recenti di Amazon risolvono il problema con un limite «Numero massimo di file aperti» inferiore rispetto alle versioni precedenti AL2 di AmazonEMR. EMRLe versioni di Amazon 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 ora includono una correzione permanente con un'impostazione «Max open files» più elevata.

• Spark: miglioramenti delle prestazioni del runtime Spark.

Problemi noti

• Amazon EMR 6.2 ha delle autorizzazioni errate impostate nel file /etc/cron.d/ nella versione libinstance-controller-java 6.2.0. EMR Le autorizzazioni sul file sono 645 (-rw-r--r-x), quando dovrebbero essere 644 (-rw-r--r--). Di conseguenza, la EMR versione 6.2 di Amazon non registra i log dello stato dell'istanza e la directory /emr/instance-logs è vuota. Questo problema è stato risolto in Amazon EMR 6.3.0 e versioni successive.

  Per risolvere il problema, esegui il seguente script come operazione di bootstrap all'avvio del cluster.

  #!/bin/bash
  sudo chmod 644 /etc/cron.d/libinstance-controller-java
              

• Per i cluster di sottoreti privati Amazon EMR 6.2.0 e 6.3.0, non puoi accedere all'interfaccia utente web di Ganglia. Verrà visualizzato l'errore "access denied (403) (accesso negato (403))". Altri siti WebUIs, come Spark, Hue, Zeppelin, Livy e JupyterHub Tez, funzionano normalmente. Anche l'accesso all'interfaccia utente Web di Ganglia sui cluster della sottorete pubblica funziona normalmente. Per risolvere il problema, riavvia il servizio httpd sul nodo primario con sudo systemctl restart httpd. Questo problema è stato risolto in Amazon EMR 6.4.0.

• C'è un problema in Amazon EMR 6.2.0 in cui httpd fallisce continuamente, causando l'indisponibilità di Ganglia. Viene visualizzato un errore "cannot connect to the server (impossibile connettersi al server)". Per correggere un cluster già in esecuzione con questo problema, vai SSH al nodo primario del cluster e aggiungi la riga Listen 80 al file httpd.conf che si trova in. /etc/httpd/conf/httpd.conf Questo problema è stato risolto in Amazon EMR 6.3.0.

• HTTPDfallisce sui cluster EMR 6.2.0 quando si utilizza una configurazione di sicurezza. Ciò rende l'interfaccia utente dell'applicazione Web Ganglia non disponibile. Per accedere all'interfaccia utente dell'applicazione Web Ganglia, aggiungi Listen 80 al file /etc/httpd/conf/httpd.conf sul nodo primario del cluster. Per informazioni sulla connessione al cluster, consulta Connect to the Primary Node Using SSH.

  EMRInoltre, i notebook non riescono a stabilire una connessione con i cluster EMR 6.2.0 quando si utilizza una configurazione di sicurezza. Il notebook non riuscirà a elencare i kernel e a inviare processi Spark. Ti consigliamo invece di utilizzare EMR Notebooks con un'altra versione di Amazon. EMR

• Riduci il limite «Numero massimo di file aperti» rispetto alle versioni precedenti AL2 [corretto nelle versioni più recenti]. EMRLe versioni di Amazon: 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 sulle versioni precedenti di Linux ofAmazon 2 ()AL2, che hanno un'impostazione ulimit inferiore per «Max open files» quando i cluster Amazon vengono creati con l'impostazione predefinita. EMR AMI EMRLe versioni di Amazon 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» superiore. 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'EMRimpostazione predefinita di Amazon AMI ha un'impostazione ulimit predefinita di 4096 per «Max open files», che è inferiore al limite di 65536 file in Linux 2. latestAmazon AMI 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 bootstrap action (BA) che regola l'impostazione ulimit alla creazione del cluster.

  Se utilizzi una EMR versione precedente di Amazon che non include la correzione permanente per questo problema, la seguente soluzione alternativa ti consente di impostare in modo esplicito il limite del controller di 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

• Importante

  Amazon EMR 6.1.0 e 6.2.0 includono un problema di prestazioni che può influire in modo critico su tutte le operazioni di inserimento, annullamento ed eliminazione di Hudi. Se prevedi di utilizzare Hudi con Amazon EMR 6.1.0 o 6.2.0, contatta l' AWS assistenza per ottenere un Hudi con patch. RPM

• Importante

  EMRi cluster che eseguono Amazon Linux o Amazon Linux 2 Amazon Machine Images (AMIs) utilizzano il comportamento predefinito di Amazon Linux e non scaricano e installano automaticamente aggiornamenti del kernel importanti e critici che richiedono un riavvio. Questo è lo stesso comportamento delle altre EC2 istanze Amazon che eseguono Amazon Linux AMI predefinito. Se nuovi aggiornamenti software di Amazon Linux che richiedono un riavvio (ad esempio kernel e CUDA aggiornamenti) diventano disponibili dopo la disponibilità di una EMR versione di Amazon, le istanze EMR cluster che eseguono l'impostazione predefinita AMI non scaricano e installano automaticamente tali aggiornamenti. NVIDIA Per ottenere gli aggiornamenti del kernel, puoi personalizzare Amazon EMR AMI per utilizzare la versione più recente di Amazon Linux AMI.

• Gli artefatti di Amazon EMR 6.2.0 Maven non vengono pubblicati. Verranno pubblicati con una versione futura di AmazonEMR.

• Il HFile tracciamento persistente mediante la tabella del HBase file system storefile non supporta la funzionalità di replica delle HBase regioni. Per ulteriori informazioni sulla replica delle aree, consulta HBase Timeline-Consistent High Available Reads.

• Differenze tra le versioni bucketing di Amazon EMR EMR 6.x e 5.x Hive

  EMR5.x utilizza OOS Apache Hive 2, mentre nella versione 6.x utilizza Apache Hive 3. EMR OOS L'Hive2 open source utilizza bucket di versione 1, mentre l'Hive3 open source utilizza bucket di versione 2. Questa differenza di versione di bucketing tra Hive 2 (EMR5.x) e Hive 3 (6.x) significa che l'hashing di Hive bucketing funziona in modo diverso. EMR Vedere l'esempio sottostante.

  La tabella seguente è un esempio creato rispettivamente in 6.x e 5.x. EMR EMR

  -- Using following LOCATION in EMR 6.x
  CREATE TABLE test_bucketing (id INT, desc STRING)
  PARTITIONED BY (day STRING)
  CLUSTERED BY(id) INTO 128 BUCKETS
  LOCATION 's3://your-own-s3-bucket/emr-6-bucketing/';
  
  -- Using following LOCATION in EMR 5.x 
  LOCATION 's3://your-own-s3-bucket/emr-5-bucketing/';

  Inserimento degli stessi dati sia in EMR 6.x che in 5.x. EMR

  INSERT INTO test_bucketing PARTITION (day='01') VALUES(66, 'some_data');
  INSERT INTO test_bucketing PARTITION (day='01') VALUES(200, 'some_data');

  Il controllo della posizione di S3 mostra che il nome del file del bucketing è diverso, perché la funzione di hashing è diversa tra EMR 6.x (Hive 3) e 5.x (Hive 2). EMR

  [hadoop@ip-10-0-0-122 ~]$ aws s3 ls s3://your-own-s3-bucket/emr-6-bucketing/day=01/
  2020-10-21 20:35:16         13 000025_0
  2020-10-21 20:35:22         14 000121_0
  [hadoop@ip-10-0-0-122 ~]$ aws s3 ls s3://your-own-s3-bucket/emr-5-bucketing/day=01/
  2020-10-21 20:32:07         13 000066_0
  2020-10-21 20:32:51         14 000072_0
  

  Puoi anche vedere la differenza di versione eseguendo il seguente comando in Hive nella versione 6.x. CLI EMR Potrai notare che la CLI restituisce bucket di versione 2.

  hive> DESCRIBE FORMATTED test_bucketing;
  ...
  Table Parameters:
      bucketing_version       2
  ...

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

  Se esegui cluster con più nodi primari e l'autenticazione Kerberos nelle EMR versioni di Amazon 5.20.0 e successive, potresti riscontrare problemi con le operazioni del cluster come la scalabilità verso il basso o l'invio di passaggi, dopo che il cluster è stato in esecuzione per qualche 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:

  • SSHcome hadoop utente del nodo primario principale del cluster con più nodi primari. EMR

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

• Quando usi Spark con la formattazione della posizione delle partizioni Hive per leggere i dati in Amazon S3 e esegui Spark sulle EMR versioni di Amazon 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 -8 inferiore al carattere (U+002F). UTF / 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, vedete la tabella di codifica UTF-8 e i caratteri Unicode.

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