

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.

# Streaming-Jobs für die Verarbeitung kontinuierlich gestreamter Daten
<a name="jobs-streaming"></a>

Ein Streaming-Job in EMR Serverless ist ein Jobmodus, mit dem Sie Streaming-Daten nahezu in Echtzeit analysieren und verarbeiten können. Diese lang andauernden Jobs fragen Streaming-Daten ab und verarbeiten die Ergebnisse kontinuierlich, sobald Daten eintreffen. Streaming-Jobs eignen sich am besten für Aufgaben, die eine Datenverarbeitung in Echtzeit erfordern, wie z. B. Analysen, Betrugserkennung und Empfehlungsprogramme nahezu in Echtzeit. Serverlose EMR-Streaming-Jobs bieten Optimierungen, wie z. B. integrierte Job-Resilienz, Echtzeitüberwachung, verbessertes Protokollmanagement und Integration mit Streaming-Connectoren.

Im Folgenden sind einige Anwendungsfälle für Streaming-Jobs aufgeführt:
+ **Analysen nahezu in Echtzeit** — Mit Streaming-Jobs in Amazon EMR Serverless können Sie Streaming-Daten nahezu in Echtzeit verarbeiten, sodass Sie Echtzeitanalysen für kontinuierliche Datenströme wie Protokolldaten, Sensordaten oder Clickstream-Daten durchführen können, um Erkenntnisse zu gewinnen und zeitnahe Entscheidungen auf der Grundlage der neuesten Informationen zu treffen.
+ **Betrugserkennung** — Verwenden Sie Streaming-Jobs, um Betrug bei Finanztransaktionen, Kreditkartenoperationen oder Online-Aktivitäten nahezu in Echtzeit zu erkennen, wenn Sie Datenströme analysieren und verdächtige Muster oder Anomalien identifizieren, sobald sie auftreten.
+ **Empfehlungs-Engines** — Streaming-Jobs können Benutzeraktivitätsdaten verarbeiten und Empfehlungsmodelle aktualisieren. Dies eröffnet Möglichkeiten für personalisierte Empfehlungen in Echtzeit, die auf Verhaltensweisen und Präferenzen basieren.
+ **Analyse sozialer Medien** — Streaming-Jobs können Social-Media-Daten wie Tweets, Kommentare und Beiträge verarbeiten, sodass Unternehmen Trends verfolgen, Stimmungsanalysen durchführen und den Ruf der Marke nahezu in Echtzeit verwalten können.
+ **IoT-Analysen (Internet of Things)** — Streaming-Jobs können Datenströme mit hoher Geschwindigkeit von IoT-Geräten, Sensoren und verbundenen Maschinen verarbeiten und analysieren, sodass Anomalieerkennung, vorausschauende Wartung und andere Anwendungsfälle für IoT-Analysen durchgeführt werden können. 
+ **Clickstream-Analyse** — Streaming-Jobs können Clickstream-Daten von Websites oder mobilen Anwendungen verarbeiten und analysieren. Unternehmen, die solche Daten verwenden, können Analysen durchführen, um mehr über das Nutzerverhalten zu erfahren, Benutzererlebnisse zu personalisieren und Marketingkampagnen zu optimieren.
+ **Überwachung und Analyse von Protokollen** — Streaming-Jobs können auch Protokolldaten von Servern, Anwendungen und Netzwerkgeräten verarbeiten. Auf diese Weise können Sie Anomalien erkennen, Fehler beheben und den Zustand und die Leistung Ihres Systems verbessern.

**Die wichtigsten Vorteile**

Streaming-Jobs in EMR Serverless sorgen automatisch für *Job-Resilienz*, die sich aus einer Kombination der folgenden Faktoren ergibt:
+ **Automatische Wiederholung** — EMR Serverless wiederholt automatisch alle fehlgeschlagenen Jobs ohne manuelles Eingreifen Ihrerseits.
+ **Resilienz in der Availability Zone (AZ)** — EMR Serverless schaltet Streaming-Jobs automatisch auf eine fehlerfreie AZ um, wenn in der ursprünglichen AZ Probleme auftreten.
+ **Protokollverwaltung:**
  + **Protokollrotation** — Für eine effizientere Festplattenspeicherverwaltung rotiert EMR Serverless die Protokolle für lange Streaming-Jobs regelmäßig. Dadurch wird eine Anhäufung von Protokollen verhindert, die möglicherweise den gesamten Festplattenspeicher beansprucht.
  + **Protokollkomprimierung —** unterstützt Sie bei der effizienten Verwaltung und Optimierung von Protokolldateien in verwalteter Persistenz. Die Komprimierung verbessert auch das Debug-Erlebnis, wenn Sie den Managed Spark History Server verwenden.

**Unterstützte Datenquellen und Datensenken**

EMR Serverless arbeitet mit einer Reihe von Eingabedatenquellen und Ausgabedatensenken:
+ Unterstützte Eingabedatenquellen — Amazon Kinesis Data Streams, Amazon Managed Streaming for Apache Kafka und selbstverwaltete Apache Kafka-Cluster. Standardmäßig enthalten Amazon EMR-Versionen 7.1.0 und höher den [Amazon Kinesis Data Streams Streams-Connector](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-structured-streaming-kinesis.html), sodass Sie keine zusätzlichen Pakete erstellen oder herunterladen müssen.
+ Unterstützte Ausgabedatensenken — AWS Glue Data Catalog-Tabellen, Amazon S3, Amazon Redshift, MySQL, PostgreSQL Oracle, Oracle, Microsoft SQL, Apache Iceberg, Delta Lake und Apache Hudi.

## Überlegungen und Einschränkungen
<a name="jobs-spark-streaming-considerations"></a>

Beachten Sie bei der Verwendung von Streaming-Jobs die folgenden Überlegungen und Einschränkungen.
+ Streaming-Jobs werden mit [Amazon EMR-Versionen 7.1.0 und](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-710-release.html) höher unterstützt.
+ EMR Serverless geht davon aus, dass Streaming-Jobs über einen längeren Zeitraum ausgeführt werden. Sie können daher kein Ausführungstimeout festlegen, um die Laufzeit des Jobs zu begrenzen.
+ Streaming-Jobs sind nur mit der Spark-Engine kompatibel, die auf dem [strukturierten](https://spark.apache.org/streaming/) Streaming-Framework basiert.
+ EMR Serverless versucht auf unbestimmte Zeit erneut, Streaming-Jobs zu streamen, und Sie können die Anzahl der maximalen Versuche nicht anpassen. Der Thrash-Schutz ist automatisch enthalten, um die Auftragswiederholung zu beenden, wenn die Anzahl der fehlgeschlagenen Versuche einen innerhalb eines Stundenfensters festgelegten Schwellenwert überschreitet. Der Standardschwellenwert liegt bei fünf fehlgeschlagenen Versuchen innerhalb einer Stunde. Sie können diesen Schwellenwert so konfigurieren, dass er zwischen 1 und 10 Versuchen liegt. Weitere Informationen finden Sie unter [Job Resiliency.](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/SECTION-jobs-resiliency.xml.html)
+ Streaming-Jobs verfügen über Checkpoints, um den Laufzeitstatus und den Fortschritt zu speichern, sodass EMR Serverless den Streaming-Job vom letzten Checkpoint aus fortsetzen kann. Weitere Informationen finden Sie unter [Recovering from failure with Checkpointing in der Apache Spark-Dokumentation](https://spark.apache.org/docs/latest/structured-streaming-programming-guide.html#recovering-from-failures-with-checkpointing).

# Erste Schritte beim Streamen von Jobs
<a name="jobs-spark-streaming-getting-started"></a>

In den folgenden Anweisungen erfahren Sie, wie Sie mit Streaming-Jobs beginnen können.

1. Folgen Sie [Getting started with Amazon EMR Serverless, um eine Anwendung zu erstellen](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/getting-started.html). Beachten Sie, dass Ihre Anwendung [Amazon EMR Version 7.1.0](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-710-release.html) oder höher ausführen muss.

1. Sobald Ihre Anwendung bereit ist, setzen Sie den `mode` Parameter auf, `STREAMING` um einen Streaming-Job zu senden, ähnlich dem folgenden AWS CLI Beispiel.

   ```
   aws emr-serverless start-job-run \
   --application-id <APPPLICATION_ID> \
   --execution-role-arn <JOB_EXECUTION_ROLE> \
   --mode 'STREAMING' \
   --job-driver '{
       "sparkSubmit": {
           "entryPoint": "s3://<streaming script>",
           "entryPointArguments": ["s3://<DOC-EXAMPLE-BUCKET-OUTPUT>/output"],
           "sparkSubmitParameters": "--conf spark.executor.cores=4
               --conf spark.executor.memory=16g 
               --conf spark.driver.cores=4
               --conf spark.driver.memory=16g 
               --conf spark.executor.instances=3"
       }
   }'
   ```

# Unterstützte Streaming-Konnektoren
<a name="jobs-spark-streaming-connectors"></a>

Streaming-Konnektoren erleichtern das Lesen von Daten aus einer Streaming-Quelle und können auch Daten in eine Streaming-Senke schreiben.

Die folgenden Streaming-Connectoren werden unterstützt:

**Amazon Kinesis Data Streams Streams-Konnektor**

Der [Amazon Kinesis Data Streams-Connector](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-structured-streaming-kinesis.html) für Apache Spark ermöglicht die Erstellung von Streaming-Anwendungen und -Pipelines, die Daten von Amazon Kinesis Data Streams nutzen und Daten in Amazon Kinesis Data Streams schreiben. Der Connector unterstützt einen erhöhten Fan-Out-Verbrauch mit einer speziellen Lesedurchsatzrate von bis zu 2 MB/Sekunde pro Shard. Standardmäßig enthalten Amazon EMR Serverless 7.1.0 und höher den Connector, sodass Sie keine zusätzlichen Pakete erstellen oder herunterladen müssen. [Weitere Informationen zum Connector finden Sie auf der spark-sql-kinesis-connector Seite unter. GitHub](https://github.com/awslabs/spark-sql-kinesis-connector/)

Im Folgenden finden Sie ein Beispiel dafür, wie Sie eine Jobausführung mit der Kinesis Data Streams Streams-Konnektorabhängigkeit starten.

```
aws emr-serverless start-job-run \
--application-id <APPLICATION_ID> \
--execution-role-arn <JOB_EXECUTION_ROLE> \
--mode 'STREAMING' \
--job-driver '{
    "sparkSubmit": {
        "entryPoint": "s3://<Kinesis-streaming-script>",
        "entryPointArguments": ["s3://<DOC-EXAMPLE-BUCKET-OUTPUT>/output"],
        "sparkSubmitParameters": "--conf spark.executor.cores=4
                --conf spark.executor.memory=16g 
                --conf spark.driver.cores=4
                --conf spark.driver.memory=16g 
                --conf spark.executor.instances=3
                --jars /usr/share/aws/kinesis/spark-sql-kinesis/lib/spark-streaming-sql-kinesis-connector.jar"
    }
}'
```

Um eine Verbindung zu Kinesis Data Streams herzustellen, konfigurieren Sie die EMR Serverless-Anwendung mit VPC-Zugriff und verwenden Sie einen VPC-Endpunkt, um privaten Zugriff zu ermöglichen. Oder verwenden Sie ein NAT-Gateway, um öffentlichen Zugriff zu erhalten. Weitere Informationen finden Sie unter [VPC-Zugriff konfigurieren](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/vpc-access.html). Sie müssen außerdem sicherstellen, dass Ihre Job-Runtime-Rolle über die erforderlichen Lese- und Schreibberechtigungen für den Zugriff auf die erforderlichen Datenströme verfügt. Weitere Informationen zur Konfiguration einer Job-Runtime-Rolle finden Sie unter [Job-Runtime-Rollen für Amazon EMR Serverless](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/security-iam-runtime-role.html). Eine vollständige Liste aller erforderlichen Berechtigungen finden Sie auf der [spark-sql-kinesis-connector Seite](https://github.com/awslabs/spark-sql-kinesis-connector/?tab=readme-ov-file#how-to-use-it) unter. GitHub

**Apache Kafka-Konnektor**

Der Apache Kafka-Konnektor für strukturiertes Spark-Streaming ist ein Open-Source-Konnektor der Spark-Community und in einem Maven-Repository verfügbar. Dieser Konnektor ermöglicht es strukturierten Spark-Streaming-Anwendungen, Daten aus selbstverwaltetem Apache Kafka und Amazon Managed Managed Streaming for Apache Kafka Apache Kafka zu lesen und Daten in diese zu schreiben. Weitere Informationen über den Konnektor finden Sie im [Structured Streaming \$1 Kafka Integration Guide](https://spark.apache.org/docs/latest/structured-streaming-kafka-integration.html) in der Apache Spark-Dokumentation.

Das folgende Beispiel zeigt, wie Sie den Kafka-Konnektor in Ihre Job-Run-Anforderung aufnehmen können.

```
aws emr-serverless start-job-run \
--application-id <APPLICATION_ID> \
--execution-role-arn <JOB_EXECUTION_ROLE> \
--mode 'STREAMING' \
--job-driver '{
    "sparkSubmit": {
        "entryPoint": "s3://<Kafka-streaming-script>",
        "entryPointArguments": ["s3://<DOC-EXAMPLE-BUCKET-OUTPUT>/output"],
        "sparkSubmitParameters": "--conf spark.executor.cores=4
                --conf spark.executor.memory=16g 
                --conf spark.driver.cores=4
                --conf spark.driver.memory=16g 
                --conf spark.executor.instances=3
                --packages org.apache.spark:spark-sql-kafka-0-10_2.12:<KAFKA_CONNECTOR_VERSION>"
    }
}'
```

Die Version des Apache Kafka-Connectors hängt von Ihrer EMR Serverless Release-Version und der entsprechenden Spark-Version ab. Die richtige Kafka-Version finden Sie im [Structured Streaming \$1](https://spark.apache.org/docs/latest/structured-streaming-kafka-integration.html) Kafka Integration Guide.

Um Amazon Managed Streaming for Apache Kafka mit IAM-Authentifizierung zu verwenden, fügen Sie eine weitere Abhängigkeit hinzu, damit der Kafka-Connector über IAM eine Verbindung zu Amazon MSK herstellen kann. [Weitere Informationen finden Sie im Repository unter. aws-msk-iam-auth GitHub](https://github.com/aws/aws-msk-iam-auth) Sie müssen außerdem sicherstellen, dass die Job-Runtime-Rolle über die erforderlichen IAM-Berechtigungen verfügt. Das folgende Beispiel zeigt, wie der Connector mit IAM-Authentifizierung verwendet wird.

```
aws emr-serverless start-job-run \
--application-id <APPLICATION_ID> \
--execution-role-arn <JOB_EXECUTION_ROLE> \
--mode 'STREAMING' \
--job-driver '{
    "sparkSubmit": {
        "entryPoint": "s3://<Kafka-streaming-script>",
        "entryPointArguments": ["s3://<DOC-EXAMPLE-BUCKET-OUTPUT>/output"],
        "sparkSubmitParameters": "--conf spark.executor.cores=4
                --conf spark.executor.memory=16g 
                --conf spark.driver.cores=4
                --conf spark.driver.memory=16g 
                --conf spark.executor.instances=3
                --packages org.apache.spark:spark-sql-kafka-0-10_2.12:<KAFKA_CONNECTOR_VERSION>,software.amazon.msk:aws-msk-iam-auth:<MSK_IAM_LIB_VERSION>"
    }
}'
```

Um den Kafka-Connector und die IAM-Authentifizierungsbibliothek von Amazon MSK zu verwenden, konfigurieren Sie die EMR Serverless-Anwendung mit VPC-Zugriff. Ihre Subnetze müssen über Internetzugang verfügen und ein NAT-Gateway verwenden, um auf die Maven-Abhängigkeiten zuzugreifen. Weitere Informationen finden Sie unter [VPC-Zugriff konfigurieren](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/vpc-access.html). Die Subnetze müssen über Netzwerkkonnektivität verfügen, um auf den Kafka-Cluster zugreifen zu können. Dies gilt unabhängig davon, ob Ihr Kafka-Cluster selbst verwaltet wird oder ob Sie Amazon Managed Managed Streaming for Apache Kafka verwenden. 

# Verwaltung von Streaming-Job-Protokollen
<a name="jobs-spark-streaming-log-management"></a>

Streaming-Jobs unterstützen die Protokollrotation für Spark-Anwendungsprotokolle und -Ereignisprotokolle sowie die Protokollkomprimierung für Spark-Ereignisprotokolle. Dies hilft Ihnen, Ihre Ressourcen effektiv zu verwalten.

**Rotation protokollieren**

Streaming-Jobs unterstützen die Protokollrotation für Spark-Anwendungsprotokolle und Ereignisprotokolle. Die Protokollrotation verhindert, dass lange Streaming-Jobs große Protokolldateien generieren, die Ihren gesamten verfügbaren Speicherplatz beanspruchen könnten. Die Protokollrotation hilft Ihnen, Festplattenspeicher zu sparen, und verhindert Jobfehler, die auf zu wenig Speicherplatz zurückzuführen sind. Weitere Informationen finden Sie unter [Rotation von Protokollen](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/rotating-logs.html). 

**Verdichtung von Protokollen**

Streaming-Jobs unterstützen auch die Protokollkomprimierung für Spark-Ereignisprotokolle, sofern verwaltete Protokollierung verfügbar ist. Weitere Informationen zur verwalteten Protokollierung finden Sie unter [Protokollierung mit verwaltetem Speicher](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/logging.html#jobs-log-storage-managed-storage). Streaming-Jobs können lange laufen, und die Menge an Ereignisdaten kann sich im Laufe der Zeit ansammeln und die Größe der Protokolldateien erheblich erhöhen. Der Spark History Server liest diese Ereignisse und lädt sie in den Speicher für die Benutzeroberfläche der Spark-Anwendung. Dieser Prozess kann hohe Latenzen und Kosten verursachen, insbesondere wenn die in Amazon S3 gespeicherten Ereignisprotokolle sehr umfangreich sind. 

Durch die Protokollkomprimierung wird die Größe des Ereignisprotokolls reduziert, sodass der Spark History Server zu keinem Zeitpunkt mehr als 1 GB an Ereignisprotokollen laden muss. Weitere Informationen finden Sie unter [Monitoring and Instrumentation](https://spark.apache.org/docs/latest/monitoring.html) in der Apache Spark-Dokumentation.