Rilascio 5.33.1 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.15.0

• Aggiornato alla versione 1.11.970 AWS SDK for Java

• EMRFS aggiornato alla versione 2.46.0

• EMR Goodies aggiornato alla versione 2.14.0

• EMR Record Server aggiornato alla versione 1.9.0

• EMR S3 Dist CP aggiornato alla versione 2.18.0

• EMR Secret Agent aggiornato alla versione 1.8.0

• Flink aggiornato alla versione 1.12.1

• Hadoop aggiornato alla versione 2.10.1-amzn-1

• Hive aggiornato alla versione 2.3.7-amzn-4

• Hudi aggiornato alla versione 0.7.0

• Hue aggiornato alla versione 4.9.0

• OpenCV aggiornato alla versione 4.5.0

• Presto aggiornato alla versione 0.245.1-amzn-0

• R aggiornato alla versione 4.0.2

• Spark aggiornato alla versione 2.4.7-amzn-1

• Aggiornato alla versione 2.4.1 TensorFlow

• Zeppelin aggiornato alla versione 0.9.0

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

• Configurazione di un cluster per risolvere i problemi di prestazioni di Apache YARN Timeline Server versione 1 e 1.5

  Le versioni 1 e 1.5 di Apache YARN Timeline Server possono causare problemi di prestazioni con cluster EMR molto attivi e di grandi dimensioni, in particolare con yarn.resourcemanager.system-metrics-publisher.enabled=true, che è l'impostazione predefinita in Amazon EMR. Un YARN Timeline Server v2 open source risolve il problema di prestazioni relativo alla scalabilità di YARN Timeline Server.

  Altre soluzioni alternative per questo problema includono:

  • Configurazione di yarn.resourcemanager. system-metrics-publisher.enabled=false in yarn-site.xml.

  • L'abilitazione della correzione per questo problema durante la creazione di un cluster, come descritto di seguito.

  I seguenti rilasci di Amazon EMR contengono una correzione per questo problema di prestazioni di YARN Timeline Server.

  EMR 5.30.2, 5.31.1, 5.32.1, 5.33.1, 5.34.x, 6.0.1, 6.1.1, 6.2.1, 6.3.1 e 6.4.x

  Per abilitare la correzione su una delle versioni di Amazon EMR sopra specificate, imposta queste proprietà su true in un file JSON di configurazioni che viene passato utilizzando il parametro del comando aws emr create-cluster: --configurations file://./configurations.json. Oppure abilita la correzione utilizzando l'interfaccia utente della console di riconfigurazione.

  Esempio del contenuto del file configurations.json:

  [
  {
  "Classification": "yarn-site",
  "Properties": {
  "yarn.resourcemanager.system-metrics-publisher.timeline-server-v1.enable-batch": "true",
  "yarn.resourcemanager.system-metrics-publisher.enabled": "true"
  },
  "Configurations": []
  }
  ]

• Adesso, il runtime di Spark è più veloce quando si recuperano le posizioni delle partizioni dal metastore Hive per le query di inserimento Spark.

• Versioni dei componenti aggiornate. Per un elenco delle versioni dei componenti, consulta Informazioni sui rilasci di Amazon EMR in questa guida.

• Installato il pacchetto AWS Java SDK su ogni nuovo cluster. Si tratta di un singolo jar contenente tutti i servizi SDKs e le relative dipendenze, anziché i vasetti dei singoli componenti. Per ulteriori informazioni, consulta Dipendenza dell'SDK in bundle.

• Risolti i problemi di dimensionamento gestito nelle versioni precedenti di Amazon EMR e apportati miglioramenti in modo da ridurre significativamente le percentuali di errore delle applicazioni.

• Il protocollo HTTPS ora è abilitato per impostazione predefinita per i repository Amazon Linux. Se utilizzi una policy Amazon S3 VPCE per limitare l'accesso a specifici bucket, devi aggiungere il nuovo ARN del bucket Amazon Linux arn:aws:s3:::amazonlinux-2-repos-$region/* alla tua policy (sostituisci $region con la Regione in cui si trova l'endpoint). Per ulteriori informazioni, consultate questo argomento nei AWS forum di discussione. Annuncio: Amazon Linux 2 ora supporta la possibilità di utilizzare HTTPS durante la connessione ai repository dei pacchetti .

Nuove funzionalità

• Amazon EMR supporta Amazon S3 Access Point, una funzionalità di Amazon S3 che consente di gestire facilmente l'accesso ai data lake condivisi. Utilizzando il tuo alias Amazon S3 Access Point, puoi semplificare l'accesso ai dati su larga scala su Amazon EMR. Puoi utilizzare Amazon S3 Access Point con tutte le versioni di Amazon EMR senza costi aggiuntivi in tutte le regioni in cui è disponibile AWS Amazon EMR. Per ulteriori informazioni sugli alias degli Access Point e degli Amazon S3 Access Point, consulta Utilizzo di un alias in stile bucket per il punto di accesso nella Guida per l'utente di Amazon S3.

• Amazon EMR-5.33 supporta nuovi tipi di EC2 istanze Amazon: c5a, c5ad, c6gn, c6gd, m6gd, d3, d3en, m5zn, r5b, r6gd. Consulta la sezione relativa ai tipi di istanza supportati.

Problemi noti

• Limite «Numero massimo di AL2 file aperti» inferiore rispetto alle versioni precedenti [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

• Per i cluster della sottorete privata di Amazon EMR 6.3.0 e 6.2.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 JupyterHub, Livy e 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.

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

• Il supporto da console per creare una configurazione di sicurezza che specifichi l'opzione di integrazione AWS Ranger non è attualmente supportato nella regione. GovCloud La configurazione della sicurezza può essere eseguita utilizzando la CLI. Consulta Creazione della configurazione di sicurezza EMR nella Guida alla gestione di Amazon EMR.

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

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