Amazon Athena: SQL serverless su S3

Amazon Athena è un motore di query serverless (basato su Trino/Presto per SQL, con supporto anche ad Apache Spark per l’analisi programmatica) che interroga dati direttamente su Amazon S3 senza provisioning di cluster. Il modello di costo è pay-per-query sui dati scansionati (byte letti), quindi la spesa dipende da quanti dati leggi, non dal tempo macchina. Athena usa AWS Glue Data Catalog come metastore per schemi, tabelle e partizioni. È la scelta naturale per query ad-hoc, esplorazione di un data lake, analisi di log e interrogazioni occasionali dove non vuoi gestire infrastruttura. Supporta anche federated queries verso sorgenti esterne (Amazon RDS, DynamoDB) tramite connettori Lambda, e le operazioni CTAS / INSERT INTO scrivono nuovi file su S3. Non è pensato per carichi OLTP né per update riga-per-riga.

Redshift Spectrum ed Amazon EMR

Redshift Spectrum estende Amazon Redshift consentendo di interrogare dati su S3 tramite external tables definite nel Glue Data Catalog, senza caricarli nel cluster. Lo scegli quando hai già un data warehouse Redshift e vuoi fare join tra tabelle “calde” locali e dati “freddi” storici su S3, mantenendo un unico motore SQL e la relativa governance. Come Athena, il costo Spectrum si basa sui byte scansionati su S3.

Amazon EMR è la piattaforma gestita per framework big data open-source: Apache Spark, Hive, Presto, HBase, Flink. Scegli EMR con Spark quando serve trasformazione complessa, machine learning o codice custom (PySpark/Scala) e pipeline ETL su larga scala che eccedono la query SQL pura. È disponibile su cluster EC2, EMR on EKS ed EMR Serverless (senza gestire cluster). Hive su EMR resta utile per ETL batch SQL-like. La discriminante d’esame: Athena/Spectrum = query SQL serverless; EMR/Spark = elaborazione programmatica e trasformazioni pesanti.

Amazon QuickSight

Amazon QuickSight è il servizio BI serverless per dashboard e visualizzazioni. SPICE è il suo motore in-memory che memorizza i dati per query rapide e per ridurre il carico sulle sorgenti; in alternativa puoi usare direct query verso Athena, Redshift o RDS. Usa SPICE per performance e per disaccoppiare le dashboard da sorgenti lente; usa direct query quando serve il dato in tempo reale. QuickSight offre ML Insights, anomaly detection e Q (domande in linguaggio naturale), e si connette naturalmente ad Athena e Redshift per chiudere la pipeline analytics.

Ottimizzare le query: pruning, projection, formati colonnari

Su Athena e Spectrum il fattore dominante di costo e performance è quanti dati vengono scansionati. Tre leve principali:

  • Formati colonnari: Parquet e ORC (compressi, con statistiche per colonna) riducono drasticamente i byte letti rispetto a CSV/JSON, perché leggono solo le colonne richieste e sfruttano il predicate pushdown.
  • Partition pruning: organizzando i dati in partizioni (es. per anno/mese/giorno) il motore scansiona solo le partizioni che soddisfano il filtro WHERE, saltando il resto. Le partizioni vanno registrate nel Glue Catalog (via crawler o MSCK REPAIR TABLE).
  • Partition projection: in Athena, invece di catalogare ogni partizione, la definisci tramite regole/pattern nelle table properties. Athena calcola le partizioni al volo senza interrogare il metastore, eliminando il collo di bottiglia su tabelle con moltissime partizioni ed evitando crawler/MSCK. Ideale per pattern temporali prevedibili.

Ulteriori ottimizzazioni: compattare molti file piccoli in file più grandi (riduce l’overhead), bucketing e selezionare solo le colonne necessarie.

Trappole tipiche d’esame

  • Query SQL ad-hoc su un data lake S3 senza gestire infrastruttura → soluzione: Amazon Athena. Serverless, paghi per byte scansionati; non serve un cluster EMR né caricare i dati in Redshift.
  • Trasformazione ETL complessa in PySpark/Scala o ML su grandi volumi → soluzione: Amazon EMR (Spark) o EMR Serverless. Athena non esegue codice Spark custom arbitrario per pipeline pesanti; EMR sì.
  • Ridurre costo/tempo di una query su S3 → soluzione: convertire in Parquet/ORC e partizionare. Il costo dipende dai byte scansionati: formati colonnari più partition pruning tagliano la scansione.
  • Tabella con moltissime partizioni e MSCK REPAIR/crawler lentissimi → soluzione: partition projection in Athena. Le partizioni sono derivate da regole, non lette dal Glue Catalog.
  • Join tra dati storici su S3 e tabelle nel data warehouse Redshift → soluzione: Redshift Spectrum. External table su S3 interrogata dallo stesso cluster, senza ingestione preventiva.
  • Dashboard BI veloci disaccoppiate da sorgenti lente → soluzione: QuickSight con SPICE. Il motore in-memory serve i grafici; usa direct query solo se serve il tempo reale.