Amazon DEA-C01: Data-ingestie en verzameling — 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 patronen, AWS-services en operationele details die worden gebruikt om ruwe data betrouwbaar en op schaal in een dataplatform te brengen. Data engineers moeten kiezen tussen batch- en streaming-ingangspunten, zorgen voor datacatalogisering en vindbaarheid, en ontwerpen voor doorvoer, de mogelijkheid tot opnieuw afspelen en faalscenario’s. De belangrijkste AWS-bouwstenen zijn S3 en Glue voor batch, Kinesis en Firehose voor streaming, DMS voor databasemigratie en CDC, en API/Event-driven componenten (API Gateway, Lambda, SNS, SQS, S3 events) voor ad-hoc en push-gebaseerde opname.

Batch-opname met AWS Glue en S3

Glue is de belangrijkste beheerde ETL- en metadata-oplossing voor batch-opname in S3 en je datacatalogus. Een typisch patroon: plaats ruwe bestanden in S3 (aparte raw/zone-prefixes), voer een Glue-crawler uit om het schema af te leiden en de Glue Data Catalog te vullen, en voer vervolgens Glue ETL-jobs (Spark) uit om te transformeren, partitioneren, converteren naar kolomgeoriënteerde formaten (Parquet/ORC) en geoptimaliseerde data terug te schrijven naar S3. Configureer crawlers met de juiste classifiers (ingebouwde CSV/JSON/Parquet of aangepaste grok/regex) en geef de crawler een IAM-rol met s3:GetObject/s3:ListBucket en glue:catalog-permissies — het ontbreken hiervan is een veelvoorkomende operationele fout.

Gebruik bij het configureren van Glue-jobs en -crawlers deze console/CLI-patronen en -schakelaars:

Crawler aanmaken:

undefined

en starten met

undefined

Glue-job:

undefined

; activeer job bookmarks om herverwerking te voorkomen. Beslissingscriteria voor Glue versus alternatieven:

Gebruik Glue wanneer je beheerde Spark ETL, schema-detectie en catalogusintegratie met Athena/Redshift Spectrum wilt.
Gebruik EMR wanneer je gespecialiseerde cluster-tuning, aangepaste bibliotheken of langlopende clusters nodig hebt.
Gebruik een eenvoudige Lambda of Glue on-demand voor lichtgewicht transformaties op kleine bestanden.

Streaming-opname met Kinesis Data Streams en Firehose

Kinesis Data Streams (KDS) is voor realtime opname met de mogelijkheid tot opnieuw afspelen, consumentencontrole en fijnmazige schaalvergroting. Een Kinesis-shard biedt 1 MB/sec of 1.000 records/sec schrijfcapaciteit en 2 MB/sec leescapaciteit; gebruik

undefined

en plaats data met

undefined

. Partitiesleutels bepalen de toewijzing aan shards; een lage kardinaliteit van partitiesleutels veroorzaakt ‘hot shards’ — vermijd dit door de entropie van de sleutel te verhogen of een hash als achtervoegsel toe te voegen. Schaal shards op met

undefined

of activeer de On-Demand-modus voor automatisch schalen.

Firehose is een ‘delivery stream’-service die is geoptimaliseerd voor near-realtime levering (S3, Redshift, OpenSearch, Splunk) met ingebouwde buffering, compressie en optionele Lambda-transformatie. Configureer buffering met BufferingHints: buffer_size (MB) en buffer_interval (seconden) om de leveringslatentie versus de kosten af te stemmen; activeer compressie (GZIP, Snappy) en stel een verwerkende Lambda in voor transformaties op recordniveau. Belangrijkste verschillen:

Kinesis Data Streams:
- Realtime, ondersteunt meerdere consumenten, opnieuw afspelen van bewaarde data, expliciet shard-beheer
- Doorvoer per shard (1MB/1k schrijfacties), vereist ontwerp van partitiesleutels
Kinesis Data Firehose:
- Beheerde levering aan bestemmingen, automatische retry/backoff, geen mogelijkheid om geleverde records opnieuw af te spelen
- Ondersteunt buffering (grootte/tijd), compressie, transformatie via Lambda, S3-staging voor het laden in Redshift

Kies KDS wanneer je de mogelijkheid tot opnieuw afspelen, sterke consumentencontrole of meerdere downstream-consumenten nodig hebt; kies Firehose wanneer je eenvoudige levering en transformatie naar S3/Redshift/OpenSearch nodig hebt met minimale operationele overhead.

Databasemigratie en CDC met DMS

AWS DMS wordt gebruikt voor homogene/heterogene migraties en continue replicatie (CDC). Implementeer een replicatie-instance (

undefined

) die is gedimensioneerd voor de doorvoer, waarbij de beslissingen over de grootte worden bepaald door de wijzigingssnelheid, het volume van de volledige lading en de parallelliteit van de taken. DMS-taaktypen:

full-load: kopieer alleen bestaande data
cdc: stream doorlopende wijzigingen
full-load + cdc: initiële lading en vervolgens doorgaan met het streamen van wijzigingen Configureer endpoints met de juiste engine-instellingen (JDBC/connection-string), activeer ‘supplemental logging’ of plug-ins op de bron, en lever een JSON-tabelmapping om tabellen te filteren/op te nemen. Voor op MySQL gebaseerde bronnen vereist DMS CDC dat binary logging (binlog) is ingeschakeld en dat de juiste binlog_format (ROW aanbevolen) op de bron is ingesteld; voor PostgreSQL moet je logische replicatie en een plug-in zoals wal2json inschakelen of replicatieslots gebruiken. Monitor taken via CloudWatch-metrics en taaklogboeken; stem batchApplyEnabled en maxFullLoadSubTasks af voor een betere doorvoer.

Beslissingscriteria tussen full-load en CDC: gebruik full-load+CDC wanneer je een migratie met minimale downtime nodig hebt; gebruik alleen-CDC voor doorlopende replicatie nadat een initiële lading via een ander mechanisme is voltooid. Valideer altijd de schemamapping en voer testmigraties uit op representatieve datavolumes.

Op API’s en events gebaseerde ingestiepatronen

API’s en events zijn voor push-gebaseerde ingestie en orkestratie. Veelvoorkomende patronen:

API Gateway -> Lambda -> Firehose/Kinesis: geschikt wanneer clients JSON-events pushen. Gebruik API Gateway throttling en Lambda concurrency controls voor backpressure en om idempotency-headers af te dwingen.
S3 event notifications: configureer bucket-notificaties om object-created events te sturen naar Lambda, SQS of SNS via de console of aws s3api put-bucket-notification-configuration; gebruik prefix/suffix-filters om triggers te beperken. Voor fan-out, routeer S3 -> SNS-topic -> meerdere SQS-wachtrijen/Lambda-subscribers om hetzelfde event aan meerdere consumers te leveren zonder koppeling.
SQS en SNS voor duurzame, ontkoppelde ingestie: SQS voor pull-gebaseerde worker-verwerking met visibility timeout, SNS voor push fan-out.

Operationele aandachtspunten en CLI-patronen:

Gebruik DLQ’s voor Lambda/SQS-fouten; configureer een herhalingsbeleid (retry policy) op SNS-abonnementen.
Voor streaming met hoge doorvoersnelheid vanaf API’s, geef de voorkeur aan batchen naar Kinesis of Firehose in plaats van synchrone downstream writes om te voorkomen dat API-clients worden geblokkeerd.

Veelvoorkomende valkuilen en beslissingscriteria

Verwarring tussen Kinesis Data Streams (met replay-mogelijkheid, shard-beheerd) en Firehose (beheerde levering, geen replay): kies KDS wanneer je replay of meerdere consumers nodig hebt; kies Firehose voor eenvoudige delivery pipelines.
Vergeten van IAM-permissies voor de Glue crawler: koppel altijd een IAM-rol die s3:GetObject/s3:ListBucket en glue:CreateTable/UpdateTable/DeleteTable toestaat, zodat crawlers de Data Catalog kunnen vullen.
Ontbrekende binary logging/logical replication voor DMS CDC: schakel binlog in op MySQL (ROW-formaat) of logical replication en wal2json op PostgreSQL voordat je CDC-taken start.
Lage kardinaliteit van de partitiesleutel die ‘hot shards’ veroorzaakt: verhoog de kardinaliteit van de partitiesleutel door hashing, neem attributen met hoge kardinaliteit op, of verhoog het aantal shards; monitor de Put/Get throttling-statistieken.
Overbuffering van Firehose of verkeerd geconfigureerde buffering die leidt tot hoge latentie: stem buffer_size en buffer_interval af op de acceptabele latentie en het verzoekvolume.
Vertrouwen op S3 event notifications zonder DLQ of retry-mechanisme: gebruik SNS/SQS fan-out of Lambda met een DLQ om gemiste events te voorkomen en een duurzame fan-out te garanderen.

Praktijkprobleem: Use-Case Scenario

RetailCo verzamelt mobiele clickstreams (hoog volume, real-time) en nachtelijke productcatalogusbestanden; ze hebben real-time dashboards en een geconsolideerd analytics lake nodig.

Ingesteer clickstreams in Kinesis Data Streams met partitiesleutels afgeleid van de gebruikerssessie + een gehasht shard-suffix; creëer consumers met Kinesis Data Analytics of Lambda/Kinesis Client Library voor real-time verwerking.
Gebruik Kinesis Data Firehose met een transformatie-Lambda om verrijkte streaming-output te persisteren naar S3 (Parquet), comprimeer met Snappy, en laad optioneel naar Redshift Spectrum voor analyses.
Plaats nachtelijke catalogusbestanden in S3 raw/ en voer een geplande Glue crawler uit om de Glue Data Catalog bij te werken, voer vervolgens Glue ETL-jobs uit om te converteren naar gepartitioneerde Parquet in de ‘curated zone’.
Gebruik S3 event notifications -> SNS -> Lambda om lichtgewicht metadata-updates te triggeren of caches te invalideren; routeer de levering naar SQS voor duurzame downstream verwerking.
Monitor Kinesis shard-statistieken (IncomingBytes, IncomingRecords, PutRecords.Success) en gebruik UpdateShardCount of On-Demand streams om groei op te vangen; schakel CloudWatch-alarmen in.

Rationale van AWS best practices: scheid real-time en batch paden, gebruik Kinesis Data Streams wanneer replay en consumer-isolatie vereist zijn, gebruik Firehose voor beheerde levering aan S3/bestemmingen, en onderhoud een Glue Data Catalog voor discovery en query-integratie met Athena/Redshift.

Alle domeinen · Dataopslag en Lake-architectuur →

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