Amazon DEA-C01: Przechowywanie danych i architektura jeziora 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 sposób, w jaki usługi przechowywania i silniki baz danych AWS wspierają pozyskiwanie danych na dużą skalę, trwałą archiwizację, wydajność zapytań i bezpieczne zarządzanie w nowoczesnych platformach danych. Inżynierowie danych muszą równoważyć koszty, opóźnienia w dostępie, trwałość i szczegółową kontrolę dostępu podczas integracji usług takich jak S3, Lake Formation, Redshift i DynamoDB z potokami danych. Zrozumienie kompromisów między klasami pamięci masowej, automatyzacji cyklu życia, pamięci zarządzanej w porównaniu z lokalną oraz wzorców partycjonowania zapobiega niespodziankom związanym z wydajnością i kosztami w środowisku produkcyjnym.

Klasy pamięci masowej Amazon S3 i polityki cyklu życia

S3 oferuje wiele klas pamięci masowej i mechanizmów kontroli cyklu życia w celu optymalizacji kosztów i wzorców dostępu. Skonfiguruj klasę pamięci masowej podczas przesyłania (w konsoli lub przez CLI: aws s3 cp file s3://bucket/key –storage-class INTELLIGENT_TIERING) lub użyj reguł cyklu życia bucketu (aws s3api put-bucket-lifecycle-configuration –bucket my-bucket –lifecycle-configuration file://lifecycle.json). Intelligent-Tiering automatycznie przenosi obiekty między warstwami o częstym i rzadkim dostępie i wiąże się z niewielką opłatą za monitorowanie; włącz tę opcję dla nieznanych lub zmieniających się wzorców dostępu. Użyj reguł cyklu życia, aby przenosić obiekty do GLACIER lub DEEP_ARCHIVE w celu długoterminowego przechowywania oraz aby wygaszać/usuwać stare wersje.

Kryteria decyzyjne i kompromisy:

Intelligent-Tiering: niski narzut operacyjny dla zmiennego dostępu, miesięczna opłata za monitorowanie za obiekt; najlepsze, gdy wzorzec dostępu jest nieprzewidywalny.
Glacier vs Glacier Deep Archive: Glacier zapewnia szybsze opcje odzyskiwania standardowego i przyspieszonego przy wyższym koszcie przechowywania; Deep Archive jest najtańszy do wieloletniego przechowywania z czasami odzyskiwania zbiorczego/standardowego (godziny).
Standard-IA vs Intelligent-Tiering: Standard-IA ma 30-dniową minimalną opłatę i opłaty za odzyskiwanie — unikaj w przypadku danych o częstym dostępie lub obiektów o krótkim cyklu życia.

Uwagi operacyjne:

Włącz wersjonowanie (aws s3api put-bucket-versioning –bucket my-bucket –versioning-configuration Status=Enabled) i blokadę obiektów (aws s3api put-object-lock-configuration –bucket my-bucket –object-lock-configuration file://lock.json) w celu zapewnienia niezmienności; włączenie MFA Delete wymaga specjalnych operacji CLI i konta właściciela bucketu z MFA.
Przejścia cyklu życia dotyczą wersji obiektów i mogą być ograniczone zakresem za pomocą prefiksu/tagów; użyj abort-incomplete-multipart-upload, aby uniknąć wycieków pamięci masowej.

Projektowanie data lake z S3 i Lake Formation

Zaprojektuj data lake z S3 jako centralnym magazynem obiektów i Lake Formation do scentralizowanej kontroli dostępu i katalogowania. Zarejestruj lokalizacje S3 jako zasoby Lake Formation, skonfiguruj AWS Glue Data Catalog i użyj uprawnień Lake Formation dla baz danych/tabel (aws lakeformation grant-permissions –principal arn:aws:iam::123456789012:user/analyst –permissions SELECT –resource ‘{…}’). Lake Formation może wymuszać szczegółowe kontrole: na poziomie kolumn, na poziomie wierszy (wyrażenia filtrujące) i maskowanie na poziomie komórek przy użyciu LF-tags i filtrów danych stosowanych do zapytań Glue/Athena.

Kluczowe wzorce konfiguracji i zarządzania:

Zarejestruj lokalizację: użyj konsoli Lake Formation, aby zarejestrować s3://bucket/path i dołączyć rolę IAM, która pozwala Lake Formation na crawlowanie/odczyt.
Szczegółowe polityki: zdefiniuj LF-tags i dołącz je do tabel/kolumn; nadawaj uprawnienia z listą kolumn (column-list), aby ograniczyć kolumny, i używaj wyrażeń filtrujących wiersze (row-filter expressions), aby ograniczyć wiersze zwracane dla podmiotu zabezpieczeń (principal).
Pamiętaj, że uprawnienia Lake Formation mogą nadpisywać lub blokować uprawnienia IAM S3 dla dostępu z Glue/Athena — w razie potrzeby nadaj zarówno uprawnienia na poziomie Lake Formation, jak i S3.

Punkty decyzyjne:

Użyj Lake Formation, gdy potrzebujesz scentralizowanego katalogowania, LF-tags i szczegółowego egzekwowania uprawnień w wielu silnikach analitycznych.
Dla prostej kontroli dostępu lub dostępu z narzędzi zewnętrznych, rozważ polityki bucketów S3 i IAM, ale bądź ostrożny: silniki analityczne zarządzane przez Lake Formation mogą ignorować uprawnienia nadane wyłącznie przez IAM.

Architektura i przechowywanie danych w Amazon Redshift

Redshift oddziela moc obliczeniową i zarządzaną pamięć masową w węzłach RA3 od lokalnej pamięci masowej w węzłach DS2 opartych na dyskach SSD. Węzły RA3 używają Redshift Managed Storage (RMS), gdzie dane rezydują w Amazon S3 zarządzanym przez klaster; wybierz RA3 dla skalowalnej pamięci masowej ze stałą wydajnością zapytań i możliwością płacenia za moc obliczeniową oddzielnie. Węzły DS2 przechowują dane na dyskach lokalnych instancji, co wymaga starannego doboru rozmiaru i jego zmiany w miarę wzrostu ilości danych.

Szczegóły konfiguracji i operacji:

Utwórz klaster RA3 przez konsolę lub CLI: aws redshift create-cluster –cluster-identifier my-cluster –node-type ra3.xlplus –number-of-nodes 2 –master-username admin –master-user-password Passw0rd.
Polecenie COPY: musi być uruchomione w klastrze z dołączoną rolą IAM, która nadaje uprawnienia do odczytu z S3. Dołącz rolę podczas tworzenia klastra lub zmodyfikuj klaster, aby dodać role IAM; ARN roli (arn:aws:iam::acct:role/RedshiftS3Role) jest przywoływany w poleceniu COPY jako poświadczenia ‘aws_iam_role=arn:…’.
Monitoruj kolejki WLM, akcelerację krótkich zapytań (short query acceleration), automatyczne odkurzanie (automatic vacuuming) i używaj SORT/ENCODE do optymalizacji przechowywania i wydajności.

Porównanie (RA3 vs DS2):

RA3: oddzielona pamięć masowa, automatyczne przenoszenie danych do S3 (data tiering), mniejszy narzut na zarządzanie pamięcią, najlepsze dla rosnących zbiorów danych.
DS2: lokalna pamięć masowa SSD, niższe opóźnienia dla danych lokalnych, ale ograniczona pojemność i trudniejsze skalowanie.

DynamoDB i wybór specjalizowanych baz danych

Wybierz DynamoDB dla obciążeń typu klucz-wartość i dokumentowych o dużej skali, wymagających opóźnień rzędu pojedynczych milisekund. Projekt tabeli zależy od wyboru klucza partycji (i opcjonalnego klucza sortowania): używaj kluczy o wysokiej kardynalności i dobrym rozkładzie, aby unikać gorących partycji (hot partitions). Dla kluczy sekwencyjnych lub opartych na znacznikach czasu zaimplementuj losowe prefiksy (sharding) lub użyj identyfikatorów UUID, aby rozproszyć operacje zapisu. Używaj pojemności na żądanie (on-demand), aby uniknąć provisioningu, ale rozważ pojemność provisionowaną z autoskalowaniem dla przewidywalnych obciążeń i aby wykorzystać pojemność adaptacyjną (adaptive capacity) na gorących partycjach.

Praktyczne uwagi dotyczące konfiguracji:

Tworzenie tabeli przez CLI:

undefined

Używaj GSI dla alternatywnych wzorców dostępu, włącz TTL dla automatycznego wygasania danych i wykorzystuj DynamoDB Streams + Lambda dla wzorców przechwytywania zmian danych (change-data-capture).
Do buforowania obciążeń z dużą liczbą odczytów dodaj DAX; dla złożonych zapytań lub potrzeb relacyjnych wybierz Aurora lub Redshift Spectrum w zależności od złożoności zapytań i wymagań dotyczących spójności.

Kryteria wyboru silnika bazodanowego:

Użyj DynamoDB dla przewidywalnych wzorców dostępu do pojedynczej tabeli i masowej skali przy niskich opóźnieniach.
Użyj Redshift do złożonej analityki i wielkoskalowych zastosowań OLAP.
Użyj Aurora dla transakcyjnych obciążeń relacyjnych.

Częste pułapki i kryteria decyzyjne

Używanie S3 Standard-IA dla często odpytywanych danych — Standard-IA ma minimalną opłatę za 30 dni; używaj Standard lub Intelligent-Tiering dla obiektów o krótkim cyklu życia lub często odpytywanych.
Zapominanie, że uprawnienia Lake Formation nadpisują uprawnienia IAM S3 dla Glue/Athena — nadaj dostęp zarówno w Lake Formation, jak i w S3, gdy używasz Glue/Athena, i zweryfikuj obowiązujące uprawnienia w konsoli Lake Formation.
Polecenie COPY w Redshift wymaga roli IAM przypisanej do klastra, a nie tylko uprawnień użytkownika — przypisz rolę IAM z dostępem do S3 do klastra i odwołuj się do jej ARN w operacjach COPY.
Gorące partycje (hot partitions) w DynamoDB spowodowane kluczami sekwencyjnymi — unikaj kluczy monotonicznych; używaj kluczy haszowanych, losowych prefiksów lub UUID i rozważ pojemność na żądanie (on-demand) lub provisionowaną z autoskalowaniem.
Nieprawidłowe włączanie S3 Object Lock i MFA Delete — object lock wymaga włączonego wersjonowania i odpowiednich uprawnień; MFA Delete można włączyć/wyłączyć tylko za pomocą CLI z użyciem MFA i ma ścisłe wymagania dotyczące właściciela bucketu.
Niewłaściwe przejścia cyklu życia bez testowania kosztów i czasów odzyskiwania danych — przetestuj przepływy odzyskiwania dla klas Glacier, aby uniknąć niespodziewanych opóźnień i opłat za odzyskiwanie.

Problem praktyczny: Scenariusz użycia

Firma Acme Media musi przechowywać 50 TB surowych danych wideo, zapewniać analitykom dostęp do zapytań do przetworzonych metadanych oraz wymuszać dostęp na poziomie wierszy i kolumn dla różnych jednostek biznesowych, minimalizując jednocześnie koszty przechowywania.

Przesyłaj surowe wideo do S3 za pomocą multipart upload, taguj obiekty według daty pozyskania i zestawu danych, użyj Intelligent-Tiering dla początkowych, nieznanych wzorców dostępu.
Skonfiguruj reguły cyklu życia, aby przenosić media do GLACIER lub DEEP_ARCHIVE po konfigurowalnym okresie retencji (upewnij się, że jest on zgodny z minimum 30 dniami dla Standard-IA, jeśli ta klasa jest brana pod uwagę).
Zarejestruj lokalizacje S3 w Lake Formation, zbuduj crawlery Glue, aby wypełnić Data Catalog, i nadaj uprawnienia na poziomie wierszy i kolumn oparte na tagach LF dla jednostek biznesowych.
Przechowuj przetworzone metadane w Redshift RA3 do celów analitycznych; przypisz rolę IAM do klastra dla operacji COPY z S3 i używaj operacji VACUUM/ANALYZE w oknach konserwacyjnych.
Użyj DynamoDB z haszowanymi kluczami UUID dla tabeli przeglądowej manifestów wideo o wysokiej przepustowości i włącz pojemność na żądanie (on-demand), aby absorbować skoki ruchu.

Uzasadnienie: Takie podejście izoluje koszty przechowywania zimnych danych dzięki klasom Glacier, wykorzystuje Intelligent-Tiering dla nieznanych wzorców, stosuje Lake Formation do bezpiecznej, szczegółowej kontroli dostępu w różnych silnikach analitycznych i wybiera RA3 dla skalowalnego przechowywania danych analitycznych, podczas gdy DynamoDB obsługuje operacyjne wyszukiwania o niskim opóźnieniu.

← Ingestia i gromadzenie danych · Wszystkie domeny · Katalogowanie danych i zarządzanie metadanymi →

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