Amazon DEA-C01: Datenorchestrierung und Workflow-Management — Lernleitfaden

By Laurynas Brazys · 2 August 2026 · #amazon #dea-c01 #certification #exam-prep #study-guide

Teil des Amazon Data Engineer Associate DEA-C01 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Orchestrierung und Workflow-Management sind zentral für den Aufbau zuverlässiger, wartbarer Datenplattformen: Sie koordinieren Extract-Transform-Load-Jobs, verwalten Abhängigkeiten, behandeln Fehler und integrieren ereignisgesteuerte Prozesse. Dieser Bereich behandelt verwaltete AWS-Optionen für Batch-ETL, komplexe DAGs, serverlose Zustandsautomaten und die Ereignisplanung – jeweils mit unterschiedlicher Ausführungssemantik, Dauerhaftigkeit und Kompromissen bei der Skalierung. Zu verstehen, wann man AWS Glue Workflows, MWAA, Step Functions oder EventBridge Scheduler einsetzt – und wie man Fehlerbehandlung und Observability konfiguriert – ist entscheidend für vorhersagbare Pipelines und die Kontrolle der Betriebskosten.

AWS Glue Workflows und Trigger

AWS Glue Workflows gruppieren Glue-Jobs, Crawler und Trigger in einem Abhängigkeitsgraphen und ermöglichen die Ausführung koordinierter ETL-Prozesse. Workflows werden über die Konsole oder die CLI erstellt (

undefined

). Trigger werden an Workflows angehängt und es gibt sie in drei Arten: zeitgesteuert (scheduled), bei Bedarf (on-demand) und bedingt (conditional). Beispiel für die Erstellung eines zeitgesteuerten Triggers per CLI:

undefined

Bedingte Trigger verwenden ein Prädikat (Predicate), das sich auf den Jobnamen und den Status (SUCCEEDED, FAILED) bezieht. Beispiel für ein Prädikat in JSON:

undefined

. Standardmäßig werden bedingte Glue-Trigger bei Erfolg ausgelöst; um Fehler zu behandeln, konfigurieren Sie Bedingungen mit State=FAILED oder erstellen Sie einen expliziten FAILED-Trigger, um Fehler an Korrektur-Jobs oder SNS-Benachrichtigungen weiterzuleiten.

Betriebsmuster und Entscheidungskriterien:

• Verwenden Sie Glue Workflows, wenn Sie eine native Orchestrierung von Glue-Jobs/Crawlern und Lineage benötigen; wählen Sie Trigger für die Cron-Planung oder die Verkettung von Jobs nach deren Abschluss.
• Für den Ad-hoc-Aufruf verwenden Sie

undefined

oder

undefined

für On-Demand-Trigger.

• Für komplexe Verzweigungen oder Nicht-Glue-Aufgaben sollten Step Functions oder MWAA bevorzugt werden; Glue Workflows eignen sich am besten, wenn die Pipeline Glue-zentriert ist.

Fehlerbehandlung: Fügen Sie FAILED-Trigger hinzu, senden Sie CloudWatch-Metriken für den Erfolg/Misserfolg von Jobs und leiten Sie Fehler über Lambda an eine SQS/SNS Dead-Letter-Queue weiter, um automatisierte Wiederholungsversuche und Untersuchungen zu ermöglichen.

Amazon MWAA (Managed Airflow) für komplexe DAGs

MWAA stellt eine verwaltete Apache Airflow-Umgebung bereit, um komplexe DAGs, Aufgabenabhängigkeiten, Sensoren und benutzerdefinierte Operatoren auszudrücken. Erstellen Sie Umgebungen mit

undefined

und geben Sie einen S3-Pfad für die DAGs sowie eine Ausführungsrolle an. Wichtige Details zur Dimensionierung und zum Netzwerk:

• MWAA erfordert eine VPC mit privaten Subnetzen und einem NAT-Gateway für den Internetzugang; Setups, die nur öffentliche Subnetze verwenden, werden nicht unterstützt.
• Das Verhalten von Workern und Schedulern wird über Airflow-Konfigurationsoptionen gesteuert, die bei der Erstellung der Umgebung bereitgestellt werden (AirflowConfigurationOptions). Passen Sie die Einstellungen für

undefined

,

undefined

und den Scheduler an die Parallelität der Aufgaben und die Komplexität der DAGs an.

• Überwachen Sie CloudWatch-Metriken (SchedulerHeartbeat, TasksFailed, TasksRunning, QueuedTasks) und skalieren Sie die Worker-Autoscales oder erhöhen Sie die maximale Anzahl an Workern, wenn die Warteschlange wächst.

Entscheidungskriterien:

• Verwenden Sie MWAA, wenn Sie Airflow-Funktionen benötigen: komplexe DAGs, eine große Auswahl an Operatoren, DAG-übergreifende Abhängigkeiten, Sensoren für SLAs/verpasste Aufgaben und benutzerdefinierte Python-Logik.
• Wenn Aufgaben kurzlebig sind und einen extrem hohen Durchsatz erfordern, bevorzugen Sie serverlose Step Functions Express oder Glue für verwaltete ETL-Operationen.
• Belassen Sie rechenintensive, langlaufende Aufgaben in verwalteten Compute-Diensten (Glue/EMR/EKS) und nutzen Sie MWAA-Tasks nur zur Orchestrierung – vermeiden Sie es, massive Datentransformationen auf den MWAA-Workern selbst auszuführen.

Fehlerbehandlung in Airflow: Verwenden Sie Aufgabenwiederholungen (task retries) und

undefined

in den DAG-Definitionen, setzen Sie

undefined

, um Benachrichtigungen zu senden oder Fehler an eine SQS Dead-Letter-Queue zu pushen, und konfigurieren Sie die SLA-Behandlung auf Task-Ebene, um Korrektur-DAGs auszulösen.

AWS Step Functions für serverlose Orchestrierung

Step Functions bieten eine zustandsbehaftete Orchestrierung mit der JSON-basierten Amazon States Language und lassen sich umfassend in AWS-Services integrieren. Wählen Sie zwischen Standard- und Express-Workflows:

• Standard-Workflows: Entwickelt für langlebige, dauerhafte Zustandsautomaten (Monate bis Jahre), mit Exactly-Once-Ausführungssemantik (eindeutig), integriertem Ausführungsverlauf und Tracing/Logging pro Ausführung. Starten Sie mit

undefined

.

• Express-Workflows: Optimiert für hochdurchsatzstarke, latenzarme und kurzzeitige Verarbeitung und sind bei hoher Skalierung kosteneffizient; sie verwenden eine At-Least-Once-Ausführungssemantik, daher müssen Aufgaben idempotent sein oder Deduplizierungsmuster verwenden.

Anwendungsfälle und Entscheidungskriterien:

• Verwenden Sie Standard, wenn Sie langlebige, auditierbare Workflows benötigen, die über lange Zeiträume laufen können und eine Once-Only-Semantik erfordern.
• Verwenden Sie Express für ereignisgesteuerte Mikro-Orchestrierungen mit Tausenden von Ausführungen pro Sekunde, bei denen kurze Dauer und Kosteneffizienz wichtig sind und Sie idempotente Aufgaben entwerfen oder nachgelagerte Deduplizierung implementieren können.

Fehlerbehandlungs- und Integrationsmuster:

• Verwenden Sie Retry-Blöcke in der ASL, um Wiederholungsversuche mit

undefined

,

undefined

,

undefined

und

undefined

zu definieren.

• Verwenden Sie Catch-Blöcke, um Fehler an alternative Zweige oder in einen Fail/Success-Zustand umzuleiten und

undefined

mit Fehlerdetails für die Diagnose zu füllen.

• Für asynchrones Dead-Lettering leiten Sie fehlgeschlagene Nachrichten an SQS/SNS weiter oder entwerfen Sie ein Step-Functions-Muster, das Fehler-Payloads zur Offline-Verarbeitung an eine SQS-DLQ sendet. Aktivieren Sie CloudWatch Logs und X-Ray-Tracing über

undefined

und

undefined

für die Observability.

EventBridge Scheduler und ereignisgesteuerte Pipelines

EventBridge bietet umfassendes Event-Routing und eine Scheduler-Funktion für Cron- und einmalige Aufgaben. Erstellen Sie zeitplanbasierte Regeln mit aws events put-rule --name dailyRule --schedule-expression "cron(0 2 * * ? *)" und fügen Sie Ziele über aws events put-targets hinzu. Für ereignisgesteuertes (musterbasiertes) Routing verwenden Sie put-rule mit --event-pattern '{"source":["aws.s3"],"detail-type":["Object Created"]}', um S3-Ereignisse an Lambda, Step Functions oder SQS weiterzuleiten.

Wichtige operative Punkte:

• EventBridge unterstützt Zeitplanausdrücke (cron und rate). Beachten Sie das Mindestintervall von 5 Minuten für EventBridge-Regeln bei der Verwendung von rate-Ausdrücken; für eine feinere Granularität ziehen Sie Step Functions oder eine Polling-Schicht in Betracht.
• Verwenden Sie den EventBridge Scheduler für einmalige, ad-hoc zukünftige Aufrufe und wiederkehrende Zeitpläne; der Scheduler unterstützt Zeitzonen und flexible Wiederholungseinstellungen pro Ziel und kann eine Dead-Letter-Queue (DLQ) in SQS für unzustellbare Aufrufe konfigurieren.
• Für Pipelines mit hoher Zuverlässigkeit fügen Sie Ziele wie Step Functions, Lambda oder SQS an und konfigurieren Sie zielspezifische Wiederholungsrichtlinien und DLQs. Beispielsweise akzeptiert put-targets eine DeadLetterConfig mit dem Arn einer SQS-Warteschlange.

Fehlerbehandlung: Konfigurieren Sie zielspezifische Wiederholungsversuche und Backoff, verwenden Sie eine DLQ für fehlgeschlagene Zustellungen und kombinieren Sie EventBridge mit Step Functions für komplexe Fehlerbehandlung und kompensierende Transaktionen.

Häufige Fallstricke und Entscheidungskriterien

• Fehler: Verwendung von Express Workflows für nicht-idempotente Aufgaben. Korrekter Ansatz: Idempotenz entwerfen (Deduplizierungsschlüssel, idempotente Lambda) oder Standard Workflows für Exactly-Once-Semantik verwenden.
• Fehler: Annahme, dass bedingte Glue-Trigger bei einem Fehlschlag auslösen. Korrekter Ansatz: Explizit FAILED-Trigger erstellen oder State=FAILED in das Predicate des Triggers aufnehmen, um Fehler weiterzuleiten.
• Fehler: Bereitstellung von MWAA in öffentlichen Subnetzen oder ohne NAT. Korrekter Ansatz: MWAA in privaten Subnetzen platzieren und ein NAT-Gateway oder VPC-Endpunkte für den erforderlichen Servicezugriff bereitstellen.
• Fehler: Erwartung von EventBridge-Zeitplänen im Sub-Minuten-Bereich. Korrekter Ansatz: Denken Sie daran, dass EventBridge-Regeln ein Mindestintervall von 5 Minuten haben; verwenden Sie Step Functions oder Lambda-Timer für Anforderungen unter 5 Minuten.
• Fehler: Keine zentralisierte Retry/Catch-Strategie über Dienste hinweg. Korrekter Ansatz: Standardisierung von Wiederholungsversuchen/Backoff (ASL Retry, EventBridge-Wiederholungskonfiguration, Airflow-Retries) und Verwendung von DLQs, um fehlgeschlagene Ereignisse für die manuelle/automatisierte Behebung aufzubewahren.
• Fehler: Überlastung von MWAA-Workern mit aufwendiger Datenverarbeitung. Korrekter Ansatz: Nur Orchestrierung auf MWAA durchführen, aufwendige Transformationen auf Glue/EMR/EKS ausführen und Zeiger (S3-Pfade) zwischen den Aufgaben übergeben.

Praktisches Problem: Stündlicher ETL bei Acme Retail mit Lastspitzen

Acme Retail benötigt einen stündlichen ETL-Prozess, der Glue-Jobs für die Rohdatenerfassung, einen komplexen Anreicherungs-DAG mit Python-Operatoren und eine kurzlebige SKU-Aggregation ausführt, die auf hochfrequente Bestandsereignisse reagieren muss. Sie fordern robuste Wiederholungsversuche und eine Fehlererfassung.

1. Verwenden Sie EventBridge, um eine stündlich geplante Regel auszulösen, die einen Step Functions Standard Workflow aufruft, um die gesamte Pipeline zu koordinieren.
2. Orchestrieren Sie in Step Functions langlaufende Glue-Jobs (StartJobRun) mit Retry- und Catch-Handlern; leiten Sie im Fehlerfall über einen Catch-Block an eine SQS-DLQ und eine Behebungs-Lambda weiter.
3. Stellen Sie die komplexen Anreicherungs-DAGs in MWAA bereit und rufen Sie sie von Step Functions aus über die Airflow REST API oder durch Platzieren von DAG-Run-Nachrichten in SQS auf; dimensionieren Sie die MWAA-Worker über die celery.worker_autoscale-Einstellungen basierend auf der erwarteten Parallelität und überwachen Sie CloudWatch-Metriken zur Anpassung.
4. Für hochfrequente Bestandsereignisse verwenden Sie EventBridge-Regeln mit Event-Pattern, um Ereignisse an eine Express Step Function oder eine Lambda mit Idempotenzschlüsseln und einer SQS-gestützten DLQ zu senden, um Lastspitzen abzufangen.
5. Implementieren Sie zentralisiertes Monitoring (CloudWatch Logs/Metrics, X-Ray für Step Functions) und richten Sie Alarme für das Anwachsen der DLQ und die Erschöpfung von Task-Wiederholungsversuchen ein.

Begründung: Dieses Design verwendet für jede Anforderung das richtige Werkzeug – Step Functions für langlebige, dienstübergreifende Orchestrierung und Fehlerbehandlung, MWAA für komplexe DAG-Logik, Glue für verwalteten ETL und EventBridge für Zeitplanung und reaktive Ereignisse. Es erzwingt Idempotenz und DLQs für resiliente, beobachtbare Pipelines, die den Best Practices von AWS entsprechen.

← Datentransformation und -verarbeitung · Alle Domänen · Datenabfrage und -analyse →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Amazon durchsuchen →