Amazon-EMR-Version 6.1.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.828

• Flink-Version 1.11.0

• Ganglia Version 3.7.2

• Hadoop-Version 3.2.1-amzn-1

• HBase Ausführung 2.2.5

• HBase-operator-tools 1.0.0

• HCatalog Ausführung 3.1.2-amzn-0

• Hive-Version 3.1.2-amzn-1

• Hudi-Version 0.5.2-incubating

• Hue-Version 4.7.1

• JupyterHub Ausführung 1.1.0

• Livy-Version 0.7.0

• MXNet Ausführung 1.6.0

• Oozie-Version 5.2.0

• Phoenix Version 5.0.0

• Presto-Version 0.232

• PrestoSQL-Version 338

• Spark-Version 3.0.0-amzn-0

• TensorFlow Ausführung 2.1.0

• Zeppelin-Version 0.9.0-preview1

• Zookeeper Version 3.4.14

• Anschlüsse und Treiber: DynamoDB Connector 4.14.0

Neue Features

• ARM-Instance-Typen werden ab Amazon-EMR-Version 5.30.0 und Amazon-EMR-Version 6.1.0 unterstützt.

• Allzweck-Instance-Typen von M6g werden ab den Amazon-EMR-Versionen 6.1.0 und 5.30.0 unterstützt. Weitere Informationen finden Sie unter Instance-Flotten konfigurieren im Verwaltungshandbuch für Amazon EMR.

• Die EC2 Platzierungsgruppenfunktion wird ab Amazon EMR Version 5.23.0 als Option für Cluster mit mehreren primären Knoten unterstützt. Derzeit werden nur Primärknoten-Typen von des Platzierungsgruppenfeatures unterstützt, und die SPREAD-Strategie wird auf diese Primärknoten angewendet. Bei dieser SPREAD-Strategie wird eine kleine Gruppe von Instances auf separater zugrundeliegender Hardware platziert, um den Verlust mehrerer Primärknoten im Falle eines Hardwarefehlers zu verhindern. Weitere Informationen finden Sie unter EMR-Integration mit EC2 Placement Group im Amazon EMR Management Guide.

• Verwaltete Skalierung – Mit Amazon EMR ab Version 6.1.0 können Sie Amazon EMR Managed Scaling aktivieren, um die Anzahl der Instances oder Einheiten in Ihrem Cluster basierend auf der Workload automatisch zu erhöhen oder zu verringern. Amazon EMR wertet Cluster-Metriken kontinuierlich aus, um Skalierungsentscheidungen zu treffen, die Ihre Cluster für Kosten und Geschwindigkeit optimieren. Verwaltete Skalierung ist auch in Amazon-EMR-Version 5.30.0 und höher verfügbar, außer 6.0.0. Weitere Informationen finden Sie unter Skalieren von Clusterressourcen im Verwaltungshandbuch für Amazon EMR.

• PrestoSQL-Version 338 wird mit EMR 6.1.0 unterstützt. Weitere Informationen finden Sie unter Presto.

  • PrestoSQL wird nur auf EMR 6.1.0 und späteren Versionen unterstützt, nicht auf EMR 6.0.0 oder EMR 5.x.

  • Der Anwendungsname Presto wird weiterhin verwendet, um PrestoDB auf Clustern zu installieren. Verwenden Sie den Anwendungsnamen PrestoSQL, um PrestoSQL auf Clustern zu installieren.

  • Sie können entweder PrestoDB oder PrestoSQL installieren, aber Sie können nicht beide auf einem einzigen Cluster installieren. Wenn beim Versuch, einen Cluster zu erstellen, sowohl PrestoDB als auch PrestoSQL angegeben werden, tritt ein Validierungsfehler auf und die Clustererstellungsanforderung schlägt fehl.

  • PrestoSQL wird sowohl auf Single-Haupt- als auch auf Multi-Haupt-Clustern unterstützt. Auf Multi-Haupt-Clustern ist ein externer Hive-Metastore erforderlich, um PrestoSQL oder PrestoDB auszuführen. Weitere Informationen finden Sie unter Unterstützte Anwendungen in einem EMR-Cluster mit mehreren Primärknoten.

• Unterstützung der auto ECR-Authentifizierung auf Apache Hadoop und Apache Spark mit Docker: Spark-Benutzer können Docker-Images von Docker Hub und Amazon Elastic Container Registry (Amazon ECR) verwenden, um Umgebungs- und Bibliotheksabhängigkeiten zu definieren.

  Konfigurieren Sie Docker und führen Sie Spark-Anwendungen mit Docker mithilfe von Amazon EMR 6.x aus.

• EMR unterstützt Apache Hive ACID-Transaktionen: Amazon EMR 6.1.0 bietet Unterstützung für Hive-ACID-Transaktionen, sodass es den ACID-Eigenschaften einer Datenbank entspricht. Mit diesem Feature können Sie INSERT, UPDATE, DELETE,- und MERGE-Operationen in Hive-Tabellen mit Daten in Amazon Simple Storage Service (Amazon S3) ausführen. Dies ist ein wichtiges Feature für Anwendungsfälle wie Streaming-Erfassung, Neuformulierung von Daten, Massenaktualisierungen mit MERGE und sich langsam ändernde Dimensionen. Weitere Informationen, einschließlich Konfigurationsbeispielen und Anwendungsfällen, finden Sie unter Amazon EMR unterstützt Apache-Hive-ACID-Transaktionen.

Ä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“.

• Apache Flink wird auf EMR 6.0.0 nicht unterstützt, aber es wird auf EMR 6.1.0 mit Flink 1.11.0 unterstützt. Dies ist die erste Version von Flink, die Hadoop 3 offiziell unterstützt. Siehe Ankündigung der Veröffentlichung von Apache Flink 1.11.0.

• Ganglia wurde aus den standardmäßigen EMR-6.1.0-Paketen entfernt.

Bekannte Probleme

• Niedrigeres Limit für „Max. Anzahl geöffneter Dateien“ für ältere 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

  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.

• Wenn Sie eine benutzerdefinierte Garbage-Collection-Konfiguration mit spark.driver.extraJavaOptions und spark.executor.extraJavaOptions festlegen, führt dies dazu, dass der Treiber/Executor-Start mit EMR 6.1 aufgrund einer widersprüchlichen Garbage-Collection-Konfiguration fehlschlägt. Mit EMR Version 6.1.0 sollten Sie stattdessen eine benutzerdefinierte Spark-Garbage-Collection-Konfiguration für Treiber und Executors mit den Eigenschaften spark.driver.defaultJavaOptions und spark.executor.defaultJavaOptions angeben. Weitere Informationen finden Sie unter Apache Spark Runtime Environment und Konfigurieren von Spark Garbage Collection auf Amazon EMR 6.1.0.

• Die Verwendung von Pig mit Oozie (und innerhalb von Hue, da Hue Oozie-Aktionen zur Ausführung von Pig-Skripten verwendet) generiert den Fehler, dass eine native LZO-Bibliothek nicht geladen werden kann. Diese Fehlermeldung ist informativ und verhindert nicht, dass Pig ausgeführt wird.

• Hudi-Parallelitätsunterstützung: Derzeit unterstützt Hudi keine gleichzeitigen Schreibvorgänge in eine einzelne Hudi-Tabelle. Darüber hinaus macht Hudi alle Änderungen rückgängig, die von in Bearbeitung befindlichen Autoren vorgenommen wurden, bevor ein neuer Writer beginnen kann. Gleichzeitige Schreibvorgänge können diesen Mechanismus stören und zu Wettlaufbedingungen führen, was zu Datenbeschädigungen führen kann. Sie sollten sicherstellen, dass im Rahmen Ihres Datenverarbeitungs-Workflows immer nur ein einziger Hudi-Writer mit einer Hudi-Tabelle arbeitet. Hudi unterstützt mehrere gleichzeitige Lesegeräte, die mit derselben Hudi-Tabelle arbeiten.

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

• In Amazon EMR 6.1.0 gibt es ein Problem, das Cluster betrifft, auf denen Presto ausgeführt wird. Nach einem längeren Zeitraum (Tage) kann der Cluster Fehler wie „su: failed toexecute /bin/bash: Resource temporary unavailable“ oder „Shell-Anfrage auf Kanal 0 fehlgeschlagen“ ausgeben. Dieses Problem wird durch einen internen Amazon EMR-Prozess (InstanceController) verursacht, der zu viele Light Weight Processes (LWP) erzeugt, was letztendlich dazu führt, dass der Hadoop-Benutzer sein Nproc-Limit überschreitet. Dadurch wird verhindert, dass der Benutzer zusätzliche Prozesse öffnet. Die Lösung für dieses Problem ist ein Upgrade auf EMR 6.2.0.