Amazon-EMR-Version 6.2.0

• Anwendungsversionen in Amazon-EMR-7.x-Versionen

• Anwendungsversionen in Amazon-EMR-6.x-Versionen

• Anwendungsversionen in Amazon-EMR-5.x-Versionen (PNG)

• Anwendungsversionen in Amazon-EMR-4.x-Versionen

Unterstützte Anwendungen

• AWS SDK für Java Ausführung 1.11.828

• EMR-Aufzeichnungsserver-Version 1.7.0

• Flink-Version 1.11.2

• Ganglia Version 3.7.2

• Hadoop-Version 3.2.1-amzn-1

• HBase Version 2.2.6-amzn-0

• HBase-operator-tools 1.0.0

• HCatalog-Version 3.1.2-amzn-0

• Hive Version 3.1.2-amzn-3

• Hudi Version 0.6.0-amzn-1

• Hue Version 4.8.0

• JupyterHub Ausführung 1.1.0

• Livy-Version 0.7.0

• MXNet-Version 1.7.0

• Oozie-Version 5.2.0

• Phoenix Version 5.0.0

• Pig Version 0.17.0

• Presto Version 0.238.3-amzn-1

• PrestoSQL Version 343

• Spark Version 3.0.1-amzn-0

• Spark-Rapids 0.2.0

• TensorFlow Ausführung 2.3.1

• Zeppelin-Version 0.9.0-preview1

• Zookeeper Version 3.4.14

• Konnektoren und Treiber: DynamoDB Connector 4.16.0

Neue Features

• HBase: Die Umbenennung in der Commit-Phase wurde entfernt und persistentes HFile-Tracking hinzugefügt. Weitere Informationen finden Sie unter Persistentes HFile-Tracking im Amazon-EMR-Versionshandbuch.

• HBase: Backported Erstellen Sie eine Konfiguration, die das Zwischenspeichern von Blöcken bei der Komprimierung erzwingt..

• PrestoDB: Verbesserungen beim dynamischen Partitionsbereinigen. Rule-based Join Reorder funktioniert mit nicht partitionierten Daten.

• Gültige verwaltete Richtlinien: Um den AWS Best Practices zu entsprechen, hat Amazon EMR verwaltete EMR-scoped Standardrichtlinien der Version 2 als Ersatz für Richtlinien eingeführt, die nicht mehr unterstützt werden. Weitere Informationen finden Sie unter Verwaltete Richtlinien von Amazon EMR.

• Unterstützungsstatus des Instance Metadata Service (IMDS) V2: Für Amazon EMR 6.2 oder höher verwenden Amazon-EMR-Komponenten IMDSv2 für alle IMDS-Aufrufe. Für IMDS-Aufrufe in Ihrem Anwendungscode können Sie sowohl IMDSv1 als auch IMDSv2 verwenden oder das IMDS so konfigurieren, dass es aus Sicherheitsgründen nur IMDSv2 verwendet. Wenn Sie IMDSv1 in früheren Amazon-EMR-6.x-Versionen deaktivieren, führt dies zu einem Cluster-Startup-Fehler.

Änderungen, Verbesserungen und behobene Probleme

• Dies ist eine Version zur Behebung von Problemen mit Amazon EMR Scaling, wenn ein Cluster nicht erfolgreich up/scale herunterskaliert werden kann oder Anwendungsfehler verursacht werden.

• Es wurde ein Problem behoben, bei dem Skalierungsanforderungen für einen großen, stark ausgelasteten Cluster fehlschlugen, wenn Amazon-EMR-On-Cluster-Daemons Aktivitäten zur Integritätsprüfung durchführten, z. B. das Erfassen des YARN-Knotenstatus und des HDFS-Knotenstatus. Das lag daran, dass Cluster-Daemons die Integritätsstatusdaten eines Knotens nicht an interne Amazon-EMR-Komponenten weitergeben konnten.

• Verbesserte EMR-On-Cluster-Daemons zur korrekten Nachverfolgung der Knotenstatus bei der Wiederverwendung von IP-Adressen, um die Zuverlässigkeit bei Skalierungsvorgängen zu verbessern.

• SPARK-29683. Es wurde ein Problem behoben, bei dem beim Herunterskalieren des Clusters Jobfehler auftraten, da Spark davon ausging, dass alle verfügbaren Knoten auf der Deni-List standen.

• YARN-9011. Es wurde ein Problem behoben, bei dem Jobfehler aufgrund eines Fehlers bei der Außerbetriebnahme von YARN auftraten, wenn der Cluster versuchte, nach oben oder unten zu skalieren.

• Das Problem mit Schritt- oder Jobfehlern bei der Cluster-Skalierung wurde behoben, indem sichergestellt wurde, dass die Knotenstatus zwischen den Amazon EMR-On-Cluster-Daemons und immer konsistent sind. YARN/HDFS

• Es wurde ein Problem behoben, bei dem Clustervorgänge wie Herunterskalierung und Schrittübermittlung für Amazon-EMR-Cluster, die mit Kerberos-Authentifizierung aktiviert waren, fehlschlugen. Dies lag daran, dass der Amazon EMR-On-Cluster-Daemon das Kerberos-Ticket nicht erneuert hat, das für die sichere Kommunikation mit HDFS/YARN Running on the Primary Node erforderlich ist.

• Neuere Amazon-EMR-Versionen beheben das Problem mit einem niedrigeren Limit für die „maximale Anzahl geöffneter Dateien“ auf älteren AL2-Versionen in Amazon EMR. Die Amazon-EMR-Versionen 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 und höher enthalten jetzt einen dauerhaften Fix mit einer höheren Einstellung für „Max. Anzahl geöffneter Dateien“.

• Spark: Leistungsverbesserungen in der Spark-Laufzeit.

Bekannte Probleme

• Amazon EMR 6.2 hat falsche Berechtigungen auf dem/etc/crongesetzt. d/libinstance-Controller-Java-Datei in EMR 6.2.0. Die Berechtigungen für die Datei sind 645 (-rw-r--r-x), obwohl sie 644 (-rw-r--r--) sein sollten. Aus diesem Grund protokolliert Amazon EMR Version 6.2 keine Instanzstatusprotokolle und das Verzeichnis/emr/instance-logs ist leer. Dieses Problem wurde in Amazon EMR 6.3.0 und höher behoben.

  Zur Umgehung dieses Problems führen Sie das folgende Skript als Bootstrap-Aktion beim Clusterstart aus.

  #!/bin/bash
  sudo chmod 644 /etc/cron.d/libinstance-controller-java
              

• Für private Subnetz-Cluster von Amazon EMR 6.2.0 und 6.3.0 können Sie nicht auf die Ganglia-Webbenutzeroberfläche zugreifen. Sie erhalten die Fehlermeldung „Zugriff verweigert (403)“. Andere Web-Benutzeroberflächen wie Spark, Hue, Zeppelin JupyterHub, Livy und Tez funktionieren normal. Der Zugriff auf die Ganglia-Web-Benutzeroberfläche auf öffentlichen Subnetzclustern funktioniert ebenfalls normal. Um dieses Problem zu beheben, starten Sie den httpd-Service auf dem Primärknoten mit sudo systemctl restart httpd neu. Dieses Problem wurde in Amazon EMR 6.4.0 behoben.

• In Amazon EMR 6.2.0 gibt es ein Problem, bei dem httpd kontinuierlich ausfällt, wodurch Ganglia nicht verfügbar ist. Sie erhalten die Fehlermeldung „Es kann keine Verbindung zum Server hergestellt werden“. Um einen Cluster zu reparieren, der bereits mit diesem Problem läuft, stellen Sie eine SSH-Verbindung zum Cluster-Primärknoten her und fügen Sie die Zeile Listen 80 zu der Datei httpd.conf hinzu, die sich unter /etc/httpd/conf/httpd.conf befindet. Dieses Problem wurde in Amazon EMR 6.3.0 behoben.

• HTTPD schlägt auf EMR-6.2.0-Clustern fehl, wenn Sie eine Sicherheitskonfiguration verwenden. Dadurch ist die Benutzeroberfläche der Ganglia-Webanwendung nicht verfügbar. Um auf die Benutzeroberfläche der Ganglia-Webanwendung zuzugreifen, fügen Sie Listen 80 der /etc/httpd/conf/httpd.conf-Datei auf dem Primärknoten Ihres Clusters etwas hinzu. Informationen zum Herstellen einer Verbindung zu Ihrem Cluster finden Sie unter Verbinden mit dem Primärknoten über SSH.

  EMR Notebooks können auch keine Verbindung mit EMR-6.2.0-Clustern herstellen, wenn Sie eine Sicherheitskonfiguration verwenden. Das Notebook kann keine Kernel auflisten und Spark-Aufträge nicht weiterleiten. Wir empfehlen, stattdessen EMR Notebooks mit einer anderen Version von Amazon EMR zu verwenden.

• Niedrigeres Limit für die „Max. Anzahl geöffneter Dateien“ auf älteren AL2-Versionen [in neueren Versionen behoben]. Amazon-EMR-Versionen: emr-5.30.x, emr-5.31.0, emr-5.32.0, emr-6.0.0, emr-6.1.0 und emr-6.2.0 basieren auf älteren Versionen von Amazon Linux 2 (AL2), die eine niedrigere Ulimit-Einstellung für „Max. Anzahl geöffneter Dateien“ haben, wenn Amazon-EMR-Cluster mit dem Standard-AMI erstellt werden. Die Amazon-EMR-Versionen 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 und höher enthalten einen dauerhaften Fix mit einer höheren Einstellung für „Max. Anzahl geöffneter Dateien“. Versionen mit einem niedrigeren Limit für geöffnete Dateien verursachen beim Senden des Spark-Jobs den Fehler „Zu viele offene Dateien“. In den betroffenen Versionen hat das Amazon-EMR-Standard-AMI eine Ulimit-Standardeinstellung von 4 096 für „Max. Anzahl geöffneter Dateien“, was unter dem Dateilimit von 65 536 im neuesten Amazon-Linux-2-AMI liegt. Die niedrigere Ulimit-Einstellung für „Max. Anzahl geöffneter Dateien“ führt dazu, dass der Spark-Job fehlschlägt, wenn der Spark-Treiber und der Executor versuchen, mehr als 4 096 Dateien zu öffnen. Um das Problem zu beheben, verfügt Amazon EMR über ein Bootstrap Action (BA)-Skript, das die Ulimit-Einstellung bei der Cluster-Erstellung anpasst.

  Wenn Sie eine ältere Amazon-EMR-Version verwenden, für die dieses Problem nicht dauerhaft behoben ist, können Sie mit der folgenden Problemumgehung das Instance-Controller-Ulimit explizit auf maximal 65 536 Dateien festlegen.

  Explizit ein ulimit über die Befehlszeile setzen

  1. Bearbeiten Sie /etc/systemd/system/instance-controller.service, um die folgenden Parameter zum Abschnitt Service hinzuzufügen.

     LimitNOFILE=65536

     LimitNPROC=65536

  2. Starten Sie neu InstanceController

     $ sudo systemctl daemon-reload

     $ sudo systemctl restart instance-controller

  Mithilfe der Bootstrap-Aktion (BA) ein Ulimit festlegen

  Sie können auch ein Bootstrap-Aktionsskript (BA) verwenden, um das Ulimit für den Instance-Controller bei der Clustererstellung auf 65 536 Dateien zu konfigurieren.

  #!/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

• Wichtig

  Amazon EMR 6.1.0 und 6.2.0 beinhalten ein Leistungsproblem, das sich kritisch auf alle Hudi-Operationen zum Einfügen, Upsert und Löschen auswirken kann. Wenn Sie Hudi mit Amazon EMR 6.1.0 oder 6.2.0 verwenden möchten, sollten Sie sich an den AWS Support wenden, um ein gepatchtes Hudi RPM zu erhalten.

• Wichtig

  EMR-Cluster, auf denen Amazon-Linux- oder Amazon-Linux-2-AMIs (Amazon Machine Images) ausgeführt werden, verwenden das Standardverhalten von Amazon Linux und laden wichtige und kritische Kernel-Updates, die einen Neustart erfordern, nicht automatisch herunter und installieren sie. Dies ist dasselbe Verhalten wie bei anderen Amazon-EC2-Instances, die das standardmäßige Amazon-Linux-AMI ausführen. Wenn neue Amazon-Linux-Softwareupdates, die einen Neustart erfordern (wie Kernel-, NVIDIA- und CUDA-Updates), nach der Veröffentlichung einer Amazon-EMR-Version verfügbar werden, laden EMR-Cluster-Instances, die das Standard-AMI ausführen, diese Updates nicht automatisch herunter und installieren sie. Um Kernel-Updates zu erhalten, können Sie Ihr Amazon-EMR-AMI so anpassen, dass es das neueste Amazon-Linux-AMI verwendet.

• Maven-Artefakte von Amazon EMR 6.2.0 werden nicht veröffentlicht. Sie werden mit einer zukünftigen Version von Amazon EMR veröffentlicht.

• Die persistente HFile-Nachverfolgung mithilfe der HBase-Storefile-Systemtabelle unterstützt das Feature zur Replikation von HBase-Regionen nicht. Weitere Informationen zur HBase-Regionsreplikation finden Sie unter High Available Reads. Timeline-consistent

• Unterschiede zwischen den Bucketing-Versionen von Amazon EMR 6.x und EMR 5.x Hive

  EMR 5.x verwendet OOS Apache Hive 2, während in EMR 6.x OOS Apache Hive 3 verwendet wird. Die Open-Source-Version Hive2 verwendet Bucketing Version 1, während die Open-Source-Version Hive3 Bucketing Version 2 verwendet. Dieser Unterschied in der Bucketing-Version zwischen Hive 2 (EMR 5.x) und Hive 3 (EMR 6.x) bedeutet, dass Hive-Bucketing-Hashing anders funktioniert. Sehen Sie sich das folgende Beispiel an.

  Die folgende Tabelle ist ein Beispiel, das in EMR 6.x bzw. EMR 5.x erstellt wurde.

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

  Dieselben Daten werden sowohl in EMR 6.x als auch in EMR 5.x eingefügt.

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

  Die Überprüfung des S3-Speicherorts zeigt, dass der Name der Bucketing-Datei unterschiedlich ist, da sich die Hashing-Funktion zwischen EMR 6.x (Hive 3) und EMR 5.x (Hive 2) unterscheidet.

  [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
  

  Sie können den Versionsunterschied auch erkennen, indem Sie den folgenden Befehl in der Hive-CLI in EMR 6.x ausführen. Beachten Sie, dass die Bucketing-Version 2 zurückgegeben wird.

  hive> DESCRIBE FORMATTED test_bucketing;
  ...
  Table Parameters:
      bucketing_version       2
  ...

• Bekanntes Problem in Clustern mit mehreren Primärknoten und Kerberos-Authentifizierung

  Wenn Sie Cluster mit mehreren Primärknoten und Kerberos-Authentifizierung in Amazon-EMR-Versionen 5.20.0 und höher ausführen, können Probleme mit Cluster-Vorgängen wie dem Herunterskalieren oder der schrittweisen Übermittlung auftreten, nachdem der Cluster einige Zeit lang ausgeführt wurde. Der Zeitraum hängt von der Gültigkeitsdauer des Kerberos-Tickets ab, die Sie definiert haben. Das Herunterskalierungs-Problem wirkt sich sowohl auf automatische als auch auf explizite Herunterskalierungs-Anfragen aus, die Sie eingereicht haben. Weitere Clustervorgänge können ebenfalls beeinträchtigt werden.

  Workaround:

  • SSH als hadoop-Benutzer für den führenden Primärknoten des EMR-Clusters mit mehreren Primärknoten.

  • Führen Sie den folgenden Befehl aus, um das Kerberos-Ticket für den hadoop-Benutzer zu erneuern.

    kinit -kt <keytab_file> <principal>

    In der Regel befindet sich die Keytab-Datei unter /etc/hadoop.keytab und der Prinzipal hat das Format von hadoop/<hostname>@<REALM>.

  Anmerkung

  Diese Problemumgehung gilt für den Zeitraum, in dem das Kerberos-Ticket gültig ist. Diese Dauer beträgt standardmäßig 10 Stunden, kann aber anhand Ihrer Kerberos-Einstellungen konfiguriert werden. Sie müssen den obigen Befehl erneut ausführen, sobald das Kerberos-Ticket abgelaufen ist.

• Wenn Sie Spark mit der Formatierung des Hive-Partitionsstandorts verwenden, um Daten in Amazon S3 zu lesen, und Sie Spark auf den Amazon-EMR-Versionen 5.30.0 bis 5.36.0 und 6.2.0 bis 6.9.0 ausführen, kann ein Problem auftreten, das verhindert, dass Ihr Cluster Daten korrekt liest. Dies kann passieren, wenn Ihre Partitionen alle der folgenden Eigenschaften aufweisen:

  • Zwei oder mehr Partitionen werden aus derselben Tabelle gescannt.

  • Mindestens ein Partitionsverzeichnispfad ist ein Präfix für mindestens einen anderen Partitionsverzeichnispfad, z. B. ist s3://bucket/table/p=a ein Präfix von s3://bucket/table/p=a b.

  • Das erste Zeichen, das auf das Präfix im anderen Partitionsverzeichnis folgt, hat einen UTF-8 Wert, der kleiner als das / Zeichen (U+002F) ist. Beispielsweise fällt das Leerzeichen (U+0020), das in s3://bucket/table/p=a b zwischen a und b vorkommt, in diese Kategorie. Beachten Sie, dass es 14 weitere Zeichen gibt, die keine Kontrollzeichen sind: !"#$%&‘()*+,-. Weitere Informationen finden Sie unter UTF-8 Kodieren von Tabellen- und Unicode-Zeichen.

  Um dieses Problem zu umgehen, stellen Sie die spark.sql.sources.fastS3PartitionDiscovery.enabled-Konfiguration auf false in der spark-defaults-Klassifizierung ein.