Amazon DEA-C01: Monitorowanie potoków danych i rozwiązywanie problemów — 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.

Monitorowanie i rozwiązywanie problemów z potokami danych jest kluczowe dla zapewnienia terminowego i dokładnego dostarczania danych strumieniowych i wsadowych w AWS. Ten obszar obejmuje techniki telemetrii, alertowania i diagnostyki dla usług takich jak Kinesis, Firehose, Glue, DMS, Lambda oraz ścieżek audytowych AWS, które wspierają badanie incydentów. Efektywny monitoring skraca średni czas wykrywania/naprawy (Mean Time To Detect/Recover) poprzez ujawnianie opóźnień konsumentów (consumer lag), obciążenia zasobów zadań, opóźnień w dostarczaniu oraz nieautoryzowanego dostępu. Poniższe sekcje przedstawiają konkretne sygnały, wzorce użycia CLI/konsoli oraz kryteria decyzyjne do operowania i naprawy produkcyjnych przepływów danych.

Metryki i alarmy CloudWatch dla usług danych

CloudWatch jest główną płaszczyzną telemetrii: twórz filtry metryk, pulpity nawigacyjne i alarmy dla kluczowych metryk usług oraz integruj alarmy z SNS, EventBridge lub Systems Manager w celu zautomatyzowanej naprawy. Użyj aws cloudwatch put-metric-alarm do programistycznego tworzenia alarmów; typowe flagi to --metric-name, --namespace, --statistic (lub --extended-stat), --threshold, --evaluation-periods i --comparison-operator. W przypadku pulpitów nawigacyjnych, przesyłaj niestandardowe metryki (np. z metadanych zadania Glue) za pomocą aws cloudwatch put-metric-data z przestrzenią nazw taką jak „MyCompany/DataPipeline”.

Skup się na tych metrykach i wzorcach, na które można reagować:

• Glue: monitoruj BytesRead, BytesWritten, RecordsProcessed i DPUHrs, aby wykrywać zmiany w wolumenie danych, ich skośność (skew) i koszty. Alarmy: nagły spadek RecordsProcessed lub skoki DPUHrs na rekord.
• Kinesis: monitoruj GetRecords.IteratorAgeMilliseconds pod kątem opóźnień konsumenta oraz IncomingBytes/IncomingRecords pod kątem obciążenia po stronie źródła.
• Firehose: monitoruj DeliveryToS3.DataFreshness i DeliveryToS3.Records, aby wykrywać opóźnienia w dostarczaniu i utratę danych.
• DMS: monitoruj FullLoadRows, CDCLatencyMilliseconds i AppliedChanges pod kątem kondycji replikacji.

Kryteria decyzyjne dla alertowania:

• Używaj alarmów złożonych (CloudWatch composite alarms), aby zredukować szum (liczbę fałszywych alarmów): połącz warunki IteratorAgeMilliseconds > X dla 3 punktów danych ORAZ wskaźnik błędów konsumenta > Y.
• Przy wyborze progów, wyznaczaj poziomy bazowe na podstawie danych historycznych z 7–14 dni i ustawiaj dynamiczne progi za pomocą modeli wykrywania anomalii (PutAnomalyDetector), gdy obciążenia są sezonowe.

Monitorowanie i obsługa błędów w zadaniach Glue

Glue emituje metryki do CloudWatch i zapisuje logi w /aws-glue/jobs/output (logi uruchomienia zadania) oraz /aws-glue/jobs/error (błędy). Użyj CloudWatch Logs Insights do odpytywania o uruchomienia zadań: wykonuj zapytania przez konsolę lub za pomocą aws logs start-query z zapytaniem takim jak fields @timestamp, @message | filter @message like /ERROR/ | sort @timestamp desc | limit 20. Śledź BytesRead, BytesWritten, RecordsProcessed i DPUHrs z metryk uruchomienia zadania Glue — DPUHrs jest bezpośrednio skorelowany z kosztem i równoległością zadania.

Typowe tryby awarii Glue i sposoby ich naprawy:

• OutOfMemory (OOM) lub utrata Executora: zwiększ typ workera/liczbę DPU, przełącz się na typ workera G.2X dla zadań o większym zapotrzebowaniu na pamięć, lub zoptymalizuj partycjonowanie w Sparku (repartition/coalesce) i użyj predykatów pushdown, aby zmniejszyć wolumen danych wejściowych.
• Skośność danych (data skew) powodująca maruderów (stragglers): użyj kluczy partycjonujących do zrównoważenia, zwiększ równoległość lub użyj opcji split/resolve choices w Glue DynamicFrame, gdy jest to właściwe.
• Zatrzymanie zadania lub długi czas uruchamiania: włącz zakładki zadań (job bookmarks) i monitoruj Glue JobMetrics pod kątem „TimeWaitingForResources”, aby zidentyfikować rywalizację o zasoby.

Kompromisy decyzyjne:

• Zwiększ DPU, gdy wąskim gardłem jest CPU/pamięć i liczy się przewidywalność czasu wykonania; preferuj optymalizacje kodu (partycjonowanie, cachowanie tylko w razie potrzeby), jeśli koszty muszą być pod kontrolą.
• Używaj Glue streaming do transformacji w czasie zbliżonym do rzeczywistego; używaj Glue ETL batch do złożonych transformacji Spark i większych obciążeń przyjaznych dla instancji Spot.

Monitorowanie Kinesis i Firehose

Opóźnienie konsumenta Kinesis (Consumer Lag): polegaj na GetRecords.IteratorAgeMilliseconds, aby wykryć, jak bardzo konsumenci są opóźnieni. Jeśli GetRecords.IteratorAgeMilliseconds jest stale wysokie:

• Skaluj poprzez zwiększenie liczby shardów (resharding/skalowanie), lub
• Popraw wydajność konsumenta przez batching, użycie enhanced fan-out (dla przepustowości do 2 MB/s na konsumenta) lub Kinesis Client Library (KCL) v2 z ulepszonym checkpointingiem.

Użyj aws kinesis describe-stream, aby sprawdzić liczbę shardów, oraz aws cloudwatch get-metric-statistics dla GetRecords.IteratorAgeMilliseconds. Porównując opcje naprawy, weź pod uwagę:

• Dodawanie shardów: zwiększa przepustowość zapisu i odczytu; wymaga reshardingu i rebalancingu.
• Enhanced fan-out: unika współdzielonej przepustowości odczytu, ale zwiększa koszt na konsumenta.
• Optymalizacja konsumenta: zmniejsza potrzebę dodatkowych shardów i koszty, ale wymaga wysiłku inżynierskiego.

Metryki dostarczania Firehose: DeliveryToS3.DataFreshness określa ilościowo opóźnienie w dostarczaniu; typowe ustawienia buffering_delay to 60–900 sekund i będą przechowywać rekordy, dopóki nie zostanie osiągnięty bufferSize lub bufferInterval. Jeśli DeliveryToS3.DataFreshness jest wysokie:

• Sprawdź wskazówki dotyczące buforowania Firehose (BufferIntervalInSeconds, BufferSizeInMBs) w konsoli lub za pomocą aws firehose describe-delivery-stream.
• Sprawdź błędy w CloudWatch (DeliveryToS3.RecordsFailed) i uprawnienia bucketu S3 (błędy KMS, jeśli jest zaszyfrowany).

Pamiętaj o semantyce buforowania Firehose: usługa celowo opóźnia dostarczenie danych do wartości interwału buforowania; zmniejsz interwał buforowania, aby obniżyć opóźnienie kosztem częstszych zapisów do S3.

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

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

Przeglądaj Amazon →