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

• Flink-Version 1.11.0

• Ganglia Version 3.7.2

• Hadoop-Version 3.2.1-amzn-1

• HBaseAusführung 2.2.5

• HBase-Operator-Tools 1.0.0

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

• MXNetAusführung 1.6.0

• Oozie-Version 5.2.0

• Phoenix Version 5.0.0

• Presto-Version 0.232

• Presto, Version 3.38 SQL

• 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

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

• Allzweck-Instance-Typen von M6g werden ab den EMR Amazon-Versionen 6.1.0 und 5.30.0 unterstützt. Weitere Informationen finden Sie unter Unterstützte Instance-Typen im Amazon EMR Management Guide.

• Die EC2 Platzierungsgruppenfunktion wird ab EMR Amazon-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 EMRIntegration mit EC2 Placement Group im Amazon EMR Management Guide.

• Verwaltete Skalierung — Mit EMR Amazon-Version 6.1.0 können Sie Amazon EMR Managed Scaling aktivieren, um die Anzahl der Instances oder Einheiten in Ihrem Cluster je nach Arbeitslast automatisch zu erhöhen oder zu verringern. Amazon wertet EMR kontinuierlich Cluster-Metriken aus, um Skalierungsentscheidungen zu treffen, die Ihre Cluster im Hinblick auf Kosten und Geschwindigkeit optimieren. Managed Scaling ist auch auf EMR Amazon-Version 5.30.0 und höher verfügbar, außer 6.0.0. Weitere Informationen finden Sie unter Scaling Cluster Resources im Amazon EMR Management Guide.

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

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

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

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

  • Presto SQL wird sowohl auf Single-Master- als auch auf Multi-Master-Clustern unterstützt. Auf Multi-Master-Clustern ist ein externer Hive-Metastore erforderlich, um Presto oder SQL PrestoDB auszuführen. Siehe Unterstützte Anwendungen in einem EMR Cluster mit mehreren Primärknoten.

• ECRUnterstützung der auto Authentifizierung auf Apache Hadoop und Apache Spark mit Docker: Spark-Benutzer können Docker-Images von Docker Hub und Amazon Elastic Container Registry (AmazonECR) 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.

• EMRunterstützt Apache ACID Hive-Transaktionen: Amazon EMR 6.1.0 bietet Unterstützung für ACID Hive-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 eine wichtige Funktion für Anwendungsfälle wie Streaming-Erfassung, Neuformulierung von Daten, Verwendung MERGE von Massenaktualisierungen und langsam ändernde Dimensionen. Weitere Informationen, einschließlich Konfigurationsbeispielen und Anwendungsfällen, finden Sie unter Amazon EMR unterstützt Apache ACID Hive-Transaktionen.

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

• Apache Flink wird auf 6.0.0 nicht unterstützt, aber es wird auf 6.1.0 mit Flink 1.11.0 unterstützt. EMR EMR 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 Standard-6.1.0-Paketpaketen entfernt. EMR

Bekannte Probleme

• 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

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

• 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 to execute /bin/bash: Resource temporarily unavailable“ oder „Shell-Anfrage auf Kanal 0 fehlgeschlagen“ ausgeben. Dieses Problem wird durch einen internen EMR Amazon-Prozess (InstanceController) verursacht, der zu viele Light-Weight-Prozesse (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 6.2.0. EMR