import pandas as pd

Athena and Presto/Trino: query engines on S3

Un lake su S3 diventa davvero utile solo quando qualcuno può interrogarlo con tempi, costi e permessi prevedibili. I query engine schema-on-read come Athena, Presto e Trino trasformano oggetti grezzi in tabelle analizzabili senza ETL preventivo. Il tema è tecnico, e il punto è capire quale motore scegliere e come scrivere query che non facciano esplodere la fattura.

Scegliere un motore, non un tool

La scelta non è “quale strumento è migliore” ma quale motore regge i tuoi vincoli. La differenza conta quando cambiano la concorrenza richiesta, il costo per query, il catalogo dei metadati, la latenza accettabile e il modello di governance. Athena è serverless e azzera la gestione, Trino self-managed dà controllo e federazione su più sorgenti, Redshift Spectrum si innesta su cluster esistenti. La domanda giusta è quale di questi profili corrisponde al tuo carico.

Una griglia per impostare la decisione

Conviene seguire una sequenza che lega ogni passaggio a un costo concreto.

Step	Question to ask	Expected output
Decision	Quale motore stiamo scegliendo e per quale carico?	Scelta esplicita
Signal	Quanti GB scansiona la query e quanto costa?	Metrica osservabile
Baseline	Qual è il costo o la latenza di riferimento?	Credible comparison
Vincolo	Quanta concorrenza e quale catalogo servono?	Assunzione dichiarata
Action	Quale motore e quale ottimizzazione adottiamo?	Raccomandazione verificabile

Ogni riga deve rendere chiaro il costo di una scelta sbagliata, per esempio adottare un cluster da gestire quando bastava il serverless.

Rendere misurabile la scelta

L’unità su cui ragioni è la singola query con il suo piano e i GB che scansiona. Il segnale che osservi sono costo per query e latenza. La baseline è il comportamento attuale o un benchmark comparabile. La soglia decisionale è il livello di costo o concorrenza oltre il quale cambi motore, fissato prima di misurare. Il rischio residuo è scegliere in base alla familiarità invece che ai numeri.

Element	Operational Definition	Controllo minimo
Unit of analysis	La query e i suoi input	Piano, GB scansionati
Variabile osservata	Costo per query e latenza	Misura ripetibile
Baseline	Costo o latenza attuale	Confronto diretto
Soglia decisionale	Punto in cui cambi motore	Criterio scritto prima
Rischio residuo	Scegliere per abitudine	Revisione sui numeri

Perché Athena è potente e insieme insidioso

La forza di Athena è la semplicità: scrivi SQL, punti a S3 e ottieni risultati, senza infrastruttura da gestire. Per un analyst è il punto di ingresso ideale. L’insidia è il costo: se non ottimizzi, una singola query può scansionare terabyte e costare decine di dollari. Ogni esecuzione mostra i GB scansionati, ed è bene controllarli sempre prima di lanciare query su tabelle grandi.

Essential optimizations

Le leve principali per tenere bassa la scansione sono cinque. La prima e più impattante è il partition pruning: una clausola come WHERE year=2024 AND month=01 evita di leggere tutto il resto. La seconda è il formato colonnare Parquet, che permette ad Athena di leggere solo le colonne presenti nel SELECT. La terza è la compressione, con Snappy o Zstd su Parquet, che riduce i dati da leggere da S3. La quarta è selezionare solo le colonne necessarie: un SELECT * su una tabella Parquet con 200 colonne le legge tutte e 200, perché anche nel formato colonnare più colonne significano più I/O. La quinta riguarda ORDER BY with LIMIT: quando possibile sposta il LIMIT in una subquery interna prima dell’ordinamento.

-- Athena query ottimizzata
SELECT customer_id, SUM(amount) AS total
FROM orders
WHERE year=2024 AND month BETWEEN 1 AND 6  -- partition pruning
  AND status = 'completed'
GROUP BY customer_id
ORDER BY total DESC
LIMIT 10;

Athena, Redshift Spectrum e Trino a confronto

I tre motori coprono profili diversi di gestione, costo e concorrenza.

	Athena	Redshift Spectrum	Trino self-managed
Management	AWS Serverless	Part of Redshift cluster	Self-managed cluster
Cost	$5/TB scanned	Like Redshift	Infrastructure + S3 scanning
Ideal for	Ad-hoc queries	Existing Redshift Users	Large volumes, multi-cloud
Concurrency	High (AWS managed)	Average	Depends on the cluster

Un caso concreto

Un team usa Athena per le analisi occasionali e Trino per i workload interattivi che attingono a più sorgenti. Il caso mostra come la scelta del motore dipenda da catalogo, concorrenza richiesta, federazione tra fonti, costo per query e compatibilità con i table format. Non esiste il motore “migliore” in assoluto: esiste quello che regge il carico specifico al costo accettabile.

Observed evidence	Cautious interpretation	Recommended action
Picchi di query concorrenti	Un cluster fisso potrebbe saturare	Valutare il serverless
Sorgenti dati multiple	Serve federazione tra fonti	Considerare Trino
Costo per scansione alto	Layout o formato inefficiente	Ottimizzare prima di cambiare motore

Esercizio

Per il livello base, scrivi in cinque righe quale decisione di motore vuoi prendere: carico tipico, concorrenza richiesta, costo per query atteso e rischio principale.

Per il livello intermedio, costruisci una tabella con tre scenari di carico. Per ciascuno indica il motore candidato, il costo stimato e il controllo che faresti prima di adottarlo.

Per il livello research-grade, prepara un memo che includa ipotesi sul carico, dati richiesti, criteri di esclusione, soglia di costo o concorrenza, rischio residuo e piano di monitoraggio della spesa. Come dataset usa S3 con Parquet, Athena, Glue o un log storage; se non hai dati reali, genera un set sintetico con almeno 200 righe, una dimensione temporale, un segmento e una metrica di outcome.

Typical mistake to avoid

L’errore più comune è scegliere il motore per familiarità invece che dai numeri del carico. Si adotta un cluster da gestire quando bastava il serverless, oppure si resta su un singolo motore quando il workload chiede federazione. La domanda di controllo è: a quale livello di costo o concorrenza la scelta attuale smette di reggere? Se non sai rispondere con una soglia, la decisione non è ancora fondata.

Checkpoint

1. Qual è il carico tipico che il motore deve sostenere?
2. Quanti GB scansiona la query più frequente?
3. Quanta concorrenza serve nei momenti di picco?
4. Quale soglia di costo ti farebbe cambiare motore?
5. Quali sorgenti devono essere interrogate insieme?

Summary

Un query engine su S3 si sceglie dal carico, non dall’abitudine: Athena per l’ad-hoc serverless, Trino per volumi e federazione, Spectrum per chi è già su Redshift. Qualunque sia il motore, il costo dipende da quanto scansioni, quindi partition pruning, Parquet, compressione e selezione delle colonne contano più della scelta del tool. La decisione regge quando puoi indicare la soglia di costo o concorrenza oltre la quale cambieresti rotta.

---

References:

• AWS. (2024). “Amazon Athena User Guide.” docs.aws.amazon.com/athena.
• Trino. (2024). “Trino Overview.” trino.io.