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. # Interagieren Sie mit einer serverlosen EMR-Anwendung und konfigurieren Sie sie In diesem Abschnitt erfahren Sie, wie Sie mit Ihrer Amazon EMR Serverless-Anwendung mit dem interagieren. AWS CLI Außerdem werden die Konfiguration einer Anwendung, die Durchführung von Anpassungen und die Standardeinstellungen für Spark- und Hive-Engines beschrieben. **Topics** + [Status der Anwendung](#application-states) + [Eine serverlose EMR-Anwendung von der EMR Studio-Konsole aus erstellen](studio.md) + [Interaktion mit Ihrer EMR Serverless-Anwendung auf dem AWS CLI](applications-cli.md) + [Konfiguration einer Anwendung bei der Arbeit mit EMR Serverless](application-capacity.md) + [Anpassen eines serverlosen EMR-Images](application-custom-image.md) + [Konfiguration des VPC-Zugriffs für serverlose EMR-Anwendungen zur Verbindung mit Daten](vpc-access.md) + [Optionen für die serverlose Architektur von Amazon EMR](architecture.md) + [Parallelität von Aufträgen und Warteschlangen für eine serverlose EMR-Anwendung](applications-concurrency-queuing.md) ## Status der Anwendung Wenn Sie eine Anwendung mit EMR Serverless erstellen, wechselt die ausgeführte Anwendung in den `CREATING` Status. Danach durchläuft er die folgenden Zustände, bis er erfolgreich ist (Abschluss mit Code `0`) oder fehlschlägt (Abschluss mit einem Code ungleich null). Anwendungen können die folgenden Status haben: **** | Status | Description | | --- | --- | | Erstellen | Die Anwendung wird vorbereitet und ist noch nicht einsatzbereit. | | Erstellt | Die Anwendung wurde erstellt, hat aber noch keine Kapazität bereitgestellt. Sie können die Anwendung ändern, um ihre anfängliche Kapazitätskonfiguration zu ändern. | | Wird gestartet | Die Anwendung wird gestartet und stellt Kapazität bereit. | | Gestartet | Die Bewerbung ist bereit, neue Jobs anzunehmen. Die Bewerbung akzeptiert nur Jobs, wenn sie sich in diesem Status befindet. | | Wird angehalten | Alle Jobs wurden abgeschlossen und die Kapazität der Anwendung wird ausgeschöpft. | | Angehalten | Die Anwendung wurde gestoppt und es werden keine Ressourcen für die Anwendung ausgeführt. Sie können die Anwendung ändern, um ihre anfängliche Kapazitätskonfiguration zu ändern. | | Beendet | Die Anwendung wurde beendet und erscheint nicht auf Ihrer Anwendungsliste. | Das folgende Diagramm veranschaulicht den Verlauf der Serverless-Anwendungszustände von EMR. ![\[Status der serverlosen EMR-Anwendung.\]](http://docs.aws.amazon.com/de_de/emr/latest/EMR-Serverless-UserGuide/images/emr-serverless-application-states.png) # Eine serverlose EMR-Anwendung von der EMR Studio-Konsole aus erstellen Von der EMR Studio-Konsole aus können Sie EMR Serverless-Anwendungen erstellen, darauf zugreifen und sie verwalten. Folgen Sie den Anweisungen unter [Erste Schritte mit der Konsole, um zur EMR Studio-Konsole](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/getting-started.html#gs-console) zu navigieren. ## Erstellen einer Anwendung **Erstellen Sie auf der Seite „Anwendung** erstellen“ eine serverlose EMR-Anwendung, indem Sie die folgenden Schritte ausführen. 1. Geben Sie im Feld **Name** den Namen ein, den Sie für Ihre Anwendung verwenden möchten. 1. Wählen Sie im Feld **Typ** Spark oder Hive als Anwendungstyp aus. 1. Wählen Sie im Feld **Release-Version** die EMR-Release-Nummer aus. 1. Wählen Sie in den **Architekturoptionen** die zu verwendende Befehlssatzarchitektur aus. Weitere Informationen finden Sie unter [Optionen für die serverlose Architektur von Amazon EMR](architecture.md). + **arm64** — 64-Bit-ARM-Architektur; zur Verwendung von Graviton-Prozessoren + **x86\$164** — 64-Bit-x86-Architektur; zur Verwendung von x86-basierten Prozessoren 1. Für die übrigen Felder gibt es zwei Optionen zur Anwendungseinrichtung: Standardeinstellungen und benutzerdefinierte Einstellungen. Diese Felder sind optional. **Standardeinstellungen** — Mit den Standardeinstellungen können Sie schnell eine Anwendung mit vorinitialisierter Kapazität erstellen. Dazu gehören ein Treiber und ein Executor für Spark sowie ein Treiber und eine Tez Task für Hive. Die Standardeinstellungen ermöglichen keine Netzwerkkonnektivität zu Ihrem. VPCs Die Anwendung ist so konfiguriert, dass sie angehalten wird, wenn sie 15 Minuten lang inaktiv ist, und startet automatisch, wenn der Job eingereicht wird. **Benutzerdefinierte Einstellungen** — Mithilfe von benutzerdefinierten Einstellungen können Sie die folgenden Eigenschaften ändern. + **Vorinitialisierte Kapazität** — Die Anzahl der Fahrer und Ausführenden oder Hive Tez Task-Worker sowie die Größe der einzelnen Worker. + **Anwendungsgrenzen** — Die maximale Kapazität einer Anwendung. + **Anwendungsverhalten** — Das automatische Start- und Stoppverhalten der Anwendung. + **Netzwerkverbindungen** — Netzwerkkonnektivität zu VPC-Ressourcen. + **Tags** — Benutzerdefinierte Tags, die der Anwendung zugewiesen werden. Weitere Informationen zu vorinitialisierter Kapazität, Anwendungslimits und Anwendungsverhalten finden Sie unter. [Konfiguration einer Anwendung bei der Arbeit mit EMR Serverless](application-capacity.md) Weitere Informationen zur Netzwerkkonnektivität finden Sie unter. [Konfiguration des VPC-Zugriffs für serverlose EMR-Anwendungen zur Verbindung mit Daten](vpc-access.md) 1. Um die Anwendung zu erstellen, wählen Sie **Anwendung erstellen**. # Anwendungen von der EMR Studio-Konsole aus auflisten Sie können auf der Seite Anwendungen **auflisten auf alle vorhandenen EMR Serverless-Anwendungen** zugreifen. Sie können den Namen einer Anwendung wählen, um zur **Detailseite** für diese Anwendung zu navigieren. # Anwendungen von der EMR Studio-Konsole aus verwalten Sie können die folgenden Aktionen für eine Anwendung entweder auf der Seite „**Anwendungen auflisten**“ oder auf der **Detailseite** einer bestimmten Anwendung ausführen. ****Anwendung starten**** Wählen Sie diese Option, um eine Anwendung manuell zu starten. ****Anwendung beenden**** Wählen Sie diese Option, um eine Anwendung manuell zu beenden. Eine Anwendung darf keine laufenden Jobs haben, um gestoppt zu werden. Weitere Informationen zu Statusübergängen bei Anwendungen finden Sie unter[Status der Anwendung](applications.md#application-states). ****Anwendung konfigurieren**** Bearbeiten Sie die optionalen Einstellungen für eine Anwendung auf der Seite **Anwendung konfigurieren**. Sie können die meisten Anwendungseinstellungen ändern. Ändern Sie beispielsweise das Release-Label für eine Anwendung, um sie auf eine andere Version von Amazon EMR zu aktualisieren, oder wechseln Sie die Architektur von x86\$164 auf arm64. **Die anderen optionalen Einstellungen entsprechen denen, die sich im Abschnitt **Benutzerdefinierte Einstellungen auf der Seite Anwendung erstellen** befinden.** Weitere Informationen zu den Anwendungseinstellungen finden Sie unter[Erstellen einer Anwendung](studio.md#studio-create-app). ****Anwendung löschen**** Wählen Sie diese Option, um eine Anwendung manuell zu löschen. Sie müssen eine Anwendung beenden, um sie zu löschen. Weitere Informationen zu Statusübergängen bei Anwendungen finden Sie unter[Status der Anwendung](applications.md#application-states). # Interaktion mit Ihrer EMR Serverless-Anwendung auf dem AWS CLI Erstellen AWS CLI, beschreiben und löschen Sie einzelne Anwendungen aus. Sie können auch alle Ihre Anwendungen auflisten, sodass Sie auf einen Blick darauf zugreifen können. In diesem Abschnitt wird beschrieben, wie Sie diese Aktionen ausführen. Weitere Anwendungsvorgänge wie Starten, Stoppen und Anwendungsupdates finden Sie in der [EMR Serverless API](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/Welcome.html) Reference. Beispiele für die Verwendung der EMR Serverless API mithilfe von finden Sie in den AWS SDK für Java[Java-Beispielen](https://github.com/aws-samples/emr-serverless-samples/tree/main/examples/java-api) in unserem GitHub Repository. Beispiele für die Verwendung der EMR Serverless API mithilfe von finden Sie in den AWS SDK für Python (Boto)[Python-Beispielen](https://github.com/aws-samples/emr-serverless-samples/tree/main/examples/python-api) in unserem GitHub Repository. Um eine Anwendung zu erstellen, verwenden Sie. `create-application` Sie müssen `SPARK` oder `HIVE` als Anwendung angeben`type`. Dieser Befehl gibt den ARN, den Namen und die ID der Anwendung zurück. ``` aws emr-serverless create-application \ --name my-application-name \ --type 'application-type' \ --release-label release-version ``` Um eine Anwendung zu beschreiben, verwenden Sie sie `get-application` und geben Sie sie an`application-id`. Dieser Befehl gibt den Status und die kapazitätsbezogenen Konfigurationen für Ihre Anwendung zurück. ``` aws emr-serverless get-application \ --application-id application-id ``` Rufen Sie an, um alle Ihre Anwendungen aufzulisten. `list-applications` Dieser Befehl gibt dieselben Eigenschaften zurück wie alle Ihre Anwendungen, schließt sie `get-application` jedoch ein. ``` aws emr-serverless list-applications ``` Um Ihre Anwendung zu löschen, rufen Sie an `delete-application` und geben Sie Ihre an`application-id`. ``` aws emr-serverless delete-application \ --application-id application-id ``` # 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. # Anpassen eines serverlosen EMR-Images Verwenden Sie ab Amazon EMR 6.9.0 benutzerdefinierte Images, um Anwendungsabhängigkeiten und Laufzeitumgebungen mit Amazon EMR Serverless in einem einzigen Container zu verpacken. Dies vereinfacht die Verwaltung von Workload-Abhängigkeiten und macht Ihre Pakete portabler. Wenn Sie Ihr EMR Serverless-Image anpassen, bietet es die folgenden Vorteile: + Installiert und konfiguriert Pakete, die für Ihre Workloads optimiert sind. Diese Pakete sind in der öffentlichen Distribution von Amazon EMR-Laufzeitumgebungen nicht allgemein verfügbar. + Integriert EMR Serverless in die derzeit etablierten Build-, Test- und Bereitstellungsprozesse in Ihrem Unternehmen, einschließlich lokaler Entwicklung und Tests. + Wendet etablierte Sicherheitsprozesse an, wie z. B. das Scannen von Bildern, die die Compliance- und Governance-Anforderungen in Ihrem Unternehmen erfüllen. + Ermöglicht es Ihnen, Ihre eigenen Versionen von JDK und Python für Ihre Anwendungen zu verwenden. EMR Serverless stellt Images bereit, die Sie als Basis verwenden, wenn Sie Ihre eigenen Images erstellen. Das Basis-Image enthält die wesentlichen JAR-Dateien, Konfigurationen und Bibliotheken für die Interaktion des Images mit EMR Serverless. Sie finden das Basisbild in der [Amazon ECR Public Gallery](https://gallery.ecr.aws/emr-serverless/). Verwenden Sie das Image, das Ihrem Anwendungstyp (Spark oder Hive) und Ihrer Release-Version entspricht. Wenn Sie beispielsweise eine Anwendung auf Amazon EMR Version 6.9.0 erstellen, verwenden Sie die folgenden Bilder. | Typ | Image | | --- | --- | | Spark | `public.ecr.aws/emr-serverless/spark/emr-6.9.0:latest` | | Hive | `public.ecr.aws/emr-serverless/hive/emr-6.9.0:latest` | ## Voraussetzungen Bevor Sie ein benutzerdefiniertes EMR Serverless-Image erstellen, müssen Sie diese Voraussetzungen erfüllen. 1. Erstellen Sie ein Amazon ECR-Repository in demselben Verzeichnis AWS-Region , das Sie zum Starten von EMR Serverless-Anwendungen verwenden. Informationen zum Erstellen eines privaten Amazon ECR-Repositorys finden Sie unter [Privates Repository erstellen](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-create.html). 1. Um Benutzern Zugriff auf Ihr Amazon ECR-Repository zu gewähren, fügen Sie Benutzern und Rollen, die EMR Serverless-Anwendungen mit Bildern aus diesem Repository erstellen oder aktualisieren, die folgenden Richtlinien hinzu. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "ECRRepositoryListGetPolicy", "Effect": "Allow", "Action": [ "ecr:GetDownloadUrlForLayer", "ecr:BatchGetImage", "ecr:DescribeImages" ], "Resource": [ "arn:aws:ecr:*:123456789012:repository/my-repo" ] } ] } ``` ------ Weitere Beispiele für identitätsbasierte Amazon ECR-Richtlinien finden Sie unter Beispiele für identitätsbasierte Richtlinien von [Amazon Elastic Container Registry](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security_iam_id-based-policy-examples.html). ## Schritt 1: Erstellen Sie ein benutzerdefiniertes Image aus EMR Serverless-Basisimages Erstellen Sie zunächst ein [Dockerfile](https://docs.docker.com/engine/reference/builder/), das mit einer `FROM` Anweisung beginnt, die Ihr bevorzugtes Basis-Image verwendet. Fügen Sie nach der `FROM` Anweisung alle Änderungen hinzu, die Sie am Image vornehmen möchten. Das Basis-Image legt automatisch den Wert `USER` auf fest`hadoop`. Diese Einstellung verfügt nicht über Berechtigungen für alle Änderungen, die Sie vornehmen. Um das Problem zu umgehen, setzen Sie den `USER` Wert auf`root`, ändern Sie Ihr Bild und setzen Sie dann den Wert `USER` Zurück auf`hadoop:hadoop`. Beispiele für gängige Anwendungsfälle finden Sie unter. [Verwenden von benutzerdefinierten Images mit EMR Serverless](using-custom-images.md) ``` # Dockerfile FROM public.ecr.aws/emr-serverless/spark/emr-6.9.0:latest USER root # MODIFICATIONS GO HERE # EMRS runs the image as hadoop USER hadoop:hadoop ``` Nachdem Sie das Dockerfile haben, erstellen Sie das Image mit dem folgenden Befehl. ``` # build the docker image docker build . -t aws-account-id.dkr.ecr.region.amazonaws.com/my-repository[:tag]or[@digest] ``` ## Schritt 2: Überprüfen Sie das Image lokal EMR Serverless bietet ein Offline-Tool, mit dem Sie Ihr benutzerdefiniertes Image statisch überprüfen können, um grundlegende Dateien, Umgebungsvariablen und korrekte Image-Konfigurationen zu validieren. Informationen zur Installation und Ausführung des Tools finden Sie in [der Amazon EMR Serverless Image](https://github.com/awslabs/amazon-emr-serverless-image-cli) CLI. GitHub Führen Sie nach der Installation des Tools den folgenden Befehl aus, um ein Image zu validieren: ``` amazon-emr-serverless-image \ validate-image -r emr-6.9.0 -t spark \ -i aws-account-id.dkr.ecr.region.amazonaws.com/my-repository:tag/@digest ``` Die Ausgabe sieht wie folgt aus. ``` Amazon EMR Serverless - Image CLI Version: 0.0.1 ... Checking if docker cli is installed ... Checking Image Manifest [INFO] Image ID: 9e2f4359cf5beb466a8a2ed047ab61c9d37786c555655fc122272758f761b41a [INFO] Created On: 2022-12-02T07:46:42.586249984Z [INFO] Default User Set to hadoop:hadoop : PASS [INFO] Working Directory Set to : PASS [INFO] Entrypoint Set to /usr/bin/entrypoint.sh : PASS [INFO] HADOOP_HOME is set with value: /usr/lib/hadoop : PASS [INFO] HADOOP_LIBEXEC_DIR is set with value: /usr/lib/hadoop/libexec : PASS [INFO] HADOOP_USER_HOME is set with value: /home/hadoop : PASS [INFO] HADOOP_YARN_HOME is set with value: /usr/lib/hadoop-yarn : PASS [INFO] HIVE_HOME is set with value: /usr/lib/hive : PASS [INFO] JAVA_HOME is set with value: /etc/alternatives/jre : PASS [INFO] TEZ_HOME is set with value: /usr/lib/tez : PASS [INFO] YARN_HOME is set with value: /usr/lib/hadoop-yarn : PASS [INFO] File Structure Test for hadoop-files in /usr/lib/hadoop: PASS [INFO] File Structure Test for hadoop-jars in /usr/lib/hadoop/lib: PASS [INFO] File Structure Test for hadoop-yarn-jars in /usr/lib/hadoop-yarn: PASS [INFO] File Structure Test for hive-bin-files in /usr/bin: PASS [INFO] File Structure Test for hive-jars in /usr/lib/hive/lib: PASS [INFO] File Structure Test for java-bin in /etc/alternatives/jre/bin: PASS [INFO] File Structure Test for tez-jars in /usr/lib/tez: PASS ----------------------------------------------------------------- Overall Custom Image Validation Succeeded. ----------------------------------------------------------------- ``` ## Schritt 3: Laden Sie das Bild in Ihr Amazon ECR-Repository hoch Übertragen Sie Ihr Amazon ECR-Image mit den folgenden Befehlen in Ihr Amazon ECR-Repository. Stellen Sie sicher, dass Sie über die richtigen IAM-Berechtigungen verfügen, um das Image in Ihr Repository zu übertragen. Weitere Informationen finden Sie unter [Pushing an Image](https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-push.html) im *Amazon ECR-Benutzerhandbuch*. ``` # login to ECR repo aws ecr get-login-password --region region | docker login --username AWS --password-stdin aws-account-id.dkr.ecr.region.amazonaws.com # push the docker image docker push aws-account-id.dkr.ecr.region.amazonaws.com/my-repository:tag/@digest ``` ## Schritt 4: Erstellen oder aktualisieren Sie eine Anwendung mit benutzerdefinierten Bildern Wählen Sie die AWS-Managementkonsole Registerkarte oder AWS CLI Registerkarte aus, je nachdem, wie Sie Ihre Anwendung starten möchten, und führen Sie dann die folgenden Schritte aus. ------ #### [ Console ] 1. Melden Sie sich bei der EMR Studio-Konsole unter [https://console.aws.amazon.com/emr](https://console.aws.amazon.com/emr) an. Navigieren Sie zu Ihrer Anwendung, oder erstellen Sie mithilfe der Anweisungen unter Anwendung [erstellen](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/studio.html#studio-create-app) eine neue Anwendung. 1. Um benutzerdefinierte Images anzugeben, wenn Sie eine EMR Serverless-Anwendung erstellen oder aktualisieren, wählen Sie in den Einrichtungsoptionen der Anwendung die Option **Benutzerdefinierte Einstellungen** aus. 1. Aktivieren Sie im Abschnitt **Benutzerdefinierte Image-Einstellungen** das Kontrollkästchen **Benutzerdefiniertes Image mit dieser Anwendung verwenden**. 1. Fügen Sie die Amazon ECR-Image-URI in das Feld **Image-URI** ein. EMR Serverless verwendet dieses Image für alle Worker-Typen der Anwendung. Alternativ können Sie **Verschiedene benutzerdefinierte Bilder** auswählen und URIs für jeden Arbeitertyp ein anderes Amazon ECR-Bild einfügen. ------ #### [ CLI ] + Erstellen Sie eine Anwendung mit dem `image-configuration` Parameter. EMR Serverless wendet diese Einstellung auf alle Worker-Typen an. ``` aws emr-serverless create-application \ --release-label emr-6.9.0 \ --type SPARK \ --image-configuration '{ "imageUri": "aws-account-id.dkr.ecr.region.amazonaws.com/my-repository:tag/@digest" }' ``` Verwenden Sie den Parameter, um eine Anwendung mit unterschiedlichen Image-Einstellungen für jeden Worker-Typ zu erstellen. `worker-type-specifications` ``` aws emr-serverless create-application \ --release-label emr-6.9.0 \ --type SPARK \ --worker-type-specifications '{ "Driver": { "imageConfiguration": { "imageUri": "aws-account-id.dkr.ecr.region.amazonaws.com/my-repository:tag/@digest" } }, "Executor" : { "imageConfiguration": { "imageUri": "aws-account-id.dkr.ecr.region.amazonaws.com/my-repository:tag/@digest" } } }' ``` Verwenden Sie den `image-configuration` Parameter, um eine Anwendung zu aktualisieren. EMR Serverless wendet diese Einstellung auf alle Worker-Typen an. ``` aws emr-serverless update-application \ --application-id application-id \ --image-configuration '{ "imageUri": "aws-account-id.dkr.ecr.region.amazonaws.com/my-repository:tag/@digest" }' ``` ------ ## Schritt 5: Erlauben Sie EMR Serverless, auf das benutzerdefinierte Image-Repository zuzugreifen Fügen Sie dem Amazon ECR-Repository die folgende Ressourcenrichtlinie hinzu, damit der EMR Serverless Service Principal die `get``describe`, und `download` -Anfragen aus diesem Repository verwenden kann. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "EmrServerlessCustomImageSupport", "Effect": "Allow", "Action": [ "ecr:BatchGetImage", "ecr:DescribeImages", "ecr:GetDownloadUrlForLayer" ], "Resource": "arn:aws:ecr:*:123456789012:repository/my-repo", "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:emr-serverless:*:123456789012:/applications/*" } } } ] } ``` ------ Aus Sicherheitsgründen sollten Sie der Repository-Richtlinie einen `aws:SourceArn` Bedingungsschlüssel hinzufügen. Der globale IAM-Bedingungsschlüssel `aws:SourceArn` stellt sicher, dass EMR Serverless das Repository nur für einen Anwendungs-ARN verwendet. Weitere Informationen zu den Amazon ECR-Repository-Richtlinien finden Sie unter [Erstellen eines privaten Repositorys](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-policies.html). ## Überlegungen und Einschränkungen Wenn Sie mit benutzerdefinierten Images arbeiten, sollten Sie Folgendes beachten: + Verwenden Sie das richtige Basis-Image, das dem Typ (Spark oder Hive) und dem Release-Label (z. B.`emr-6.9.0`) für Ihre Anwendung entspricht. + EMR Serverless ignoriert unsere `[CMD]` `[ENTRYPOINT]` Anweisungen in der Docker-Datei. Verwenden Sie allgemeine Anweisungen in der Docker-Datei, z. B., und. `[COPY]` `[RUN]` `[WORKDIR]` + Ändern Sie die Umgebungsvariablen`JAVA_HOME`,, nicht `SPARK_HOME``HIVE_HOME`, `TEZ_HOME` wenn Sie ein benutzerdefiniertes Image erstellen. + Benutzerdefinierte Bilder dürfen eine Größe von 10 GB nicht überschreiten. + Wenn Sie Binärdateien oder JAR-Dateien in den Amazon EMR-Basis-Images ändern, kann dies zu Fehlern beim Starten von Anwendungen oder Jobs führen. + Das Amazon ECR-Repository muss sich in demselben Verzeichnis befinden AWS-Region , das Sie zum Starten von EMR Serverless-Anwendungen verwenden. # Konfiguration des VPC-Zugriffs für serverlose EMR-Anwendungen zur Verbindung mit Daten Sie können serverlose EMR-Anwendungen so konfigurieren, dass sie eine Verbindung zu Ihren Datenspeichern in Ihrer VPC herstellen, z. B. Amazon Redshift Redshift-Cluster, Amazon RDS-Datenbanken oder Amazon S3 S3-Buckets mit VPC-Endpunkten. Ihre EMR Serverless-Anwendung verfügt über ausgehende Konnektivität zu den Datenspeichern in Ihrer VPC. Standardmäßig blockiert EMR Serverless sowohl den eingehenden Zugriff auf Ihre Anwendungen als auch den ausgehenden Internetzugang, um die Sicherheit zu erhöhen. **Anmerkung** Sie müssen den VPC-Zugriff konfigurieren, wenn Sie eine externe Hive-Metastore-Datenbank für Ihre Anwendung verwenden möchten. [Informationen zur Konfiguration eines externen Hive-Metastores finden Sie unter Metastore-Konfiguration.](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/metastore-config.html) ## Erstellen von Anwendungen Wählen Sie auf der Seite **Anwendung erstellen** benutzerdefinierte Einstellungen aus und geben Sie die VPC, Subnetze und Sicherheitsgruppen an, die EMR Serverless-Anwendungen verwenden können. ### VPCs Wählen Sie den Namen der Virtual Private Cloud (VPC), die Ihre Datenspeicher enthält. Auf der Seite „**Anwendung erstellen**“ werden alle VPCs für Sie ausgewählten AWS-Region Anwendungen aufgeführt. ### Subnets Wählen Sie die Subnetze innerhalb der VPC aus, die Ihren Datenspeicher enthält. Auf der Seite **Anwendung erstellen** werden alle Subnetze für die Datenspeicher in Ihrer VPC aufgeführt. Sowohl öffentliche als auch private Subnetze werden unterstützt. Sie können entweder private oder öffentliche Subnetze an Ihre Anwendungen übergeben. Bei der Entscheidung, ob ein öffentliches oder ein privates Subnetz eingerichtet werden soll, sind einige Überlegungen zu beachten. Für private Subnetze: + Die zugehörigen Routing-Tabellen dürfen keine Internet-Gateways haben. + Für ausgehende Verbindungen zum Internet konfigurieren Sie bei Bedarf ausgehende Routen mithilfe eines NAT-Gateways. Informationen zur Konfiguration eines NAT-Gateways finden Sie unter [NAT-Gateways](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html#nat-gateway-working-with). + Für Amazon S3 S3-Konnektivität konfigurieren Sie entweder ein NAT-Gateway oder einen VPC-Endpunkt. Informationen zur Konfiguration eines S3-VPC-Endpunkts finden Sie unter [Gateway-Endpunkt erstellen](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html#create-gateway-endpoint-s3). + Wenn Sie einen S3-VPC-Endpunkt konfigurieren und eine Endpunktrichtlinie zur Zugriffskontrolle anhängen, folgen Sie den Anweisungen unter [Logging for EMR Serverless with managed storage](logging.html#jobs-log-storage-managed-storage), um EMR Serverless Berechtigungen zum Speichern und Bereitstellen von Anwendungsprotokollen zu erteilen. + Für Konnektivität zu anderen Geräten AWS-Services außerhalb der VPC, z. B. zu Amazon DynamoDB, konfigurieren Sie entweder VPC-Endpunkte oder ein NAT-Gateway. Informationen zur Konfiguration von VPC-Endpunkten finden Sie AWS-Services unter [Arbeiten mit VPC-Endpunkten](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html#working-with-privatelink). **Anmerkung** Wenn Sie eine Amazon EMR Serverless-Anwendung in einem privaten Subnetz einrichten, empfehlen wir Ihnen, auch VPC-Endpunkte für Amazon S3 einzurichten. Wenn sich Ihre EMR Serverless-Anwendung in einem privaten Subnetz ohne VPC-Endpunkte für Amazon S3 befindet, fallen zusätzliche NAT-Gateway-Gebühren an, die mit dem S3-Verkehr verbunden sind. Dies liegt daran, dass der Datenverkehr zwischen Ihrer EMR-Anwendung und Amazon S3 nicht innerhalb Ihrer VPC verbleibt, wenn VPC-Endpunkte nicht konfiguriert sind. Für öffentliche Subnetze: + Diese haben eine Route zu einem Internet Gateway. + Sie müssen sicherstellen, dass die Sicherheitsgruppen ordnungsgemäß konfiguriert sind, um den ausgehenden Verkehr zu kontrollieren. Mitarbeiter können über ausgehenden Datenverkehr eine Verbindung zu den Datenspeichern in Ihrer VPC herstellen. Standardmäßig blockiert EMR Serverless den eingehenden Zugriff für Mitarbeiter. Dies dient der Verbesserung der Sicherheit. Wenn Sie es verwenden AWS Config, erstellt EMR Serverless einen elastic network interface Interface-Elementdatensatz für jeden Worker. Um Kosten im Zusammenhang mit dieser Ressource zu vermeiden, sollten Sie die Option deaktivieren`AWS::EC2::NetworkInterface`. AWS Config **Anmerkung** Wir empfehlen, dass Sie mehrere Subnetze in mehreren Availability Zones auswählen. Dies liegt daran, dass die von Ihnen ausgewählten Subnetze die Availability Zones bestimmen, die für den Start einer EMR Serverless-Anwendung verfügbar sind. Jeder Worker verwendet eine IP-Adresse in dem Subnetz, in dem er gestartet wird. Bitte stellen Sie sicher, dass die angegebenen Subnetze über ausreichend IP-Adressen für die Anzahl der Worker verfügen, die Sie starten möchten. Weitere Informationen zur Subnetzplanung finden Sie unter. [Bewährte Methoden für die Subnetzplanung](#subnet-best-practices) #### Überlegungen und Einschränkungen für Subnetze + EMR Serverless mit öffentlichen Subnetzen unterstützt AWS Lake Formation nicht. + Eingehender Datenverkehr wird für öffentliche Subnetze nicht unterstützt. ### Sicherheitsgruppen Wählen Sie eine oder mehrere Sicherheitsgruppen aus, die mit Ihren Datenspeichern kommunizieren können. Auf der Seite **Anwendung erstellen** werden alle Sicherheitsgruppen in Ihrer VPC aufgeführt. EMR Serverless verknüpft diese Sicherheitsgruppen mit elastischen Netzwerkschnittstellen, die an Ihre VPC-Subnetze angeschlossen sind. **Anmerkung** Wir empfehlen, dass Sie eine separate Sicherheitsgruppe für EMR Serverless-Anwendungen erstellen. **Mit EMR Serverless können Sie keine **Anwendung ****erstellen/aktualisieren/starten******, wenn Sicherheitsgruppen Ports für das öffentliche Internet im Bereich **0.0.0.0/0 oder: :/0** haben.** Dies bietet mehr Sicherheit und Isolierung und macht die Verwaltung von Netzwerkregeln effizienter. Dadurch wird beispielsweise unerwarteter Datenverkehr an Mitarbeiter mit öffentlichen IP-Adressen blockiert. Um beispielsweise mit Amazon Redshift Redshift-Clustern zu kommunizieren, definieren Sie die Verkehrsregeln zwischen Redshift- und EMR-Serverless-Sicherheitsgruppen, wie im Beispiel im folgenden Abschnitt gezeigt. **Example Beispiel — Kommunikation mit Amazon Redshift Redshift-Clustern** 1. Fügen Sie der Amazon Redshift Redshift-Sicherheitsgruppe eine Regel für eingehenden Datenverkehr aus einer der serverlosen EMR-Sicherheitsgruppen hinzu. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/emr/latest/EMR-Serverless-UserGuide/vpc-access.html) 1. Fügen Sie eine Regel für ausgehenden Datenverkehr von einer der EMR Serverless Security Groups hinzu. Gehen Sie dazu auf eine von zwei Arten vor. Öffnen Sie zunächst den ausgehenden Verkehr zu allen Ports. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/emr/latest/EMR-Serverless-UserGuide/vpc-access.html) Alternativ können Sie den ausgehenden Datenverkehr auf Amazon Redshift Redshift-Cluster beschränken. Dies ist nur nützlich, wenn die Anwendung mit Amazon Redshift Redshift-Clustern kommunizieren muss und sonst nichts. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/emr/latest/EMR-Serverless-UserGuide/vpc-access.html) ## Anwendung konfigurieren Sie können die Netzwerkkonfiguration für eine bestehende EMR Serverless-Anwendung auf der Seite **Anwendung konfigurieren** ändern. ### Greifen Sie auf Details zur Auftragsausführung zu Greifen Sie auf der **Detailseite der Auftragsausführung** auf das Subnetz zu, das von Ihrem Job für einen bestimmten Lauf verwendet wurde. Beachten Sie, dass ein Job nur in einem Subnetz ausgeführt wird, das aus den angegebenen Subnetzen ausgewählt wurde. ## Bewährte Methoden für die Subnetzplanung AWS Ressourcen werden in einem Subnetz erstellt, das eine Teilmenge der verfügbaren IP-Adressen in einer Amazon VPC darstellt. Beispielsweise verfügt eine VPC mit einer /16-Netzmaske über bis zu 65.536 verfügbare IP-Adressen, die mithilfe von Subnetzmasken in mehrere kleinere Netzwerke aufgeteilt werden können. Sie können diesen Bereich beispielsweise in zwei Subnetze aufteilen, von denen jedes die /17-Maske und 32.768 verfügbare IP-Adressen verwendet. Ein Subnetz befindet sich in einer Availability Zone und kann sich nicht zonenübergreifend erstrecken. Die Subnetze sollten unter Berücksichtigung Ihrer Skalierungsgrenzen für serverlose EMR-Anwendungen entworfen werden. Wenn Sie beispielsweise eine Anwendung haben, die 4 vCPU-Worker anfordert und auf bis zu 4.000 vCPUs skaliert werden kann, benötigt Ihre Anwendung maximal 1.000 Worker für insgesamt 1.000 Netzwerkschnittstellen. Wir empfehlen, Subnetze für mehrere Availability Zones zu erstellen. Auf diese Weise kann EMR Serverless in einem unwahrscheinlichen Fall, wenn eine Availability Zone ausfällt, Ihren Job erneut versuchen oder vorinitialisierte Kapazität in einer anderen Availability Zone bereitstellen. Daher sollte jedes Subnetz in mindestens zwei Availability Zones über mehr als 1.000 verfügbare IP-Adressen verfügen. Sie benötigen Subnetze mit einer Maskengröße von weniger als oder gleich 22, um 1.000 Netzwerkschnittstellen bereitzustellen. Jede Maske, die größer als 22 ist, erfüllt die Anforderung nicht. Eine Subnetzmaske von /23 bietet beispielsweise 512 IP-Adressen, während eine Maske von /22 1024 und eine Maske von /21 2048 IP-Adressen bereitstellt. Im Folgenden finden Sie ein Beispiel für 4 Subnetze mit /22-Maske in einer VPC mit /16-Netzmaske, die verschiedenen Availability Zones zugewiesen werden können. Es gibt einen Unterschied von fünf zwischen verfügbaren und verwendbaren IP-Adressen, da die ersten vier IP-Adressen und die letzte IP-Adresse in jedem Subnetz von reserviert sind. AWS | Subnetz-ID | Subnetz-Adresse | Subnetzmaske | IP-Adressbereiche | Verfügbare IP-Adressen | Verwendbare IP-Adressen | | --- | --- | --- | --- | --- | --- | | 1 | 10.0.0.0 | 255,255,252,0/22 | 10,0,0,0 - 10,0,3,255 | 1,024 | 1.019 | | 2 | 10.0.4.0 | 255,255,252,0/22 | 10,0,4,0 - 10,0,7,255 | 1,024 | 1.019 | | 3 | 10.0.8.0 | 255,255,252,0/22 | 10,0,8,0 - 10,0,11,255 | 1,024 | 1.019 | | 4 | 10.0.12.0 | 255,255,252,0/22 | 10,0,12,0 - 10,0,15,255 | 1,024 | 1.019 | Sie sollten abwägen, ob Ihr Workload am besten für größere Mitarbeiter geeignet ist. Für die Verwendung größerer Mitarbeiter sind weniger Netzwerkschnittstellen erforderlich. Beispielsweise sind für die Verwendung von 16 vCPU-Workern mit einem Anwendungsskalierungslimit von 4.000 vCPUs höchstens 250 Worker für insgesamt 250 verfügbare IP-Adressen für die Bereitstellung von Netzwerkschnittstellen erforderlich. Sie benötigen Subnetze in mehreren Availability Zones mit einer Maskengröße von weniger als oder gleich 24, um 250 Netzwerkschnittstellen bereitzustellen. Jede Maskengröße von mehr als 24 bietet weniger als 250 IP-Adressen. Wenn Sie Subnetze für mehrere Anwendungen gemeinsam nutzen, sollte jedes Subnetz so konzipiert werden, dass die kollektiven Skalierungsgrenzen all Ihrer Anwendungen berücksichtigt werden. Wenn Sie beispielsweise 3 Anwendungen haben, die 4 vCPU-Worker anfordern, und jede Anwendung kann auf bis zu 4000 vCPUs mit einem dienstbasierten Kontingent von 12.000 vCPUs skaliert werden, benötigt jedes Subnetz 3000 verfügbare IP-Adressen. Wenn die VPC, die Sie verwenden möchten, nicht über eine ausreichende Anzahl von IP-Adressen verfügt, versuchen Sie, die Anzahl der verfügbaren IP-Adressen zu erhöhen. Das ist möglich, indem Sie zusätzliche CIDR-Blöcke (Classless Inter-Domain Routing) mit Ihrer VPC verbinden. Weitere Informationen finden Sie unter [Zusätzliche IPv4 CIDR-Blöcke mit Ihrer VPC verknüpfen](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#add-ipv4-cidr) im *Amazon VPC-Benutzerhandbuch*. Sie können eines der vielen online verfügbaren Tools verwenden, um schnell Subnetzdefinitionen zu generieren und den verfügbaren IP-Adressbereich zu überprüfen. # Optionen für die serverlose Architektur von Amazon EMR Die Befehlssatzarchitektur Ihrer Amazon EMR Serverless-Anwendung bestimmt die Art der Prozessoren, die die Anwendung zur Ausführung des Jobs verwendet. **Amazon EMR bietet zwei Architekturoptionen für Ihre Anwendung: **x86\$164** und arm64.** EMR Serverless aktualisiert automatisch auf die neueste Generation von Instances, sobald diese verfügbar sind, sodass Ihre Anwendungen die neueren Instances ohne zusätzlichen Aufwand verwenden können. **Topics** + [Verwendung der x86\$164-Architektur](#x86) + [Verwendung der Arm64-Architektur (Graviton)](#arm64) + [Einführung neuer Anwendungen mit Graviton-Unterstützung](#arm64-new) + [Konfiguration vorhandener Anwendungen für die Verwendung von Graviton](#arm64-existing) + [Überlegungen zur Verwendung von Graviton](#arm64-considerations) ## Verwendung der x86\$164-Architektur Die **x86\$164-Architektur wird auch als x86 64-Bit oder x64** bezeichnet. **x86\$164** ist die Standardoption für serverlose EMR-Anwendungen. Diese Architektur verwendet x86-basierte Prozessoren und ist mit den meisten Tools und Bibliotheken von Drittanbietern kompatibel. **Die meisten Anwendungen sind mit der x86-Hardwareplattform kompatibel und können erfolgreich auf der x86\$164-Standardarchitektur ausgeführt werden.** Wenn Ihre Anwendung jedoch mit 64-Bit-ARM kompatibel ist, wechseln Sie zu **arm64**, um Graviton-Prozessoren zu verwenden, um Leistung, Rechenleistung und Speicher zu verbessern. Es kostet weniger, Instanzen auf einer arm64-Architektur auszuführen, als wenn Sie Instanzen gleicher Größe auf einer x86-Architektur ausführen. ## Verwendung der Arm64-Architektur (Graviton) AWS Graviton-Prozessoren wurden speziell AWS mit 64-Bit-ARM-Neoverse-Kernen entwickelt und nutzen die Arm64-Architektur (auch bekannt als Arch64 oder 64-Bit-ARM). Die AWS auf EMR Serverless verfügbaren Graviton-Prozessoren umfassen Graviton3- und Graviton2-Prozessoren. Diese Prozessoren bieten ein hervorragendes Preis-Leistungs-Verhältnis für Spark- und Hive-Workloads im Vergleich zu vergleichbaren Workloads, die auf der x86\$164-Architektur ausgeführt werden. EMR Serverless verwendet automatisch die neueste Generation von Prozessoren, sofern verfügbar, ohne dass Sie ein Upgrade auf die neueste Prozessorgeneration vornehmen müssen. ## Einführung neuer Anwendungen mit Graviton-Unterstützung Verwenden Sie eine der folgenden Methoden, um eine Anwendung zu starten, die die **Arm64-Architektur** verwendet. ------ #### [ AWS CLI ] Um eine Anwendung mit Graviton-Prozessoren von aus zu starten AWS CLI, geben Sie dies `ARM64` als `architecture` Parameter in der `create-application` API an. Geben Sie in den anderen Parametern die entsprechenden Werte für Ihre Anwendung an. ``` aws emr-serverless create-application \ --name my-graviton-app \ --release-label emr-6.8.0 \ --type "SPARK" \ --architecture "ARM64" \ --region us-west-2 ``` ------ #### [ EMR Studio ] Um eine Anwendung mit Graviton-Prozessoren von EMR Studio aus zu starten, wählen Sie **arm64** als **Architekturoption**, wenn Sie eine Anwendung erstellen oder aktualisieren. ------ ## Konfiguration vorhandener Anwendungen für die Verwendung von Graviton Sie können Ihre vorhandenen Amazon EMR Serverless-Anwendungen so konfigurieren, dass sie die Graviton-Architektur (arm64) mit dem SDK oder EMR Studio verwenden. AWS CLI **Um eine bestehende Anwendung von x86 nach arm64 zu konvertieren** 1. Vergewissern Sie sich, dass Sie die neueste Hauptversion des [AWS CLI/SDK](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/emr-serverless/index.html#cli-aws-emr-serverless) verwenden, die den `architecture` Parameter unterstützt. 1. Vergewissern Sie sich, dass keine Jobs ausgeführt werden, und beenden Sie dann die Anwendung. ``` aws emr-serverless stop-application \ --application-id application-id \ --region us-west-2 ``` 1. Um die Anwendung `ARM64` für die Verwendung von Graviton zu aktualisieren, geben Sie den `architecture` Parameter in der `update-application` API an. ``` aws emr-serverless update-application \ --application-id application-id \ --architecture 'ARM64' \ --region us-west-2 ``` 1. Verwenden Sie die `get-application` API, um zu überprüfen ARM64, ob die CPU-Architektur der Anwendung aktuell ist. ``` aws emr-serverless get-application \ --application-id application-id \ --region us-west-2 ``` 1. Wenn Sie bereit sind, starten Sie die Anwendung neu. ``` aws emr-serverless start-application \ --application-id application-id \ --region us-west-2 ``` ## Überlegungen zur Verwendung von Graviton Bevor Sie eine EMR Serverless-Anwendung mit arm64 für Graviton-Unterstützung starten, überprüfen Sie Folgendes. ### Bibliothekskompatibilität Wenn Sie Graviton (arm64) als Architekturoption auswählen, stellen Sie sicher, dass Pakete und Bibliotheken von Drittanbietern mit der 64-Bit-ARM-Architektur kompatibel sind. Informationen zum Packen von Python-Bibliotheken in eine virtuelle Python-Umgebung, die mit Ihrer ausgewählten Architektur kompatibel ist, finden Sie unter[Verwenden von Python-Bibliotheken mit EMR Serverless](using-python-libraries.md). Weitere Informationen finden Sie im [AWS Graviton Getting Started](https://github.com/aws/aws-graviton-getting-started) Repository unter GitHub. Dieses Repository enthält wichtige Ressourcen, die Ihnen beim Einstieg in das ARM-basierte Graviton helfen können. # Parallelität von Aufträgen und Warteschlangen für eine serverlose EMR-Anwendung Geben Sie ab Amazon EMR Version 7.0.0 und höher das Zeitlimit für die Warteschlange bei der Auftragsausführung und die Konfiguration der Parallelität für Ihre Anwendung an. Wenn Sie diese Konfiguration angeben, stellt Amazon EMR Serverless Ihren Job zunächst in die Warteschlange und beginnt mit der Ausführung auf der Grundlage der Parallelitätsnutzung in Ihrer Anwendung. Wenn die Parallelität Ihrer Auftragsausführung beispielsweise 10 beträgt, werden in Ihrer Anwendung jeweils nur zehn Jobs ausgeführt. Die verbleibenden Jobs werden in die Warteschlange gestellt, bis einer der laufenden Jobs beendet wird. Wenn das Zeitlimit für die Warteschlange früher erreicht wird, wird das Zeitlimit für Ihren Job überschritten. Weitere Informationen finden Sie unter Status der [Auftragsausführung](job-states.html). ## Hauptvorteile von Parallelität und Warteschlangen Job-Parallelität und Warteschleifenbildung bieten die folgenden Vorteile, wenn viele Jobeinreichungen erforderlich sind: + Es hilft dabei, gleichzeitig ausgeführte Jobs zu kontrollieren, um Ihre Kapazitätsgrenzen auf Anwendungsebene effizient zu nutzen. + Die Warteschlange kann einen plötzlichen Anstieg von Auftragsübermittlungen mit einer konfigurierbaren Timeout-Einstellung enthalten. ## Erste Schritte mit Parallelität und Warteschleifenbildung Die folgenden Verfahren zeigen verschiedene Möglichkeiten, Parallelität und Warteschlangen zu implementieren. **Mit dem AWS CLI** 1. Erstellen Sie eine serverlose Amazon EMR-Anwendung mit Warteschlangen-Timeout und gleichzeitigen Auftragsausführungen: ``` aws emr-serverless create-application \ --release-label emr-7.0.0 \ --type SPARK \ --scheduler-configuration '{"maxConcurrentRuns": 1, "queueTimeoutMinutes": 30}' ``` 1. Aktualisieren Sie eine Anwendung, um das Zeitlimit für die Job-Warteschlange und die Parallelität zu ändern: ``` aws emr-serverless update-application \ --application-id application-id \ --scheduler-configuration '{"maxConcurrentRuns": 5, "queueTimeoutMinutes": 30}' ``` **Anmerkung** Sie können Ihre bestehende Anwendung aktualisieren, um Parallelität und Warteschlangen für Jobs zu aktivieren. Dazu muss die Anwendung das Release-Label *emr-7.0.0* oder höher haben. **Unter Verwendung des AWS-Managementkonsole** Die folgenden Schritte zeigen, wie Sie mit Job-Parallelität und Warteschlangen beginnen können. Verwenden Sie dazu: AWS-Managementkonsole 1. Gehen Sie zu EMR Studio und wählen Sie, ob Sie eine Anwendung mit dem Release-Label EMR-7.0.0 oder höher erstellen möchten. 1. **Wählen Sie unter **Optionen zur Anwendungskonfiguration** die Option Benutzerdefinierte Einstellungen verwenden aus.** 1. Unter **Zusätzliche Konfigurationen** gibt es einen Abschnitt für **Job Run Settings**. Wählen Sie die Option **Jobparallelität aktivieren,** um die Funktion zu aktivieren. 1. Wählen Sie nach der Auswahl **Gleichzeitige Auftragsausführungen** und **Warteschlangen-Timeout aus, um die Anzahl der gleichzeitigen Auftragsausführungen bzw. das Warteschlangen-Timeout** zu konfigurieren. Wenn Sie keine Werte für diese Einstellungen eingeben, werden die Standardwerte verwendet. 1. Wählen Sie **Anwendung erstellen** und die Anwendung wird mit aktivierter Funktion erstellt. Gehen Sie zur Überprüfung zum Dashboard, wählen Sie Ihre Anwendung aus und überprüfen Sie auf der Registerkarte Eigenschaften, ob die Funktion aktiviert ist. Reichen Sie nach der Konfiguration Jobs mit aktivierter Funktion ein. ## Überlegungen zu Parallelität und Warteschleifen Beachten Sie bei der Implementierung von Parallelität und Warteschlangen die folgenden Punkte: + Job-Parallelität und Warteschlangen werden in Amazon EMR Version 7.0.0 und höher unterstützt. + Job-Parallelität und Warteschlangen sind in Amazon EMR Version 7.3.0 und höher standardmäßig aktiviert. + **Sie können die Parallelität für eine Anwendung im Status STARTED nicht aktualisieren.** + Der gültige Bereich für `maxConcurrentRuns` liegt zwischen 1 und 1000 und für `queueTimeoutMinutes` ihn zwischen 15 und 720. + Für ein Konto können sich maximal 2000 Aufträge im Status **QUEUED** befinden. + Parallelität und Warteschleife gelten für Batch- und Streaming-Jobs. Es kann nicht für interaktive Jobs verwendet werden. Weitere Informationen finden Sie unter [Ausführen interaktiver Workloads mit EMR Serverless über EMR](interactive-workloads.html) Studio.