Amazon DEA-C01: Ingestia i gromadzenie danych — Przewodnik do nauki

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

Część Amazon Data Engineer Associate DEA-C01 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Amazon, albo rozwiąż testy na czas na ExamRoll.io.

Wzorce pozyskiwania danych oparte na API i zdarzeniach

API i zdarzenia służą do pozyskiwania danych w modelu push oraz do orkiestracji. Typowe wzorce:

• API Gateway -> Lambda -> Firehose/Kinesis: odpowiednie, gdy klienci wysyłają zdarzenia JSON. Użyj mechanizmów throttling w API Gateway i kontroli współbieżności w Lambda, aby zapewnić backpressure i wymusić stosowanie nagłówków idempotencji.
• Powiadomienia o zdarzeniach S3: skonfiguruj powiadomienia w buckecie, aby wysyłać zdarzenia utworzenia obiektu do Lambda, SQS lub SNS za pomocą konsoli lub polecenia aws s3api put-bucket-notification-configuration; użyj filtrów prefix/suffix, aby ograniczyć wyzwalacze. W celu realizacji wzorca fan-out, przekieruj zdarzenia S3 -> temat SNS -> wiele kolejek SQS/subskrybentów Lambda, aby dostarczyć to samo zdarzenie do wielu konsumentów bez tworzenia ścisłych powiązań.
• SQS i SNS dla trwałego, luźno powiązanego pozyskiwania danych: SQS do przetwarzania przez workery w modelu pull z visibility timeout, SNS do dystrybucji w modelu push (fan-out).

Kwestie operacyjne i wzorce CLI:

• Używaj kolejek DLQ (Dead-Letter Queues) dla niepowodzeń Lambda/SQS; skonfiguruj politykę ponowień (retry policy) w subskrypcjach SNS.
• Dla strumieniowania o wysokiej przepustowości z API, preferuj grupowanie (batching) danych do Kinesis lub Firehose zamiast synchronicznych zapisów do systemów docelowych, aby uniknąć blokowania klientów API.

Częste pułapki i kryteria decyzyjne

• Mylenie Kinesis Data Streams (z możliwością odtwarzania, zarządzanie shardami) z Firehose (zarządzane dostarczanie, bez możliwości odtwarzania): wybierz KDS, gdy potrzebujesz odtwarzania danych lub masz wielu konsumentów; wybierz Firehose dla prostych potoków dostarczania danych.
• Zapominanie o uprawnieniach IAM dla crawlera Glue: zawsze dołączaj rolę IAM, która nadaje uprawnienia s3:GetObject/s3:ListBucket oraz glue:CreateTable/UpdateTable/DeleteTable, aby crawlery mogły wypełniać Data Catalog.
• Brak włączonego logowania binarnego/replikacji logicznej dla DMS CDC: włącz binlog w MySQL (format ROW) lub replikację logiczną i wal2json w PostgreSQL przed uruchomieniem zadań CDC.
• Niska kardynalność klucza partycji powodująca gorące shardy (hot shards): zwiększ kardynalność klucza partycji poprzez haszowanie, dołączenie atrybutów o wysokiej kardynalności lub zwiększenie liczby shardów; monitoruj metryki throttlingu dla operacji Put/Get.
• Nadmierne buforowanie w Firehose lub błędna konfiguracja buforowania prowadząca do wysokich opóźnień: dostosuj parametry buffer_size i buffer_interval w oparciu o akceptowalne opóźnienie i wolumen zapytań.
• Poleganie na powiadomieniach o zdarzeniach S3 bez DLQ lub mechanizmu ponowień: użyj wzorca fan-out z SNS/SQS lub Lambda z DLQ, aby uniknąć utraty zdarzeń i zapewnić trwałą dystrybucję.

Problem praktyczny: Scenariusz użycia

Firma RetailCo zbiera strumienie kliknięć z aplikacji mobilnych (duży wolumen, czas rzeczywisty) oraz nocne pliki z katalogiem produktów; potrzebuje dashboardów w czasie rzeczywistym i skonsolidowanego jeziora danych analitycznych (analytics lake).

1. Pozyskuj strumienie kliknięć do Kinesis Data Streams, używając kluczy partycji utworzonych z sesji użytkownika + haszowanego sufiksu sharda; twórz konsumentów za pomocą Kinesis Data Analytics lub Lambda/Kinesis Client Library do przetwarzania w czasie rzeczywistym.
2. Użyj Kinesis Data Firehose z transformującą funkcją Lambda, aby zapisywać wzbogacone dane strumieniowe w S3 (format Parquet), kompresować za pomocą Snappy i opcjonalnie ładować do Redshift Spectrum w celach analitycznych.
3. Umieszczaj nocne pliki katalogowe w S3 w ścieżce raw/ i uruchamiaj zaplanowany crawler Glue, aby zaktualizować Glue Data Catalog, a następnie uruchamiaj zadania Glue ETL, aby przekonwertować dane na partycjonowany format Parquet w strefie przetworzonej (curated zone).
4. Użyj powiadomień o zdarzeniach S3 -> SNS -> Lambda, aby wyzwalać lekkie aktualizacje metadanych lub unieważniać pamięć podręczną (cache); przekieruj dostarczanie do SQS w celu zapewnienia trwałego przetwarzania w dalszych etapach.
5. Monitoruj metryki shardów Kinesis (IncomingBytes, IncomingRecords, PutRecords.Success) i używaj UpdateShardCount lub strumieni On-Demand, aby radzić sobie ze wzrostem obciążenia; włącz alarmy CloudWatch.

Uzasadnienie zgodne z najlepszymi praktykami AWS: oddziel ścieżki przetwarzania danych w czasie rzeczywistym i wsadowych, używaj Kinesis Data Streams, gdy wymagane jest odtwarzanie danych i izolacja konsumentów, używaj Firehose do zarządzanego dostarczania danych do S3/innych miejsc docelowych oraz utrzymuj Glue Data Catalog w celu odnajdywania danych i integracji zapytań z Athena/Redshift.

Wszystkie domeny · Przechowywanie danych i architektura jeziora danych →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →

Przeglądaj Amazon →