Amazon SAA-C03: Analityka, Data Lake, ML i specjalistyczne obciążenia — Przewodnik do nauki

By Laurynas Brazys · 18 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Część AWS SAA-C03 — Kompletny przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Amazon, albo rozwiąż testy na czas na ExamRoll.io.

Podstawy jeziora danych: Lake Formation i Glue Data Catalog

Centrum grawitacyjnym dla analityki w AWS jest AWS Glue Data Catalog — magazyn metadanych kompatybilny z Hive metastore, z którego korzystają Athena, Redshift Spectrum, EMR i Glue ETL. Każda definicja tabeli, partycji, typu kolumny i konfiguracja SerDe znajduje się tutaj, a każdy silnik analityczny odczytuje z niego dane. Jeśli dwie ścieżki pozyskiwania danych (np. crawler Glue i ręczne polecenie CREATE EXTERNAL TABLE) mają rozbieżne definicje schematu dla tego samego prefiksu S3, zapytania po cichu zwracają błędne wyniki lub kończą się niepowodzeniem. Prawidłowym wzorcem jest wyznaczenie jednego źródła prawdy dla każdej tabeli: albo crawler jest właścicielem schematu, albo zadanie ETL zapisuje dane za pomocą glueContext.write_dynamic_frame.from_catalog, ale nigdy obie metody jednocześnie bez strategii scalania. Kiedy wsadowe zadania ETL, konwersja do formatu Parquet przez Firehose i ręczne polecenia DDL zapisują dane do tej samej tabeli, dryf katalogu staje się cichym zabójcą. Wymuś jednego właściciela na tabelę, używaj Glue Schema Registry dla producentów danych strumieniowych i uruchamiaj crawlery w trybie LOG (a nie UPDATE_IN_DATABASE) na tabelach należących do zadań ETL, aby ujawniały dryf bez nadpisywania przygotowanych schematów.

AWS Lake Formation działa nad Data Catalog i zastępuje gruboziarnisty model uprawnień oparty na IAM/politykach bucketów S3 warstwą uprawnień w stylu bazodanowym. Zamiast nadawać s3:GetObject na prefiksie, wykonujesz GRANT SELECT ON customers.orders TO role/AnalystRole, a Lake Formation transparentnie dostarcza krótkoterminowe poświadczenia, gdy Athena lub Redshift Spectrum odwołuje się do bazowych obiektów. Jego prawdziwą wartością jest drobnoziarnista autoryzacja: filtrowanie na poziomie kolumn, bezpieczeństwo na poziomie wierszy poprzez filtry danych oraz kontrola dostępu oparta na tagach (LF-Tags), która skaluje się na tysiące tabel. Platforma handlowa z danymi osobowymi (PII) w tabeli customers może przyznać analitykom dostęp do customer_id, region, signup_date, blokując jednocześnie email i ssn — jest to egzekwowane w czasie wykonywania zapytania, bez konieczności mnożenia widoków.

Kanoniczna konfiguracja dla zarządzanego jeziora danych:

1. Register S3 locations with Lake Formation (removes IAMAllowedPrincipals default).
2. Create databases and let Glue crawlers populate tables.
3. Define LF-Tags (e.g., Classification=PII, Domain=Sales).
4. Grant tag-based permissions to IAM principals.
5. Point Athena/Redshift/QuickSight at the catalog — permissions flow through.

Szablony (blueprints) Lake Formation to gotowe szablony przepływów pracy, które łączą crawlery, zadania i wyzwalacze w celu pozyskiwania danych ze źródeł JDBC lub S3 do zarządzanego jeziora danych — redukując to, co wymagałoby dziesiątek ręcznie konfigurowanych zasobów Glue, do procesu opartego na kreatorze.

Częstym błędem jest próba egzekwowania ograniczeń na poziomie kolumn wyłącznie w QuickSight. QuickSight posiada mechanizmy bezpieczeństwa na poziomie wierszy i kolumn powiązane z zestawami danych, ale chroni to tylko warstwę QuickSight — każdy, kto ma bezpośredni dostęp do Atheny lub S3, omija te zabezpieczenia. Kontrola na poziomie kolumn musi być egzekwowana na warstwie danych (poprzez uprawnienia Lake Formation lub fizyczne rozdzielenie kolumn podczas ETL), a QuickSight dziedziczy tę konfigurację poprzez swoją rolę IAM.

Athena: Bezserwerowy SQL na S3

Athena to bezserwerowy silnik Presto/Trino działający w modelu płatności za zapytanie, który odczytuje dane bezpośrednio z Amazon S3. Nie ma klastra do provisioningu, nie jest wymagany krok ETL przed wykonaniem zapytania i nie ma kosztów, gdy usługa jest bezczynna — płacisz tylko za przeskanowane bajty (zazwyczaj 5 USD/TB). To sprawia, że Athena jest kanonicznym wyborem do analizy ad-hoc plików już znajdujących się w S3, niezależnie od tego, czy są to logi aplikacji w formacie JSON, eksporty CSV, czy tabele faktów w formacie Parquet. Athena potrzebuje schematu i układu partycji, które znajdują się w Glue Data Catalog.

Ponieważ Athena nalicza opłaty za przeskanowany terabajt, format przechowywania danych ma nieproporcjonalnie duży wpływ na koszt i opóźnienia. Dwie główne dźwignie optymalizacji to format i partycjonowanie:

• Formaty kolumnowe (Parquet, ORC) pozwalają Athenie na pomijanie kolumn i grup wierszy. Zapytanie takie jak SELECT sum(amount) FROM orders WHERE region='us-east-1' na danych w formacie Parquet odczytuje tylko dwie wskazane kolumny; na danych CSV odczytałoby każdy bajt każdego wiersza.
• Partycjonowanie według kolumn o wysokiej selektywności (np. dt=2024-03-11/) zmienia pełne skanowanie tabeli w ukierunkowany odczyt. W przypadku wieloterabajtowych logów (CloudFront, ALB, VPC Flow Logs) jest to różnica między zapytaniem za 0,15 USD a zapytaniem za 30 USD.

Konwersja surowych danych JSON lub CSV do partycjonowanego formatu Parquet z kompresją Snappy jest prawie zawsze pierwszą dźwignią kosztową, którą należy zastosować. W połączeniu z mechanizmem LIMIT pushdown, Athena radzi sobie z większością potrzeb analitycznych na S3 bez żadnej infrastruktury.

Efektywny kosztowo wzorzec dla tabeli „readings” przechowywanej jako partycjonowany Parquet:

CREATE EXTERNAL TABLE readings (
  station_id string,
  reading_ts timestamp,
  temp_c    double
)
PARTITIONED BY (dt string)
STORED AS PARQUET
LOCATION 's3://weather-lake/readings/'
TBLPROPERTIES ('has_encrypted_data'='true');

SELECT station_id, AVG(temp_c) OVER (
         PARTITION BY station_id
         ORDER BY reading_ts
         ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) AS moving_avg
FROM readings
WHERE dt = '2024-03-11';

Pominięcie crawlera to częsty błąd. Bez wpisu w katalogu musisz albo pisać ręczne polecenia DDL CREATE EXTERNAL TABLE (co jest kruche w miarę ewolucji schematów), albo używać prowizorycznych rozwiązań z odczytem schematu w locie, które skanują każdy plik. Co gorsza, bez MSCK REPAIR TABLE lub projekcji partycji, Athena skanuje cały prefiks przy każdym zapytaniu. Crawlery Glue wykrywają nowe partycje zgodnie z harmonogramem i aktualizują katalog w sposób atomowy.

Athena na zaszyfrowanych danych S3. Athena obsługuje SSE-S3, SSE-KMS i CSE-KMS, ale tylko wtedy, gdy podmiot wywołujący ma odpowiednie uprawnienia KMS, a grupa robocza lub klient jest skonfigurowany pod kątem używanego trybu szyfrowania. W przypadku CSE-KMS plik jest szyfrowany po stronie klienta przed wysłaniem; podmiot IAM wykonujący zapytanie potrzebuje uprawnień kms:Decrypt i kms:GenerateDataKey do klucza CMK, a polityka klucza musi to odwzajemniać. Częsty scenariusz błędu: załadowanie danych Parquet zaszyfrowanych za pomocą CSE-KMS, przyznanie roli Atheny tylko uprawnień do odczytu z S3, a następnie otrzymywanie nieprzejrzystych błędów AccessDenied lub HIVE_CANNOT_OPEN_SPLIT — obiekt jest czytelny, ale szyfrogram nie może zostać odszyfrowany. Innym częstym błędem jest zarejestrowanie tabeli z niewłaściwym trybem szyfrowania (SSE-KMS we właściwościach tabeli, podczas gdy obiekty zostały zapisane z CSE-KMS); Athena próbuje deszyfrowania po stronie serwera podczas operacji GetObject, a ładunek wraca jako surowy szyfrogram, który nie przechodzi weryfikacji liczb magicznych formatu Parquet.

Zapytania federacyjne Atheny pozwalają łączyć dane z S3 z operacyjnymi bazami danych (DynamoDB, RDS) bez przenoszenia danych. Rezerwuj Athenę do analizy ad-hoc zorientowanej na odczyt; używaj zadań Glue do zaplanowanego kształtowania przygotowanych stref danych.

Crawlery Glue, zadania ETL i zakładki zadań (Job Bookmarks)

Crawlery Glue skanują ścieżki S3, wnioskują schemat (w tym klucze partycji ze struktury katalogów, np. year=2024/month=01/) oraz rejestrują lub aktualizują tabele w katalogu. Są one odpowiedzią typu low-code na potrzebę „wrzucamy pliki do S3, udostępnij je do zapytań”. Zaplanuj uruchamianie crawlera co godzinę na docelowym buckecie, a Athena natychmiast zobaczy nowe partycje.

aws glue create-crawler \
  --name logs-crawler \
  --role AWSGlueServiceRole-Logs \
  --database-name analytics_db \
  --targets '{"S3Targets":[{"Path":"s3://acme-logs/app/"}]}' \
  --schedule "cron(0 * * * ? *)"

Zadania ETL w Glue (Spark, Python shell lub Ray) obsługują część transformacyjną. Glue jest bezserwerowe — płacisz za DPU-godzinę z minimum jednej minuty — a środowisko wykonawcze automatycznie skaluje workery. Dominującym wzorcem jest wejście w formacie CSV/JSON i wyjście w postaci partycjonowanego Parquet:

import sys
from awsglue.context import GlueContext
from pyspark.context import SparkContext

glueContext = GlueContext(SparkContext.getOrCreate())
df = glueContext.create_dynamic_frame.from_catalog(
    database="raw", table_name="reports_csv")
glueContext.write_dynamic_frame.from_options(
    frame=df,
    connection_type="s3",
    connection_options={"path": "s3://curated/reports/",
                        "partitionKeys": ["report_date"]},
    format="parquet",
    format_options={"compression": "snappy"})

Kluczową funkcją operacyjną jest zakładka zadania (job bookmark): Glue przechowuje stan dotyczący tego, które pliki lub partycje zostały już przetworzone, dzięki czemu kolejne uruchomienia odczytują tylko nowe dane. Zapomnienie o włączeniu zakładek oznacza, że każde uruchomienie ponownie przetwarza cały zbiór danych od początku, liniowo zwiększając koszty i czas wykonania, a często prowadząc do duplikacji danych wyjściowych. Zakładki są włączane dla każdego zadania i muszą być sparowane ze źródłami, które je obsługują (źródła S3 poprzez czytnik Glue DynamicFrame tak; dowolne odczyty Spark nie). Zakładki wymagają argumentu transformation_ctx przy każdym źródle oraz ujęcia operacji w job.init(...) / job.commit():

job = Job(glueContext)
job.init(args['JOB_NAME'], args)   # bookmark state loaded

datasource = glueContext.create_dynamic_frame.from_catalog(
    database="analytics_db",
    table_name="app_logs",
    transformation_ctx="datasource"   # required for bookmarking
)
# ... transforms ...
job.commit()                          # bookmark state persisted

W przypadku czystej konwersji formatu bez żadnej logiki, najprostszym rozwiązaniem jest często crawler Glue na surowych danych oraz zadanie Glue stworzone w edytorze wizualnym (lub receptura DataBrew) — nie jest wymagany żaden kod Spark. Niestandardowe klastry EMR lub konwertery Lambda dodają obciążenia operacyjnego, które eliminuje bezserwerowy model Glue.

Typowe codzienne zadanie, które przetwarza dane z S3 i ładuje je do Redshift Serverless:

# Glue 4.0 PySpark: S3 raw -> curated -> Redshift Serverless
df = glueContext.create_dynamic_frame.from_catalog(
        database="raw", table_name="orders").toDF()
df = df.filter("order_status <> 'CANCELLED'") \
       .withColumn("order_date", to_date("order_ts"))

glueContext.write_dynamic_frame.from_jdbc_conf(
    frame       = DynamicFrame.fromDF(df, glueContext, "out"),
    catalog_connection = "redshift-serverless-conn",
    connection_options = {"dbtable": "fact_orders", "database": "analytics"},
    redshift_tmp_dir   = "s3://stg/redshift-tmp/")

Konfiguracje bezpieczeństwa Glue i wielodostępowe ETL

Crawlery i zadania Glue wymagają takiej samej świadomości szyfrowania jak Athena. Konfiguracje bezpieczeństwa Glue to nazwane pakiety określające, w jaki sposób szyfrowane są cele S3, logi CloudWatch i zakładki zadań — w tym CSE-KMS z określonym kluczem CMK. Zadanie przypisane do konfiguracji bezpieczeństwa transparentnie deszyfruje dane wejściowe CSE-KMS i szyfruje dane wyjściowe w ten sam sposób, pod warunkiem, że rola IAM zadania ma uprawnienia KMS do używanych kluczy.

W przypadku wielodostępowego ETL — platformy SaaS przetwarzającej dane każdego klienta za pomocą jego własnego klucza CMK — prawidłowym wzorcem jest jedna konfiguracja bezpieczeństwa na klienta (lub parametr zadania wybierający CMK) oraz rola IAM z zakresem uprawnień do tego klucza CMK. Przetwarzanie danych wszystkich klientów w jednym zadaniu z jednym współdzielonym kluczem niweczy gwarancję izolacji, którą ma zapewniać CSE-KMS.

Powiązana dyscyplina: produkcyjne tabele analityczne nie powinny być bezpośrednim celem eksploracyjnych zadań Glue ani notebooków. Wyeksportuj migawkę do prefiksu S3 „analytics” i skieruj Athenę lub Sparka na tę kopię. Uruchamianie eksperymentalnych transformacji na tabeli produkcyjnej grozi nadpisaniem na poziomie partycji, uszkodzeniem zakładek i rywalizacją o blokady, a także zaciera granicę audytu między danymi operacyjnymi a pochodnymi analitycznymi.

AWS Glue DataBrew

DataBrew to niskokodowy (low-code) odpowiednik Glue dla użytkowników, którzy nie mogą lub nie powinni pisać kodu w Spark. Oferuje interfejs w stylu arkusza kalkulacyjnego z ponad 250 gotowymi transformacjami (imputacja, maskowanie danych PII, grupowanie wartości odstających, parsowanie dat). Jego wyróżnikami są współdzielone receptury (shared recipes) — wersjonowane artefakty JSON, które można publikować i ponownie stosować w różnych projektach — oraz wizualizacja pochodzenia danych (data lineage), która śledzi kolumny od źródłowych zbiorów danych, przez receptury i zadania, aż do lokalizacji wyjściowych. Wybierz DataBrew, gdy analitycy są odpowiedzialni za logikę transformacji; wybierz Glue Studio/skrypty, gdy odpowiadają za nią inżynierowie, a potok wymaga niestandardowego kodu, przetwarzania strumieniowego lub złożonych złączeń.

Amazon EMR: Przetwarzanie rozproszone i role czasu wykonania (Runtime Roles)

Amazon EMR to zarządzana platforma klastrowa obsługująca Spark, Hadoop, Hive, Presto, HBase i Flink. Jej idealne zastosowanie to duże, równoległe zadania wsadowe lub interaktywne, które odczytują petabajtowe zbiory danych z S3 i łączą je z innym systemem źródłowym (często Redshift) w celu wzbogacenia. EMR może uruchamiać klastry efemeryczne (uruchom, wykonaj, zakończ) lub długo działające, a także może mieszać instancje On-Demand, Spot i Reserved za pomocą flot instancji (instance fleets).

Kanoniczny wzorzec: zadanie Spark odczytuje dane Parquet z S3, pobiera tabele wymiarów z Redshift poprzez UNLOAD-to-S3, łączy je na wielu executorach i zapisuje wzbogacone dane z powrotem do S3:

# Spark on EMR: enrich S3 events with Redshift dimensions
df_events = spark.read.parquet("s3://raw/events/dt=2024-11-01/")
df_dims = (spark.read
    .format("io.github.spark_redshift_community.spark.redshift")
    .option("url", "jdbc:redshift://cluster:5439/analytics")
    .option("dbtable", "public.customer_dim")
    .option("tempdir", "s3://staging/redshift-unload/")
    .load())

enriched = df_events.join(df_dims, "customer_id", "left")
enriched.write.mode("overwrite").partitionBy("region").parquet("s3://curated/events/")

EMR wygrywa w tym przypadku, ponieważ Spark rozprasza operację złączenia na dziesiątki węzłów, a przesyłanie danych przez S3 pozwala uniknąć jednowątkowego wąskiego gardła JDBC. Pułapką jest odruchowe sięganie po EMR za każdym razem, gdy dane w S3 wymagają zapytania. W przypadku zapytań SQL ad-hoc na dziesiątkach lub setkach gigabajtów, provisionowanie i strojenie klastra Spark to czysty narzut operacyjny — dobór wielkości klastra, konfiguracja YARN, autoskalowanie, rotacja logów, patchowanie. EMR jest opłacalny tylko wtedy, gdy uzasadnia to wolumen danych, niestandardowy kod lub elastyczność silnika wykonawczego.

Role czasu wykonania EMR (Runtime roles). Historycznie wszystkie kroki na klastrze dziedziczyły profil instancji EC2 — jedną rolę przypisaną do bazowych węzłów — co oznaczało, że każdy zespół współdzielący klaster miał sumę wszystkich uprawnień potrzebnych każdemu z zespołów. Role czasu wykonania rozwiązują ten problem: gdy użytkownik przesyła krok, przekazuje --execution-role-arn, a EMR przyjmuje tę rolę na czas trwania kroku. Zespół A może być ograniczony do s3://team-a/*, a zespół B do s3://team-b/*. Profil instancji staje się minimalną rolą startową, która pobiera tylko artefakty klastra.

Role czasu wykonania są również mechanizmem blokowania dostępu do IMDS. Gdy funkcja jest włączona (EMR 6.7+ ze Spark/Hive na YARN), kod użytkownika nie może uzyskać dostępu do usługi metadanych instancji — w tym IMDSv2 — ponieważ platforma przechwytuje te wywołania. Zamyka to ścieżkę eskalacji uprawnień, w której zadanie mogłoby w przeciwnym razie wywołać http://169.254.169.254/latest/api/token i przyjąć potężny profil instancji EC2.

aws emr create-cluster \
  --release-label emr-6.15.0 \
  --applications Name=Spark Name=Hive \
  --security-configuration team-isolation-sc \
  --service-role EMR_DefaultRole \
  --ec2-attributes InstanceProfile=EMR_EC2_MinimalRole,...

aws emr add-steps --cluster-id j-XXXX \
  --steps Type=Spark,Name="TeamA-ETL",\
ActionOnFailure=CONTINUE,\
Jar=command-runner.jar,\
Args=[spark-submit,s3://team-a/jobs/etl.py] \
  --execution-role-arn arn:aws:iam::111122223333:role/TeamA-EMRRuntime

To właśnie konfiguracja bezpieczeństwa umożliwia egzekwowanie ról czasu wykonania i blokowanie IMDS. Bez niej założenie, że zadania EMR „automatycznie używają ról o najmniejszych uprawnieniach” jest błędne — domyślnie współdzielą one profil instancji, a IMDS jest osiągalny z poziomu kodu użytkownika.

Amazon Redshift i Redshift ML

Redshift to kolumnowa, masowo równoległa (MPP) hurtownia danych przeznaczona do ciągłych obciążeń analitycznych, które wymagają pulpitów nawigacyjnych (dashboardów) z opóźnieniami poniżej sekundy, złożonych operacji JOIN na miliardach wierszy i stałych opóźnień przy wielu jednoczesnych użytkownikach BI. Węzły RA3 oddzielają moc obliczeniową od zarządzanego magazynu; Redshift Serverless rozlicza w RPU-sekundach w odniesieniu do skonfigurowanej pojemności bazowej, skaluje się pod obciążeniem i pauzuje w stanie bezczynności, eliminując tradycyjny problem z doborem wielkości klastra.

Redshift uczestniczy w potokach analitycznych w dwóch trybach wzbogacania:

• Jako źródło: Spark na EMR pobiera wymiary za pomocą UNLOAD-to-S3, lub Glue odczytuje dane przez Redshift Data API.
• Jako cel: Firehose lub zadanie Glue wczytuje wzbogacone dane za pomocą polecenia COPY.

Redshift Spectrum rozszerza te możliwości, pozwalając na odpytywanie S3 bezpośrednio z Redshift SQL poprzez Glue Data Catalog — ten sam katalog, którego używa Athena — co umożliwia realizację wzorca lake-house. Jest to idealne rozwiązanie, gdy masz już klaster Redshift i chcesz łączyć fakty z hurtowni z zimnymi danymi historycznymi w S3 bez przenoszenia danych.

Ładowanie wsadowe wykorzystuje polecenie COPY z S3, zrównoleglone na wszystkich węzłach obliczeniowych; pliki powinny być podzielone na w przybliżeniu równe części (wielokrotność liczby plasterków - slice), aby zapewnić równoległość:

COPY events FROM 's3://acme-lake/events/dt=2024-05-12/'
IAM_ROLE 'arn:aws:iam::111:role/RedshiftLoader'
FORMAT AS PARQUET;

Ingestia strumieniowa zazwyczaj przepływa przez Firehose (buforowane polecenie COPY), aby zapewnić bezobsługowe dostarczanie.

Redshift ML pozwala użytkownikom SQL tworzyć, trenować i wywoływać modele za pomocą polecenia CREATE MODEL:

CREATE MODEL churn_predictor
FROM (SELECT tenure, plan, monthly_spend, churned FROM customers)
TARGET churned
FUNCTION predict_churn
IAM_ROLE default
SETTINGS (S3_BUCKET 'redshift-ml-artifacts');

SELECT customer_id, predict_churn(tenure, plan, monthly_spend)
FROM customers_current;

W tle Redshift eksportuje zbiór treningowy do S3, wywołuje SageMaker Autopilot (lub określony algorytm, jak XGBoost) i importuje skompilowany model do wnioskowania wewnątrz bazy danych. Jest to potężne narzędzie, gdy analitycy na co dzień pracują w SQL, ale nie zastępuje ono pełnej platformy ML: przenoszenie danych do S3 i moc obliczeniowa do trenowania w SageMaker są rozliczane osobno, duże zbiory treningowe mogą generować znaczne opłaty za ruch wychodzący i czas działania Autopilota, i nie ma wbudowanego przepływu pracy dla magazynów cech (feature stores), śledzenia eksperymentów czy wdrożeń A/B. Należy traktować Redshift ML jako zdemokratyzowane wnioskowanie na danych w Redshift, a nie jako narzędzie do trenowania ogólnego przeznaczenia.

Wybór między Athena a Redshift

Ingestia strumieniowa: Kinesis Data Streams, Firehose i MSK

Trzy usługi strumieniowe AWS rozwiązują częściowo pokrywające się problemy, ale z istotnie różnymi gwarancjami:

Kinesis Data Streams używa fragmentów (shards) (lub trybu on-demand); rekordy z tym samym kluczem partycji trafiają do tego samego fragmentu i są konsumowane w kolejności. Konsumenci używają klasycznego GetRecords lub Enhanced Fan-Out (dedykowane 2 MB/s na konsumenta). Funkcja Lambda podłączona jako źródło zdarzeń jest wywoływana z wsadami danych dla każdego fragmentu, z zachowaniem kolejności. Jest to właściwy wybór, gdy logika w dalszych etapach jest nietrywialna, gdy wielu niezależnych konsumentów musi mieć możliwość powtórnego odczytu historii lub gdy wolumeny danych z clickstream są ogromne — na przykład witryna generująca 30 TB danych dziennie przesyłałaby je przez KDS do Firehose, skąd trafiałyby do S3 w celu analizy przez Athena/Spectrum.

Kinesis Data Firehose to zarządzane dostarczanie typu „wyślij i zapomnij”: buforuje dane według rozmiaru lub czasu (np. 5 MB / 300 sekund), opcjonalnie wywołuje funkcję Lambda w celu transformacji, opcjonalnie konwertuje format JSON na Parquet/ORC, używając schematu z tabeli Glue, i zapisuje je do S3, Redshift (przez S3 + COPY), OpenSearch lub Splunk. Włączenie konwersji do formatu Parquet w Firehose to prosty sposób na zapisywanie danych strumieniowych w formacie zoptymalizowanym pod kątem zapytań, bez potrzeby tworzenia dodatkowego zadania Glue:

Firehose delivery stream → 
  Record transformation: Lambda (optional, for enrichment) →
  Format conversion: enabled, schema from Glue table "events.raw" →
  Destination: s3://lake/events/ partitioned by !{timestamp:yyyy/MM/dd}

Firehose nie gwarantuje zachowania kolejności end-to-end, nie obsługuje wielu konsumentów z możliwością powtórnego odczytu, a jego miejsca docelowe to stała lista ujść (sinks). Wybranie Firehose, gdy wymaganiem jest „przetwarzanie każdego rekordu w kolejności” lub „wielu niezależnych konsumentów”, jest błędem w obu przypadkach. Podobnie, oczekiwanie, że sam Firehose wykona złożone transformacje, jest pułapką — jego jedyny punkt zaczepienia dla transformacji to funkcja Lambda wywoływana dla każdej zbuforowanej partii danych. Wszystko, co obejmuje zewnętrzne wzbogacanie, agregację wielu rekordów lub warunkowe kierowanie, musi być zaimplementowane w tej funkcji Lambda lub przeniesione do wcześniejszego etapu, np. do Managed Service for Apache Flink.

Amazon MSK to zarządzana usługa Apache Kafka. Wybierz tę usługę, gdy masz już producentów/konsumentów Kafka, potrzebujesz specyficznych funkcji Kafka (tematy skompaktowane, transakcje, Kafka Streams, Connect) lub wymagasz przepustowości wykraczającej poza to, co Kinesis oparty na fragmentach (shards) jest w stanie komfortowo zapewnić.

Używanie SQS lub EventBridge jako ścieżki do ingestii danych analitycznych jest błędem: SQS nie zapewnia kolejności w ramach strumienia i nie ma możliwości powtórnego odczytu; EventBridge jest zoptymalizowany do routingu zdarzeń, a nie do ciągłej ingestii danych z prędkością wielu MB/s.

Wyszukiwanie w czasie rzeczywistym: KDS + Firehose + OpenSearch + QuickSight

Kanononicznym zamiennikiem dla lokalnego stosu Elasticsearch+Logstash jest:

Firehose buforuje rekordy strumienia i dostarcza je bezpośrednio do domeny OpenSearch, obsługując ponawianie prób, kopie zapasowe w S3 i opcjonalną transformację Lambda. OpenSearch Dashboards jest wbudowany i darmowy w ramach domeny i jest odpowiedni dla operatorów obserwujących strumienie w czasie rzeczywistym. QuickSight uzupełnia to rozwiązanie o analitykę biznesową — wysyła zapytania bezpośrednio do Athena, Redshift, RDS i OpenSearch, a jego kolumnowy silnik w pamięci SPICE buforuje przetworzone zbiory danych, zapewniając wydajność dashboardów na poziomie poniżej sekundy.

Typowy podział wygląda następująco: OpenSearch Dashboards dla operatorów; QuickSight dla kadry zarządzającej, która korzysta z zagregowanych, przygotowanych zbiorów danych pochodzących z data lake na Athena/Glue. Obie usługi muszą mieć nadane uprawnienia IAM do odczytu oraz, w stosownych przypadkach, uprawnienie KMS Decrypt do kluczy CMK chroniących bazową pamięć masową — w przeciwnym razie warstwa wizualizacji będzie renderować puste panele z błędami uprawnień ukrytymi w logach zapytań.

Kontrola dostępu w QuickSight

QuickSight tworzy zbiory danych (logiczne zapytania plus obliczone pola i zabezpieczenia na poziomie wiersza), następnie analizy na podstawie zbiorów danych, a na końcu publikuje dashboardy (widoki tylko do odczytu, które można udostępniać). Kontrola dostępu jest warstwowa i musi być stosowana na odpowiedniej warstwie. Pułapką jest przyznawanie szerokiego dostępu na poziomie dashboardu — udostępnianie go grupie obejmującej całą organizację, podczas gdy tylko podzbiór użytkowników powinien widzieć dane źródłowe.

Zasada najmniejszych uprawnień w QuickSight oznacza:

• Udostępnianie zbioru danych tylko tym użytkownikom/grupom, które go potrzebują.
• Stosowanie zabezpieczeń na poziomie wiersza za pomocą zbioru danych uprawnień, który filtruje wiersze według nazwy użytkownika lub grupy.
• Stosowanie zabezpieczeń na poziomie kolumny w celu ukrycia wrażliwych pól.
• Udostępnianie dashboardów konkretnym użytkownikom, grupom lub (w przypadku analityki osadzonej) przestrzeniom nazw.

Upublicznienie dashboardu lub udostępnienie go w ramach całego konta omija intencję kontroli na poziomie zbioru danych, ponieważ przeglądający dashboard dziedziczą uprawnienia do odczytu wizualizowanych danych, niezależnie od uprawnień do źródła. Pamiętaj, że zabezpieczenia na poziomie kolumny w QuickSight chronią tylko interfejs QuickSight; każdy, kto ma bezpośredni dostęp do Athena lub S3, może je ominąć, więc wrażliwe kontrole powinny być implementowane w Lake Formation lub ETL, a nie tylko w QuickSight.

QuickSight role — Admin, Author, Reader — kontrolują, co użytkownik może zrobić, w odróżnieniu od uprawnień do udostępniania, które kontrolują, co może zobaczyć. Rola Reader wiąże się z niższym kosztem za sesję niż licencja Author, więc populacje przeglądających powinny domyślnie mieć rolę Reader, a dostęp powinien być przyznawany poprzez członkostwo w grupach, a nie indywidualnie.

Amazon Neptune dla obciążeń grafowych

Neptune to zarządzana grafowa baza danych obsługująca model grafu właściwości (Gremlin, openCypher) oraz RDF (SPARQL). Jest specjalnie zaprojektowana do obsługi silnie połączonych danych — relacji społecznych, siatek oszustw, grafów wiedzy, silników rekomendacji — gdzie rekurencyjne złączenia w relacyjnej bazie danych stają się nieefektywne. Platforma społecznościowa z użytkownikami, obserwacjami, polubieniami i postami naturalnie mapuje się na wierzchołki i krawędzie, a Neptune odpowiada na zapytania o przechodzenie wieloskokowe („znajomi znajomych, którzy polubili X”) w milisekundach.

Neptune Streams udostępnia uporządkowany, chronologiczny dziennik każdej mutacji w grafie. Funkcja Lambda lub aplikacja odpytująca strumień może reagować na zmiany — ponownie obliczać rekomendacje, aktualizować indeks wyszukiwania, wyzwalać alerty o oszustwach — bez potrzeby tworzenia dedykowanego potoku change-data-capture. Odtworzenie tego na Aurora lub DynamoDB wymagałoby przechodzenia grafu na poziomie aplikacji oraz oddzielnej implementacji CDC. Gdy w opisie problemu pojawiają się zarówno „analiza relacji”, jak i „monitorowanie zmian”, Neptune ze Streams jest idealnym rozwiązaniem.

SageMaker: Kompleksowe, niestandardowe ML

SageMaker zapewnia obsługę pełnego cyklu życia: notatniki Studio, zarządzane zadania treningowe (z obsługą instancji spot), Model Registry, punkty końcowe działające w czasie rzeczywistym i bezserwerowe, transformację wsadową oraz Pipelines dla MLOps. Typowy przepływ polega na przesłaniu danych treningowych do S3, uruchomieniu zadania treningowego z określeniem wbudowanego algorytmu lub niestandardowego kontenera, a SageMaker przydziela efemeryczne instancje, przesyła logi do CloudWatch i zapisuje artefakt modelu z powrotem do S3. Wdrożenie to pojedyncze wywołanie API:

from sagemaker.estimator import Estimator
est = Estimator(image_uri=xgb_image, role=role,
                instance_count=2, instance_type="ml.m5.xlarge",
                output_path="s3://models/xgb/")
est.fit({"train": "s3://data/train/", "validation": "s3://data/val/"})
predictor = est.deploy(initial_instance_count=1, instance_type="ml.m5.large")

Nie trzeba zarządzać Kubernetesem, sterownikami GPU ani serwerem modeli. Dla zespołów, których wymaganiem jest „wytrenowanie i udostępnienie modelu”, SageMaker jest prawie zawsze odpowiedzią o najmniejszym narzucie w porównaniu do samodzielnego wdrażania wnioskowania na ECS/EC2.

SageMaker Savings Plans to zobowiązanie do wydatków na poziomie określonej kwoty dolarów na godzinę na kwalifikujące się komponenty (Studio, zadania treningowe, przetwarzanie, wnioskowanie w czasie rzeczywistym) na okres 1 roku lub 3 lat, co daje do 64% zniżki w stosunku do cen na żądanie. Są one elastyczne pod względem rodziny instancji, rozmiaru, regionu i komponentu — ale nie obejmują Ground Truth, pamięci masowej ani transferu danych. Używaj Savings Plans, gdy bazowe wykorzystanie ML jest przewidywalne; szczytowe obciążenia treningowe pozostaw na instancjach spot, aby zwielokrotnić oszczędności.

Zarządzane usługi AI a niestandardowe ML

Amazon Rekognition (obrazy/wideo: wykrywanie obiektów i scen, analiza twarzy, moderacja), Textract (OCR oraz ekstrakcja formularzy i tabel) i Comprehend (NLP: rozpoznawanie encji, analiza sentymentu, wykrywanie danych PII, klasyfikacja niestandardowa) udostępniają wstępnie wytrenowane modele za pośrednictwem prostych API. Funkcja DetectEntities w Comprehend zwraca typowane encje, w tym kategorię COMMERCIAL_ITEM — idealną do wyciągania nazw składników z tekstu przepisu i zasilania zapytań do DynamoDB, bez danych treningowych, bez hostingu i z ceną za żądanie:

aws comprehend detect-entities \
    --language-code en \
    --text "Combine 2 cups flour, 1 tsp salt, and 3 eggs..."

Częstym błędem jest nadmierna inżynieria (over-engineering) — uruchamianie zadań treningowych w SageMaker, etykietowanie danych za pomocą Ground Truth i hostowanie endpointów, gdy usługa zarządzana już spełnia wymagania za ułamek kosztów operacyjnych. Niestandardowe ML jest uzasadnione tylko wtedy, gdy dokładność na danych specyficznych dla domeny jest znacznie wyższa, gdy potrzebne typy encji nie pasują do schematu usługi zarządzanej (Comprehend Custom Classification/Entity Recognition jest wciąż tańsze niż surowy SageMaker) lub gdy ograniczenia dotyczące opóźnień i rezydencji danych wymagają prywatnego modelu.

Pamięć masowa i sieć dla HPC: FSx for Lustre i EFA

Ściśle powiązane obciążenia HPC — CFD, dynamika molekularna, obrazowanie sejsmiczne, trenowanie na dużą skalę — mają dwa niepodważalne wymagania: komunikację międzywęzłową o ekstremalnie niskim opóźnieniu oraz współdzieloną pamięć masową o wysokiej przepustowości.

Elastic Fabric Adapter (EFA) to interfejs sieciowy dostępny w określonych rodzinach instancji EC2 (hpc7a, hpc6id, c6in, p4d/p5 i innych). Omija on stos TCP/IP jądra systemu operacyjnego za pomocą techniki OS-bypass Libfabric, pozwalając MPI i NCCL osiągać mikrosekundowe opóźnienia na setkach węzłów. EFA wymaga, aby instancje znajdowały się w tej samej Strefie Dostępności (Availability Zone) oraz, dla maksymalnej przepustowości, w grupie rozmieszczenia typu klaster (cluster placement group).

FSx for Lustre to zarządzany, równoległy system plików zapewniający przepustowość setek GB/s i opóźnienia poniżej milisekundy. Integruje się natywnie z S3: system plików FSx można połączyć z bucketem, dzięki czemu obiekty pojawiają się jako pliki POSIX, a wyniki zapisane w Lustre można wyeksportować z powrotem do S3. Wdrożenia typu Persistent SSD nadają się do długotrwałej przestrzeni roboczej (scratch); typ Scratch2 jest tańszy dla efemerycznych danych zadań.

Niewłaściwym wzorcem jest używanie EFS do zastosowań HPC. EFS jest oparty na NFS i zoptymalizowany dla wielu małych klientów wykonujących operacje I/O ogólnego przeznaczenia; nie jest w stanie utrzymać zagregowanej przepustowości ani liczby IOPS na metadanych, których potrzebuje 500-węzłowe zadanie MPI, a jego architektura multi-AZ wprowadza dodatkowe opóźnienia. Używanie standardowego ENA zamiast EFA ogranicza MPI do opóźnień TCP, kilkukrotnie wydłużając czas wykonania zadań intensywnie korzystających z operacji allreduce. Prawidłowe połączenie to instancje z włączonym EFA w grupie rozmieszczenia typu klaster, montujące system plików FSx for Lustre, z S3 jako trwałą pamięcią masową (cold storage) połączoną z systemem plików.

← Bazy danych i buforowanie · Wszystkie domeny · Integracja aplikacji →

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

Przeglądaj Amazon →