Amazon Athena: bezserwerowy SQL w S3

Amazon Athena to bezserwisowa, interaktywna usługa zapytań, która umożliwia wykonywanie standardowych zapytań SQL bezpośrednio na danych przechowywanych w Amazon S3. Nie trzeba udostępniać serwerów ani zarządzać klastrami, a opłaty są naliczane wyłącznie za ilość danych przeskanowanych przez zapytanie (około 5 USD za 1 TB przeskanowanych danych). Athena korzysta wewnętrznie z Presto i natywnie integruje się z Glue Data Catalogue w zakresie metadanych tabel.

Przed uruchomieniem zapytań należy skonfigurować Athena Workgroup i określić ścieżkę S3, w której będą zapisywane wyniki zapytań. Grupy robocze umożliwiają rozdzielenie historii zapytań i śledzenia kosztów między zespołami, wymuszenie szyfrowania wyników oraz ustawienie limitów ilości danych skanowanych przez pojedyncze zapytanie, aby zapobiec niekontrolowanemu wzrostowi kosztów. Wynik każdego zapytania jest zapisywany jako plik CSV w skonfigurowanym zasobniku wyjściowym S3.

Wskaż bazę danych Glue Data Catalogue i uruchom zapytanie ANSI SQL. Athena obsługuje SELECT, JOIN, GROUP BY, funkcje okna oraz CTE. Można także użyć CREATE TABLE AS SELECT (CTAS), aby zapisać wyniki zapytania jako nową tabelę w formacie Parquet, skutecznie materializując wyniki pośrednie i przyspieszając kolejne zapytania.

Athena pobiera opłaty za każdy TB przeskanowanych danych. Najskuteczniejszym sposobem ograniczenia kosztów jest przycinanie partycji: zawsze należy uwzględniać kolumny partycji w klauzuli WHERE. Jeśli dane są podzielone na partycje według year/month/day, filtrowanie tych kolumn zapobiega skanowaniu pozostałych partycji przez Athena. Bez filtra partycji w tabeli o rozmiarze petabajtowym proste zapytanie może kosztować setki dolarów.

Przechowywanie danych w formacie Apache Parquet lub ORC zamiast CSV albo JSON znacznie ogranicza ilość danych skanowanych przez Athena podczas każdego zapytania. Zapytanie kolumnowe, które korzysta z 3 z 50 kolumn, skanuje na dysku dane tylko tych 3 kolumn. W połączeniu z wbudowaną kompresją (Snappy, Zstd) pliki Parquet są zazwyczaj 5–10 razy mniejsze niż odpowiadające im pliki CSV, co dodatkowo zwiększa oszczędności.

Athena Federated Query rozszerza możliwości Athena poza S3, umożliwiając wykonywanie zapytań dotyczących danych w RDS, DynamoDB, Redshift, Elasticsearch i niestandardowych źródłach za pomocą opartych na Lambda konektorów źródeł danych. Należy wdrożyć funkcję Lambda konektora z Serverless Application Repository, zarejestrować ją jako źródło danych Athena, a następnie wykonywać w jednym zapytaniu SQL JOIN operacje na tabelach S3 i aktywnych bazach danych — bez wcześniejszego przenoszenia danych.

Amazon QuickSight łączy się bezpośrednio z Athena jako źródłem danych, umożliwiając analitykom biznesowym tworzenie interaktywnych pulpitów na podstawie danych z S3 bez pośredniej bazy danych. QuickSight korzysta z SPICE (Super-fast, Parallel, In-memory Calculation Engine), aby buforować wyniki zapytań Athena i szybko renderować pulpity. Ten bezserwerowy stos BI (S3 + Glue + Athena + QuickSight) jest częstym wzorcem egzaminacyjnym dla opłacalnej analityki.

Oprócz partycjonowania i formatu kolumnowego można dodatkowo dostrajać zapytania Athena, stosując: dzielenie dużych plików (dla zapewnienia równoległości należy dążyć do rozmiaru 128 MB–1 GB na plik), grupowanie w zasobniki dla często łączonych kolumn, unikanie SELECT * oraz przybliżone funkcje agregujące, takie jak approx_distinct() i approx_percentile(), gdy dokładne wartości nie są wymagane. Techniki te ograniczają zarówno koszty, jak i opóźnienia.

Athena integruje się z IAM w zakresie kontroli dostępu: użytkownicy potrzebują uprawnień do uruchamiania zapytań Athena (athena:StartQueryExecution), dostępu do zasobnika wyjściowego S3 oraz odczytu bazowych danych S3. Aby zapewnić szczegółową kontrolę dostępu do kolumn i wierszy, należy połączyć Athena z Lake Formation. Można także ograniczyć grupę roboczą do określonych baz danych za pomocą kluczy warunkowych IAM odnoszących się do ARN grupy roboczej.

Wyniki zapytań Athena są przechowywane jako pliki CSV w S3 i buforowane przez 7 dni, dzięki czemu ponowne uruchomienie identycznego zapytania w tym okresie nie powoduje ponownego skanowania danych. W przypadku cyklicznych raportów należy użyć Athena Scheduled Queries, aby uruchamiać zapytanie zgodnie z harmonogramem cron i zapisywać wyniki w nowej lokalizacji S3 lub bezpośrednio w tabeli. Alternatywnie można uruchomić zapytanie Athena z poziomu maszyny stanów Step Functions albo reguły EventBridge.

Na egzaminie SAA-C03 należy wiedzieć, kiedy zalecić Athena, a kiedy Redshift. Wybierz Athena w przypadku doraźnych, sporadycznych zapytań dotyczących danych w S3, gdy nie chcesz zarządzać infrastrukturą. Wybierz Redshift, gdy potrzebujesz odpowiedzi w czasie krótszym niż sekunda dla złożonych złączeń, masz dedykowany zespół analityczny uruchamiający setki współbieżnych zapytań lub chcesz użyć Redshift Spectrum do rozszerzenia hurtowni danych o dane z S3. Kluczowym kryterium jest częstotliwość i złożoność zapytań.

Sprawdź swoją znajomość zagadnień AWS Solutions Architect (SAA-C03) omówionych w tej lekcji.

W tej lekcji nauczyli się Państwo, że: Athena pobiera opłaty za każdy TB przeskanowanych danych, dlatego przycinanie partycji i format Parquet są kluczowymi sposobami kontroli kosztów, Athena Federated Query rozszerza SQL na źródła danych inne niż S3 za pomocą konektorów Lambda, a Athena najlepiej sprawdza się w przypadku zapytań doraźnych, natomiast Redshift jest odpowiedniejszy dla analityki o wysokiej współbieżności. W następnej części omówimy Kinesis do strumieniowania i analityki danych w czasie rzeczywistym.