Amazon EMR versione 6.0.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.711

• Ganglia versione 3.7.2

• Hadoop versione 3.2.1

• HBaseversione 2.2.3

• HCatalogversione 3.1.2

• Hive versione 3.1.2

• Hudi versione 0.5.0 in fase di sviluppo

• Hue versione 4.4.0

• JupyterHub versione 1.0.0

• Livy versione 0.6.0

• MXNetversione 1.5.1

• Oozie versione 5.1.0

• Phoenix versione 5.0.0

• Presto versione 0.230

• Spark versione 2.4.4

• TensorFlow versione 1.14.0

• Zeppelin versione 0.9.0- SNAPSHOT

• Zookeeper versione 3.4.14

• Connettori e driver: DynamoDB Connector 4.14.0

Nuove funzionalità

• YARNDocker Runtime Support: YARN le applicazioni, come i job Spark, possono ora essere eseguite nel contesto di un contenitore Docker. Ciò consente di definire facilmente le dipendenze in un'immagine Docker senza la necessità di installare librerie personalizzate sul cluster AmazonEMR. Per ulteriori informazioni, consulta Configurare l'integrazione con Docker ed eseguire applicazioni Spark con Docker utilizzando Amazon 6.0.0. EMR

• Hive LLAP Support - Hive ora supporta la modalità di LLAP esecuzione per migliorare le prestazioni delle query. Per ulteriori informazioni, vedere Utilizzo di Hive. LLAP

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.

• Amazon Linux

  • Amazon Linux 2 è il sistema operativo per la serie di release EMR 6.x.

  • systemdviene utilizzato per la gestione dei servizi anziché inAmazon Linux 1 upstart utilizzato.

• Kit di sviluppo Java (JDK)

  • Corretto JDK 8 è l'impostazione predefinita JDK per la serie di release EMR 6.x.

• Scala

  • Scala 2.12 è usato con Apache Spark e Apache Livy.

• Python 3

  • Python 3 è ora la versione predefinita di Python in. EMR

• YARNetichette dei nodi

  • A partire dalla serie di release di Amazon EMR 6.x, la funzionalità delle etichette dei YARN nodi è disabilitata per impostazione predefinita. Per impostazione predefinita, i processi master dell'applicazione possono essere eseguiti su entrambi i nodi di task e core. Puoi abilitare la funzionalità delle etichette dei YARN nodi configurando le seguenti proprietà: yarn.node-labels.enabled e. yarn.node-labels.am.default-node-label-expression Per ulteriori informazioni, consulta la sezione Understanding Primary, Core, and Task Nodes (Informazioni sui nodi primari, core e attività).

Problemi noti

• Limite «Numero massimo di file aperti» inferiore 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

• La shell interattiva Spark PySpark, tra cui SparkR e spark-shell, non supporta l'uso di Docker con librerie aggiuntive.

• Per usare Python 3 con la EMR versione Amazon 6.0.0, devi aggiungere a. PATH yarn.nodemanager.env-whitelist

• La funzionalità Live Long and Process (LLAP) non è supportata quando si utilizza AWS Glue Data Catalog come metastore per Hive.

• Quando usi Amazon EMR 6.0.0 con l'integrazione di Spark e Docker, devi configurare le istanze del cluster con lo stesso tipo di istanza e la stessa quantità di EBS volumi per evitare errori durante l'invio di un job Spark con Docker runtime.

• In Amazon EMR 6.0.0, HBase la modalità di storage di Amazon S3 è interessata dal HBASE problema -24286. HBaseil master non può inizializzarsi quando il cluster viene creato utilizzando dati S3 esistenti.

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