EMRAmazon-Version 5.30.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

Upgrades

• Auf Version AWS SDK for Java 1.11.759 aktualisiert

• Amazon SageMaker Spark wurde SDK auf Version 1.3.0 aktualisiert

• EMRRecord Server wurde auf Version 1.6.0 aktualisiert

• Flink auf Version 1.10.0 aktualisiert

• Ganglia auf Version 3.7.2 aktualisiert

• Auf Version HBase 1.4.13 aktualisiert

• Hudi auf Version 0.5.2-incubating aktualisiert

• Hue auf Version 4.6.0 aktualisiert

• Auf Version JupyterHub 1.1.0 aktualisiert

• Livy auf Version 0.7.0-incubating aktualisiert

• Oozie auf Version 5.2.0 aktualisiert

• Presto auf Version 0.232 aktualisiert

• Spark auf Version 2.4.5 aktualisiert

• Aktualisierte Konnektoren und Treiber: Amazon Glue Connector 1.12.0; Amazon Kinesis Connector 3.5.0; DynamoDB Connector 4.14.0 EMR

Neue Features

• EMRNotebooks — Bei Verwendung mit EMR Clustern, die mit 5.30.0 erstellt wurden, werden Notebook-Kernel auf dem Cluster ausgeführt. EMR Dies verbessert die Notebook-Leistung und ermöglicht es Ihnen, Kernel zu installieren und anzupassen. Sie können Python-Bibliotheken auch auf dem Cluster-Primärknoten installieren. Weitere Informationen finden Sie unter Installation und Verwendung von Kernels and Libraries im Management Guide. EMR

• Verwaltete Skalierung — Mit EMR Amazon-Version 5.30.0 und höher können Sie 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. Weitere Informationen finden Sie unter Scaling Cluster Resources im Amazon EMR Management Guide.

• In Amazon S3 gespeicherte Protokolldateien verschlüsseln — Mit Amazon EMR Version 5.30.0 und höher können Sie in Amazon S3 gespeicherte Protokolldateien mit einem AWS KMS vom Kunden verwalteten Schlüssel verschlüsseln. Weitere Informationen finden Sie unter Verschlüsseln von in Amazon S3 gespeicherten Protokolldateien im Amazon EMR Management Guide.

• Amazon Linux 2-Unterstützung — In EMR Version 5.30.0 und höher, EMR usesAmazon Linux 2-Betriebssystem. Das neue benutzerdefinierte AMIs (Amazon Machine Image) muss auf theAmazon Linux 2 basierenAMI. Weitere Informationen finden Sie unter Benutzerdefiniert verwenden AMI.

• Presto Graceful Auto Scale — Für EMR Cluster, die 5.30.0 verwenden, kann ein Timeout für die automatische Skalierung festgelegt werden, sodass Presto-Aufgaben Zeit haben, ihre Ausführung zu beenden, bevor ihr Knoten außer Betrieb genommen wird. Weitere Informationen finden Sie unter Auto Scaling von Presto mit ordnungsgemäßer Stilllegung verwenden.

• Erstellung einer Flotteninstanz mit neuer Zuweisungsstrategieoption — Eine neue Zuweisungsstrategieoption ist in Version 5.12.1 und höher verfügbar. EMR Sie bietet eine schnellere Cluster-Bereitstellung, eine genauere Spot-Zuweisung und weniger Unterbrechungen von Spot Instances. Aktualisierungen für nicht standardmäßige EMR Servicerollen sind erforderlich. Sehen Sie unter Konfigurieren von Instance-Flotten.

• Befehle sudo systemctl stop und sudo systemctl start — In EMR Version 5.30.0 und höher, die das Betriebssystem useAmazon Linux 2 verwendet, und Befehle, um Dienste neu zu starten. EMR sudo systemctl stop sudo systemctl start Weitere Informationen finden Sie unter Wie starte ich einen Service bei Amazon neuEMR? .

Änderungen, Verbesserungen und behobene Probleme

• EMRVersion 5.30.0 installiert Ganglia nicht standardmäßig. Sie können Ganglia explizit für die Installation auswählen, wenn Sie einen Cluster erstellen.

• Spark-Leistungsoptimierungen.

• Presto-Leistungsoptimierungen.

• Python 3 ist der Standard für EMR Amazon-Version 5.30.0 und höher.

• Die standardmäßige verwaltete Sicherheitsgruppe für den Zugriff auf Services in privaten Subnetzen wurde mit neuen Regeln aktualisiert. Wenn Sie benutzerdefinierte Sicherheitsgruppe für den Servicezugriff verwenden, müssen Sie dieselben Regeln wie die standardmäßige verwaltete Sicherheitsgruppe einschließen. Weitere Informationen finden Sie unter Amazon EMR -Managed Security Group for Service Access (Private Subnets). Wenn Sie eine benutzerdefinierte Servicerolle für Amazon verwendenEMR, müssen Sie die entsprechenden Berechtigungen erteilen, ec2:describeSecurityGroups damit überprüft werden EMR kann, ob die Sicherheitsgruppen korrekt erstellt wurden. Wenn Sie EMR_DefaultRole verwenden, ist diese Berechtigung bereits in der standardmäßigen verwalteten Richtlinie enthalten.

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

• 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 EMR Amazon-Versionen 5.30.0 und 5.30.1 erstellen, auch wenn Ihr Job 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 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.

• Die Standard-Datenbank-Engine für Hue 4.6.0 istSQLite, was zu Problemen führt, wenn Sie versuchen, Hue mit einer externen Datenbank zu verwenden. Um dieses Problem zu beheben, setzen Sie engine in Ihrer hue-ini Konfigurationsklassifizierung auf mysql. Dieses Problem wurde in EMR Amazon-Version 5.30.1 behoben.

• 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 Ihr Cluster daran hindert, Daten korrekt zu lesen. 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.