Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Konfigurieren von Spark

Sie können Spark in Amazon EMR mithilfe von Konfigurationsklassifizierungen konfigurieren. Weitere Informationen über Konfigurationsklassifizierungen finden Sie unter Anwendungen konfigurieren.

Zu den Konfigurationsklassifizierungen für Spark in Amazon EMR gehören die folgenden:

Durch Amazon EMR festgelegte Spark-Standardeinstellungen

Die folgende Tabelle zeigt, wie Amazon EMR Standardwerte in spark-defaults setzt, die sich auf Anwendunen auswirken.

Konfiguration der Spark-Garbage-Collection auf Amazon EMR 6.1.0

Das Einrichten von benutzerdefinierten Garbage-Collection-Konfigurationen mit spark.driver.extraJavaOptions und spark.executor.extraJavaOptions führt dazu, dass der Treiber- oder Ausführer-Start mit Amazon EMR 6.1 fehlschlägt, weil eine Konfiguration der Garbage-Collection-Konfiguration mit Amazon EMR 6.1.0 in Konflikt steht. Für Amazon EMR 6.1.0 wird die Standard-Garbage-Collection über spark.driver.defaultJavaOptions und spark.executor.defaultJavaOptions festgelegt. Diese Konfiguration gilt nur für Amazon EMR 6.1.0. JVM-Optionen, die nichts mit der Garbage-Collection zu tun haben, wie z. B. die für die Konfiguration von Protokollierung (-verbose:class), können dennoch durch extraJavaOptions festgelegt werden. Weitere Informationen finden Sie unter Spark-Anwendungs-Eigenschaften.

Verwenden von maximizeResourceAllocation

Um Ihre Executors so zu konfigurieren, dass sie auf jedem Knoten in einem Cluster die maximal möglichen Ressourcen nutzen, setzen Sie in Ihrer spark-Konfigurationsklassifizierung maximizeResourceAllocation auf true. maximizeResourceAllocation ist spezifisch für Amazon EMR. Wenn Sie maximizeResourceAllocation aktivieren, berechnet Amazon EMR die maximal verfügbaren Rechen- und Speicherressourcen für einen Executor auf einer Instance in der Core-Instance-Gruppe. Anschließend werden die entsprechenden spark-defaults-Einstellungen auf der Grundlage der berechneten Höchstwerte festgelegt.

Amazon EMR berechnet die maximalen Rechen- und Speicherressourcen, die für einen Executor verfügbar sind, basierend auf einem Instance-Typ aus der Core-Instance-Flotte. Da jede Instance-Flotte unterschiedliche Instance-Typen und Größen innerhalb einer Flotte haben kann, ist die von Amazon EMR verwendete Executor-Konfiguration möglicherweise nicht die beste für Ihre Cluster. Daher empfehlen wir nicht, die Standardeinstellungen zu verwenden, wenn Sie die maximale Ressourcenzuweisung verwenden. Konfigurieren Sie benutzerdefinierte Einstellungen für Ihre Instance-Flottencluster.

Im Folgenden finden Sie ein Beispiel für eine Spark-Konfigurationsklassifizierung mit der maximizeResourceAllocation-Einstellung auf true.

[
  {
    "Classification": "spark",
    "Properties": {
      "maximizeResourceAllocation": "true"
    }
  }
]

Verhalten der Außerbetriebnahme von Knoten konfigurieren

Bei der Verwendung von Amazon-EMR-Version 5.9.0 oder höher, enthält Spark für Amzon EMR eine Reihe von Features, um sicherzustellen, dass Spark die Knotenbeendigung infolge einer manuellen Größenänderung oder einer Anforderung einer Auto-Scaling-Richtlinie zuverlässig ausführt. Amazon EMR implementiert einen Sperr-Mechanismus in Spark, der dem Außerbetriebnahme-Mechanismus von YARN übergeordnet ist. Dieser Mechanismus hilft sicherzustellen, dass keine neuen Aufgaben in einem Knoten geplant werden, der außer Betrieb genommen wird. Gleichzeitig werden bereits begonnene Aufgaben abgeschlossen. Darüber hinaus gibt es Funktionen, mit deren Hilfe Spark-Aufgaben schneller wiederhergestellt werden, wenn Shuffle-Blöcke bei der Beendigung eines Knotens verloren gehen. Der Neuberechnungsprozess wird früher ausgelöst und ist optimiert, um eine schnellere Neuberechnung mit weniger Stufenwiederholungen zu ermöglichen. Außerdem kann vermieden werden, dass Aufträge infolge von fehlenden Shuffle-Blöcken fehlschlagen.

Spark-Umgebungsvariable ThriftServer

Spark legt die Hive-Thrift-Server-Port-Umgebungsvariable HIVE_SERVER2_THRIFT_PORT auf "10001" fest.

Ändern von Spark-Standardeinstellungen

Sie ändern die Standardwerte in spark-defaults.conf mit der Konfigurationsklassifizierungspark-defaults oder der Einstellung maximizeResourceAllocation in der Konfigurationsklassifizierung spark.

In den folgenden Verfahren wird gezeigt, wie Sie Einstellungen mithilfe der CLI oder der Konsole ändern.

Migration von Apache Log4j 1.x zu Log4j 2.x

Apache-Spark-Versionen 3.2.x und frühere Versionen verwenden den älteren Apache Log4j 1.x und die log4j.properties-Datei, um Log4j in Spark-Prozessen zu konfigurieren. Apache-Spark-Versionen 3.3.0 und höher verwenden Apache Log4j 2.x und die Datei log4j2.properties, um Log4j in Spark-Prozessen zu konfigurieren.

Wenn Sie Apache Spark Log4j mit einer Amazon-EMR-Version vor 6.8.0 konfiguriert haben, müssen Sie die alte spark-log4j-Konfigurationsklassifizierung entfernen und zur spark-log4j2-Konfigurationsklassifizierung und zum Schlüsselformat migrieren, bevor Sie auf Amazon EMR 6.8.0 oder höher aktualisieren können. Die spark-log4j-Legacy-Klassifizierung führt dazu, dass die Clustererstellung in Amazon-EMR-Versionen 6.8.0 und höher mit einem ValidationException-Fehler fehlschlägt. Ein Fehler im Zusammenhang mit der Log4j-Inkompatibilität wird Ihnen nicht in Rechnung gestellt. Sie müssen jedoch die Klassifizierung für die veraltete spark-log4j-Konfiguration entfernen, um fortzufahren.

Weitere Informationen zur Migration von Apache Log4j 1.x zu Log4j 2.x finden Sie im Apache Log4j Migration Benutzerhandbuch und im Spark Log4j 2 Template auf Github.