Amazon DEA-C01: Datenerfassung und -sammlung — 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 Muster, AWS-Services und operativen Details, die verwendet werden, um Rohdaten zuverlässig und skaliert in eine Datenplattform zu bringen. Data Engineers müssen zwischen Batch- und Streaming-Einstiegspunkten wählen, die Datenkatalogisierung und Auffindbarkeit sicherstellen und für Durchsatz, Wiederholbarkeit und Fehlermodi planen. Wichtige AWS-Bausteine sind S3 und Glue für Batch, Kinesis und Firehose für Streaming, DMS für Datenbankmigration und CDC sowie API-/ereignisgesteuerte Komponenten (API Gateway, Lambda, SNS, SQS, S3-Events) für Ad-hoc- und Push-basierte Ingestion.

Batch-Ingestion mit AWS Glue und S3

Glue ist die primäre verwaltete ETL- und Metadatenlösung für die Batch-Ingestion in S3 und Ihren Datenkatalog. Typisches Muster: Rohdateien in S3 ablegen (getrennte Präfixe für Raw/Zone), einen Glue-Crawler ausführen, um das Schema abzuleiten und den Glue Data Catalog zu befüllen, und dann Glue-ETL-Jobs (Spark) ausführen, um die Daten zu transformieren, zu partitionieren, in spaltenbasierte Formate (Parquet/ORC) zu konvertieren und optimierte Daten zurück nach S3 zu schreiben. Konfigurieren Sie Crawler mit geeigneten Klassifikatoren (integriert für CSV/JSON/Parquet oder benutzerdefiniert mit Grok/Regex) und weisen Sie dem Crawler eine IAM-Rolle mit den Berechtigungen s3:GetObject/s3:ListBucket und glue:catalog zu – das Fehlen dieser Berechtigungen ist ein häufiger Betriebsfehler.

Verwenden Sie bei der Konfiguration von Glue-Jobs und Crawlern diese Konsolen-/CLI-Muster und Schalter:

Crawler erstellen:

undefined

und starten mit

undefined

Glue-Job:

undefined

; aktivieren Sie Job-Lesezeichen (Job Bookmarks), um eine erneute Verarbeitung zu vermeiden. Entscheidungskriterien für Glue im Vergleich zu Alternativen:

Verwenden Sie Glue, wenn Sie verwaltetes Spark-ETL, Schemaerkennung und Katalogintegration mit Athena/Redshift Spectrum wünschen.
Verwenden Sie EMR, wenn Sie spezialisiertes Cluster-Tuning, benutzerdefinierte Bibliotheken oder langlebige Cluster benötigen.
Verwenden Sie einfaches Lambda oder Glue on-demand für leichtgewichtige Transformationen bei kleinen Dateien.

Streaming-Ingestion mit Kinesis Data Streams und Firehose

Kinesis Data Streams (KDS) dient der Echtzeit-Ingestion mit Wiederholbarkeit, Consumer-Steuerung und feingranularer Skalierung. Ein Kinesis-Shard bietet 1 MB/s oder 1.000 Datensätze/s Schreibkapazität und 2 MB/s Lesekapazität; verwenden Sie

undefined

und fügen Sie Daten mit

undefined

hinzu. Partition Keys bestimmen die Zuweisung zu den Shards; eine niedrige Kardinalität der Partition Keys verursacht „Hot Shards“ – vermeiden Sie dies, indem Sie die Entropie des Schlüssels erhöhen oder einen Hash als Suffix anhängen. Skalieren Sie Shards mit

undefined

oder aktivieren Sie den On-Demand-Modus für automatische Skalierung.

Firehose ist ein Delivery-Stream-Dienst, der für die Bereitstellung in Nahezu-Echtzeit (S3, Redshift, OpenSearch, Splunk) optimiert ist, mit integrierter Pufferung, Komprimierung und optionaler Lambda-Transformation. Konfigurieren Sie die Pufferung mit BufferingHints: buffer_size (MB) und buffer_interval (Sekunden), um die Lieferlatenz im Verhältnis zu den Kosten abzustimmen; aktivieren Sie die Komprimierung (GZIP, Snappy) und legen Sie eine verarbeitende Lambda-Funktion für Transformationen auf Datensatzebene fest. Wesentliche Unterschiede:

Kinesis Data Streams:
- Echtzeit, unterstützt mehrere Consumer, Wiederholung von aufbewahrten Daten, explizites Shard-Management
- Durchsatz pro Shard (1MB/1k Schreibvorgänge), erfordert das Design von Partition Keys
Kinesis Data Firehose:
- Verwaltete Lieferung an Ziele, automatische Wiederholungsversuche/Backoff, keine Wiederholung von gelieferten Datensätzen
- Unterstützt Pufferung (Größe/Zeit), Komprimierung, Transformation via Lambda, S3-Staging für Redshift-Ladevorgänge

Wählen Sie KDS, wenn Sie Wiederholbarkeit, starke Consumer-Kontrolle oder mehrere nachgelagerte Consumer benötigen; wählen Sie Firehose, wenn Sie eine einfache Lieferung und Transformation nach S3/Redshift/OpenSearch mit minimalem Betriebsaufwand benötigen.

Datenbankmigration und CDC mit DMS

AWS DMS wird für homogene/heterogene Migrationen und kontinuierliche Replikation (CDC) verwendet. Stellen Sie eine Replikationsinstanz bereit (

undefined

), die für den erforderlichen Durchsatz dimensioniert ist, wobei die Dimensionierung von der Änderungsrate, dem Volumen des Full-Loads und der Aufgabenparallelität abhängt. DMS-Aufgabentypen:

full-load: nur bestehende Daten kopieren
cdc: laufende Änderungen streamen
full-load + cdc: initiale Ladung und anschließendes Streamen von Änderungen Konfigurieren Sie Endpunkte mit den entsprechenden Engine-Einstellungen (JDBC/Connection-String), aktivieren Sie zusätzliches Logging oder Plugins auf der Quelle und stellen Sie ein JSON-Table-Mapping bereit, um Tabellen zu filtern/einzuschließen. Für MySQL-basierte Quellen erfordert DMS CDC die Aktivierung des Binary Logging (binlog) und ein geeignetes binlog_format (ROW empfohlen) auf der Quelle; für PostgreSQL müssen Sie die logische Replikation und ein Plugin wie wal2json aktivieren oder Replication Slots verwenden. Überwachen Sie Aufgaben über CloudWatch-Metriken und Aufgabenprotokolle; passen Sie batchApplyEnabled und maxFullLoadSubTasks an, um den Durchsatz zu optimieren.

Entscheidungskriterien zwischen Full-Load und CDC: verwenden Sie full-load+CDC, wenn Sie eine Migration mit minimaler Ausfallzeit benötigen; verwenden Sie nur CDC für die laufende Replikation, nachdem eine initiale Ladung durch einen anderen Mechanismus abgeschlossen wurde. Validieren Sie immer das Schema-Mapping und führen Sie Testmigrationen mit repräsentativen Datenmengen durch.

API-basierte und ereignisgesteuerte Ingestionsmuster

APIs und Events sind für Push-basierte Ingestion und Orchestrierung. Gängige Muster:

API Gateway -> Lambda -> Firehose/Kinesis: geeignet, wenn Clients JSON-Events pushen. Verwenden Sie API Gateway Throttling und Lambda Concurrency Controls, um Gegendruck (Backpressure) zu erzeugen und Idempotenz-Header zu erzwingen.
S3-Event-Benachrichtigungen: Konfigurieren Sie Bucket-Benachrichtigungen, um “Object-Created”-Ereignisse über die Konsole oder

undefined

an Lambda, SQS oder SNS zu senden; verwenden Sie Präfix-/Suffix-Filter, um Auslöser einzuschränken. Für Fan-Out leiten Sie S3 -> SNS-Topic -> mehrere SQS-Queues/Lambda-Subscriber weiter, um dasselbe Ereignis an mehrere Konsumenten ohne Kopplung zu liefern.

SQS und SNS für dauerhafte, entkoppelte Ingestion: SQS für Pull-basierte Worker-Verarbeitung mit Visibility Timeout, SNS für Push-Fan-Out.

Betriebliche Aspekte und CLI-Muster:

Verwenden Sie DLQs für Lambda/SQS-Fehler; konfigurieren Sie eine Wiederholungsrichtlinie (Retry Policy) für SNS-Subscriptions.
Für Streaming mit hohem Durchsatz von APIs, bevorzugen Sie Batching in Kinesis oder Firehose anstelle von synchronen nachgelagerten Schreibvorgängen, um das Blockieren von API-Clients zu vermeiden.

Häufige Fallstricke und Entscheidungskriterien

Verwechslung von Kinesis Data Streams (Replay-fähig, Shard-verwaltet) mit Firehose (verwaltete Zustellung, kein Replay): Wählen Sie KDS, wenn Sie Replay oder mehrere Konsumenten benötigen; wählen Sie Firehose für unkomplizierte Zustellungs-Pipelines.
Vergessen von IAM-Berechtigungen für Glue-Crawler: Fügen Sie immer eine IAM-Rolle an, die s3:GetObject/s3:ListBucket und glue:CreateTable/UpdateTable/DeleteTable gewährt, damit Crawler den Data Catalog befüllen können.
Fehlendes Binary Logging/logische Replikation für DMS CDC: Aktivieren Sie binlog bei MySQL (ROW-Format) oder die logische Replikation und wal2json bei PostgreSQL, bevor Sie CDC-Tasks starten.
Geringe Kardinalität des Partitionsschlüssels verursacht Hot Shards: Erhöhen Sie die Kardinalität des Partitionsschlüssels durch Hashing, Einbeziehung von Attributen mit hoher Kardinalität oder Erhöhung der Shard-Anzahl; überwachen Sie die Put/Get-Throttling-Metriken.
Übermäßiges Buffering bei Firehose oder falsch konfiguriertes Buffering, das zu hoher Latenz führt: Passen Sie buffer_size und buffer_interval basierend auf akzeptabler Latenz und Anfragevolumen an.
Sich auf S3-Event-Benachrichtigungen ohne DLQ oder Retry zu verlassen: Verwenden Sie SNS/SQS-Fan-Out oder Lambda mit DLQ, um verpasste Ereignisse zu vermeiden und ein dauerhaftes Fan-Out sicherzustellen.

Praktisches Problem: Anwendungsfall-Szenario

RetailCo sammelt mobile Clickstreams (hohes Volumen, Echtzeit) und nächtliche Produktkatalogdateien; sie benötigen Echtzeit-Dashboards und einen konsolidierten Analytics Lake.

Ingestieren Sie Clickstreams in Kinesis Data Streams mit Partitionsschlüsseln, die aus der Benutzersitzung + einem gehashten Shard-Suffix abgeleitet sind; erstellen Sie Konsumenten mit Kinesis Data Analytics oder Lambda/Kinesis Client Library für die Echtzeitverarbeitung.
Verwenden Sie Kinesis Data Firehose mit einer Transformations-Lambda, um angereicherte Streaming-Ausgaben in S3 (Parquet) zu persistieren, mit Snappy zu komprimieren und optional zur Analyse in Redshift Spectrum zu laden.
Legen Sie die nächtlichen Katalogdateien in S3 raw/ ab und führen Sie einen geplanten Glue-Crawler aus, um den Glue Data Catalog zu aktualisieren. Führen Sie anschließend Glue-ETL-Jobs aus, um sie in partitioniertes Parquet in der Curated Zone zu konvertieren.
Verwenden Sie S3-Event-Benachrichtigungen -> SNS -> Lambda, um schlanke Metadaten-Updates auszulösen oder Caches zu invalidieren; leiten Sie die Zustellung an SQS für eine dauerhafte nachgelagerte Verarbeitung weiter.
Überwachen Sie Kinesis-Shard-Metriken (IncomingBytes, IncomingRecords, PutRecords.Success) und verwenden Sie UpdateShardCount oder On-Demand-Streams, um Wachstum zu bewältigen; aktivieren Sie CloudWatch-Alarme.

Begründung der AWS Best Practice: Trennen Sie Echtzeit- und Batch-Pfade, verwenden Sie Kinesis Data Streams, wenn Replay und Konsumenten-Isolation erforderlich sind, nutzen Sie Firehose für die verwaltete Zustellung an S3/Ziele und pflegen Sie einen Glue Data Catalog für Discovery und Abfrageintegration mit Athena/Redshift.

Alle Domänen · Datenspeicherung und Lake-Architektur →

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