Amazon DEA-C01: Datenqualität, Validierung und Observability — 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.

Dieser Bereich behandelt die End-to-End-Praktiken und AWS-Services, die verwendet werden, um die Korrektheit von Daten sicherzustellen, Anomalien zu erkennen und die Zuverlässigkeit von Pipelines zu gewährleisten. Starke Validierung und Beobachtbarkeit reduzieren nachgelagerte Fehler, ermöglichen die Einhaltung von SLAs und eine sichere Wiederverarbeitung. Data Engineers müssen Glue Data Quality, Validierungs-Frameworks, CloudWatch-Anomalieerkennung, DLQs und idempotentes Design kombinieren, um robuste Pipelines zu erstellen.

AWS Glue Data Quality-Regeln und -Auswertung

Glue Data Quality verwendet Regelwerke der Data Quality Definition Language (DQDL), um Zusicherungen (Assertions) über Datensätze zu definieren (Zeilenanzahl, Nullwert-Schwellenwerte, Eindeutigkeit, benutzerdefinierte SQL-Prüfungen). Erstellen Sie Regelwerke in der Konsole oder mit der CLI (Beispiel-Pattern:

undefined

). Regelwerke können an Glue-ETL-Jobs angehängt oder unabhängig über die APIs StartDataQualityRuleRecommendationRun / StartDataQualityRulesetEvaluationRun ausgeführt werden, um Datensätze zu bewerten, die in S3, Katalogtabellen oder Glue DynamicFrames gespeichert sind.

Wichtige Konfigurationsdetails und Entscheidungskriterien:

DQDL-Struktur: Regeln umfassen ruleName, expression (DQDL oder SQL), severity (Schweregrad) und action on failure (Aktion bei Fehlschlag). Setzen Sie die Aktion bei Fehlschlag explizit auf FAIL, damit der Job bei kritischen Prüfungen fehlschlägt; andernfalls protokolliert Glue möglicherweise nur die Ergebnisse, ohne den Lauf als fehlgeschlagen zu markieren.
Evaluierungskontext: Geben Sie Tabellen- oder S3-Pfadreferenzen und Sampling-Optionen (vollständiger Scan vs. Stichprobe) über Job-Parameter oder Eingaben für den Evaluierungslauf an, um Kosten und Abdeckung abzuwägen.
Ausgabe: Die Regelauswertung schreibt Ergebnisse in Glue-Metriken und als JSON nach Amazon S3; nutzen Sie diese Artefakte für Audits und automatisierte Korrekturmaßnahmen.

Wann Glue Data Quality im Vergleich zu externen Frameworks verwenden:

Verwenden Sie Glue DQDL für Standardprüfungen von Schema, Vollständigkeit und einfacher Eindeutigkeit, die sich nativ in Glue-Jobs und Lineage integrieren.
Verwenden Sie Great Expectations (siehe nächster Unterbereich), wenn Sie umfangreichere Expectation-Bibliotheken, ausdrucksstärkere Prüfungen oder gemeinsam genutzte Expectation-Suites über mehrere Systeme hinweg benötigen.

Datenvalidierungsmuster in Pipelines

Validierung gehört an mehrere Berührungspunkte: Eingang (Ingress), Transformation und Senke (Sink). Gängige Muster:

Leichte Pre-Ingest-Prüfungen in Lambda/Kinesis-Producern für Schema und grundlegende Wertebereiche, um fehlerhafte Zeilen vor der Pipeline abzulehnen oder umzuleiten.
Serverseitige Validierung in Glue-ETL-(Spark)-Jobs mithilfe von DQDL-Regelwerken und expliziten Validierungen im Code. Fügen Sie in Glue Studio eine Data-Quality-Transformation hinzu, die auf ein Regelwerk verweist; übergeben Sie in der CLI

undefined

oder fügen Sie Job-Parameter hinzu, um Evaluierungsläufe auszulösen.

Validierung nach der Transformation mit Great Expectations, integriert in Glue-Python-Shell- oder Glue-Spark-Jobs. Stellen Sie Expectations in S3 bereit (Verzeichnis expectations/) und laden Sie den DataContext im Job:

undefined

, nachdem die S3-Expectations mit der Job-Umgebung synchronisiert wurden.

Vergleich der Validierungsoptionen:

Glue DQDL
- Vorteile: native Integration, geringer Betriebsaufwand, schreibt Ergebnisse in den Glue-Katalog/Metriken
- Nachteile: weniger ausdrucksstark für komplexe logische Expectations
Great Expectations
- Vorteile: umfangreiche Expectations, Data Docs, integrierte Checkpoints, erweiterbare Backends
- Nachteile: erfordert das Paketieren und Verwalten von Expectations-Artefakten in S3 und die Orchestrierung in Glue-Jobs
Manuelle Prüfungen im Code (Spark/DataFrame)
- Vorteile: volle Flexibilität, hohe Leistung für benutzerdefinierte Logik
- Nachteile: höherer Wartungsaufwand, kein standardisiertes Reporting ohne zusätzlichen Aufwand

Validieren Sie beim Streaming Datensätze während der Übertragung (in-flight) und leiten Sie sie bei einem Fehler an eine SQS-DLQ weiter (konfigurieren Sie die RedrivePolicy mit maxReceiveCount über die AWS CLI oder die Konsole), anstatt sie zu verwerfen. Generieren Sie bei der Stapelverarbeitung (Batch) ein Artefakt mit einem Validierungsbericht und lassen Sie die Verarbeitung fehlschlagen oder stellen Sie die Ausgaben je nach Richtlinie unter Quarantäne.

Anomalieerkennung und Überwachung von Daten-Drift

Verwenden Sie die CloudWatch-Anomalieerkennung für Betriebsmetriken (verarbeitete Datensätze, Fehlerrate, Job-Laufzeit). Erstellen Sie einen Detektor mit der CLI:

undefined

und erstellen Sie dann CloudWatch-Alarme, die sich auf das Band der Anomalieerkennung beziehen. Für Drift auf Datenebene (Verteilungsverschiebungen, Änderungen der Nullwertrate) planen Sie Glue-DataBrew-Profil-Jobs (

undefined

), um Statistiken, Histogramme und Quantile zu berechnen; speichern Sie die Profile als Baselines in S3.

Entscheidungskriterien für Anomalie- vs. Schwellenwertalarme:

Wählen Sie die CloudWatch-Anomalieerkennung, wenn Metrikmuster saisonal oder variabel sind; sie lernt aus vergangenem Verhalten und reduziert die manuelle Anpassung von Schwellenwerten.
Verwenden Sie statische Schwellenwertalarme für binäre Bedingungen (z. B. Job hängt seit > X Stunden), bei denen die Vorhersagbarkeit hoch ist.

Für die automatisierte Drift-Erkennung:

Planen Sie regelmäßige DataBrew-Profil-Jobs (täglich/wöchentlich je nach Datengeschwindigkeit), um Metrik-Baselines zu erfassen (Nullwert-%, Kardinalität, Perzentile).
Vergleichen Sie neue Profilausgaben mit den Baseline-Profilen entweder mit Glue-Regelwerken (benutzerdefinierte SQL-Prüfungen) oder mit benutzerdefinierten Great-Expectations-Expectations, die auf die Baseline-Statistiken verweisen.
Alarmieren Sie über SNS / EventBridge, wenn die Drift Richtlinienschwellenwerte überschreitet oder wenn Anomaliedetektoren ungewöhnliches Metrikverhalten melden.

SLA-Management und Pipeline-Zuverlässigkeit

SLA-Management verbindet Observability mit Fehlerbehebung und Reliability Engineering. Instrumentieren Sie jede Pipeline mit diesen Basismetiken: Durchsatz (Datensätze/Sek.), Latenz (Ingest→Sink), Fehlerrate, Job-/Laufzeit und Downstream-Zählungen. Verwenden Sie CloudWatch Metrics für Glue-Jobs (Job-Laufzeitmetriken), Kinesis/Kafka-Consumer-Lag und benutzerdefinierte Anwendungsmetriken über

undefined

Zuverlässigkeitsmuster und Konfigurationsdetails:

Dead-Letter-Queues (SQS DLQ): Konfigurieren Sie für Streaming-Consumer (Lambda, Kinesis-Consumer) eine DLQ und legen Sie eine RedrivePolicy(maxReceiveCount) fest. Nutzen Sie die DLQ-Aufbewahrung (Retention) und einen separaten Verarbeitungsjob, um DLQ-Nachrichten zu prüfen und erneut zu verarbeiten.
Idempotentes Design: Stellen Sie sicher, dass Sinks idempotente Schreibvorgänge unterstützen – Beispiele:
- DynamoDB: Verwenden Sie PutItem mit bedingten Ausdrücken oder einen zusammengesetzten Schlüssel für ein Idempotenz-Token.
- S3: Schreiben Sie mit atomaren Umbenennungsmustern oder verwenden Sie inhaltsbasierte Schlüssel (Hash des Datensatzes), damit Wiederholungen überschreiben statt duplizieren.
- Redshift/Glue ETL: Verwenden Sie Staging + MERGE nach Schlüssel, um nach der Wiederverarbeitung zu deduplizieren.
Checkpointing: Aktivieren Sie Checkpoints des Kinesis/DynamoDB-Connectors und steuern Sie die Checkpoint-Frequenz der Consumer, um ein Gleichgewicht zwischen dem Wiederverarbeitungsfenster und dem Duplizierungsrisiko zu finden.

Entscheidungskriterien für Wiederholung vs. Fail-Fast:

Bei transienten Fehlern (Drosselung nachgelagerter Systeme) implementieren Sie Wiederholungsversuche mit exponentiellem Backoff und eine DLQ erst nach Erreichen der maximalen Wiederholungsversuche.
Bei Datenqualitätsfehlern (Schema-Inkonsistenz) führen Sie einen Fail-Fast durch und schreiben Sie die fehlerhaften Datensätze zur manuellen Überprüfung mit Metadaten in ein Quarantäne-S3-Präfix.

Häufige Fallstricke und Entscheidungskriterien

Glue Data Quality-Regeln protokollieren standardmäßig Fehler, lassen den Job aber nicht fehlschlagen – konfigurieren Sie die Regelaktion für kritische Prüfungen auf FAIL und hängen Sie die Auswertung des Regelsatzes an den Job-Lauf an.
Streaming-Pipelines ohne DLQs verwerfen oder verlieren fehlgeschlagene Datensätze – konfigurieren Sie immer SQS DLQs (oder persistentes S3-Staging) und eine Redrive Policy zur Überprüfung und Wiederverarbeitung.
Wiederverarbeitung ohne Idempotenz erzeugt doppelte Datensätze – entwerfen Sie deterministische Schlüssel, verwenden Sie Upsert/Merge-Semantik am Sink oder wenden Sie inhaltsbasierte Objektschlüssel für S3 an.
Die Erkennung von Data Drift ohne Basislinien (Baselines) erzeugt rauschanfällige Alarme – planen Sie Glue DataBrew-Profil-Jobs, um Basisstatistiken zu erstellen und zu speichern, und vergleichen Sie dann neue Profile mit diesen.
Eine übermäßige Abhängigkeit von statischen CloudWatch-Schwellenwerten verursacht Fehlalarme (False Positives) – verwenden Sie die CloudWatch-Anomalieerkennung für saisonale/variable Metriken und behalten Sie statische Schwellenwerte für nicht verhandelbare Grenzwerte bei.
Ein zu hoch eingestellter maxReceiveCount verzögert das DLQ-Routing und erhöht die Verarbeitungslatenz – wählen Sie einen sinnvollen maxReceiveCount, damit DLQs dauerhaft fehlschlagende Nachrichten zeitnah erhalten.

Praktisches Problem: Anwendungsfallszenario

Streamline Retail hat nach dem nächtlichen ETL mit häufigen Fehlern im nachgelagerten Reporting zu kämpfen: gelegentliche Schema-Spitzen, stille Regelverstöße und doppelte Bestellungen bei der Wiederverarbeitung fehlgeschlagener Läufe.

Implementieren Sie Glue Data Quality-Regeln (DQDL) für Schema, Nullwert-Schwellenwerte und Eindeutigkeit von order_id; setzen Sie die Aktion bei einem Fehler auf FAIL für den Job und veröffentlichen Sie die Auswertungsartefakte in S3.
Fügen Sie Great Expectations in einem Glue Python Shell-Schritt für komplexe Geschäftslogikprüfungen hinzu (Bestellkonsistenz über Tabellen hinweg); speichern Sie die Expectations in S3 und führen Sie Checkpoints in der Pipeline aus.
Planen Sie DataBrew-Profil-Jobs, um tägliche Basislinien (Kardinalität, Null-Rate, Perzentile) zu erfassen und nutzen Sie automatisierte Vergleiche zur Erkennung von Drift.
Konfigurieren Sie für Streaming-Bestellereignisse eine SQS DLQ mit einer geeigneten RedrivePolicy und erstellen Sie einen Replay-Job, um DLQ-Nachrichten idempotent zu verarbeiten (unter Verwendung von order_id als Deduplizierungsschlüssel).
Instrumentieren Sie CloudWatch-Anomaliedetektoren für die Job-Laufzeit und die Fehleranzahl; hängen Sie anomaliebasierte Alarme an SNS für die Eskalation an die Rufbereitschaft.

Begründung der AWS Best Practice: Kombinieren Sie native Glue-Qualitätskontrollen für eine schnelle Integration, Great Expectations für die Ausdrucksstärke, DataBrew für Basisstatistiken und CloudWatch-Anomaliedetektoren für eine adaptive Überwachung. DLQs und idempotente Sinks schließen den Kreis für sichere Wiederholungsversuche und Wiederverarbeitung unter Einhaltung der SLAs.

← Kostenoptimierung für Daten-Workloads · Alle Domänen

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