Amazon-EMR-Version 5.30.1

• 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

Änderungen, Verbesserungen und behobene Probleme

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

• Es wurde ein Problem behoben, bei dem der Instance-Controller-Prozess unendlich viele Prozesse ausgelöst hat.

• Es wurde ein Problem behoben, bei dem Hue keine Hive-Abfrage ausführen konnte, die Meldung „Datenbank ist gesperrt“ angezeigt wurde und die Ausführung von Abfragen verhindert wurde.

• Es wurde ein Spark-Problem behoben, durch das mehr Aufgaben gleichzeitig auf dem EMR-Cluster ausgeführt werden konnten.

• Es wurde ein Problem mit dem Jupyter Notebook behoben, das den Fehler „Zu viele Dateien öffnen“ auf dem Jupyter-Server verursachte.

• Ein Problem mit den Startzeiten von Clustern wurde behoben.

Neue Features

• Persistente Anwendungsschnittstellen für die Tez-Benutzeroberfläche und den YARN-Timeline-Server sind mit den Amazon-EMR-Versionen 6.x und EMR-Version 5.30.1 und höher verfügbar. Durch den Linkzugriff mit einem Klick auf den persistenten Anwendungsverlauf können Sie schnell auf den Jobverlauf zugreifen, ohne einen Webproxy über eine SSH-Verbindung einrichten zu müssen. Protokolle für aktive und beendete Cluster sind 30 Tage nach Ende der Anwendung verfügbar. Weitere Informationen finden Sie unter Ansicht der Benutzeroberflächen für persistente Anwendungen im Verwaltungshandbuch für Amazon EMR an.

• EMR Notebook Execution APIs ist verfügbar, um EMR-Notebooks über ein Skript oder eine Befehlszeile auszuführen. Durch die Möglichkeit, EMR-Notebookausführungen ohne die AWS Konsole zu starten, zu stoppen, aufzulisten und zu beschreiben, können Sie ein EMR-Notebook programmgesteuert steuern. Mithilfe einer parametrisierten Notebook-Zelle können Sie verschiedene Parameterwerte an ein Notebook übergeben, ohne für jeden neuen Satz von Parameterwerten eine Kopie des Notebooks erstellen zu müssen. Siehe EMR-API-Aktionen. Beispielcode finden Sie unter Beispielbefehle zur programmatischen Ausführung von EMR Notebooks.

Bekannte Probleme

• Niedrigerer Grenzwert 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

• EMR Notebooks

  Das Feature, mit der Sie Kernel und zusätzliche Python-Bibliotheken auf dem Cluster-Primärknoten installieren können, ist in EMR-Version 5.30.1 standardmäßig deaktiviert. Weitere Informationen zu diesem Feature finden Sie unter Installation von Kernels und Python-Bibliotheken auf einem Cluster-Primärknoten.

  Um das Feature zu aktivieren, gehen Sie wie folgt vor:

  1. Stellen Sie sicher, dass die der Servicerolle für EMR Notebooks zugeordnete Berechtigungsrichtlinie die folgende Aktion zulässt:

     elasticmapreduce:ListSteps

     Weitere Informationen finden Sie unter Servicerolle für EMR-Notebooks.

  2. Verwenden Sie den AWS CLI , um einen Schritt auf dem Cluster auszuführen, der EMR Notebooks einrichtet, wie im folgenden Beispiel gezeigt. us-east-1Ersetzen Sie durch die Region, in der sich Ihr Cluster befindet. Weitere Informationen finden Sie unter Hinzufügen von Schritten zu einem Cluster mithilfe AWS CLI.

     aws emr add-steps  --cluster-id MyClusterID --steps Type=CUSTOM_JAR,Name=EMRNotebooksSetup,ActionOnFailure=CONTINUE,Jar=s3://us-east-1.elasticmapreduce/libs/script-runner/script-runner.jar,Args=["s3://awssupportdatasvcs.com/bootstrap-actions/EMRNotebooksSetup/emr-notebooks-setup.sh"]
                             

• Verwaltete Skalierung

  Verwaltete Skalierungsvorgänge auf Clustern der Versionen 5.30.0 und 5.30.1, ohne dass Presto installiert ist, können zu Anwendungsausfällen führen oder dazu führen, dass eine einheitliche Instance-Gruppe oder Instance-Flotte unverändert im Status ARRESTED bleibt, insbesondere wenn auf einen Herunterskalierungsvorgang schnell ein Skalierungsvorgang folgt.

  Um dieses Problem zu umgehen, wählen Sie Presto als zu installierende Anwendung, wenn Sie einen Cluster mit den Amazon-EMR-Versionen 5.30.0 und 5.30.1 erstellen, auch wenn Ihr Auftrag Presto nicht benötigt.

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