Athena e Presto/Trino: query engines su 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 con 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.

Passaggio	Domanda da fare	Output atteso
Decisione	Quale motore stiamo scegliendo e per quale carico?	Scelta esplicita
Segnale	Quanti GB scansiona la query e quanto costa?	Metrica osservabile
Baseline	Qual è il costo o la latenza di riferimento?	Confronto credibile
Vincolo	Quanta concorrenza e quale catalogo servono?	Assunzione dichiarata
Azione	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.

Elemento	Definizione operativa	Controllo minimo
Unità di analisi	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.

Ottimizzazioni essenziali

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 su 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 con 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
Gestione	Serverless AWS	Parte del cluster Redshift	Self-managed cluster
Costo	$5/TB scanned	Come Redshift	Infrastruttura + S3 scanning
Ideale per	Query ad-hoc	Utenti Redshift esistenti	Grandi volumi, multi-cloud
Concorrenza	Alta (AWS gestisce)	Media	Dipende dal 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.

Evidenza osservata	Lettura prudente	Azione consigliata
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

Errore tipico da evitare

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.

Riferimenti

• 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?