Amazon DEA-C01: Dataquery en -analyse — 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 omvat het ontwerpen, afstemmen en beheren van AWS-services die analytische query’s en BI op grote datasets ondersteunen. Het richt zich op kostenefficiënte, high-performance querypatronen voor Athena, Redshift, OpenSearch en QuickSight, en hoe deze samenwerken met S3, Glue en transactionele opslag. Beheersing vereist het balanceren van opslagformaat, partitionering, compute-type en datalocatie om gescande bytes en netwerk-skew te minimaliseren en tegelijkertijd inzichten met lage latentie te leveren.

Amazon Athena query-optimalisatie

De prijs van Athena is gebaseerd op gescande bytes, dus de fysieke data-indeling en metadata zijn de belangrijkste hefbomen. Gebruik kolomgeoriënteerde formaten (Parquet of ORC) met compressie (Snappy voor Parquet, Zlib/ORC-opties) om de omvang en het CPU-gebruik te verminderen. Partitioneer data op kolommen met een hoge kardinaliteit waarop gefilterd wordt in query’s (datum, regio) en registreer partities in de Glue Data Catalog. Typische patronen:

Schrijf data naar S3 in paden zoals s3://bucket/events/date=2026-08-02/ en gebruik Glue crawlers of MSCK REPAIR TABLE om partities te vullen.
Gebruik CREATE EXTERNAL TABLE … STORED AS PARQUET TBLPROPERTIES (‘parquet.compress’=‘SNAPPY’) om kolomgeoriënteerde compressie af te dwingen.
Gebruik projectie en ‘partition pruning’ via WHERE-clausules die verwijzen naar partitiesleutels om het scannen van onnodige partities te vermijden.

Wanneer query’s joins met transactionele opslag vereisen, gebruik dan Athena Federated Query (Lambda connectors) om cross-source joins uit te voeren met RDS, DynamoDB of Redshift. Connectors worden geïmplementeerd als Lambda-functies en geregistreerd als databronnen in Athena; een voorbeeld van de console-flow is: Athena > Data sources > Connectors > New. Beslissingscriteria:

Gebruik Federated Query wanneer de datavolumes in RDS/DynamoDB bescheiden zijn of wanneer een kleine dimensietabel wordt gejoind met een grote S3-dataset.
Voor herhaalde, zware joins: extraheer en materialiseer de operationele data naar S3 (Parquet) om de join-kosten te verplaatsen naar een enkele ETL en gebruik Athena voor herhaalde leesacties.

Amazon Redshift query-tuning en distributie

De prestaties van Redshift zijn afhankelijk van de ‘distribution style’ en ‘sort keys’ om dataverplaatsing te minimaliseren en ‘zone mapping’ mogelijk te maken. Kies DIST-stijlen op basis van deze beslispunten:

DISTKEY (KEY): nuttig bij het joinen van grote tabellen op een join-sleutel met hoge kardinaliteit; vermijdt herdistributie als beide tabellen dezelfde DISTKEY delen.
ALL: repliceer een kleine dimensietabel naar alle nodes om netwerk-shuffles bij joins te voorkomen.
EVEN: de standaard voor onvoorspelbare workloads of wanneer er geen goede sleutel bestaat; vermijdt hotspots.
AUTO: laat Redshift kiezen op basis van tabelgrootte en workload als duidelijke richtlijnen ontbreken.

Definieer SORTKEYs op kolommen die worden gebruikt in ‘range filters’ of ORDER BY om ‘zone maps’ mogelijk te maken en schijfleesacties te verminderen. Veelvoorkomende operationele commando’s:

CREATE TABLE sales (…) DISTKEY(user_id) SORTKEY(order_date);
Gebruik periodiek VACUUM en ANALYZE: VACUUM; ANALYZE VERBOSE table; monitor SVV_TABLE_INFO en STL_QUERY voor skew- en distributiemetrieken. Met Redshift Spectrum kun je externe S3-tabellen queryen via de Glue Data Catalog. Maak het externe schema aan met:
CREATE EXTERNAL SCHEMA spectrum FROM DATA CATALOG DATABASE ’ext_db’ IAM_ROLE ‘arn:aws:iam::123456789012:role/RedshiftSpectrumRole’ CREATE EXTERNAL DATABASE IF NOT EXISTS; Beslissingscriteria voor Spectrum versus native Redshift:
Gebruik Spectrum voor zelden gebruikte, grote ‘cold data’ die is opgeslagen in S3 of voor gelaagde data-architecturen.
Bewaar ‘hot’, vaak gejoinde datasets binnen Redshift voor prestaties; kies bij het joinen met Spectrum DISTKEYs om join-sleutels te coloceren of gebruik herdistributie om netwerk-I/O te minimaliseren.

Amazon OpenSearch Service voor log-analyse

OpenSearch is geoptimaliseerd voor ‘ingest’ en snelle, ad-hoc log-analyse; de index- en clusterconfiguratie bepalen de doorvoer en kosten. Indexontwerp en lifecycle:

Gebruik indexpatronen zoals logs-YYYY.MM.DD en een ‘index template’ om index.number_of_shards (kleine indexen: 1 shard; grote: meerdere shards van ~10–50 GB) en index.number_of_replicas voor beschikbaarheid in te stellen.
Configureer ‘index lifecycle policies’ (ILM) om indexen door de hot-, warm-, cold- en UltraWarm-lagen te laten gaan voor kostenbeheersing; UltraWarm verlaagt de opslagkosten op hot nodes voor historische data. Sharding en replica’s beïnvloeden de prestaties van query’s en indexering:
Meer shards verhogen het parallellisme maar voegen overhead toe; stem het aantal shards per node af op de heap en CPU.
Replica’s verbeteren de leesdoorvoer en fouttolerantie; stel het aantal replica’s in op basis van de query-concurrency en SLA. Operationele commando’s en consolepatronen:
Gebruik de OpenSearch Dev Tools (of curl) om ‘index templates’ en ILM-policies te PUT’en, en monitor met de cluster health API’s. Wijs ’node attributes’ toe en gebruik ‘shard allocation awareness’ om hot-spotting te voorkomen. Beslissingscriteria:
Kies UltraWarm wanneer de latency-eisen voor query’s op historische logs een hogere leeslatentie kunnen tolereren in ruil voor lagere opslagkosten.
Bewaar recente indexen op hot nodes om snelle aggregaties en dashboards te ondersteunen.

QuickSight voor BI en visualisatie

QuickSight levert snelle dashboards met twee belangrijke ‘ingestion modes’: SPICE (in-memory) en ‘direct query’. SPICE biedt prestaties van minder dan een seconde voor dashboards en is geschikt voor herhaalde leesacties; directe SQL-query’s (naar Athena, Redshift, RDS) hebben de voorkeur voor zeer grote datasets of vaak veranderende data. Belangrijke configuratie en best practices:

Maak datasets aan in de console: New dataset > Choose source (Athena/Redshift/RDS/OpenSearch) > Import to SPICE of Use direct query.
Gebruik geplande SPICE-refreshes voor dagelijkse/near-real-time behoeften; configureer ‘incremental refresh’ via timestamp-partitionering om dataverplaatsing te beperken. Beveiliging en governance:
Implementeer ‘row-level security’ via QuickSight user/group mappings en dataset-regels.
Voor cross-account datatoegang, implementeer een IAM-rol en resource-based permissions die QuickSight kan aannemen (‘assume’). Beslissingscriteria:
Gebruik SPICE voor dashboards met veel gelijktijdige kijkers en voorspelbare refresh-vensters.
Gebruik ‘direct query’ wanneer de versheid van data cruciaal is of de SPICE-capaciteit beperkt is; combineer met ‘calculated fields’ en parameters voor een interactieve UX.

Veelvoorkomende Valkuilen en Beslissingscriteria

Athena brengt kosten in rekening per gescande data — partitioneer altijd op basis van query-predicaten en sla op in kolommige formaten (Parquet/ORC) met compressie (Snappy/Zlib) om het aantal gescande bytes te verminderen.
Een Redshift DISTKEY op een kolom met lage kardinaliteit veroorzaakt data skew — kies join-sleutels met hoge kardinaliteit voor DISTKEY of gebruik DISTSTYLE ALL voor kleine dimensietabellen.
Externe tabellen in Redshift Spectrum vereisen de Glue Data Catalog — zorg ervoor dat Glue is ingeschakeld in de doelregio en dat IAM-rollen Redshift toestemming geven om de catalogus te benaderen.
Fouten in het aantal en de grootte van OpenSearch-shards — vermijd te veel kleine shards; dimensioneer shards op tientallen GB en gebruik ILM om oudere indices naar UltraWarm te verplaatsen voor kostenbesparingen.
Vergeten om RUN ANALYZE/VACUUM uit te voeren op Redshift na bulk-uploads — plan ANALYZE en VACUUM in om statistieken te vernieuwen en schijfruimte vrij te maken voor optimale queryplannen.
QuickSight SPICE-overflow en verouderde data — plan de SPICE-capaciteit, gebruik incrementele refreshes of schakel over naar direct query voor real-time behoeften.

Praktijkprobleem: Gebruikersscenario

Acme Retail heeft dagelijkse BI-rapporten nodig die transactionele bestellingen in Amazon RDS, clickstream-events in S3 en gebruikersprofielen in DynamoDB combineren, met kostenlimieten en dashboard-refreshes van minder dan een minuut voor recente data.

Converteer clickstream-data in S3 naar gepartitioneerde Parquet (op basis van datum), comprimeer met Snappy en registreer de metadata in AWS Glue via een crawler.
Gebruik Athena voor ad-hoc-query’s op S3 en implementeer Federated Query-connectoren voor RDS en DynamoDB om joins met kleine dimensies uit te voeren; materialiseer veelgebruikte join-resultaten als Parquet als query’s worden herhaald.
Provisioneer Redshift voor zware analytische joins: laad geaggregeerde snapshots in Redshift, stel DISTKEY in op een customer_id met hoge kardinaliteit en definieer SORTKEY op order_date; gebruik Spectrum voor koude, historische S3-data.
Neem applicatielogs op in OpenSearch met dagelijkse indexpatronen; pas ILM toe om recente indices op hot nodes te houden en verplaats oudere indices naar UltraWarm voor kostenbesparingen.
Bouw QuickSight-dashboards: importeer recente aggregaties in SPICE met ingeplande incrementele refreshes voor een waargenomen responsiviteit van minder dan een minuut, en gebruik direct queries voor statistieken die altijd actueel zijn.

Rationale: Deze aanpak minimaliseert de scankosten van Athena door partitionering en kolommige formaten, vermindert Redshift network shuffle met de juiste distributie- en sorteersleutels, gebruikt Spectrum om te voorkomen dat koude data in Redshift wordt opgeslagen, past OpenSearch ILM toe om opslagkosten te optimaliseren en benut SPICE voor responsieve dashboards terwijl kritieke actualiteit wordt behouden via direct queries.

← Data-orkestratie en workflowbeheer · Alle domeinen · Databeveiliging →

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