Amazon DEA-C01: Datakwaliteit, validatie en observeerbaarheid — Studiegids

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

Onderdeel van de Amazon Data Engineer Associate DEA-C01 — Studiegids. Oefen met geverifieerde antwoorden in het Amazon-examencentrum, of doe getimede oefentests op ExamRoll.io.

Dit domein behandelt de end-to-end-praktijken en AWS-services die worden gebruikt om de correctheid van data te waarborgen, afwijkingen te detecteren en pipelines betrouwbaar te houden. Sterke validatie en observeerbaarheid verminderen defecten verderop in de keten, zorgen ervoor dat SLA’s worden gehaald en maken veilige herverwerking mogelijk. Data-engineers moeten Glue Data Quality, validatieframeworks, CloudWatch-anomaliedetectie, DLQ’s en een idempotent ontwerp combineren om robuuste pipelines te bouwen.

AWS Glue Data Quality-regels en -evaluatie

Glue Data Quality gebruikt Data Quality Definition Language (DQDL)-regelsets om beweringen over datasets te definiëren (aantal rijen, null-drempels, uniciteit, aangepaste SQL-controles). Maak regelsets aan in de console of met de CLI (voorbeeldpatroon:

undefined

). Regelsets kunnen worden gekoppeld aan Glue ETL-jobs of onafhankelijk worden uitgevoerd via de

undefined

API’s om datasets te evalueren die zijn opgeslagen in S3, catalogustabellen of Glue DynamicFrames.

Belangrijke configuratiedetails en beslissingscriteria:

DQDL-structuur: regels bevatten

undefined

(DQDL of SQL),

undefined

. Stel de actie bij falen expliciet in op

undefined

om de job te laten mislukken wanneer kritieke controles falen; anders zal Glue de resultaten mogelijk alleen loggen zonder de run te laten mislukken.

Evaluatiecontext: geef tabel- of S3-padreferenties en sampling-opties (volledige scan vs. steekproef) op via jobparameters of invoer voor de evaluatierun om een balans te vinden tussen kosten en dekking.
Output: de regelevaluatie schrijft resultaten naar Glue-metrics en naar Amazon S3 als JSON; gebruik deze artefacten voor audits en geautomatiseerd herstel.

Wanneer Glue Data Quality gebruiken versus externe frameworks:

Gebruik Glue DQDL voor standaard schema-, volledigheids- en eenvoudige uniciteitsregels die native integreren in Glue-jobs en lineage.
Gebruik Great Expectations (zie volgend subdomein) wanneer u rijkere ’expectation’-bibliotheken, expressievere controles of gedeelde ’expectation suites’ voor meerdere systemen nodig heeft.

Datavalidatiepatronen in pipelines

Validatie hoort thuis op meerdere contactpunten: ingress, transformatie en sink. Veelvoorkomende patronen:

Lichtgewicht pre-ingest-controles in Lambda/Kinesis-producers voor schema en basis-waardebereiken om slechte rijen te weigeren of om te leiden voordat ze de pipeline ingaan.
Server-side validatie in Glue ETL (Spark)-jobs met behulp van DQDL-regelsets en expliciete validaties in code. Voeg in Glue Studio een Data Quality-transformatie toe die naar een regelset verwijst; geef in de CLI

undefined

mee of voeg jobparameters toe om evaluatieruns te activeren.

Post-transformatie validatie met Great Expectations geïntegreerd in Glue Python Shell- of Glue Spark-jobs. Implementeer ’expectations’ naar S3 (

undefined

-directory) en laad de DataContext in de job:

undefined

na het synchroniseren van de S3-’expectations’ met de jobomgeving.

Vergelijking van validatie-opties:

Glue DQDL
- Voordelen: native integratie, lage operationele overhead, schrijft resultaten naar Glue-catalogus/metrics
- Nadelen: minder expressief voor complexe logische ’expectations'
Great Expectations
- Voordelen: rijke ’expectations’, ‘data docs’, geïntegreerde ‘checkpoints’, uitbreidbare backends
- Nadelen: vereist het verpakken en beheren van ’expectations’-artefacten in S3 en orkestratie in Glue-jobs
Handmatige controles in code (Spark/DataFrame)
- Voordelen: volledige flexibiliteit, hoge prestaties voor aangepaste logica
- Nadelen: meer onderhoud, geen gestandaardiseerde rapportage zonder extra werk

Voor streaming, valideer records ‘in-flight’ en stuur ze bij een fout naar een SQS DLQ (configureer

undefined

met

undefined

via de AWS CLI of console) in plaats van ze te verwijderen. Voor batch, genereer een validatierapport-artefact en laat de outputs mislukken of plaats ze in quarantaine op basis van het beleid.

Anomaliedetectie en monitoring van data drift

Gebruik CloudWatch-anomaliedetectie voor operationele metrics (verwerkte records, foutenpercentage, jobduur). Maak een detector aan met de CLI:

undefined

en maak vervolgens CloudWatch-alarmen aan die verwijzen naar de anomaliedetectieband. Voor ‘data-level drift’ (verschuivingen in distributie, veranderingen in null-percentage), plan Glue DataBrew-profieljobs (

undefined

) in om statistieken, histogrammen en kwantielen te berekenen; sla de profielen op in S3 als baselines.

Beslissingscriteria voor anomalie- versus drempelwaarderalarmen:

Kies CloudWatch-anomaliedetectie wanneer metric-patronen seizoensgebonden of variabel zijn; het leert van eerder gedrag en vermindert de noodzaak voor handmatige aanpassing van drempelwaarden.
Gebruik statische drempelwaarderalarmen voor binaire condities (bijv. job vastgelopen > X uur) waar de voorspelbaarheid hoog is.

Voor geautomatiseerde driftdetectie:

Plan reguliere DataBrew-profieljobs in (dagelijks/wekelijks afhankelijk van de datasnelheid) om metric-baselines vast te leggen (null-%, kardinaliteit, percentielen).
Vergelijk nieuwe profieloutputs met de baseline-profielen met behulp van Glue-regelsets (aangepaste SQL-controles) of aangepaste ’expectations’ van Great Expectations die verwijzen naar baseline-statistieken.
Verstuur een melding via SNS / EventBridge wanneer de drift beleidsdrempels overschrijdt of wanneer anomaliedetectoren ongebruikelijk metric-gedrag signaleren.

SLA-beheer en betrouwbaarheid van pipelines

SLA-beheer koppelt observability aan herstel (remediation) en reliability engineering. Instrumenteer elke pipeline met deze basisstatistieken: doorvoersnelheid (records/sec), latentie (ingest→sink), foutenpercentage, job-/runtime en downstream-tellingen. Gebruik CloudWatch Metrics voor Glue-jobs (job run metrics), Kinesis/Kafka consumer lag en aangepaste applicatiemetrieken via PutMetricData.

Betrouwbaarheidspatronen en configuratiedetails:

Dead-letter queues (SQS DLQ): configureer voor streaming consumers (Lambda, Kinesis consumers) een DLQ en stel RedrivePolicy(maxReceiveCount) in. Gebruik DLQ-retentie en een aparte verwerkingsjob om DLQ-berichten te inspecteren en opnieuw te verwerken.
Idempotent ontwerp: zorg ervoor dat sinks idempotente schrijfacties ondersteunen — voorbeelden:
- DynamoDB: gebruik PutItem met conditionele expressies of een samengestelde sleutel voor een idempotency-token.
- S3: schrijf met atomaire hernoempatronen of gebruik op inhoud gebaseerde sleutels (hash van het record) zodat herhalingen overschrijven in plaats van dupliceren.
- Redshift/Glue ETL: gebruik staging + MERGE op basis van een sleutel om te ontdubbelen na herverwerking.
Checkpointing: schakel Kinesis/DynamoDB connector-checkpoints in en beheer de checkpoint-frequentie van de consumer om een balans te vinden tussen het herverwerkingsvenster en het risico op duplicatie.

Beslissingscriteria voor retry versus fail-fast:

Voor tijdelijke fouten (downstream throttling), implementeer retries met exponential backoff en een DLQ pas na het maximale aantal retries.
Voor datakwaliteitsfouten (schema-mismatch), gebruik fail-fast en schrijf de foutieve records naar een quarantaine S3-prefix met metadata voor handmatige beoordeling.

Veelvoorkomende valkuilen en beslissingscriteria

Glue Data Quality-regels loggen fouten, maar laten de job standaard niet falen — configureer de regelactie op FAIL voor kritieke controles en koppel de evaluatie van de ruleset aan de job run.
Streaming pipelines zonder DLQ’s negeren of verliezen mislukte records — configureer altijd SQS DLQ’s (of persistente S3-staging) en een redrive policy om te inspecteren en opnieuw te verwerken.
Herverwerking zonder idempotentie produceert dubbele records — ontwerp deterministische sleutels, gebruik upsert/merge-semantiek bij de sink, of pas op inhoud gebaseerde objectsleutels toe voor S3.
Detectie van data drift zonder baselines produceert ’noisy’ alerts — plan Glue DataBrew-profieljobs om basisstatistieken te creëren en op te slaan, en vergelijk vervolgens nieuwe profielen hiermee.
Te veel vertrouwen op statische CloudWatch-drempelwaarden veroorzaakt false positives — gebruik CloudWatch anomaly detection voor seizoensgebonden/variabele metrieken en reserveer statische drempels voor niet-onderhandelbare limieten.
Een te hoge maxReceiveCount instellen stelt DLQ-routing uit en verhoogt de verwerkingslatentie — kies een verstandige maxReceiveCount zodat DLQ’s persisterende, falende berichten tijdig ontvangen.

Praktijkprobleem: Use-Case Scenario

Streamline Retail ondervindt na de nachtelijke ETL-run regelmatig fouten in de downstream-rapportage: occasionele schema-afwijkingen, stille regelovertredingen en dubbele bestellingen bij het herverwerken van mislukte runs.

Implementeer Glue Data Quality-regels (DQDL) voor schema, null-drempels en uniciteit op order_id; stel de actie bij een fout in op FAIL voor de job en publiceer de evaluatie-artefacten naar S3.
Voeg Great Expectations toe in een Glue Python Shell-stap voor complexe bedrijfscontroles (consistentie van bestellingen over tabellen heen); sla de expectations op in S3 en voer checkpoints uit in de pipeline.
Plan DataBrew-profieljobs om dagelijkse baselines vast te leggen (kardinaliteit, null-percentage, percentielen) en gebruik geautomatiseerde vergelijkingen om drift te detecteren.
Configureer voor streaming order-events een SQS DLQ met een geschikte RedrivePolicy en creëer een replay-job om DLQ-berichten idempotent te verwerken (met order_id als ontdubbelingssleutel).
Instrumenteer CloudWatch anomaly detectors voor de runtime van de job en het aantal fouten; koppel op anomalie gebaseerde alarmen aan SNS voor on-call escalatie.

Rationale volgens AWS best practices: combineer native Glue-kwaliteitscontroles voor snelle integratie, Great Expectations voor expressiviteit, DataBrew voor basisstatistieken en CloudWatch anomaly detectors voor adaptieve monitoring. DLQ’s en idempotente sinks sluiten de cirkel voor veilige retries en herverwerking met behoud van SLA’s.

← Kostenoptimalisatie voor dataworkloads · Alle domeinen

Oefen deze vragen → · Getimede oefening op ExamRoll.io →