Amazon DEA-C01: Jakość danych, walidacja i obserwowalność — 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 kompleksowe praktyki i usługi AWS używane do zapewnienia poprawności danych, wykrywania anomalii i utrzymania niezawodności potoków. Silna walidacja i obserwowalność redukują defekty w dalszych etapach, pozwalając spełniać umowy SLA i umożliwiając bezpieczne ponowne przetwarzanie. Inżynierowie danych muszą łączyć Glue Data Quality, frameworki walidacyjne, wykrywanie anomalii w CloudWatch, kolejki DLQ i idempotentne projektowanie, aby budować solidne potoki.

Reguły i ocena w AWS Glue Data Quality

Glue Data Quality używa zestawów reguł w języku Data Quality Definition Language (DQDL) do definiowania asercji dotyczących zbiorów danych (liczba wierszy, progi wartości null, unikalność, niestandardowe sprawdzenia SQL). Zestawy reguł można tworzyć w konsoli lub za pomocą CLI (przykładowy wzorzec: aws glue create-data-quality-ruleset –name MyRuleset –rules file://dqdl.json). Zestawy reguł mogą być dołączane do zadań Glue ETL lub uruchamiane niezależnie za pomocą API StartDataQualityRuleRecommendationRun / StartDataQualityRulesetEvaluationRun w celu oceny zbiorów danych przechowywanych w S3, tabelach katalogu lub Glue DynamicFrames.

Kluczowe szczegóły konfiguracji i kryteria decyzyjne:

• Struktura DQDL: reguły zawierają ruleName, expression (DQDL lub SQL), severity (poziom ważności) i akcję w przypadku niepowodzenia. Jawnie ustaw akcję w przypadku niepowodzenia na FAIL zadania, gdy krytyczne sprawdzenia zawiodą; w przeciwnym razie Glue może zapisać wyniki w logach bez zatrzymywania wykonania z błędem.
• Kontekst oceny: podaj odwołania do tabeli lub ścieżki S3 oraz opcje próbkowania (pełne skanowanie vs. próbka) za pomocą parametrów zadania lub danych wejściowych uruchomienia oceny, aby zrównoważyć koszt i zakres.
• Wyniki: ocena reguł zapisuje wyniki do metryk Glue oraz do Amazon S3 w formacie JSON; użyj tych artefaktów do audytu i automatycznej naprawy.

Kiedy używać Glue Data Quality a kiedy zewnętrznych frameworków:

• Używaj Glue DQDL do standardowych reguł dotyczących schematu, kompletności i prostej unikalności, które integrują się natywnie z zadaniami Glue i pochodzeniem danych (lineage).
• Używaj Great Expectations (zobacz następną poddomenę), gdy potrzebujesz bogatszych bibliotek oczekiwań, bardziej ekspresywnych sprawdzeń lub współdzielonych zestawów oczekiwań (expectation suites) w wielu systemach.

Wzorce walidacji danych w potokach

Walidacja powinna odbywać się w wielu punktach styku: na wejściu (ingress), podczas transformacji i na wyjściu (sink). Typowe wzorce:

• Lekkie sprawdzenia przed pozyskaniem danych (pre-ingest) w producentach Lambda/Kinesis pod kątem schematu i podstawowych zakresów wartości, aby odrzucać lub przekierowywać nieprawidłowe wiersze przed potokiem.
• Walidacja po stronie serwera w zadaniach Glue ETL (Spark) przy użyciu zestawów reguł DQDL i jawnych walidacji w kodzie. W Glue Studio dodaj transformację Data Quality, która odwołuje się do zestawu reguł; w CLI przekaż

undefined

lub dołącz parametry zadania, aby wyzwolić uruchomienia oceny.

• Walidacja po transformacji za pomocą Great Expectations zintegrowanego z zadaniami Glue Python Shell lub Glue Spark. Wdróż oczekiwania (expectations) do S3 (katalog

undefined

) i załaduj DataContext w zadaniu:

undefined

po zsynchronizowaniu oczekiwań z S3 ze środowiskiem zadania.

Porównanie opcji walidacji:

• Glue DQDL
  • Zalety: natywna integracja, niski narzut operacyjny, zapisuje wyniki do katalogu/metryk Glue
  • Wady: mniej ekspresywny dla złożonych oczekiwań logicznych
• Great Expectations
  • Zalety: bogate oczekiwania, dokumentacja danych (data docs), zintegrowane punkty kontrolne, rozszerzalne backendy
  • Wady: wymaga pakowania i zarządzania artefaktami oczekiwań w S3 oraz orkiestracji w zadaniach Glue
• Ręczne sprawdzenia w kodzie (Spark/DataFrame)
  • Zalety: pełna elastyczność, wysoka wydajność dla niestandardowej logiki
  • Wady: wyższe koszty utrzymania, brak standaryzowanego raportowania bez dodatkowej pracy

Dla przetwarzania strumieniowego waliduj rekordy „w locie” (in-flight), a w przypadku niepowodzenia przesyłaj je do kolejki SQS DLQ (skonfiguruj RedrivePolicy z maxReceiveCount za pomocą AWS CLI lub konsoli), zamiast je odrzucać. Dla przetwarzania wsadowego (batch) generuj artefakt z raportem walidacji i na podstawie polityki zakończ zadanie niepowodzeniem lub poddaj wyniki kwarantannie.

Wykrywanie anomalii i monitorowanie dryfu danych

Używaj wykrywania anomalii w CloudWatch dla metryk operacyjnych (przetworzone rekordy, wskaźnik błędów, czas trwania zadania). Utwórz detektor za pomocą CLI:

undefined

, a następnie utwórz alarmy CloudWatch odwołujące się do pasma detekcji anomalii. W przypadku dryfu na poziomie danych (zmiany w dystrybucji, zmiany wskaźnika wartości null), planuj zadania profilowania w Glue DataBrew (

undefined

) do obliczania statystyk, histogramów i kwantyli; przechowuj profile w S3 jako punkty odniesienia (baselines).

Kryteria decyzyjne dla alarmów anomalii a alarmów progowych:

• Wybierz wykrywanie anomalii w CloudWatch, gdy wzorce metryk są sezonowe lub zmienne; uczy się ono przeszłych zachowań i redukuje potrzebę ręcznego dostrajania progów.
• Używaj statycznych alarmów progowych dla warunków binarnych (np. zadanie zablokowane przez > X godzin), gdzie przewidywalność jest wysoka.

Dla zautomatyzowanego wykrywania dryfu:

• Planuj regular

Zarządzanie SLA i niezawodność potoków

Zarządzanie SLA łączy obserwowalność z naprawą i inżynierią niezawodności (reliability engineering). Instrumentuj każdy potok za pomocą tych podstawowych metryk: przepustowość (rekordy/sek), opóźnienie (ingest→sink), wskaźnik błędów, czas działania zadania/środowiska uruchomieniowego oraz liczba elementów w systemach docelowych. Użyj CloudWatch Metrics dla zadań Glue (metryki uruchomienia zadania), opóźnienia konsumenta Kinesis/Kafka oraz niestandardowych metryk aplikacji za pomocą

undefined

.

Wzorce niezawodności i szczegóły konfiguracji:

• Kolejki martwych listów (SQS DLQ): dla konsumentów strumieniowych (Lambda, konsumenci Kinesis) skonfiguruj DLQ i ustaw

undefined

. Użyj retencji DLQ i oddzielnego zadania przetwarzającego do inspekcji i ponownego przetwarzania wiadomości z DLQ.

• Projektowanie idempotentne: upewnij się, że ujścia (sinks) obsługują idempotentne zapisy — przykłady:
  • DynamoDB: użyj

undefined

z wyrażeniami warunkowymi lub kluczem złożonym jako tokenem idempotencji.

• S3: zapisuj za pomocą wzorców atomowej zmiany nazwy lub używaj kluczy opartych na zawartości (hash rekordu), aby ponowne uruchomienia nadpisywały dane, a nie je duplikowały.
• Redshift/Glue ETL: użyj tabeli przejściowej (staging) i operacji

undefined

według klucza, aby deduplikować dane po ponownym przetworzeniu.

• Checkpointing: włącz punkty kontrolne (checkpoints) konektora Kinesis/DynamoDB i zarządzaj częstotliwością checkpointingu konsumenta, aby zrównoważyć okno ponownego przetwarzania i ryzyko duplikacji.

Kryteria decyzyjne dla ponawiania prób (retry) vs szybkiego przerywania (fail-fast):

• Dla błędów przejściowych (throttling w systemie docelowym) zaimplementuj ponawianie prób z wykładniczym czasem oczekiwania (exponential backoff) i przekierowanie do DLQ dopiero po osiągnięciu maksymalnej liczby prób.
• Dla błędów jakości danych (niedopasowanie schematu) szybko przerwij działanie (fail fast) i zapisz problematyczne rekordy do prefiksu kwarantanny w S3 z metadanymi do ręcznej weryfikacji.

Typowe pułapki i kryteria decyzyjne

• Reguły Glue Data Quality domyślnie rejestrują błędy, ale nie powodują niepowodzenia zadania — skonfiguruj akcję reguły na

undefined

dla krytycznych sprawdzeń i dołącz ocenę zestawu reguł do uruchomienia zadania.

• Potoki strumieniowe bez DLQ odrzucają lub tracą nieprzetworzone rekordy — zawsze konfiguruj SQS DLQ (lub trwały staging na S3) oraz politykę ponownego kierowania (redrive policy) w celu inspekcji i ponownego przetwarzania.
• Ponowne przetwarzanie bez idempotencji powoduje powstawanie zduplikowanych rekordów — projektuj deterministyczne klucze, używaj semantyki upsert/merge w ujściu (sink) lub stosuj klucze obiektów oparte na zawartości dla S3.
• Wykrywanie dryfu danych (data drift) bez punktów odniesienia (baselines) generuje szum informacyjny w alertach — zaplanuj zadania profilujące w Glue DataBrew, aby tworzyć i przechowywać statystyki bazowe, a następnie porównuj z nimi nowe profile.
• Nadmierne poleganie na statycznych progach CloudWatch powoduje fałszywe alarmy — używaj wykrywania anomalii CloudWatch dla metryk sezonowych/zmiennych, a statyczne progi rezerwuj dla nienegocjowalnych limitów.
• Ustawienie zbyt wysokiej wartości

undefined

opóźnia przekierowanie do DLQ i zwiększa opóźnienie przetwarzania — wybierz rozsądną wartość

undefined

, aby wiadomości, które stale powodują błędy, trafiały do DLQ w odpowiednim czasie.

Problem praktyczny: Scenariusz użycia

Firma Streamline Retail napotyka częste błędy w raportowaniu po nocnych zadaniach ETL: sporadyczne nagłe zmiany schematu, ciche naruszenia reguł i zduplikowane zamówienia podczas ponownego przetwarzania nieudanych uruchomień.

1. Zaimplementuj reguły Glue Data Quality (DQDL) dla schematu, progów wartości null i unikalności

undefined

; ustaw akcję w przypadku błędu na

undefined

zadania i publikuj artefakty oceny w S3. 2. Dodaj Great Expectations w kroku Glue Python Shell dla złożonych weryfikacji biznesowych (spójność zamówień między tabelami); przechowuj oczekiwania (expectations) w S3 i uruchamiaj punkty kontrolne (checkpoints) w potoku. 3. Zaplanuj zadania profilujące w DataBrew, aby przechwytywać codzienne dane bazowe (kardynalność, wskaźnik wartości null, percentyle) i używaj zautomatyzowanych porównań do wykrywania dryfu. 4. Dla strumieniowych zdarzeń zamówień skonfiguruj SQS DLQ z odpowiednią polityką

undefined

i utwórz zadanie ponawiające (replay job) do idempotentnego przetwarzania wiadomości z DLQ (używając

undefined

jako klucza deduplikacji). 5. Instrumentuj detektory anomalii CloudWatch dla czasu działania zadania i liczby błędów; podłącz alarmy oparte na anomaliach do SNS w celu eskalacji do zespołu dyżurnego.

Uzasadnienie zgodne z najlepszymi praktykami AWS: połącz natywne mechanizmy kontroli jakości Glue w celu szybkiej integracji, Great Expectations dla większej ekspresywności, DataBrew do tworzenia statystyk bazowych oraz detektory anomalii CloudWatch do adaptacyjnego monitorowania. Kolejki DLQ i idempotentne ujścia (sinks) zamykają pętlę, umożliwiając bezpieczne ponawianie prób i ponowne przetwarzanie przy jednoczesnym zachowaniu umów SLA.

← Optymalizacja kosztów dla obciążeń danych · Wszystkie domeny

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

Przeglądaj Amazon →