EMRAmazon-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 for Java Version 1.11.828

• emr-record-server Ausführung 1.7.0

• Flink-Version 1.11.2

• Ganglia Version 3.7.2

• Hadoop-Version 3.2.1-amzn-1

• HBaseAusführung 2.2.6-amzn-0

• HBase-operator-tools 1.0.0

• HCatalogAusführung 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

• MXNetAusführung 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

• Presto, Version 3.4.3 SQL

• 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 Persistent HFile Tracking im Amazon EMR Release Guide.

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

• PrestoDB: Verbesserungen beim dynamischen Partitionsbereinigen. Die regelbasierte Join Reorder funktioniert mit nicht partitionierten Daten.

• Verwaltete Richtlinien mit Geltungsbereich: Um den AWS bewährten Verfahren Rechnung zu tragen, EMR hat Amazon EMR verwaltete Standardrichtlinien mit Geltungsbereich v2 als Ersatz für Richtlinien eingeführt, die nicht mehr unterstützt werden. Weitere Informationen finden Sie unter EMRVon Amazon verwaltete Richtlinien.

• Support-Status für Instance Metadata Service (IMDS) V2: Für Amazon EMR 6.2 oder höher werden EMR Amazon-Komponenten IMDSv2 für alle IMDS Aufrufe verwendet. Für IMDS Aufrufe in Ihrem Anwendungscode können Sie IMDSv1 sowohl als auch verwenden oder die Option so konfigurierenIMDSv2, IMDS dass sie nur IMDSv2 für zusätzliche Sicherheit verwendet wird. Wenn Sie die Option IMDSv1 in früheren Versionen von Amazon EMR 6.x deaktivieren, führt dies zu einem Fehler beim Starten des Clusters.

Änderungen, Verbesserungen und behobene Probleme

• Dies ist eine Version zur Behebung von Problemen mit Amazon EMR Scaling, wenn ein Cluster nicht erfolgreich hoch-/herunterskaliert werden kann oder wenn es zu Anwendungsausfällen kommt.

• Es wurde ein Problem behoben, bei dem Skalierungsanforderungen für einen großen, stark ausgelasteten Cluster fehlschlugen, wenn EMR Amazon-On-Cluster-Daemons Aktivitäten zur Integritätsprüfung durchführten, z. B. das Erfassen von YARN Knotenstatus und HDFS Knotenstatus. Dies geschah, weil On-Cluster-Daemons nicht in der Lage waren, die Gesundheitsstatusdaten eines Knotens an interne Amazon-Komponenten zu übermitteln. EMR

• Die EMR Cluster-Daemons wurden verbessert, um den Knotenstatus bei der Wiederverwendung von IP-Adressen korrekt nachzuverfolgen, um die Zuverlässigkeit bei Skalierungsvorgängen zu erhöhen.

• SPARK-29683. Es wurde ein Problem behoben, bei dem während der Cluster-Skalierung Auftragsfehler auftraten, da Spark davon ausging, dass alle verfügbaren Knoten auf der Verweigern-Liste standen.

• YARN-9011. Es wurde ein Problem behoben, bei dem Jobfehler aufgrund eines Fehlers bei der YARN Außerbetriebnahme 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 EMR Amazon-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 EMR Amazon-Cluster, die mit Kerberos-Authentifizierung aktiviert waren, fehlschlugen. Dies lag daran, dass der EMR Amazon-On-Cluster-Daemon das Kerberos-Ticket nicht erneuert hat, das für die sichere Kommunikation HDFS YARN mit/auf dem primären Knoten erforderlich ist.

• Neuere EMR Amazon-Versionen beheben das Problem mit einem niedrigeren Limit für „Max. Anzahl geöffneter Dateien“ für ältere Versionen AL2 in AmazonEMR. Die EMR Amazon-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 für das Verzeichnis 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 ist leer gesetzt. 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 Websites wie SparkUIs, 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, gehen Sie SSH zum primären Clusterknoten und fügen Sie die Zeile Listen 80 zu der Datei httpd.conf hinzu, die sich unter befindet. /etc/httpd/conf/httpd.conf Dieses Problem wurde in Amazon EMR 6.3.0 behoben.

• HTTPDschlä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 mit Ihrem Cluster finden Sie unter Herstellen einer Verbindung zum Primärknoten mithilfe von SSH.

  EMRNotebooks können auch keine Verbindung zu 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, EMR Notebooks EMR stattdessen mit einer anderen Version von Amazon zu verwenden.

• Niedrigeres Limit für die maximale Anzahl geöffneter Dateien bei älteren Versionen AL2 [in neueren Versionen behoben]. EMRAmazon-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 ofAmazon Linux 2 (AL2), die eine niedrigere Ulimit-Einstellung für „Max. Geöffnete Dateien“ haben, wenn Amazon-Cluster mit der Standardeinstellung erstellt werden. EMR AMI Die EMR Amazon-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 AMI hat die EMR Amazon-Standardeinstellung eine Ulimit-Standardeinstellung von 4096 für „Max. Geöffnete Dateien“, was unter dem Dateilimit von 65536 in Linux 2 liegt. latestAmazon AMI 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, EMR verfügt Amazon über ein Bootstrap Action (BA) -Skript, das die Ulimit-Einstellung bei der Cluster-Erstellung anpasst.

  Wenn Sie eine ältere EMR Amazon-Version verwenden, die nicht über die permanente Lösung für dieses Problem verfügt, können Sie mit der folgenden Problemumgehung das Instance-Controller-Ulimit explizit auf maximal 65536 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 entscheidend auf alle Hudi-Einfüge-, Upsert- und Löschvorgänge 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 zu erhalten. RPM

• Wichtig

  EMRCluster, auf denen Amazon Linux oder Amazon Linux 2 Amazon Machine Images (AMIs) 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 EC2 Amazon-Instances, auf denen das standardmäßige Amazon Linux ausgeführt wirdAMI. Wenn neue Amazon Linux-Softwareupdates, die einen Neustart erfordern (wie Kernel und CUDA Updates)NVIDIA, verfügbar werden, nachdem eine EMR Amazon-Version verfügbar wird, laden EMR Cluster-Instances, die standardmäßig ausgeführt werden, diese Updates AMI nicht automatisch herunter und installieren sie. Um Kernel-Updates zu erhalten, können Sie Ihr Amazon so anpassen EMR AMI, dass es das neueste Amazon Linux verwendet AMI.

• Amazon EMR 6.2.0 Maven-Artefakte werden nicht veröffentlicht. Sie werden mit einer future Version von Amazon veröffentlichtEMR.

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

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

  EMR5.x verwendet OOS Apache Hive 2, während in EMR 6.x Apache Hive 3 verwendet wird. OOS 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 (EMR5.x) und Hive 3 (EMR6.x) bedeutet, dass Hive Bucketing-Hashing anders funktioniert. Sehen Sie sich das folgende Beispiel an.

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

  -- 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 5.x eingefügt. EMR

  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 5.x (Hive 2) unterscheidet. EMR

  [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 Hive in 6.x ausführen. CLI EMR 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 EMR Amazon-Versionen 5.20.0 und höher ausführen, können Probleme mit Cluster-Vorgängen wie Scale-Down oder Step-Submission 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:

  • SSHals hadoop Benutzer des führenden Primärknotens 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-Partitionsspeicherorts verwenden, um Daten in Amazon S3 zu lesen, und Sie Spark auf den EMR Amazon-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 Wert von UTF -8, 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 Kodierungstabelle UTF -8 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.