Amazon DEA-C01: Zapytania i analityka 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.

Ta domena obejmuje projektowanie, dostrajanie i obsługę usług AWS, które wspierają zapytania analityczne i BI na dużych zbiorach danych. Skupia się na efektywnych kosztowo, wysokowydajnych wzorcach zapytań w usługach Athena, Redshift, OpenSearch i QuickSight oraz na ich współdziałaniu z S3, Glue i transakcyjnymi bazami danych. Opanowanie materiału wymaga zrównoważenia formatu przechowywania, partycjonowania, typu zasobów obliczeniowych i umiejscowienia danych w celu minimalizacji liczby skanowanych bajtów i nierównomiernego obciążenia sieci (network skew), przy jednoczesnym dostarczaniu wniosków z niskim opóźnieniem.

Optymalizacja zapytań w Amazon Athena

Cennik Athena opiera się na liczbie przeskanowanych bajtów, więc fizyczny układ danych i metadane są głównymi narzędziami optymalizacji. Używaj formatów kolumnowych (Parquet lub ORC) z kompresją (Snappy dla Parquet, opcje Zlib/ORC), aby zmniejszyć rozmiar i zużycie CPU. Partycjonuj dane według kolumn o wysokiej kardynalności, używanych do filtrowania w zapytaniach (np. data, region) i rejestruj partycje w Glue Data Catalog. Typowe wzorce:

Zapisuj dane w S3 w ścieżkach takich jak s3://bucket/events/date=2026-08-02/ i używaj crawlerów Glue lub polecenia MSCK REPAIR TABLE do wypełniania partycji.
Użyj

undefined

, aby wymusić kompresję kolumnową.

Używaj projekcji i przycinania partycji (partition pruning) za pomocą klauzul WHERE odwołujących się do kluczy partycji, aby uniknąć skanowania niepotrzebnych partycji.

Gdy zapytania wymagają złączeń z transakcyjnymi bazami danych, użyj Athena Federated Query (konektory Lambda), aby wykonywać złączenia między różnymi źródłami, takimi jak RDS, DynamoDB czy Redshift. Konektory są wdrażane jako funkcje Lambda i rejestrowane jako źródła danych w Athena; przykładowy przepływ w konsoli: Athena > Data sources > Connectors > New. Kryteria decyzyjne:

Używaj Federated Query, gdy wolumeny danych w RDS/DynamoDB są niewielkie lub gdy łączysz małą tabelę wymiarów z dużym zbiorem danych w S3.
W przypadku powtarzających się, ciężkich złączeń, wyodrębnij i zmaterializuj dane operacyjne do S3 (w formacie Parquet), aby przenieść koszt złączenia na pojedynczy proces ETL i używać Athena do powtarzalnych odczytów.

Dostrajanie zapytań i dystrybucja w Amazon Redshift

Wydajność Redshift zależy od stylu dystrybucji (distribution style) i kluczy sortowania (sort keys), które minimalizują przesyłanie danych i umożliwiają mapowanie stref (zone mapping). Wybierz styl dystrybucji (DIST style), korzystając z następujących punktów decyzyjnych:

DISTKEY (KEY): przydatny przy łączeniu dużych tabel za pomocą klucza złączenia o wysokiej kardynalności; unika redystrybucji, jeśli obie tabele mają ten sam DISTKEY.
ALL: replikuje małą tabelę wymiarów na wszystkie węzły, aby uniknąć przetasowań sieciowych (network shuffles) podczas złączeń.
EVEN: domyślny dla nieprzewidywalnych obciążeń lub gdy nie ma dobrego klucza; pozwala unikać hotspotów.
AUTO: pozwala Redshift wybrać styl na podstawie rozmiaru tabeli i obciążenia, jeśli brakuje jasnych wytycznych.

Definiuj klucze sortowania (SORTKEYs) na kolumnach używanych w filtrach zakresowych lub w klauzuli ORDER BY, aby włączyć mapy stref i zredukować liczbę odczytów z dysku. Częste polecenia operacyjne:

undefined

;

Używaj okresowo poleceń VACUUM i ANALYZE:

undefined

; monitoruj widoki SVV_TABLE_INFO i STL_QUERY pod kątem metryk nierównomiernego rozkładu danych (skew) i dystrybucji. Redshift Spectrum pozwala na odpytywanie zewnętrznych tabel S3 za pośrednictwem Glue Data Catalog. Utwórz schemat zewnętrzny za pomocą:

undefined

; Kryteria decyzyjne dla wyboru między Spectrum a natywnym Redshift:

Używaj Spectrum dla rzadko odpytywanych, dużych i zimnych danych przechowywanych w S3 lub dla architektur danych warstwowych.
Trzymaj gorące, często łączone zbiory danych wewnątrz Redshift dla zapewnienia wydajności; podczas łączenia z danymi w Spectrum, wybierz odpowiednie DISTKEYs, aby współlokować klucze złączenia lub użyj redystrybucji w celu zminimalizowania operacji I/O w sieci.

Amazon OpenSearch Service do analityki logów

OpenSearch jest zoptymalizowany pod kątem pozyskiwania (ingest) i szybkiej, doraźnej analizy logów, a konfiguracja jego indeksów i klastra determinuje przepustowość i koszt. Projektowanie indeksów i cykl ich życia:

Używaj wzorców indeksów, takich jak logs-YYYY.MM.DD, oraz szablonu indeksu (index template), aby ustawić index.number_of_shards (małe indeksy: 1 shard; duże: wiele shardów o rozmiarze ~10–50 GB) oraz index.number_of_replicas dla zapewnienia dostępności.
Skonfiguruj polityki cyklu życia indeksu (ILM), aby przenosić indeksy przez warstwy hot, warm, cold i UltraWarm w celu kontroli kosztów; UltraWarm redukuje koszty przechowywania danych historycznych na węzłach hot. Sharding i repliki wpływają na wydajność zapytań i indeksowania:
Więcej shardów zwiększa równoległość, ale dodaje narzut; dostosuj liczbę shardów na węzeł w oparciu o stertę (heap) i CPU.
Repliki poprawiają przepustowość odczytu i odporność na awarie; ustaw liczbę replik w oparciu o współbieżność zapytań i SLA. Polecenia operacyjne i wzorce w konsoli:
Użyj OpenSearch Dev Tools (lub curl) do wysyłania (PUT) szablonów indeksów i polityk ILM oraz monitoruj stan za pomocą API kondycji klastra. Alokuj atrybuty węzłów i używaj mechanizmu świadomości alokacji shardów (shard allocation awareness), aby zapobiegać hotspotom. Kryteria decyzyjne:
Wybierz UltraWarm, gdy wymagania dotyczące opóźnień zapytań do logów historycznych pozwalają na wyższe opóźnienie odczytu w zamian za niższy koszt przechowywania.
Trzymaj najnowsze indeksy na węzłach hot, aby wspierać szybkie agregacje i dashboardy.

QuickSight do BI i wizualizacji

QuickSight dostarcza szybkie dashboardy dzięki dwóm głównym trybom pobierania danych: SPICE (w pamięci) i direct query (zapytanie bezpośrednie). SPICE oferuje wydajność poniżej sekundy dla dashboardów i jest odpowiedni do powtarzalnych odczytów; bezpośrednie zapytania SQL (do Athena, Redshift, RDS) są preferowane dla bardzo dużych zbiorów danych lub danych często się zmieniających. Kluczowe konfiguracje i najlepsze praktyki:

Twórz zbiory danych w konsoli: New dataset > Wybierz źródło (Athena/Redshift/RDS/OpenSearch) > Import to SPICE lub Use direct query.
Używaj zaplanowanych odświeżeń SPICE dla potrzeb codziennych lub zbliżonych do czasu rzeczywistego; skonfiguruj odświeżanie przyrostowe oparte na partycjonowaniu według znacznika czasu, aby ograniczyć transfer danych. Bezpieczeństwo i zarządzanie:
Zaimplementuj zabezpieczenia na poziomie wiersza (row-level security) za pomocą mapowań użytkowników/grup QuickSight i reguł w zbiorze danych.
Dla dostępu do danych między kontami, wdróż rolę IAM i uprawnienia oparte na zasobach, które QuickSight będzie mógł przyjąć (assume). Kryteria decyzyjne:
Używaj SPICE dla dashboardów z wieloma jednoczesnymi użytkownikami i przewidywalnymi oknami odświeżania.
Używaj zapytań bezpośrednich, gdy świeżość danych jest krytyczna lub pojemność SPICE jest ograniczona; łącz je z polami obliczeniowymi i parametrami, aby uzyskać interaktywny interfejs użytkownika (UX).

← Orkiestracja danych i zarządzanie przepływami pracy · Wszystkie domeny · Bezpieczeństwo →

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