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. # Konfiguration einer Anwendung bei der Arbeit mit EMR Serverless Konfigurieren Sie mit EMR Serverless die Anwendungen, die Sie verwenden. Legen Sie beispielsweise die maximale Kapazität fest, auf die eine Anwendung skaliert werden kann, konfigurieren Sie vorinitialisierte Kapazität, um Fahrer und Mitarbeiter einsatzbereit zu halten, und legen Sie gemeinsame Laufzeit- und Überwachungskonfigurationen auf Anwendungsebene fest. Auf den folgenden Seiten wird beschrieben, wie Sie Anwendungen konfigurieren, wenn Sie EMR Serverless verwenden. **Topics** + [Grundlegendes zum Anwendungsverhalten in EMR Serverless](app-behavior.md) + [Vorinitialisierte Kapazität für die Arbeit mit einer Anwendung in EMR Serverless](pre-init-capacity.md) + [Standardanwendungskonfiguration für EMR Serverless](default-configs.md) # Grundlegendes zum Anwendungsverhalten in EMR Serverless In diesem Abschnitt werden das Verhalten bei der Auftragsübermittlung, die Kapazitätskonfiguration für die Skalierung und die Worker-Konfigurationseinstellungen für EMR Serverless beschrieben. ## Standardverhalten von Anwendungen **Autostart** — Eine Anwendung ist standardmäßig so konfiguriert, dass sie bei der Auftragserteilung automatisch gestartet wird. Sie können diese Funktion ausschalten. **Auto-Stop** — Eine Anwendung ist standardmäßig so konfiguriert, dass sie automatisch stoppt, wenn sie 15 Minuten lang inaktiv ist. Wenn eine Anwendung in den `STOPPED` Status wechselt, gibt sie alle konfigurierten vorinitialisierten Kapazitäten frei. Sie können die Dauer der Leerlaufzeit ändern, bevor eine Anwendung automatisch beendet wird, oder Sie können diese Funktion deaktivieren. ## Maximale Kapazität Sie können die maximale Kapazität konfigurieren, auf die eine Anwendung skaliert werden kann. Sie können Ihre maximale Kapazität in Bezug auf CPU, Arbeitsspeicher (GB) und Festplatte (GB) angeben. **Anmerkung** Es empfiehlt sich, Ihre maximale Kapazität so zu konfigurieren, dass sie proportional zu Ihrer unterstützten Mitarbeitergröße ist, indem Sie die Anzahl der Mitarbeiter mit ihrer Größe multiplizieren. Wenn Sie Ihre Anwendung beispielsweise auf 50 Worker mit 2 VCPUs, 16 GB Arbeitsspeicher und 20 GB Festplatte beschränken möchten, legen Sie Ihre maximale Kapazität auf 100 VCPUs, 800 GB für Arbeitsspeicher und 1000 GB für Festplatte fest. ## Unterstützte Worker-Konfigurationen In der folgenden Tabelle sind die unterstützten Worker-Konfigurationen und -Größen aufgeführt, die für EMR Serverless angegeben werden können. Konfigurieren Sie je nach den Anforderungen Ihrer Arbeitslast unterschiedliche Größen für Treiber und Executoren. **Konfigurationen und Größen von Workern** | CPU | Arbeitsspeicher | Temporärer Standardspeicher | | --- | --- | --- | | 1 vCPU | Mindestens 2 GB, maximal 8 GB, in Schritten von 1 GB | 20 GB — 200 GB | | 2 vCPU | Mindestens 4 GB, maximal 16 GB, in Schritten von 1 GB | 20 GB — 200 GB | | 4 vCPU | Mindestens 8 GB, maximal 30 GB, in Schritten von 1 GB | 20 GB — 200 GB | | 8 vCPU | Mindestens 16 GB, maximal 60 GB, in Schritten von 4 GB | 20 GB — 200 GB | | 16 vCPU | Mindestens 32 GB, maximal 120 GB, in Schritten von 8 GB | 20 GB — 200 GB | **CPU** — Jeder Worker kann 1, 2, 4, 8 oder 16 V habenCPUs. **Arbeitsspeicher** — Jeder Worker verfügt über Arbeitsspeicher, der in GB angegeben wird und innerhalb der in der vorherigen Tabelle aufgeführten Grenzwerte liegt. Spark-Jobs haben einen Speicheraufwand, was bedeutet, dass der Speicherplatz, den sie verwenden, die angegebenen Containergrößen übersteigt. Dieser Overhead wird mit den Eigenschaften `spark.driver.memoryOverhead` und angegeben`spark.executor.memoryOverhead`. Der Overhead hat einen Standardwert von 10% des Container-Speichers mit einem Minimum von 384 MB. Sie sollten diesen Mehraufwand berücksichtigen, wenn Sie die Größe der Mitarbeiter wählen. Wenn Sie beispielsweise 4 V CPUs für Ihre Worker-Instance und eine vorinitialisierte Speicherkapazität von 30 GB wählen, legen Sie einen Wert von etwa 27 GB als Executor-Speicher für Ihren Spark-Job fest. Dadurch wird die Nutzung Ihrer vorinitialisierten Kapazität maximiert. Der nutzbare Arbeitsspeicher beträgt 27 GB plus 10% von 27 GB (2,7 GB), also insgesamt 29,7 GB. **Festplatte** — Sie können jeden Worker mit temporären Speicherfestplatten mit einer Mindestgröße von 20 GB und einer Höchstgröße von 200 GB konfigurieren. Sie zahlen nur für zusätzlichen Speicherplatz über 20 GB, den Sie pro Mitarbeiter konfigurieren. # Vorinitialisierte Kapazität für die Arbeit mit einer Anwendung in EMR Serverless EMR Serverless bietet eine optionale Funktion, mit der Fahrer und Mitarbeiter vorinitialisiert sind und innerhalb von Sekunden einsatzbereit sind. Dadurch wird effektiv ein warmer Pool von Mitarbeitern für eine Anwendung geschaffen. Diese Funktion wird als *vorinitialisierte Kapazität* bezeichnet. Um diese Funktion zu konfigurieren, setzen Sie den `initialCapacity` Parameter einer Anwendung auf die Anzahl der Worker, die Sie vorab initialisieren möchten. Bei vorinitialisierter Arbeitskapazität werden Jobs sofort gestartet. Dies ist ideal, wenn Sie iterative Anwendungen und zeitkritische Jobs implementieren möchten. Durch die vorinitialisierte Kapazität steht ein warmer Pool von Mitarbeitern bereit, sodass Jobs und Sitzungen innerhalb von Sekunden gestartet werden können. Sie zahlen für bereitgestellte vorinitialisierte Worker auch dann, wenn sich die Anwendung im Leerlauf befindet. Wir empfehlen daher, sie für Anwendungsfälle zu aktivieren, die von der schnellen Startzeit profitieren, und sie so zu dimensionieren, dass die Ressourcen optimal genutzt werden. Serverlose EMR-Anwendungen werden automatisch heruntergefahren, wenn sie inaktiv sind. Wir empfehlen, diese Funktion aktiviert zu lassen, wenn Sie vorinitialisierte Worker verwenden, um unerwartete Gebühren zu vermeiden. Wenn Sie einen Job weiterleiten und Mitarbeiter von verfügbar `initialCapacity` sind, verwendet der Job diese Ressourcen, um seine Ausführung zu starten. Wenn diese Arbeitskräfte bereits für andere Jobs verwendet werden oder wenn für die Stelle mehr Ressourcen benötigt werden, als verfügbar sind`initialCapacity`, werden in der Anwendung zusätzliche Arbeitskräfte angefordert und eingestellt, und zwar bis zu den für die Bewerbung festgelegten Höchstgrenzen für Ressourcen. Wenn die Ausführung eines Auftrags beendet ist, werden die von ihm verwendeten Worker wieder freigegeben, und die Anzahl der für die Anwendung verfügbaren Ressourcen wird wieder erreicht`initialCapacity`. Eine Anwendung behält die `initialCapacity` Ressourcen auch dann bei, wenn die Ausführung der Jobs abgeschlossen ist. Die Anwendung gibt überschüssige Ressourcen ab dem `initialCapacity` Zeitpunkt frei, zu dem sie für die Ausführung der Jobs nicht mehr benötigt werden. Vorinitialisierte Kapazität ist verfügbar und einsatzbereit, sobald die Anwendung gestartet wurde. Die vorinitialisierte Kapazität wird inaktiv, wenn die Anwendung gestoppt wird. Eine Anwendung wechselt nur dann in den `STARTED` Status, wenn die angeforderte vorinitialisierte Kapazität erstellt wurde und einsatzbereit ist. Während der gesamten Zeit, in der sich die Anwendung im `STARTED` Status befindet, hält EMR Serverless die vorinitialisierte Kapazität für die Nutzung oder Nutzung durch Jobs oder interaktive Workloads verfügbar. Die Funktion stellt die Kapazität für freigegebene oder ausgefallene Container wieder her. Dadurch wird die Anzahl der Mitarbeiter beibehalten, die der `InitialCapacity` Parameter angibt. Der Status einer Anwendung ohne vorinitialisierte Kapazität kann sofort von `CREATED` zu geändert werden. `STARTED` Sie können die Anwendung so konfigurieren, dass vorinitialisierte Kapazität freigegeben wird, wenn sie für einen bestimmten Zeitraum nicht verwendet wird. Die Standardeinstellung ist 15 Minuten. Eine gestoppte Bewerbung wird automatisch gestartet, wenn Sie einen neuen Job einreichen. Sie können diese automatischen Start- und Stoppkonfigurationen festlegen, wenn Sie die Anwendung erstellen, oder sie ändern, wenn sich die Anwendung im `STOPPED` Status `CREATED` oder befindet. Sie können die `InitialCapacity` Anzahl ändern und Rechenkonfigurationen wie CPU, Arbeitsspeicher und Festplatte für jeden Worker angeben. Da Sie keine teilweisen Änderungen vornehmen können, geben Sie alle Rechenkonfigurationen an, wenn Sie Werte ändern. Sie können Konfigurationen nur ändern, wenn sich die Anwendung im `STOPPED` Status `CREATED` oder befindet. **Anmerkung** Um die Nutzung der Ressourcen durch Ihre Anwendung zu optimieren, empfehlen wir, Ihre Containergrößen an die Größe Ihrer vorinitialisierten Capacity-Worker anzupassen. Wenn Sie beispielsweise die Größe Ihres Spark-Executors auf 2 CPUs und Ihren Arbeitsspeicher auf 8 GB konfigurieren, Ihre vorinitialisierte Worker-Größe jedoch 4 CPUs mit 16 GB Arbeitsspeicher beträgt, dann nutzen die Spark-Executoren nur die Hälfte der Ressourcen der Mitarbeiter, wenn sie diesem Job zugewiesen werden. ## Anpassen der vorinitialisierten Kapazität für Spark und Hive Sie können die vorinitialisierte Kapazität für Workloads, die auf bestimmten Big-Data-Frameworks ausgeführt werden, weiter anpassen. Wenn ein Workload beispielsweise auf Apache Spark ausgeführt wird, geben Sie an, wie viele Worker als Treiber und wie viele als Executoren starten. Wenn Sie Apache Hive verwenden, geben Sie auf ähnliche Weise an, wie viele Worker als Hive-Treiber starten und wie viele Tez-Aufgaben ausführen sollen. **Konfiguration einer Anwendung, auf der Apache Hive mit vorinitialisierter Kapazität ausgeführt wird** Die folgende API-Anfrage erstellt eine Anwendung, auf der Apache Hive ausgeführt wird, die auf der Amazon EMR-Version emr-6.6.0 basiert. Die Anwendung beginnt mit 5 vorinitialisierten Hive-Treibern mit jeweils 2 vCPUs und 4 GB Arbeitsspeicher und 50 vorinitialisierten Tez-Task-Workern mit jeweils 4 vCPUs und 8 GB Arbeitsspeicher. Wenn Hive-Abfragen in dieser Anwendung ausgeführt werden, verwenden sie zunächst die vorinitialisierten Worker und beginnen sofort mit der Ausführung. Wenn alle vorinitialisierten Worker ausgelastet sind und mehr Hive-Jobs eingereicht werden, kann die Anwendung auf insgesamt 400 vCPU und 1024 GB Arbeitsspeicher skaliert werden. Sie können optional die Kapazität für den oder den Worker weglassen. `DRIVER` `TEZ_TASK` ``` aws emr-serverless create-application \ --type "HIVE" \ --name my-application-name \ --release-label emr-6.6.0 \ --initial-capacity '{ "DRIVER": { "workerCount": 5, "workerConfiguration": { "cpu": "2vCPU", "memory": "4GB" } }, "TEZ_TASK": { "workerCount": 50, "workerConfiguration": { "cpu": "4vCPU", "memory": "8GB" } } }' \ --maximum-capacity '{ "cpu": "400vCPU", "memory": "1024GB" }' ``` **Konfiguration einer Anwendung, auf der Apache Spark mit vorinitialisierter Kapazität ausgeführt wird** Die folgende API-Anfrage erstellt eine Anwendung, die Apache Spark 3.2.0 auf Basis von Amazon EMR Version 6.6.0 ausführt. Die Anwendung beginnt mit 5 vorinitialisierten Spark-Treibern mit jeweils 2 vCPUs und 4 GB Arbeitsspeicher und 50 vorinitialisierten Executoren mit jeweils 4 vCPUs und 8 GB Arbeitsspeicher. Wenn Spark-Jobs in dieser Anwendung ausgeführt werden, verwenden sie zunächst die vorinitialisierten Worker und beginnen sofort mit der Ausführung. Wenn alle vorinitialisierten Worker ausgelastet sind und mehr Spark-Jobs eingereicht werden, kann die Anwendung auf insgesamt 400 vCPU und 1024 GB Arbeitsspeicher skaliert werden. Sie können optional die Kapazität für entweder den oder den weglassen. `DRIVER` `EXECUTOR` **Anmerkung** Spark fügt dem für Treiber und Executoren angeforderten Speicher einen konfigurierbaren Speicheraufwand mit einem Standardwert von 10% hinzu. Damit Jobs vorinitialisierte Worker verwenden, sollte die anfängliche Speicherkonfiguration für die Kapazität größer sein als der Arbeitsspeicher, den der Job und der Overhead anfordern. ``` aws emr-serverless create-application \ --type "SPARK" \ --name my-application-name \ --release-label emr-6.6.0 \ --initial-capacity '{ "DRIVER": { "workerCount": 5, "workerConfiguration": { "cpu": "2vCPU", "memory": "4GB" } }, "EXECUTOR": { "workerCount": 50, "workerConfiguration": { "cpu": "4vCPU", "memory": "8GB" } } }' \ --maximum-capacity '{ "cpu": "400vCPU", "memory": "1024GB" }' ``` # Standardanwendungskonfiguration für EMR Serverless Sie können auf Anwendungsebene gemeinsame Laufzeit- und Überwachungskonfigurationen für alle Jobs angeben, die Sie im Rahmen derselben Anwendung einreichen. Dadurch wird der zusätzliche Aufwand reduziert, der mit der Notwendigkeit verbunden ist, für jeden Job dieselben Konfigurationen einzureichen. Sie können die Konfigurationen zu den folgenden Zeitpunkten ändern: + [Deklarieren Sie Konfigurationen auf Anwendungsebene bei der Auftragserteilung.](#default-configs-declare) + [Überschreiben Sie die Standardkonfigurationen während der Auftragsausführung.](#default-configs-override) Die folgenden Abschnitte enthalten weitere Informationen und ein Beispiel für weiteren Kontext. ## Deklarieren von Konfigurationen auf Anwendungsebene Sie können Protokollierungs- und Laufzeitkonfigurationseigenschaften auf Anwendungsebene für die Jobs angeben, die Sie im Rahmen der Anwendung einreichen. **`monitoringConfiguration`** Verwenden Sie das Feld, um die Protokollkonfigurationen für Jobs anzugeben, die Sie mit der Anwendung einreichen. [https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_MonitoringConfiguration.html](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_MonitoringConfiguration.html) Weitere Informationen zur Protokollierung für EMR Serverless finden Sie unter. [Speichern von Protokollen](logging.md) **`runtimeConfiguration`** Um Eigenschaften der Laufzeitkonfiguration anzugeben, geben Sie z. `spark-defaults` B. ein Konfigurationsobjekt in das `runtimeConfiguration` Feld ein. Dies wirkt sich auf die Standardkonfigurationen für alle Jobs aus, die Sie mit der Anwendung einreichen. Weitere Informationen finden Sie unter [Parameter zum Überschreiben der Hive-Konfiguration](jobs-hive.md#hive-defaults-configurationOverrides) und [Parameter zum Überschreiben der Spark-Konfiguration](jobs-spark.md#spark-defaults-configurationOverrides). Die verfügbaren Konfigurationsklassifizierungen variieren je nach EMR Serverless-Version. Zum Beispiel Klassifizierungen für benutzerdefiniertes Log4j `spark-driver-log4j2` und `spark-executor-log4j2` sind nur mit Versionen 6.8.0 und höher verfügbar. Eine Liste der anwendungsspezifischen Eigenschaften finden Sie unter und. [Eigenschaften von Spark-Jobs](jobs-spark.md#spark-defaults) [Eigenschaften von Hive-Jobs](jobs-hive.md#hive-defaults) Sie können [Apache Log4j2-Eigenschaften AWS Secrets Manager](log4j2.md) [für den Datenschutz](secrets-manager.md) und die [Java 17-Laufzeit](using-java-runtime.md) auch auf Anwendungsebene konfigurieren. Um Secrets Manager Manager-Geheimnisse auf Anwendungsebene weiterzugeben, fügen Sie Benutzern und Rollen, die EMR Serverless-Anwendungen mit Geheimnissen erstellen oder aktualisieren müssen, die folgende Richtlinie hinzu. **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "SecretsManagerPolicy", "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret" ], "Resource": [ "arn:aws:secretsmanager:us-east-1:123456789012:secret:my-secret-name-123abc" ] }, { "Sid": "KMSDecryptPolicy", "Effect": "Allow", "Action": [ "kms:Decrypt" ], "Resource": [ "arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012" ] } ] } ``` Weitere Informationen zum Erstellen benutzerdefinierter Richtlinien für geheime Daten finden Sie AWS Secrets Manager im *AWS Secrets Manager Benutzerhandbuch* unter [Beispiele für Berechtigungsrichtlinien](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_examples.html). **Anmerkung** Die`runtimeConfiguration`, die Sie auf Anwendungsebene angeben, `applicationConfiguration` entspricht der [https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_StartJobRun.html](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_StartJobRun.html)API. ### Beispiel einer Deklaration Das folgende Beispiel zeigt, wie Standardkonfigurationen mit deklariert `create-application` werden. ``` aws emr-serverless create-application \ --release-label release-version \ --type SPARK \ --name my-application-name \ --runtime-configuration '[ { "classification": "spark-defaults", "properties": { "spark.driver.cores": "4", "spark.executor.cores": "2", "spark.driver.memory": "8G", "spark.executor.memory": "8G", "spark.executor.instances": "2", "spark.hadoop.javax.jdo.option.ConnectionDriverName":"org.mariadb.jdbc.Driver", "spark.hadoop.javax.jdo.option.ConnectionURL":"jdbc:mysql://db-host:db-port/db-name", "spark.hadoop.javax.jdo.option.ConnectionUserName":"connection-user-name", "spark.hadoop.javax.jdo.option.ConnectionPassword": "EMR.secret@SecretID" } }, { "classification": "spark-driver-log4j2", "properties": { "rootLogger.level":"error", "logger.IdentifierForClass.name": "classpathForSettingLogger", "logger.IdentifierForClass.level": "info" } } ]' \ --monitoring-configuration '{ "s3MonitoringConfiguration": { "logUri": "s3://amzn-s3-demo-logging-bucket/logs/app-level" }, "managedPersistenceMonitoringConfiguration": { "enabled": false } }' ``` ## Überschreiben von Konfigurationen während einer Jobausführung Mit der [https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_StartJobRun.html](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_StartJobRun.html)API können Sie Konfigurationsüberschreibungen für die Anwendungskonfiguration und die Überwachungskonfiguration angeben. EMR Serverless führt dann die Konfigurationen zusammen, die Sie auf Anwendungs- und Jobebene angeben, um die Konfigurationen für die Jobausführung zu bestimmen. Die Granularitätsstufe bei der Zusammenführung ist wie folgt: + **[https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_ConfigurationOverrides.html#emrserverless-Type-ConfigurationOverrides-applicationConfiguration](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_ConfigurationOverrides.html#emrserverless-Type-ConfigurationOverrides-applicationConfiguration)**- Zum Beispiel `spark-defaults` der Klassifizierungstyp. + **[https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_ConfigurationOverrides.html#emrserverless-Type-ConfigurationOverrides-monitoringConfiguration](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_ConfigurationOverrides.html#emrserverless-Type-ConfigurationOverrides-monitoringConfiguration)**- Konfigurationstyp, zum Beispiel`s3MonitoringConfiguration`. **Anmerkung** Die Priorität der Konfigurationen, die Sie auf Anwendungsebene bereitstellen, [https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_StartJobRun.html](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_StartJobRun.html)hat Vorrang vor den Konfigurationen, die Sie auf Anwendungsebene bereitstellen. Weitere Informationen zur Rangfolge der Prioritäten finden Sie unter und. [Parameter zum Überschreiben der Hive-Konfiguration](jobs-hive.md#hive-defaults-configurationOverrides) [Parameter zum Überschreiben der Spark-Konfiguration](jobs-spark.md#spark-defaults-configurationOverrides) Wenn Sie einen Job starten und keine bestimmte Konfiguration angeben, wird diese von der Anwendung übernommen. Wenn Sie die Konfigurationen auf Jobebene deklarieren, können Sie die folgenden Operationen ausführen: + **Eine bestehende Konfiguration überschreiben** — Geben Sie denselben Konfigurationsparameter in der `StartJobRun` Anfrage mit Ihren Override-Werten an. + **Zusätzliche Konfiguration hinzufügen** — Fügen Sie der `StartJobRun` Anfrage den neuen Konfigurationsparameter mit den Werten hinzu, die Sie angeben möchten. + **Eine bestehende Konfiguration entfernen** — Um eine *Laufzeitkonfiguration* einer Anwendung zu entfernen, geben Sie den Schlüssel für die Konfiguration ein, die Sie entfernen möchten, und übergeben Sie eine leere Deklaration `{}` für die Konfiguration. Es wird nicht empfohlen, Klassifizierungen zu entfernen, die Parameter enthalten, die für die Ausführung eines Jobs erforderlich sind. Wenn Sie beispielsweise versuchen, die [erforderlichen Eigenschaften für einen Hive-Job zu entfernen, schlägt der Job](https://docs.aws.amazon.com/) fehl. Um eine *Konfiguration zur Anwendungsüberwachung* zu entfernen, verwenden Sie die entsprechende Methode für den entsprechenden Konfigurationstyp: + **`cloudWatchLoggingConfiguration`**— Um zu entfernen`cloudWatchLogging`, übergeben Sie das Kennzeichen enabled als`false`. + **`managedPersistenceMonitoringConfiguration`**— Um die verwalteten Persistenzeinstellungen zu entfernen und zum Standardstatus aktiviert zurückzukehren, übergeben Sie eine leere Deklaration `{}` für die Konfiguration. + **`s3MonitoringConfiguration`**— Um zu entfernen`s3MonitoringConfiguration`, übergeben Sie eine leere Deklaration `{}` für die Konfiguration. ### Beispiel für Override Das folgende Beispiel zeigt verschiedene Operationen, die Sie bei der Einreichung eines Jobs unter ausführen können`start-job-run`. ``` aws emr-serverless start-job-run \ --application-id your-application-id \ --execution-role-arn your-job-role-arn \ --job-driver '{ "sparkSubmit": { "entryPoint": "s3://us-east-1.elasticmapreduce/emr-containers/samples/wordcount/scripts/wordcount.py", "entryPointArguments": ["s3://amzn-s3-demo-destination-bucket1/wordcount_output"] } }' \ --configuration-overrides '{ "applicationConfiguration": [ { // Override existing configuration for spark-defaults in the application "classification": "spark-defaults", "properties": { "spark.driver.cores": "2", "spark.executor.cores": "1", "spark.driver.memory": "4G", "spark.executor.memory": "4G" } }, { // Add configuration for spark-executor-log4j2 "classification": "spark-executor-log4j2", "properties": { "rootLogger.level": "error", "logger.IdentifierForClass.name": "classpathForSettingLogger", "logger.IdentifierForClass.level": "info" } }, { // Remove existing configuration for spark-driver-log4j2 from the application "classification": "spark-driver-log4j2", "properties": {} } ], "monitoringConfiguration": { "managedPersistenceMonitoringConfiguration": { // Override existing configuration for managed persistence "enabled": true }, "s3MonitoringConfiguration": { // Remove configuration of S3 monitoring }, "cloudWatchLoggingConfiguration": { // Add configuration for CloudWatch logging "enabled": true } } }' ``` Zum Zeitpunkt der Auftragsausführung gelten die folgenden Klassifizierungen und Konfigurationen, die auf der unter [Parameter zum Überschreiben der Hive-Konfiguration](jobs-hive.md#hive-defaults-configurationOverrides) und [Parameter zum Überschreiben der Spark-Konfiguration](jobs-spark.md#spark-defaults-configurationOverrides) beschriebenen Rangfolge der Prioritätsüberschreibung basieren. + Die Klassifizierung `spark-defaults` wird mit den auf Auftragsebene angegebenen Eigenschaften aktualisiert. Für diese Klassifizierung werden nur `StartJobRun` die in enthaltenen Eigenschaften berücksichtigt. + Die Klassifizierung `spark-executor-log4j2` wird in die bestehende Liste der Klassifizierungen aufgenommen. + Die Klassifizierung `spark-driver-log4j2` wird entfernt. + Die Konfigurationen für `managedPersistenceMonitoringConfiguration` werden mit Konfigurationen auf Auftragsebene aktualisiert. + Die Konfigurationen für `s3MonitoringConfiguration` werden entfernt. + Die Konfigurationen für `cloudWatchLoggingConfiguration` werden zu bestehenden Überwachungskonfigurationen hinzugefügt.