Rilascio 6.1.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

Applicazioni supportate

• AWS SDK per Java versione 1.11.828

• Flink versione 1.11.0

• Ganglia versione 3.7.2

• Hadoop versione 3.2.1-amzn-1

• HBase versione 2.2.5

• HBase-operator-tools 1.0.0

• HCatalog versione 3.1.2-amzn-0

• Hive versione 3.1.2-amzn-1

• Hudi versione 0.5.2 in fase di sviluppo

• Hue versione 4.7.1

• JupyterHub versione 1.1.0

• Livy versione 0.7.0

• MXNet versione 1.6.0

• Oozie versione 5.2.0

• Phoenix versione 5.0.0

• Presto versione 0.232

• PrestoSQL versione 338

• Spark versione 3.0.0-amzn-0

• TensorFlow versione 2.1.0

• Zeppelin versione 0.9.0-preview1

• Zookeeper versione 3.4.14

• Connettori e driver: DynamoDB Connector 4.14.0

Nuove funzionalità

• I tipi di istanze ARM sono supportati a partire da Amazon EMR versione 5.30.0 e Amazon EMR versione 6.1.0.

• I tipi di istanze per uso generico M6g sono supportati a partire dalle versioni di Amazon EMR 6.1.0 e 5.30.0. Per ulteriori informazioni, consulta Tipi di istanza supportati nella Guida alla gestione di Amazon EMR.

• La caratteristica del gruppo di collocamento EC2 è supportata a partire da Amazon EMR versione 5.23.0 come opzione per i cluster con più nodi primari. Attualmente, solo i tipi di nodi primari sono supportati dalla caratteristica del gruppo di collocamento e la strategia SPREAD viene applicata a tali nodi primari. La strategia SPREAD colloca un piccolo gruppo di istanze su hardware sottostante separato per evitare la perdita di più nodi primari in caso di guasto hardware. Per ulteriori informazioni, consulta Integrazione di EMR con il gruppo di collocamento EC2 nella Guida alla gestione di Amazon EMR.

• Scalabilità gestita: con la versione 6.1.0 di Amazon EMR, puoi abilitare Scalabilità gestita di Amazon 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à. Il dimensionamento gestito è disponibile anche su Amazon EMR versione 5.30.0 e successive, tranne 6.0.0. Per maggiori informazioni, consulta Dimensionamento delle risorse del cluster nella Guida alla gestione di Amazon EMR.

• PrestoSQL versione 338 è supportata con EMR 6.1.0. Per ulteriori informazioni, consulta Presto.

  • PrestoSQL è supportata solo su EMR 6.1.0 e versioni successive, non su EMR 6.0.0 o EMR 5.x.

  • Il nome dell'applicazione Presto continua ad essere utilizzato per installare PrestoDB sui cluster. Per installare PrestoSQL sui cluster, utilizza il nome dell'applicazione PrestoSQL.

  • È possibile installare PrestoDB o PrestoSQL, ma non è possibile installare entrambi in un singolo cluster. Se durante il tentativo di creare un cluster vengono specificati sia PrestoDB che PrestoSQL, si verifica un errore di convalida e la richiesta di creazione del cluster ha esito negativo.

  • PrestoSQL è supportato su entrambi i cluster single-master e muti-master. Nei cluster multi-master, è necessario un metastore Hive esterno per eseguire PrestoSQL o PrestoDB. Consulta la sezione Applicazioni supportate in un cluster EMR con più nodi primari.

• Supporto per l'autenticazione automatica ECR su Apache Hadoop e Apache Spark con Docker: gli utenti di Docker possono utilizzare le immagini Docker da Docker Hub e Amazon Elastic Container Registry (Amazon ECR) per definire le dipendenze dell'ambiente e della libreria.

  Consulta Configurazione di Docker ed Esecuzione di applicazioni Spark con Docker utilizzando Amazon EMR 6.x.

• EMR supporta le transazioni Apache Hive ACID: Amazon EMR 6.1.0 aggiunge il supporto per le transazioni Hive ACID in modo che sia conforme alle proprietà ACID di un database. Con questa funzione, puoi eseguire operazioni INSERT, UPDATE, DELETE, e MERGE nelle tabelle gestite da Hive con dati in Amazon Simple Storage Service (Amazon S3). Questa è una caratteristica chiave per casi d'uso come l'importazione dati in streaming, il riavvio dei dati, gli aggiornamenti in blocco tramite MERGE e la graduale variazione delle dimensioni. Per ulteriori informazioni, inclusi esempi di configurazione e casi d'uso, consulta Amazon EMR supporta le transazioni Apache Hive ACID.

Modifiche, miglioramenti e problemi risolti

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

• È stato risolto il problema per cui le richieste di dimensionamento avevano esito negativo per i cluster di grandi dimensioni e ad alto utilizzo quando i daemon su cluster di Amazon EMR eseguivano attività di controllo dell'integrità, come la raccolta dello stato del nodo YARN e dello stato del nodo HDFS. Ciò si verificava perché i daemon su cluster non erano in grado di comunicare i dati sullo stato di integrità di un nodo ai componenti interni di Amazon EMR.

• I daemon su cluster di EMR sono stati migliorati per monitorare correttamente gli stati dei nodi quando gli indirizzi IP vengono riutilizzati per migliorare l'affidabilità durante le operazioni di dimensionamento.

• SPARK-29683. È stato risolto un problema a causa del quale si verificavano errori di lavoro durante la riduzione del cluster, poiché Spark riteneva che tutti i nodi disponibili fossero stati negati.

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

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

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

• Le versioni più recenti di Amazon EMR risolvono il problema con un limite "Max open files" (Max. file aperti) sulla versione di AL2 meno recente di Amazon EMR. 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).

• Apache Flink non è supportata su EMR 6.0.0, ma è supportata su EMR 6.1.0 con Flink 1.11.0. Si tratta della prima versione di Flink a supportare ufficialmente Hadoop 3. Consulta Annuncio del rilascio di Apache Flink 1.11.0.

• Ganglia è stato rimosso dai pacchetti EMR 6.1.0 di default.

Problemi noti

• Riduci il limite "Max open files" (Max. file aperti) sulla versione di AL2 meno recente [corretto nelle versioni più recenti]. Rilasci 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 sulle versioni precedenti di Amazon Linux 2 (AL2), le quali hanno un'impostazione ulimit inferiore per "Max open files (Max. file aperti)" quando i cluster Amazon EMR vengono creati con l'AMI predefinita. 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

• 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, upsert ed eliminazione di Hudi. Se prevedi di utilizzare Hudi con Amazon EMR 6.1.0 o 6.2.0, AWS contatta l'assistenza per ottenere un Hudi RPM con patch.

• Se si imposta una configurazione personalizzata della raccolta dei rifiuti con spark.driver.extraJavaOptions espark.executor.extraJavaOptions, ciò comporterà un errore di driver/executor avvio con EMR 6.1 a causa di una configurazione della raccolta dei rifiuti in conflitto. Con il rilascio EMR 6.1.0, è invece necessario specificare la configurazione di garbage collection Spark personalizzata per driver ed executor con le proprietà spark.driver.defaultJavaOptions e spark.executor.defaultJavaOptions. Per maggiori informazioni, consulta Ambiente di runtime Apache Spark e Configurazione di garbage collection Spark su Amazon EMR 6.1.0.

• L'utilizzo di Pig con Oozie (e all'interno di Hue, dal momento che Hue utilizza le operazioni Oozie per eseguire gli script Pig) genera un errore che impedisce il caricamento di una libreria native-lzo. Questo messaggio di errore è informativo e non impedisce l'esecuzione di Pig.

• Supporto della simultaneità di Hudi: attualmente, le scritture simultanee in una singola tabella Hudi non sono supportate. Inoltre, Hudi esegue il rollback di tutte le modifiche apportate dalle istanze di scrittura in corso prima di consentire l'avvio di una nuova istanza di scrittura. Le scritture simultanee possono interferire con questo meccanismo e introdurre condizioni di competizione, le quali possono causare il danneggiamento dei dati. È necessario assicurarsi che, come parte del flusso di lavoro di elaborazione dei dati, ci sia sempre una sola istanza di scrittura Hudi che opera su una tabella Hudi. Hudi supporta più istanze di lettura simultanee che operano sulla stessa tabella Hudi.

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

• Si è verificato un problema in Amazon EMR 6.1.0 che interessa i cluster che eseguono Presto. Dopo un periodo di tempo prolungato (giorni), il cluster può generare errori come «su: failed to execute/bin/bash: Resource temporaneamente non disponibile» o «richiesta shell fallita sul canale 0". Questo problema è causato da un processo interno di Amazon EMR (InstanceController) che genera troppi processi leggeri (LWP), che alla fine fa sì che l'utente Hadoop superi il limite nproc. Ciò impedisce all'utente di aprire ulteriori processi. La soluzione a questo problema consiste nell'eseguire l'aggiornamento a EMR 6.2.0.