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 auf Amazon EMR mit Konfigurationsklassifizierungen konfigurieren. Weitere Informationen über Konfigurationsklassifizierungen finden Sie unter Anwendungen konfigurieren.

Zu den Konfigurationsklassifizierungen für Spark bei Amazon EMR gehören:

Von Amazon festgelegte Spark-Standardeinstellungen EMR

Die folgende Tabelle zeigt, wie Amazon Standardwerte EMR festlegtspark-defaults, die sich auf Anwendungen 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 Executor-Start mit Amazon EMR 6.1 fehlschlägt, weil eine Konfiguration der Garbage-Collection-Konfiguration mit Amazon 6.1.0 in Konflikt steht. EMR Für Amazon EMR 6.1.0 wird die Standardkonfiguration für die Garbage-Collection über spark.driver.defaultJavaOptions und spark.executor.defaultJavaOptions festgelegt. Diese Konfiguration gilt nur für Amazon EMR 6.1.0. JVMOptionen, die nichts mit der Garbage-Collection zu tun haben, wie z. B. die für die Konfiguration von logging (-verbose:class), können trotzdem verwendet werden. extraJavaOptions 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. Das maximizeResourceAllocation ist spezifisch für AmazonEMR. Wenn Sie diese Option aktivierenmaximizeResourceAllocation, EMR berechnet Amazon die maximalen Rechen- und Speicherressourcen, die für einen Executor auf einer Instance in der Core-Instance-Gruppe verfügbar sind. 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

Mit der EMR Amazon-Version 5.9.0 und höher EMR enthält Spark on Amazon eine Reihe von Funktionen, die sicherstellen, dass Spark die Knotenbeendigung aufgrund einer manuellen Größenänderung oder einer automatischen Skalierungsrichtlinienanforderung ordnungsgemäß verarbeitet. Amazon EMR implementiert in Spark einen Deny-Listing-Mechanismus, der auf dem Mechanismus YARN zur Außerbetriebnahme aufbaut. 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.

ThriftServer Spark-Umgebungsvariable

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.

Die folgenden Verfahren zeigen, wie Sie Einstellungen mit der CLI OR-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 EMR Amazon-Version vor 6.8.0 konfiguriert haben, müssen Sie die alte spark-log4j Konfigurationsklassifizierung entfernen und zur Konfigurationsklassifizierung und zum Schlüsselformat migrieren, bevor Sie ein Upgrade auf Amazon EMR 6.8.0 oder höher durchführen können. spark-log4j2 Die spark-log4j Legacy-Klassifizierung führt dazu, dass die Clustererstellung in EMR Amazon-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.