Amazon-EMR-Version 6.3.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 Ausführung 1.11.977

• CloudWatch Version 2.1.0 senken

• Version 4.16.0 von EMR DynamoDB Connector

• EMRFS-Version 2.46.0

• Version 3.2.0 von Amazon EMR Goodies

• Version 3.5.0 von Amazon EMR Kinesis Connector

• Version 2.0.0 von Amazon EMR Record Server

• Version 2.5.0 von Amazon EMR Skripts

• Flink-Version 1.12.1

• Ganglia Version 3.7.2

• AWS Glue Hive Metastore Client Version 3.2.0

• Hadoop-Version 3.2.1-amzn-3

• HBase Ausführung 2.2.6-amzn-1

• HBase-operator-tools 1.0.0

• HCatalog Ausführung 3.1.2-amzn-0

• Hive-Version 3.1.2-amzn-4

• Hudi-Version 0.7.0-amzn-0

• Hue Version 4.9.0

• Java-JDK-Version Corretto-8.282.08.1 (Build 1.8.0_282-b08)

• JupyterHub Ausführung 1.2.0

• Livy-Version 0.7.0-incubating

• MXNet Ausführung 1.7.0

• Oozie-Version 5.2.1

• Phoenix Version 5.0.0

• Pig Version 0.17.0

• Presto-Version 0.245.1-amzn-0

• PrestoSQL-Version 350

• Version 2.0.0 von Apache Ranger KMS (transparente Multi-Master-Verschlüsselung)

• Ranger-Plugins 2.0.1-amzn-0

• Ranger-S3-Plugin 1.1.0

• SageMaker Spark SDK, Version 1.4.1

• Scala-Version 2.12.10 (OpenJDK 64-Bit-Server-VM, Java 1.8.0_282)

• Spark-Version 3.1.1-amzn-0

• Spark-Rapids 0.4.1

• Sqoop-Version 1.4.7

• TensorFlow Ausführung 2.4.1

• Tez-Version 0.9.2

• Zeppelin-Version 0.9.0

• Zookeeper Version 3.4.14

• Konnektoren und Treiber: DynamoDB Connector 4.16.0

Neue Features

• Amazon EMR unterstützt Amazon S3 Access Points, ein Feature von Amazon S3, mit dem Sie den Zugriff auf gemeinsam genutzte Data Lakes einfach verwalten können. Mit Ihrem Alias von Amazon S3 Access Point können Sie Ihren Datenzugriff auf Amazon EMR in großem Umfang vereinfachen. Sie können Amazon S3 Access Points mit allen Versionen von Amazon EMR ohne zusätzliche Kosten in allen AWS Regionen verwenden, in denen Amazon EMR verfügbar ist. Weitere Informationen zu Amazon S3 Access Points und Zugangspunkt-Aliassen finden Sie unter Verwenden eines Alias im Bucket-Stil für Ihren Zugangspunkt im Amazon-S3-Benutzerhandbuch.

• Neue DescribeReleaseLabel und ListReleaseLabel API-Parameter bieten Details zum Amazon-EMR-Release-Label. Sie können programmgesteuert Versionen auflisten, die in der Region verfügbar sind, in der die API-Anfrage ausgeführt wird, und die verfügbaren Anwendungen für ein bestimmtes Amazon-EMR-Release-Label auflisten. In den Release-Label-Parametern sind auch Amazon-EMR-Versionen aufgeführt, die eine bestimmte Anwendung unterstützen, z. B. Spark. Diese Informationen können verwendet werden, um Amazon-EMR-Cluster programmgesteuert zu starten. Sie können beispielsweise einen Cluster mit der neuesten Release-Version aus den ListReleaseLabel-Ergebnissen starten. Weitere Informationen finden Sie unter DescribeReleaseLabelund ListReleaseLabelsin der Amazon EMR API-Referenz.

• Mit Amazon EMR 6.3.0 können Sie einen Cluster starten, der nativ in Apache Ranger integriert ist. Apache Ranger ist ein Open-Source-Framework zur Aktivierung, Überwachung und Verwaltung einer umfassenden Datensicherheit auf der gesamten Hadoop-Plattform. Weitere Informationen finden Sie unter Apache Ranger. Dank der nativen Integration können Sie Ihren eigenen Apache Ranger verwenden, um eine detaillierte Datenzugriffskontrolle auf Amazon EMR durchzusetzen. Weitere Informationen finden Sie unter Amazon EMR mit Apache Ranger im Verwaltungshandbuch für Amazon EMR.

• Verwaltete Richtlinien mit Geltungsbereich: Um den AWS bewährten Methoden zu entsprechen, hat Amazon EMR verwaltete Standardrichtlinien mit EMR-Geltungsbereich der Version v2 eingeführt, die als Ersatz für Richtlinien dienen, die nicht mehr unterstützt werden. Weitere Informationen finden Sie unter Verwaltete Richtlinien von Amazon EMR.

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

Änderungen, Verbesserungen und behobene Probleme

• Dies ist eine Version zur Behebung von Problemen mit Amazon-EMR-Skalierung, wenn ein Cluster nicht erfolgreich hoch-/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 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 Auftragsfehler aufgrund eines Fehlers bei der Außerbetriebnahme von YARN auftraten, wenn der Cluster versuchte, hoch- oder herunterzuskalieren.

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

• 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 erforderlich ist, das auf dem Primärknoten ausgeführt wird.

• Neuere Amazon EMR-Versionen beheben das Problem mit einem niedrigeren Limit für die maximale Anzahl geöffneter Dateien für ältere Versionen AL2 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“.

• Der Erklärungsmodus der Spark-SQL-Benutzeroberfläche wurde in Spark 3.1 von extended auf formatted geändert. Amazon EMR hat ihn wieder auf extended zurückgesetzt, um logische Planinformationen in die Spark-SQL-Benutzeroberfläche aufzunehmen. Dies kann durch Einstellen von spark.sql.ui.explainMode auf formatted rückgängig gemacht werden.

• Die folgenden Commits wurden aus dem Spark-Master-Branch zurückportiert.

  – [SPARK-34752] [BUILD] Bump Jetty auf 9.4.37, um CVE-2020-27223 zu adressieren.

  - [SPARK-34534] Die Reihenfolge der BlockIDs beim Abrufen von Blöcken wurde korrigiert. FetchShuffleBlocks

  – [SPARK-34681] [SQL] Es wurde ein Fehler behoben, der beim Erstellen der linken Seite mit einer ungleichen Bedingung beim Erstellen einer linken Seite auftrat.

  – [SPARK-34497] [SQL] Korrigiert integrierte JDBC-Verbindungsanbieter, um Änderungen im JVM-Sicherheitskontext wiederherzustellen.

• Um die Interoperabilität mit dem Nvidia RAPIDs Spark-Plugin zu verbessern, wurde eine Problemumgehung hinzugefügt, um ein Problem zu beheben, das verhindert, dass dynamisches Partitionsbereinigen ausgelöst wird, wenn Nvidia Spark RAPIDs mit deaktivierter adaptiver Abfrageausführung verwendet wird. Weitere Informationen finden Sie unter RAPIDS-Problem #1378 und RAPIDS-Problem Nr. #1386. Einzelheiten zur neuen spark.sql.optimizer.dynamicPartitionPruning.enforceBroadcastReuse-Konfiguration finden Sie in der RAPIDS-Problem ##1386.

• Der Standardalgorithmus für den Dateiausgabe-Committer wurde in Open Source Spark 3.1 vom v2-Algorithmus auf den v1-Algorithmus geändert. Weitere Informationen finden Sie unter Amazon EMR zur Optimierung der Spark-Leistung – dynamisches Bereinigen von Partitionen.

• Amazon EMR hat auf den v2-Algorithmus zurückgesetzt, den in früheren Amazon-EMR-6.x-Versionen verwendeten Standard, um eine Leistungsregression zu verhindern. Um das Open-Source-Verhalten von Spark 3.1 wiederherzustellen, setzen Sie spark.hadoop.mapreduce.fileoutputcommitter.algorithm.version auf 1. Open Source Spark hat diese Änderung vorgenommen, weil das Festschreiben von Aufgaben im Datei-Output-Committer-Algorithmus v2 nicht atomar ist, was in einigen Fällen zu Problemen mit der Korrektheit der Ausgabedaten führen kann. Das Festschreiben von Aufgaben im Algorithmus v1 ist jedoch auch nicht atomar. In einigen Szenarien beinhaltet die Aufgabenübergabe ein Löschen, das vor einer Umbenennung durchgeführt wird. Dies kann zu einem unbemerkten Problem mit der Datenkorrektheit führen.

• Probleme bei der verwalteten Skalierung in früheren Amazon-EMR-Versionen wurden behoben und Verbesserungen vorgenommen, sodass die Ausfallraten von Anwendungen erheblich reduziert wurden.

• Das AWS Java SDK-Bundle wurde auf jedem neuen Cluster installiert. Dies ist ein einzelnes JAR, das alle Dienste SDKs und ihre Abhängigkeiten enthält, anstatt einzelne Komponenten-Jars. Weitere Informationen finden Sie unter Gebündelte Java SDK Abhängigkeit

Bekannte Probleme

• Für private Subnetz-Cluster von Amazon EMR 6.3.0 und 6.2.0 können Sie nicht auf die Ganglia-Webbenutzeroberfläche zugreifen. Sie erhalten die Fehlermeldung „Zugriff verweigert (403)“. Andere Websites UIs wie Spark, Hue JupyterHub, Zeppelin, 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.

• Wenn der AWS Glue-Datenkatalog aktiviert ist, kann die Verwendung von Spark für den Zugriff auf eine AWS Glue-Datenbank mit einer Null-Ort-URI fehlschlagen. Dies passiert bei früheren Amazon EMR-Versionen, aber bei SPARK-31709 (https://issues.apache. org/jira/browse/SPARK-31709) macht es auf mehr Fälle anwendbar. Wenn Sie beispielsweise eine Tabelle in der AWS Standard-Glue-DB erstellen, deren Standort-URI eine Nullzeichenfolge ist, spark.sql("CREATE TABLE mytest (key string) location '/table_path';") schlägt dies mit der Meldung „Cannot create a Path from an empty string“ fehl. Um dies zu umgehen, legen Sie manuell einen Standort-URI Ihrer AWS Glue-Datenbanken fest und erstellen Sie dann mit Spark Tabellen innerhalb dieser Datenbanken.

• In Amazon EMR 6.3.0 wurde PrestoSQL von Version 343 auf Version 350 aktualisiert. Es gibt zwei sicherheitsrelevante Änderungen von Open Source, die sich auf diese Versionsänderung beziehen. Die dateibasierte Katalogzugriffssteuerung wurde von deny zu allow geändert, wenn keine Regeln für Tabellen-, Schema- oder Sitzungseigenschaften definiert sind. Außerdem wurde die dateibasierte Systemzugriffskontrolle dahingehend geändert, dass sie Dateien unterstützt, für die keine Katalogregeln definiert sind. In diesem Fall ist der gesamte Zugriff auf Kataloge zulässig.

  Weitere Informationen finden Sie in Version 344 (9. Oktober 2020).

• Beachten Sie das Hadoop-Benutzerverzeichnis (/) home/hadoop) is readable by everyone. It has Unix 755 (drwxr-xr-x) directory permissions to allow read access by frameworks like Hive. You can put files in /home/hadoop und seine Unterverzeichnisse. Beachten Sie jedoch die Berechtigungen für diese Verzeichnisse, um vertrauliche Informationen zu schützen.

• Niedrigeres Limit für die maximale Anzahl geöffneter Dateien bei älteren Versionen AL2 [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

  EMR-Cluster, 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-AMI ausgeführt wird. 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.

• Um Spark-Aktionen mit Apache Oozie zu verwenden, müssen Sie Ihrer Oozie-workflow.xml-Datei die folgende Konfiguration hinzufügen. Andernfalls fehlen mehrere wichtige Bibliotheken wie Hadoop und EMRFS im Klassenpfad der Spark-Executoren, die Oozie startet.

  <spark-opts>--conf spark.yarn.populateHadoopClasspath=true</spark-opts>

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