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

• Connettore Amazon Glue aggiornato alla versione 1.13.0

• Amazon SageMaker Spark SDK aggiornato alla versione 1.4.0

• Connettore Amazon Kinesis aggiornato alla versione 3.5.9

• Aggiornato alla versione 1.11.852 AWS SDK for Java

• Bigtop-tomcat aggiornato alla versione 8.5.56

• EMR FS aggiornato alla versione 2.43.0

• Client MetricsAndEventsApiGateway EMR aggiornato alla versione 1.4.0

• EMR S3 Dist CP aggiornato alla versione 2.15.0

• EMR S3 Select aggiornato alla versione 1.6.0

• Flink aggiornato alla versione 1.11.0

• Hadoop aggiornato alla versione 2.10.0

• Hive aggiornato alla versione 2.3.7

• Hudi aggiornato alla versione 0.6.0

• Hue aggiornato alla versione 4.7.1

• Aggiornato alla versione 1.1.0 JupyterHub

• MXNet aggiornato alla versione 1.6.0

• OpenCV aggiornato alla versione 4.3.0

• Presto aggiornato alla versione 0.238.3

• Aggiornato alla versione 2.1.0 TensorFlow

Modifiche, miglioramenti e problemi risolti

• Questa versione risolve i problemi di dimensionamento di Amazon EMR nei casi in cui non riesce ad aumentare/ridurre correttamente un cluster o causa errori dell'applicazione.

• È 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 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 il problema per cui si verificavano errori di processo a causa di una race condition nella disattivazione di YARN quando il cluster tentava di aumentare o ridursi.

• È stato risolto il problema relativo agli errori di fase o processo durante il dimensionamento del cluster garantendo che gli stati dei nodi siano sempre coerenti tra i daemon su cluster di Amazon EMR 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 era dovuto al fatto che il daemon su cluster di Amazon EMR non rinnovava il ticket di Kerberos, necessario per comunicare in modo sicuro con HDFS/YARN in esecuzione sul nodo primario.

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

• Le statistiche di colonna Hive sono supportate per Amazon EMR 5.31.0 e versioni successive.

• Versioni dei componenti aggiornate.

• Supporto di EMRFS S3EC V2 in Amazon EMR 5.31.0. In S3 Java SDK 1.11.837 e versioni successive, il client di crittografia versione 2 (S3EC V2) è stato introdotto con vari miglioramenti alla sicurezza. Per ulteriori informazioni, consulta gli argomenti seguenti:

  • Post del blog S3: Updates to the Amazon S3 encryption client (Aggiornamenti al client di crittografia Amazon S3).

  • AWS SDK for Java Guida per gli sviluppatori: migra i client di crittografia e decrittografia alla versione 2.

  • Guida alla gestione di EMR: Crittografia lato client di Amazon S3.

  Il client di crittografia V1 è ancora disponibile nell'SDK per la compatibilità con le versioni precedenti.

Nuove funzionalità

• Riduci il limite «Numero massimo di file aperti» 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

• Con Amazon EMR 5.31.0, puoi avviare un cluster che si integra con Lake Formation. Questa integrazione fornisce un filtraggio granulare dei dati a livello di colonna per database e tabelle nel Glue Data Catalog. AWS Inoltre, consente l'accesso federato single sign-on a EMR Notebooks o Apache Zeppelin da un sistema di identità aziendale. Per ulteriori informazioni, consulta Integrazione di Amazon EMR con AWS Lake Formation nella Guida alla gestione di Amazon EMR.

  Amazon EMR with Lake Formation è attualmente disponibile in 16 AWS regioni: Stati Uniti orientali (Ohio e Virginia settentrionale), Stati Uniti occidentali (California settentrionale e Oregon), Asia Pacifico (Mumbai, Seoul, Singapore, Sydney e Tokyo), Canada (Centrale), Europa (Francoforte, Irlanda, Londra, Parigi e Stoccolma), Sud America (San Paolo).

Problemi noti

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

• Quando AtRestEncryption la crittografia HDFS è abilitata su un cluster che utilizza Amazon EMR 5.31.0 o 5.32.0, le query Hive generano la seguente eccezione di runtime.

  TaskAttempt 3 failed, info=[Error: Error while running task ( failure ) : attempt_1604112648850_0001_1_01_000000_3:java.lang.RuntimeException: java.lang.RuntimeException: Hive Runtime Error while closing operators: java.io.IOException: java.util.ServiceConfigurationError: org.apache.hadoop.security.token.TokenIdentifier: Provider org.apache.hadoop.hbase.security.token.AuthenticationTokenIdentifier not found

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