Prestazioni e ottimizzazione query su S3

Questa lezione, come le altre del binario ml-tabellare, parte da una constatazione che sorprende sempre chi arriva dai database tradizionali: una query su un data lake S3 può essere lenta non per colpa del motore, ma per file troppo piccoli, formati sbagliati, partizioni inutili o scansioni troppo ampie. Ottimizzare le prestazioni significa collegare layout, formato, compressione e pruning al costo reale delle analisi. Il tema è tecnico e il punto è capire quale leva sposta davvero latenza e fattura quando interroghi dati su object storage.

L’idea in una frase

Ottimizzare le query su S3 significa ridurre i dati letti con formato, dimensione dei file, partizionamento, statistiche e caching prima di cambiare motore.

Come procedere, passo dopo passo

1. Misura GB scansionati, numero di file e formato della query più costosa.
2. Converti i dati in Parquet compresso con file tra 200 e 500 MB.
3. Applica il partition pruning e seleziona solo le colonne necessarie.
4. Aggiorna le statistiche e sfrutta cache o pre-aggregazioni per le query ripetute.
5. Rimisura la stessa query e confronta costo e latenza prima e dopo.

Da dove nasce la lentezza

Prima di cambiare motore conviene capire dove va il tempo. La diagnosi parte da quattro domande: quanti dati legge la query, da quanti file, in quale formato e con quale possibilità di evitare i dati irrilevanti. Spesso il collo di bottiglia non è il calcolo ma lo scambio con S3: migliaia di file piccoli da aprire, colonne lette inutilmente e partizioni non sfruttate. Una query diventa economica solo quando questi quattro fattori sono sotto controllo.

Una griglia per impostare la diagnosi

Conviene seguire una sequenza che lega ogni scelta a un costo misurabile.

Passaggio	Domanda da fare	Output atteso
Decisione	Quale leva di performance stiamo valutando?	Intervento esplicito
Segnale	Quanti GB e quanti file legge la query?	Misura osservabile
Baseline	Quanto costa oggi la query tipica?	Costo di riferimento
Vincolo	Cosa limita il parallelismo?	Assunzione dichiarata
Azione	Quale ottimizzazione applichiamo?	Cambiamento verificabile

Ogni riga deve chiarire il costo di un intervento sbagliato, per esempio comprimere senza ridurre i file piccoli.

Rendere misurabile l’intervento

L’unità di ragionamento è la query, con piano di esecuzione e file di input. Il segnale osservato sono i GB scansionati e il tempo di risposta. La baseline è il costo prima dell’intervento. La soglia decisionale è il risparmio che giustifica il lavoro, fissata prima di iniziare. Il rischio residuo è ottimizzare una query rara, spendendo tempo dove l’impatto è marginale.

Elemento	Definizione operativa	Controllo minimo
Unità di analisi	La singola query e i suoi input	Piano, file, formato
Variabile osservata	GB scansionati e latenza	Misura ripetibile
Baseline	Costo prima dell’ottimizzazione	Confronto diretto
Soglia decisionale	Risparmio minimo che giustifica l’intervento	Criterio scritto prima
Rischio residuo	Ottimizzare query poco frequenti	Revisione della frequenza

Statistiche di tabella e colonna

Parquet include statistiche per ogni row group: minimo, massimo e conteggio dei null. Athena le usa per saltare i row group non rilevanti. Aggiornare le statistiche con ANALYZE migliora le decisioni del query planner:

ANALYZE orders COMPUTE STATISTICS;
ANALYZE orders COMPUTE STATISTICS FOR COLUMNS customer_id;

La dimensione dei file conta

I file non devono essere né troppo piccoli né troppo grandi. Sotto i 50 MB l’overhead di apertura e di listing su S3 domina il tempo della query. Sopra 1 GB i file sono pochi e il parallelismo si riduce, perché Athena parallelizza per file e non per row group. Il bersaglio ragionevole è tra 200 e 500 MB per file Parquet. Se hai tanti file piccoli, compattali con un CREATE TABLE AS SELECT.

Caching dei risultati

Athena conserva automaticamente i risultati per 24 ore quando query e parametri coincidono, salvandoli su S3. Le query ripetute costano zero e tornano istantanee. Per una dashboard aggiornata spesso, questo comportamento distingue un report fluido da una bolletta in crescita.

Pre-aggregazione con CTAS

Per le dashboard con query ricorrenti conviene pre-calcolare i risultati una volta sola:

CREATE TABLE daily_orders_agg AS
SELECT order_date, customer_id, SUM(amount) AS daily_total
FROM orders GROUP BY order_date, customer_id;

La dashboard legge da daily_orders_agg, una tabella circa 100 volte più piccola, invece che dalla orders completa. Costa meno e risponde prima. Il pattern è semplice e l’impatto è sproporzionato rispetto allo sforzo.

Un caso concreto

Una query Athena scansiona 800 GB per un KPI settimanale, perché legge CSV non compressi sparsi su migliaia di file piccoli. Convertendo a Parquet, compattando i file, partizionando per data e sfruttando il pruning, costo e latenza crollano senza toccare la domanda business. La risposta resta la stessa: cambia solo quanto dato il motore deve leggere per produrla.

Evidenza osservata	Lettura prudente	Azione consigliata
La query legge centinaia di GB	Formato o layout inefficiente	Convertire a Parquet e partizionare
Migliaia di file piccoli	Overhead di listing elevato	Compattare con CTAS
Stessa query ripetuta ogni ora	Calcolo ridondante	Sfruttare cache o pre-aggregazione

Errore tipico da evitare

L’errore più comune è cambiare motore o aggiungere infrastruttura prima di misurare dove va il tempo. Così ottimizzi il pezzo sbagliato, magari comprimendo dati che il pruning avrebbe già escluso. La domanda di controllo è: se la query restasse lenta dopo l’intervento, quale assunzione avrei sbagliato? Se non rispondi con un numero, ti manca ancora la baseline.

Verdetto: converti in Parquet, compatta tra 200 e 500 MB, sfrutta pruning e cache, e cambia motore solo se la baseline resta alta dopo questi interventi.

Riferimenti

• AWS. (2024). “Athena Performance Tuning.” docs.aws.amazon.com/athena.

Il caso Apache Parquet

Apache Parquet è nato nel 2013 dalla collaborazione tra Twitter e Cloudera come formato colonnare aperto per l’ecosistema Hadoop. La sua forza sta nelle statistiche per row group, con minimo, massimo e conteggio dei null, che permettono ai motori di saltare i blocchi irrilevanti. Rispetto al CSV non compresso, il colonnare compresso legge solo le colonne richieste e riduce drasticamente i GB scansionati. Il caso mostra perché la prima leva di performance è il formato dei file e non il motore che li legge.

Domande per verificare quello che hai capito

1. Quanti GB scansiona oggi la query che vuoi ottimizzare?
2. Da quanti file legge e in quale formato sono scritti?
3. Quale leva tra formato, compattazione, pruning e cache riduce di più la tua scansione?
4. Quale risparmio minimo giustifica il lavoro di ottimizzazione?
5. Come verifichi che il guadagno su costo e latenza regga nel tempo?