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](https://aws.amazon.com/elasticmapreduce/details/spark/) mithilfe von Konfigurationsklassifizierungen konfigurieren. Weitere Informationen über Konfigurationsklassifizierungen finden Sie unter [Anwendungen konfigurieren](emr-configure-apps.md).
Zu den Konfigurationsklassifizierungen für Spark in Amazon EMR gehören die folgenden:
+ **`spark`** – Setzt die `maximizeResourceAllocation`-Eigenschaft auf „wahr“ oder „falsch“. Wenn „wahr“, konfiguriert Amazon EMR die `spark-defaults`-Eigenschaften automatisch auf der Grundlage der Cluster-Hardwarekonfiguration. Weitere Informationen finden Sie unter [Verwenden von `maximizeResourceAllocation`](#emr-spark-maximizeresourceallocation).
+ **`spark-defaults`** – Setzt Werte in der `spark-defaults.conf`-Datei. Weitere Informationen finden Sie unter [Spark-Konfiguration](https://spark.apache.org/docs/latest/configuration.html) in der Spark-Dokumentation.
+ **`spark-env`** – Setzt Werte in der `spark-env.sh`-Datei. Weiter Informationen finden Sie unter [Umgebungsvariablen](https://spark.apache.org/docs/latest/configuration.html#environment-variables) in der Spark-Dokumentation.
+ **`spark-hive-site`** – Legt Werte in der `hive-site.xml` für Spark fest.
+ **`spark-log4j`** – (Amazon-EMR-Versionen 6.7.x und niedriger) Legt Werte in der `log4j.properties`-Datei fest. Weitere Informationen finden Sie in der [log4j.properties.template](https://github.com/apache/spark/blob/branch-3.2/conf/log4j.properties.template)-Datei auf Github.
+ **`spark-log4j2`** – (Amazon-EMR-Version 6.8.0 und höher) Legt Werte in der `log4j2.properties`-Datei fest. Weitere Informationen finden Sie in der [log4j2.properties.template](https://github.com/apache/spark/blob/v3.3.0/conf/log4j2.properties.template)-Datei auf Github.
+ **`spark-metrics`** – Setzt Werte in der `metrics.properties`-Datei. Einstellungen und weitere Informationen finden Sie in der [metrics.properties.template](https://github.com/apache/spark/blob/master/conf/metrics.properties.template)-Datei auf GitHub und unter [Metrics](https://spark.apache.org/docs/latest/monitoring.html#metrics) in der Spark-Dokumentation.
**Anmerkung**
Wenn Sie Spark-Workloads von einer anderen Plattform zu Amazon EMR migrieren, empfehlen wir Ihnen, Ihre Workloads mit den [Durch Amazon EMR festgelegte Spark-Standardeinstellungen](#spark-defaults) zu testen, bevor Sie benutzerdefinierte Konfigurationen hinzufügen. Die meisten Kunden sehen mit unseren Standardeinstellungen eine verbesserte Leistung.
**Topics**
+ [Durch Amazon EMR festgelegte Spark-Standardeinstellungen](#spark-defaults)
+ [Konfiguration der Spark-Garbage-Collection auf Amazon EMR 6.1.0](#spark-gc-config)
+ [Verwenden von `maximizeResourceAllocation`](#emr-spark-maximizeresourceallocation)
+ [Verhalten der Außerbetriebnahme von Knoten konfigurieren](#spark-decommissioning)
+ [ThriftServer Spark-Umgebungsvariable](#spark-thriftserver)
+ [Ändern von Spark-Standardeinstellungen](#spark-change-defaults)
+ [Migration von Apache Log4j 1.x zu Log4j 2.x](#spark-migrate-logj42)
## Durch Amazon EMR festgelegte Spark-Standardeinstellungen
Die folgende Tabelle zeigt, wie Amazon EMR Standardwerte in `spark-defaults` setzt, die sich auf Anwendunen auswirken.
**Durch Amazon EMR festgelegte Spark-Standardeinstellungen**
| Einstellung | Description | Standardwert |
| --- | --- | --- |
| spark.executor.memory | Die pro Executor-Prozess zu verwendende Größe des Speichers. Zum Beispiel: `1g`, `2g`. | Diese Einstellung wird durch die Core- und Aufgaben-Instance-Typen im Cluster bestimmt. |
| spark.executor.cores | Die für jeden Executor zu verwendende Anzahl der Kerne. | Diese Einstellung wird durch die Core- und Aufgaben-Instance-Typen im Cluster bestimmt. |
| spark.dynamicAllocation.enabled | Wenn „wahr“, verwenden Sie die dynamische Ressourcenzuteilung, um die Anzahl der bei einer Anwendung registrierten Executoren basierend auf dem Workload nach oben oder unten zu skalieren. | `true` (mit Amazon EMR 4.4.0 und höher) Spark Shuffle Service wird automatisch von Amazon EMR konfiguriert. |
| spark.sql.hive.advancedPartitionPredicatePushdown.enabled | Wenn der Wert „wahr“ ist, ist der erweiterte Pushdown von Partitionsprädikaten in den Hive-Metastore aktiviert. | true |
| spark.sql.hive.stringLikePartitionPredicatePushdown.enabled | Verschiebt und filtert `startsWith`, `contains` und `endsWith` nach unten in den Hive-Metastore. Glue unterstützt das Prädikat-Pushdown für `startsWith`, `contains` oder `endsWith` nicht. Wenn Sie Glue Metastore verwenden und aufgrund des Prädikat-Pushdowns für diese Funktionen auf Fehler stoßen, setzen Sie diese Konfiguration auf `false`. | true |
## 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.](https://spark.apache.org/docs/latest/configuration.html#application-properties)
## 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.
**Anmerkung**
Sie sollten die `maximizeResourceAllocation` Option nicht für Cluster mit anderen verteilten Anwendungen wie verwenden HBase. Amazon EMR verwendet benutzerdefinierte YARN-Konfigurationen für verteilte Anwendungen, die zu Konflikten mit `maximizeResourceAllocation` führen und zum Scheitern von Spark-Anwendungen führen können.
Im Folgenden finden Sie ein Beispiel für eine Spark-Konfigurationsklassifizierung mit der `maximizeResourceAllocation`-Einstellung auf `true`.
```
[
{
"Classification": "spark",
"Properties": {
"maximizeResourceAllocation": "true"
}
}
]
```
**Einstellungen, die in `spark-defaults` konfiguriert sind, wenn `maximizeResourceAllocation` aktiviert ist**
| Einstellung | Description | Wert |
| --- | --- | --- |
| spark.default.parallelism | Die Standardanzahl von Partitionen wird von Transformationen wie Join, und Parallelize RDDs zurückgegeben reduceByKey, wenn sie nicht vom Benutzer festgelegt wurden. | Die zweifache Anzahl von CPU-Kernen für YARN-Container. |
| spark.driver.memory | Speichermenge, die für den Treiberprozess verwendet werden soll, d. h. wo SparkContext er initialisiert wird. (zum Beispiel 1 g, 2 g). | Die Einstellung wird auf der Grundlage der Instance-Typen im Cluster konfiguriert. Da die Spark-Treiberanwendung jedoch entweder in der Primär-Instance oder in einer der Core-Instances ausgeführt werden kann (z. B. im YARN-Client- und -Cluster-Modus), wird sie auf der Grundlage des kleineren Instance-Typs in diesen beiden Instance-Gruppen festgelegt. |
| spark.executor.memory | Die pro Executor-Prozess zu verwendende Größe des Speichers (beispielsweise 1g, 2g). | Die Einstellung wird auf der Grundlage der Core- und der Aufgaben-Instance-Typen im Cluster konfiguriert. |
| spark.executor.cores | Die für jeden Executor zu verwendende Anzahl der Kerne. | Die Einstellung wird auf der Grundlage der Core- und der Aufgaben-Instance-Typen im Cluster konfiguriert. |
| spark.executor.instances | Die Anzahl der Executor. | Die Einstellung wird auf der Grundlage der Core- und der Aufgaben-Instance-Typen im Cluster konfiguriert. Festgelegt, wenn `spark.dynamicAllocation.enabled` nicht gleichzeitig explizit auf "true" festgelegt wurde. |
## 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.
**Wichtig**
Die Einstellung `spark.decommissioning.timeout.threshold` wurde in Amazon-EMR-Version 5.11.0 hinzugefügt, um die Ausfallsicherheit von Spark zu verbessern, wenn Sie Spot Instances verwenden. Wenn in früheren Versionen ein Knoten eine Spot Instance verwendet und die Instance aufgrund des Bid-Preises beendet wird, kann Spark die Beendigung möglicherweise nicht zuverlässig abschliessen. Aufträge können fehlschlagen und Shuffle-Neuberechnungen können eine geraume Zeit in Anspruch nehmen. Aus diesem Grund empfehlen wir die Nutzung von Version 5.11.0 oder höher, wenn Sie Spot Instances verwenden.
**Einstellungen für die Außerbetriebnahme von Spark Node**
| Einstellung | Description | Standardwert |
| --- | --- | --- |
| `spark.blacklist.decommissioning.enabled` | Wenn die Einstellung auf `true` gesetzt ist, sperrt Spark die Knoten, die sich in YARN im `decommissioning`-Zustand befinden. Spark plant keine neuen Aufgaben auf Executors aus, die auf dem betreffenden Knoten ausgeführt werden. Bereits begonnene Aufgaben werden abgeschlossen. | `true` |
| `spark.blacklist.decommissioning.timeout` | Die Zeitspanne, wie lange ein Knoten im Status `decommissioning` gesperrt wird. Standardmäßig ist dieser Wert auf eine Stunde festgelegt. Dies ist auch die Standardeinstellung für `yarn.resourcemanager.decommissioning.timeout`. Um sicherzustellen, dass ein Knoten über den gesamten Außerbetriebnahme-Zeitraum gesperrt wird, setzen Sie diesen Wert größer oder gleich `yarn.resourcemanager.decommissioning.timeout`. Nachdem die Frist für die Außerbetriebnahme abgelaufen ist, wird der Knoten in den Zustand `decommissioned` überführt, und Amazon EMR kann die EC2-Instance des Knotens beenden. Wenn noch Aufgaben ausgeführt werden, nachdem die Zeitbeschränkung abgelaufen ist, gehen diese verloren oder werden abgebrochen und auf Executors, die auf anderen Knoten ausgeführt werden, verschoben. | `1h` |
| `spark.decommissioning.timeout.threshold` | Verfügbar in Amazon-EMR-Version 5.11.0 oder höher. In Sekunden angegeben. Wenn ein Knoten in den Status „Außerbetriebnahme“ übergeht und der Host ihn innerhalb der durch diesen Wert festgelegten Frist außer Betrieb nimmt, sperrt Amazon EMR den Knoten nicht nur, sondern bereinigt auch den Host-Status (wie in `spark.resourceManager.cleanupExpiredHost` angegeben), ohne darauf zu warten, dass der Knoten in den Status „Außerbetriebnahme“ übergeht. Auf diese Weise kann Spark das Beenden von Spot-Instances besser verarbeiten, weil Spot-Instances innerhalb eines Timeouts von 20 Sekunden außer Betrieb genommen werden, unabhängig von dem Wert von `yarn.resourcemager.decommissioning.timeout`, sodass andere Knoten möglicherweise nicht genügend Zeit haben, Shuffle-Dateien zu lesen. | `20s` |
| `spark.resourceManager.cleanupExpiredHost` | Wenn die Einstellung auf `true` gesetzt ist, löscht Spark alle zwischengespeicherten Daten und Shuffle-Blöcke, die in Executors in Knoten gespeichert sind, die sich im Zustand `decommissioned` befinden. Dadurch wird der Wiederherstellungsprozess beschleunigt. | `true` |
| `spark.stage.attempt.ignoreOnDecommissionFetchFailure` | Wenn die Einstellung auf `true` gesetzt ist, wird verhindert, dass in Spark Stufen und letztendlich Aufträge wegen zu vieler Abrufe von außer Betrieb genommenen Knoten fehlschlagen. Fehler beim Abrufen von Shuffle-Blöcken von einem Knoten im Zustand `decommissioned` werden nicht zu der maximal zulässigen Anzahl von aufeinander folgenden Abruffehlern hinzugezählt. | true |
## 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 Konfigurationsklassifizierung`spark-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.
**Erstellen Sie einen Cluster mithilfe der CLI mit der Einstellung „spark.executor.memory“ auf „2G“ wie folgt**
+ Erstellen Sie einen Cluster mit installiertem Spark und `spark.executor.memory` auf 2G gesetzt, indem Sie den folgenden Befehl eingeben, der auf die Datei `myConfig.json` verweist, die in Amazon S3 gespeichert ist.
```
aws emr create-cluster --release-label emr-7.12.0 --applications Name=Spark \
--instance-type m5.xlarge --instance-count 2 --service-role EMR_DefaultRole_V2 --ec2-attributes InstanceProfile=EMR_EC2_DefaultRole --configurations https://s3.amazonaws.com/amzn-s3-demo-bucket/myfolder/myConfig.json
```
**Anmerkung**
Linux-Zeilenfortsetzungszeichen (\$1) sind aus Gründen der Lesbarkeit enthalten. Sie können entfernt oder in Linux-Befehlen verwendet werden. Entfernen Sie sie unter Windows oder ersetzen Sie sie durch ein Caret-Zeichen (^).
`myConfig.json`:
```
[
{
"Classification": "spark-defaults",
"Properties": {
"spark.executor.memory": "2G"
}
}
]
```
**Erstellen Sie einen Clustermithilfe der Konsole mit der Einstellung „spark.executor.memory“ auf „2G“ wie folgt**
1. Navigieren Sie zur neuen Amazon-EMR-Konsole und wählen Sie in der Seitennavigation die Option **Zur alten Konsole wechseln** aus. Weitere Informationen darüber, was Sie erwartet, wenn Sie zur alten Konsole wechseln, finden Sie unter [Verwenden der alten Konsole](https://docs.aws.amazon.com/emr/latest/ManagementGuide/whats-new-in-console.html#console-opt-in).
1. Wählen Sie **Create Cluster (Cluster erstellen)** und **Go to advanced options (Zu erweiterten Optionen)** aus.
1. Wählen Sie **Spark** aus.
1. Lassen Sie unter **Edit software settings (Softwareeinstellungen bearbeiten)** die Option **Enter configuration (Konfiguration eingeben)** ausgewählt und nehmen Sie folgende Konfiguration vor:
```
classification=spark-defaults,properties=[spark.executor.memory=2G]
```
1. Wählen Sie andere Optionen aus, dann **** und anschließend **Create cluster (Cluster erstellen)**.
**Zum Einstellen maximizeResourceAllocation**
+ Erstellen Sie einen Cluster, auf dem Spark installiert und auf true `maximizeResourceAllocation` gesetzt ist AWS CLI, indem Sie die in Amazon S3 gespeicherte Datei referenzieren. `myConfig.json`
```
aws emr create-cluster --release-label emr-7.12.0 --applications Name=Spark \
--instance-type m5.xlarge --instance-count 2 --service-role EMR_DefaultRole_V2 --ec2-attributes InstanceProfile=EMR_EC2_DefaultRole --configurations https://s3.amazonaws.com/amzn-s3-demo-bucket/myfolder/myConfig.json
```
**Anmerkung**
Linux-Zeilenfortsetzungszeichen (\$1) sind aus Gründen der Lesbarkeit enthalten. Sie können entfernt oder in Linux-Befehlen verwendet werden. Entfernen Sie sie unter Windows oder ersetzen Sie sie durch ein Caret-Zeichen (^).
`myConfig.json`:
```
[
{
"Classification": "spark",
"Properties": {
"maximizeResourceAllocation": "true"
}
}
]
```
**Anmerkung**
Ab Amazon-EMR-Version 5.21.0 können Sie Cluster-Konfigurationen überschreiben und zusätzliche Konfigurationsklassifikationen für jede Instance-Gruppe in einem ausgeführten Cluster angeben. Dazu verwenden Sie die Amazon EMR-Konsole, das AWS Command Line Interface (AWS CLI) oder das AWS SDK. Weitere Informationen finden Sie unter [Angeben einer Konfiguration für eine Instance-Gruppe in einem aktiven Cluster](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps-running-cluster.html).
## Migration von Apache Log4j 1.x zu Log4j 2.x
[Apache-Spark-Versionen](https://aws.amazon.com/emr/features/spark/) 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](https://logging.apache.org/log4j/2.x/manual/migration.html) und im [Spark Log4j 2 Template](https://github.com/apache/spark/blob/master/conf/log4j2.properties.template) auf Github.
**Anmerkung**
Bei Amazon EMR verwendet Apache Spark eine `log4j2.properties`-Datei anstelle der im [Apache-Log4j-Migration-Benutzerhandbuch](https://logging.apache.org/log4j/2.x/manual/migration.html) beschriebenen .xml-Datei. Außerdem empfehlen wir nicht, die Log4j-1.x-Bridge-Methode für die Konvertierung nach Log4j 2.x zu verwenden.