Amazon SAP-C02: Bazy danych i analityka — Przewodnik do nauki

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

Część AWS Solutions Architect Professional SAP-C02 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Amazon, albo rozwiąż testy na czas na ExamRoll.io.

Transakcyjne bazy danych, wzorce skalowania i buforowanie

Wybór między Amazon RDS (MySQL/PostgreSQL/Oracle/SQL Server), Amazon Aurora i Amazon DynamoDB zaczyna się od profilu obciążenia: ścisły schemat relacyjny i złożone transakcje przemawiają za RDS/Aurora; masowa skala, wyszukiwanie z jednocyfrowym opóźnieniem milisekundowym i elastyczny schemat przemawiają za DynamoDB. Aurora oferuje wysoką przepustowość dzięki rozproszonej pamięci masowej, automatycznemu skalowaniu replik, szybkiemu przełączaniu awaryjnemu (failover), Global Database dla odczytów międzyregionalnych i odzyskiwaniu po awarii (disaster recovery) z niższym opóźnieniem. RDS Multi-AZ zapewnia synchroniczną replikację w celu zapewnienia dostępności, ale nie skalowania odczytu; repliki do odczytu (read replicas) w RDS/Aurora obsługują obciążenia z dużą liczbą operacji odczytu. Dla buforowania klucz-wartość i mikrosekundowych opóźnień, ElastiCache (Redis lub Memcached) zmniejsza obciążenie bazy danych; MemoryDB for Redis dodaje trwałość (durability) i kompatybilną z Redis persystencję tam, gdzie dane muszą być wysoko dostępne i odtwarzalne. Częste pułapki to niedoszacowanie limitów połączeń (maksymalna liczba połączeń w MySQL), nieużywanie puli połączeń (connection pooling) (gdy Lambda/kontenery tworzą wiele połączeń), gorące partycje (hot partitions) w DynamoDB z powodu złego projektu klucza oraz zaniedbanie strategii usuwania danych z pamięci podręcznej (cache eviction) i jej projektu, co prowadzi do nieaktualności danych. Kompromisy decyzyjne często koncentrują się na koszcie w stosunku do wydajności i odporności: provisioned instancje Aurora lub duże instancje RDS kosztują więcej, ale zmniejszają opóźnienia i upraszczają transakcje, podczas gdy DynamoDB w trybie on-demand lub z autoskalowaniem może obniżyć koszty operacyjne, ale wymaga starannego planowania schematu i pojemności. Szyfrowanie, zautomatyzowane kopie zapasowe, PITR (przywracanie do punktu w czasie) i wzorce replikacji międzyregionalnej powinny być dobierane zgodnie z RPO/RTO.

Data Lake, ETL i analityczne silniki zapytań

S3 jest kanonicznym, trwałym jeziorem danych (data lake); projektuj je w oparciu o partycjonowanie, formaty kolumnowe (Parquet/ORC), kompresję i kompakcję, aby zapewnić opłacalne zapytania. AWS Glue i AWS Glue Data Catalog zapewniają bezserwerowy ETL, wykrywanie schematów i katalogowanie; Lake Formation dodaje scentralizowaną kontrolę dostępu, szczegółowe uprawnienia (fine-grained permissions) i udostępnianie między kontami dla zarządzanych jezior danych (governed lakes). Do interaktywnej analityki Amazon Athena odpytuje dane bezpośrednio z S3 (bezserwerowo, płatność za zapytanie), podczas gdy Amazon Redshift (ze wsparciem dla RA3/Iceberg) zapewnia wydajną, zarządzaną hurtownię danych MPP dla złożonych zapytań BI i operacji join. Użyj Redshift Spectrum, aby odpytywać dane z S3 bezpośrednio z Redshift bez konieczności ich wcześniejszego ładowania. Kinesis Data Firehose to zarządzana ścieżka pozyskiwania danych (ingest), która umożliwia zapisywanie zdarzeń strumieniowych w S3 lub Redshift. Częste pułapki architektoniczne to zbyt wiele małych plików powodujących duży narzut w Athena/Redshift, źle dobrane klucze partycji tworzące nierównomierne rozłożenie danych (skew) oraz brak kompakcji lub konwersji do formatów kolumnowych. Kompromisy dotyczą opóźnienia w stosunku do kosztu: Athena ma niski koszt operacyjny dla zapytań ad-hoc; Redshift zapewnia wyższą, stałą wydajność przy wyższym koszcie provisioned. Zarządzanie danymi (data governance) i śledzenie ich pochodzenia (lineage) za pomocą Glue/Lake Formation są kluczowe dla zgodności z regulacjami (compliance) i współdzielenia odpowiedzialności przez wiele zespołów.

Przetwarzanie strumieniowe, przetwarzanie w czasie rzeczywistym i wyszukiwanie

Pozyskiwanie i przetwarzanie w czasie rzeczywistym wykorzystuje Kinesis Data Streams (przepustowość oparta na fragmentach (shard) i gwarancje kolejności), Kinesis Data Firehose (zarządzane dostarczanie do miejsc docelowych, tzw. sinks), Kinesis Data Analytics (przetwarzanie za pomocą SQL/Apache Flink) lub Amazon MSK dla potrzeb kompatybilnych z Kafka. Wybierz Kinesis dla prostej, natywnej integracji bezserwerowej w AWS; wybierz MSK, gdy klienci polegają na narzędziach ekosystemu Kafka. Semantyka dostarczania „co najmniej raz” (at-least-once), limity fragmentów (shard), równoległość konsumentów i zapewnienie odpowiedniej liczby fragmentów to częste pułapki operacyjne. Dla dalszego szybkiego wyszukiwania i obserwowalności (observability), Amazon OpenSearch Service zapewnia indeksowanie, wyszukiwanie w czasie niemal rzeczywistym i wbudowane pulpity nawigacyjne Kibana; zarządzanie cyklem życia indeksów oraz warstwy warm/cold zmniejszają koszty przechowywania starszych danych. Użyj Kinesis + Lambda lub Kinesis + KDA do wzbogacania/transformacji zdarzeń przed ich zapisaniem w OpenSearch lub S3. Zaprojektuj idempotentność i deduplikację po stronie konsumentów, ponieważ ponowne próby (retries) lub powtórzenia (replays) powodują duplikaty. Kryteria decyzyjne balansują między przepustowością a opóźnieniem: Kinesis z wieloma fragmentami (shards) obsługuje wysoką przepustowość, ale zwiększa koszty i zarządzanie; Firehose zdejmuje obciążenie z konsumenta, ale oferuje mniej elastyczne transformacje.

Migracja, replikacja, ład korporacyjny i odporność operacyjna

Database Migration Service (AWS DMS) i Schema Conversion Tool (SCT) to podstawowe narzędzia do migracji homogenicznych i heterogenicznych, umożliwiające ciągłe przechwytywanie zmian danych (CDC). Wzorce migracji obejmują rehost (lift-and-shift), replatform (np. przeniesienie do Aurora) oraz refactor do DynamoDB lub rozwiązań serverless, w zależności od potrzeb. Używaj DMS z walidacją przed i po migracji, równoległym kopiowaniem tabel i ostrożnym obchodzeniem się z LOB/LOBLOB. Replikacja między kontami i regionami wymaga dostępu do kluczy KMS, VPC peeringu lub Transit Gateway oraz planowania przepustowości sieci; Global Databases i repliki do odczytu (read replicas) są alternatywami, gdy potrzebne są odczyty o niskim opóźnieniu między regionami. Ład korporacyjny i bezpieczeństwo muszą obejmować Lake Formation do udostępniania danych, zasadę najmniejszych uprawnień (least privilege) w IAM, polityki zasobów dla snapshotów S3 i RDS oraz punkty końcowe VPC/PrivateLink, aby unikać publicznego ruchu wychodzącego (egress). Pułapki operacyjne obejmują niewystarczający monitoring (przeoczone opóźnienie repliki), nietestowanie procedur przełączania awaryjnego (failover) i scenariuszy (runbooks) oraz ukryte koszty ruchu wychodzącego podczas masowych transferów. Backup, strategia PITR (point-in-time recovery) i zautomatyzowane odzyskiwanie wpływają na kompromisy między RTO/RPO; łącz replikację dla zapewnienia dostępności z regularnymi backupami dla długoterminowego przechowywania danych i zgodności z regulacjami.

Problem praktyczny: Scenariusz użycia

Scenariusz: Firma Acme Retail prowadzi platformę e-commerce w wielokontowej organizacji AWS Organization, z obciążeniami produkcyjnymi w regionach us-east-1 i europe-west-1. Przechowują strumienie kliknięć (clickstreams) i zdarzenia transakcyjne w S3 oraz utrzymują lokalną (on-premises) bazę danych OLTP, która musi zostać zmigrowana do AWS z minimalnym czasem przestoju.

Wyzwanie: Migracja bazy danych OLTP do wysoce dostępnego, skalowalnego w odczycie celu międzyregionalnego, przy jednoczesnym budowaniu zarządzanego analitycznego jeziora danych (data lake) na S3 z możliwością pozyskiwania i odpytywania danych w czasie rzeczywistym.

Zalecane podejście:

1. Użyj AWS DMS z SCT do konwersji schematu i skonfiguruj ciągłe przechwytywanie zmian (CDC) z lokalnej bazy danych do Amazon Aurora (Global Database) w regionie us-east-1, z repliką do odczytu (read replica) Aurora w europe-west-1.
2. Pozyskuj strumienie kliknięć i zdarzenia transakcyjne za pomocą Amazon Kinesis Data Streams i Firehose; buforuj i dostarczaj surowe zdarzenia do S3 w formacie Parquet, partycjonowane według daty i regionu.
3. Kataloguj dane w S3 za pomocą AWS Glue, egzekwuj kontrolę dostępu przez Lake Formation i wykonuj procesy ETL za pomocą zadań Glue (lub Glue Studio), aby tworzyć przygotowane zbiory danych; udostępniaj je analitykom za pośrednictwem Amazon Athena i Redshift Spectrum.
4. Dodaj ElastiCache (Redis) do buforowania (caching) danych o produktach i sesjach o wysokiej częstotliwości odczytu; zaimplementuj kompleksowy monitoring za pomocą CloudWatch, włącz Enhanced Monitoring w Aurora i weryfikuj procedury przełączania awaryjnego (failover) za pomocą scenariuszy (runbooks).

Uzasadnienie: Takie podejście minimalizuje przestoje dzięki wykorzystaniu CDC w DMS, zapewnia globalne odczyty o niskim opóźnieniu za pomocą Aurora Global Database, tworzy zarządzane jezioro danych na S3 dla zwinności analitycznej oraz zmniejsza obciążenie systemów OLTP dzięki buforowaniu i oddzielonemu pozyskiwaniu danych strumieniowych, zgodnie z najlepszymi praktykami w zakresie odporności i wydajności przedsiębiorstwa.

← Pamięć masowa i zarządzanie danymi · Wszystkie domeny · Migracja i modernizacja →

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

Przeglądaj Amazon →