Athena and Presto/Trino: query engines on S3

Questa lezione, come le altre del binario ml-tabellare, ruota attorno a una verità semplice: un lake su S3 diventa 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.

L’idea in una frase

Interrogare S3 with Athena, Presto o Trino significa eseguire SQL direttamente sugli oggetti del lake senza ETL preventivo, pagando in base ai dati scansionati e al carico sostenuto.

Come procedere, passo dopo passo

1. Descrivi carico tipico, concorrenza di picco e sorgenti da interrogare insieme.
2. Misura GB scansionati e costo per query sul motore attuale.
3. Confronta Athena serverless, Spectrum e Trino su gestione, costo e federazione.
4. Applica pruning, Parquet, compressione e selezione delle colonne prima di decidere.
5. Fissa la soglia di costo o concorrenza oltre la quale cambi motore e monitorala.

Scegliere un motore, non un tool

La scelta non è quale strumento sia migliore in assoluto, ma quale motore regge i tuoi vincoli. La differenza conta quando cambiano concorrenza richiesta, costo per query, catalogo dei metadati, latenza accettabile e 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 profilo 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 chiarire il costo di una scelta sbagliata, per esempio adottare un cluster da gestire quando bastava il serverless.

Rendere misurabile la scelta

L’unità di ragionamento è la singola query con piano e GB scansionati. Il segnale osservato 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, fissata prima di misurare. Il rischio residuo è scegliere per familiarità invece che sui 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: senza ottimizzazione, una singola query può scansionare terabyte e costare decine di dollari. Ogni esecuzione mostra i GB scansionati: controllali 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 il resto. La seconda è il formato colonnare Parquet, che permette di leggere solo le colonne nel SELECT. La terza è la compressione, con Snappy o Zstd over Parquet, che riduce i dati letti da S3. La quarta è selezionare solo le colonne necessarie: un SELECT * su una tabella con 200 colonne le legge tutte e 200, perché anche nel colonnare più colonne significano più input. 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 su più sorgenti. Il caso mostra come la scelta 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

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 rispondi con una soglia, la decisione non è ancora fondata.

Verdetto: usa Athena per query ad-hoc serverless, Trino per grandi volumi e federazione multi-sorgente, e Spectrum solo se il tuo team vive già su Redshift.

References

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

Il caso Presto e Trino

Presto è nato dentro Facebook per interrogare petabyte nel data lake interno con SQL interattivo ed è stato pubblicato come open source nel 2013. Il progetto ha dimostrato che un motore distribuito schema-on-read può unire velocità e federazione senza spostare i dati. Nel 2020 il team dei creatori originali ha proseguito lo sviluppo sotto il nome Trino, mentre Presto è continuato come progetto separato. La storia mostra la tesi della lezione: il motore va scelto sul carico reale, perché pruning, formato e costo di scansione restano decisivi su entrambi.

Domande per verificare quello che hai capito

1. Quale carico tipico deve sostenere il tuo motore nelle ore di punta?
2. Quanti GB scansiona la tua query più frequente e quanto costa?
3. Quanta concorrenza serve quando tutti i team interrogano insieme?
4. Quale soglia di costo o latenza ti farebbe cambiare motore?
5. Quali sorgenti devi federare nella stessa interrogazione?