Amazon DEA-C01: Datenabfrage und -analyse — 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 das Design, die Optimierung und den Betrieb von AWS-Services, die analytische Abfragen und BI auf großen Datensätzen unterstützen. Der Fokus liegt auf kosteneffizienten, hochleistungsfähigen Abfragemustern für Athena, Redshift, OpenSearch und QuickSight und wie diese mit S3, Glue und transaktionalen Speichern zusammenarbeiten. Die Beherrschung erfordert das Abwägen von Speicherformat, Partitionierung, Computetyp und Datenplatzierung, um gescannte Bytes und Netzwerk-Skew zu minimieren und gleichzeitig Einblicke mit geringer Latenz zu liefern.

Amazon Athena-Abfrageoptimierung

Die Preisgestaltung von Athena basiert auf gescannten Bytes, daher sind das physische Datenlayout und die Metadaten die wichtigsten Hebel. Verwenden Sie spaltenbasierte Formate (Parquet oder ORC) mit Komprimierung (Snappy für Parquet, Zlib/ORC-Optionen), um Größe und CPU-Auslastung zu reduzieren. Partitionieren Sie Daten nach Spalten mit hoher Kardinalität, die in Abfragen gefiltert werden (Datum, Region), und registrieren Sie die Partitionen im Glue Data Catalog. Typische Muster:

Schreiben Sie Daten in S3 in Pfade wie s3://bucket/events/date=2026-08-02/ und verwenden Sie Glue-Crawler oder

undefined

, um die Partitionen zu füllen.

undefined

, um die spaltenbasierte Komprimierung zu erzwingen.

Nutzen Sie Projektion und Partition Pruning durch WHERE-Klauseln, die auf Partitionsschlüssel verweisen, um das Scannen unnötiger Partitionen zu vermeiden.

Wenn Abfragen Joins mit transaktionalen Speichern erfordern, verwenden Sie Athena Federated Query (Lambda-Konnektoren), um quellenübergreifende Joins mit RDS, DynamoDB oder Redshift durchzuführen. Konnektoren werden als Lambda-Funktionen bereitgestellt und als Datenquellen in Athena registriert; Beispiel-Konsolenablauf: Athena > Datenquellen > Konnektoren > Neu. Entscheidungskriterien:

Verwenden Sie Federated Query, wenn die Datenmengen in RDS/DynamoDB moderat sind oder wenn eine kleine Dimensionstabelle mit einem großen S3-Datensatz verbunden wird.
Für wiederholte, aufwendige Joins extrahieren und materialisieren Sie die Betriebsdaten in S3 (Parquet), um die Join-Kosten auf einen einzigen ETL-Prozess zu verlagern und Athena für wiederholte Lesevorgänge zu verwenden.

Amazon Redshift-Abfragetuning und -verteilung

Die Leistung von Redshift hängt vom Verteilungsstil (Distribution Style) und den Sortierschlüsseln (Sort Keys) ab, um Datenbewegungen zu minimieren und Zone Mapping zu ermöglichen. Wählen Sie DIST-Stile anhand dieser Entscheidungspunkte:

DISTKEY (KEY): nützlich, wenn große Tabellen über einen Join-Schlüssel mit hoher Kardinalität verbunden werden; vermeidet eine Neuverteilung, wenn beide Tabellen denselben DISTKEY verwenden.
ALL: repliziert eine kleine Dimensionstabelle auf alle Knoten, um Netzwerk-Shuffles bei Joins zu vermeiden.
EVEN: Standard für unvorhersehbare Workloads oder wenn kein geeigneter Schlüssel existiert; vermeidet Hotspots.
AUTO: lässt Redshift basierend auf Tabellengröße und Workload wählen, wenn keine klare Anleitung vorhanden ist.

Definieren Sie SORTKEYs für Spalten, die in Bereichsfiltern oder ORDER BY verwendet werden, um Zone Maps zu aktivieren und Festplattenlesevorgänge zu reduzieren. Gängige operative Befehle:

undefined

;

Verwenden Sie

undefined

und

undefined

regelmäßig:

undefined

; überwachen Sie

undefined

und

undefined

auf Skew- und Verteilungsmetriken. Mit Redshift Spectrum können Sie externe S3-Tabellen über den Glue Data Catalog abfragen. Erstellen Sie das externe Schema mit:

undefined

; Entscheidungskriterien für Spectrum im Vergleich zu nativem Redshift:

Verwenden Sie Spectrum für selten abgefragte, große kalte Daten, die in S3 gespeichert sind, oder für mehrstufige Datenarchitekturen.
Behalten Sie heiße, häufig verbundene Datensätze für eine bessere Leistung in Redshift; wählen Sie beim Join mit Spectrum DISTKEYs, um Join-Schlüssel zu kolokalisieren, oder verwenden Sie eine Neuverteilung, um den Netzwerk-I/O zu minimieren.

Amazon OpenSearch Service für die Log-Analyse

OpenSearch ist für die Aufnahme und schnelle Ad-hoc-Log-Analyse optimiert; seine Index- und Cluster-Konfiguration bestimmt den Durchsatz und die Kosten. Indexdesign und Lebenszyklus:

Verwenden Sie Indexmuster wie

undefined

und eine Indexvorlage, um

undefined

(kleine Indizes: 1 Shard; große: mehrere Shards mit einer Größe von ~10–50 GB) und

undefined

für die Verfügbarkeit festzulegen.

Konfigurieren Sie Index-Lifecycle-Richtlinien (ILM), um Indizes durch die Tiers Hot, Warm, Cold und UltraWarm zu verschieben und so die Kosten zu kontrollieren; UltraWarm reduziert die Speicherkosten auf Hot Nodes für historische Daten. Sharding und Replikate beeinflussen die Abfrage- und Indizierungsleistung:
Mehr Shards erhöhen die Parallelität, verursachen aber auch zusätzlichen Overhead; stimmen Sie die Anzahl der Shards pro Knoten basierend auf Heap und CPU ab.
Replikate verbessern den Lesedurchsatz und die Fehlertoleranz; legen Sie die Anzahl der Replikate basierend auf der Abfrageparallelität und dem SLA fest. Operative Befehle und Konsolenmuster:
Verwenden Sie die OpenSearch Dev Tools (oder curl), um Indexvorlagen und ILM-Richtlinien per PUT zu setzen, und überwachen Sie diese mit den Cluster-Health-APIs. Weisen Sie Knotenattribute zu und verwenden Sie Shard Allocation Awareness, um Hot-Spotting zu verhindern. Entscheidungskriterien:
Wählen Sie UltraWarm, wenn die Latenzanforderungen für Abfragen historischer Logs eine höhere Leselatenz im Austausch für niedrigere Speicherkosten tolerieren können.
Behalten Sie aktuelle Indizes auf Hot Nodes, um schnelle Aggregationen und Dashboards zu unterstützen.

QuickSight für BI und Visualisierung

QuickSight bietet schnelle Dashboards mit zwei Hauptmodi für die Datenaufnahme: SPICE (In-Memory) und Direktabfrage (Direct Query). SPICE bietet eine Leistung im Subsekundenbereich für Dashboards und eignet sich für wiederholte Lesevorgänge; direkte SQL-Abfragen (an Athena, Redshift, RDS) sind für sehr große Datensätze oder sich häufig ändernde Daten vorzuziehen. Wichtige Konfigurationen und Best Practices:

Erstellen Sie Datensätze in der Konsole: Neuer Datensatz > Quelle wählen (Athena/Redshift/RDS/OpenSearch) > In SPICE importieren oder Direktabfrage verwenden.
Verwenden Sie geplante SPICE-Aktualisierungen für tägliche/nahezu Echtzeit-Anforderungen; konfigurieren Sie eine inkrementelle Aktualisierung nach Zeitstempel-Partitionierung, um die Datenbewegung zu begrenzen. Sicherheit und Governance:
Implementieren Sie Sicherheit auf Zeilenebene (Row-Level Security) über QuickSight-Benutzer-/Gruppenzuordnungen und Datensatzregeln.
Für kontoübergreifenden Datenzugriff, richten Sie IAM-Rollen und ressourcenbasierte Berechtigungen ein, die QuickSight annehmen kann. Entscheidungskriterien:
Verwenden Sie SPICE für Dashboards mit vielen gleichzeitigen Betrachtern und vorhersagbaren Aktualisierungsfenstern.
Verwenden Sie Direktabfragen, wenn die Datenaktualität kritisch ist oder die SPICE-Kapazität begrenzt ist; kombinieren Sie diese mit berechneten Feldern und Parametern für eine interaktive UX.

Häufige Fallstricke und Entscheidungskriterien

Bei Athena fallen Kosten pro gescannten Daten an – partitionieren Sie daher immer nach Abfrageprädikaten und speichern Sie die Daten in spaltenbasierten Formaten (Parquet/ORC) mit Komprimierung (Snappy/Zlib), um die Menge der gescannten Bytes zu reduzieren.
Ein Redshift DISTKEY auf einer Spalte mit niedriger Kardinalität verursacht Data Skew – wählen Sie Join-Schlüssel mit hoher Kardinalität für den DISTKEY oder verwenden Sie DISTSTYLE ALL für kleine Dimensionstabellen.
Externe Tabellen in Redshift Spectrum erfordern den Glue Data Catalog – stellen Sie sicher, dass Glue in der Zielregion aktiviert ist und dass die IAM-Rollen Redshift den Zugriff auf den Katalog erlauben.
Fehler bei der Anzahl und Größe von OpenSearch-Shards – vermeiden Sie zu viele kleine Shards; dimensionieren Sie Shards auf mehrere zehn GB und nutzen Sie ILM, um ältere Indizes zur Kostenersparnis auf UltraWarm zu verschieben.
Vergessen, nach Massen-Ladevorgängen RUN ANALYZE/VACUUM in Redshift auszuführen – planen Sie die Ausführung von ANALYZE und VACUUM, um Statistiken zu aktualisieren und Speicherplatz für optimale Abfragepläne freizugeben.
QuickSight SPICE-Überlauf und veraltete Daten – planen Sie die SPICE-Kapazität, verwenden Sie inkrementelle Aktualisierungen oder wechseln Sie für Echtzeitanforderungen zur direkten Abfrage (Direct Query).

Praktisches Problem: Anwendungsszenario

Acme Retail benötigt tägliche BI-Berichte, die Transaktionsbestellungen aus Amazon RDS, Clickstream-Ereignisse aus S3 und Benutzerprofile aus DynamoDB kombinieren, unter Einhaltung von Kostengrenzen und mit Dashboard-Aktualisierungen im Sub-Minuten-Bereich für aktuelle Daten.

Konvertieren Sie die Clickstream-Daten in S3 in partitioniertes Parquet (datumsbasiert), komprimieren Sie sie mit Snappy und registrieren Sie die Metadaten über einen Crawler in AWS Glue.
Verwenden Sie Athena für Ad-hoc-Abfragen auf S3 und stellen Sie Federated-Query-Konnektoren für RDS und DynamoDB bereit, um Joins mit kleinen Dimensionen durchzuführen; materialisieren Sie häufige Join-Ergebnisse als Parquet, wenn Abfragen wiederholt werden.
Stellen Sie Redshift für aufwendige analytische Joins bereit: Laden Sie aggregierte Snapshots in Redshift, setzen Sie den DISTKEY auf die customer_id mit hoher Kardinalität und definieren Sie den SORTKEY auf order_date; verwenden Sie Spectrum für kalte historische S3-Daten.
Nehmen Sie Anwendungs-Logs mit täglichen Indexmustern in OpenSearch auf; wenden Sie ILM an, um aktuelle Indizes auf Hot Nodes zu halten und ältere Indizes zur Kostenersparnis auf UltraWarm zu verschieben.
Erstellen Sie QuickSight-Dashboards: Importieren Sie aktuelle Aggregate mit geplanten inkrementellen Aktualisierungen in SPICE für eine wahrgenommene Reaktionsfähigkeit im Sub-Minuten-Bereich und verwenden Sie direkte Abfragen (Direct Queries) für stets aktuelle Metriken.

Begründung: Dieser Ansatz minimiert die Scankosten von Athena durch Partitionierung und spaltenbasierte Formate, reduziert den Network Shuffle in Redshift durch korrekte Verteilungs- und Sortierschlüssel, nutzt Spectrum, um die Speicherung kalter Daten in Redshift zu vermeiden, wendet OpenSearch ILM an, um die Speicherkosten zu optimieren, und setzt SPICE für reaktionsschnelle Dashboards ein, während die kritische Aktualität durch direkte Abfragen (Direct Queries) erhalten bleibt.

← Datenorchestrierung und Workflow-Management · Alle Domänen · Datensicherheit →

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