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

• HBase versione 2.2.6-amzn-0

• HBase-operator-tools 1.0.0

• HCatalog versione 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

• MXNet versione 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

• PrestoSQL versione 343

• 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 persistente HFile . Consulta 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 best practice, Amazon EMR ha introdotto policy gestite predefinite con ambito EMR v2 in sostituzione delle politiche che verranno obsolete. Consulta Policy gestite di Amazon EMR.

• Stato del supporto di Instance Metadata Service (IMDS) V2: per Amazon EMR 6.2 o versioni successive, i componenti di Amazon EMR vengono utilizzati per tutte le chiamate IMDS. IMDSv2 Per le chiamate IMDS nel codice dell'applicazione, puoi utilizzare entrambi o configurare l'IMDS in modo che IMDSv1 venga utilizzato IMDSv2 solo per una maggiore sicurezza. IMDSv2 Se si disattiva IMDSv1 nelle versioni precedenti di Amazon EMR 6.x, si verifica un errore di avvio del cluster.

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

• Spark: miglioramenti delle prestazioni del runtime Spark.

Problemi noti

• Amazon EMR 6.2 ha autorizzazioni errate impostate sulla directory the /etc/cron.d/libinstance-controller-java file in EMR 6.2.0. Permissions on the file are 645 (-rw-r--r-x), when they should be 644 (-rw-r--r--). As a result, Amazon EMR version 6.2 does not log instance-state logs, and the /emr/instance -logs vuota. Questo problema è stato risolto in Amazon EMR 6.3.0 e 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 della sottorete privata di Amazon EMR 6.2.0 e 6.3.0 non è possibile accedere all'interfaccia utente Web di Ganglia. Verrà visualizzato l'errore "access denied (403) (accesso negato (403))". Altri siti Web UIs, 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 ha continuamente esito negativo, causando la non disponibilità di Ganglia. Viene visualizzato un errore "cannot connect to the server (impossibile connettersi al server)". Per risolvere questo problema in un cluster che è già in esecuzione, abilita SSH sul nodo primario del cluster e aggiungi la riga Listen 80 al file httpd.conf presente in /etc/httpd/conf/httpd.conf. Questo problema è stato risolto in Amazon EMR 6.3.0.

• HTTPD ha esito negativo su 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 ulteriori informazioni su come connettersi al cluster, consulta la sezione Connect to the Primary Node Using SSH (Connessione al nodo primario tramite SSH).

  Inoltre, EMR Notebooks non riesce a stabilire una connessione con 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.

• Limite «Numero massimo di file aperti» inferiore rispetto alle versioni precedenti [corretto nelle versioni più recenti AL2 ]. 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

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

• Importante

  I cluster EMR 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 l'AMI Amazon Linux predefinita. Se nuovi aggiornamenti software Amazon Linux che richiedono un riavvio (ad esempio, aggiornamenti del kernel, NVIDIA e CUDA) risultano disponibili dopo il rilascio di una versione di Amazon EMR, le istanze del cluster EMR che eseguono l'AMI predefinita non scaricano e installano automaticamente tali aggiornamenti. Per ottenere gli aggiornamenti del kernel, puoi personalizzare l'AMI di Amazon EMR per utilizzare l'AMI di Amazon Linux più recente.

• Gli artifact di Amazon EMR 6.2.0 Maven non vengono pubblicati. Saranno pubblicati con una futura versione di Amazon EMR.

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

• Differenze di versione dei bucket Hive tra Amazon EMR 6.x e EMR 5.x

  EMR 5.x utilizza OOS Apache Hive 2, mentre EMR 6.x utilizza OOS Apache Hive 3. L'Hive2 open source utilizza bucket di versione 1, mentre l'Hive3 open source utilizza bucket di versione 2. Questa differenza di versione dei bucket tra Hive 2 (EMR 5.x) e Hive 3 (EMR 6.x) presuppone un funzionamento diverso dell'hashing dei bucket Hive. Vedere l'esempio sottostante.

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

  -- 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/';

  Sono stati inseriti gli stessi dati in EMR 6.x ed EMR 5.x.

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

  Osservando la posizione S3, si nota che il nome del file di bucket è diverso, poiché la funzione di hashing è diversa tra EMR 6.x (Hive 3) e EMR 5.x (Hive 2).

  [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 notare la differenza di versione anche eseguendo il comando riportato di seguito nella CLI Hive in EMR 6.x. 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 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.

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