import pandas as pd

Prestazioni e ottimizzazione query su S3

Una query su un data lake S3 può risultare 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.

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 l’I/O su S3: migliaia di file piccoli da aprire, colonne lette inutilmente, partizioni non sfruttate. Una query utile 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 rendere più chiaro il costo di un intervento sbagliato, per esempio comprimere senza ridurre i file piccoli.

Rendere misurabile l’intervento

L’unità su cui ragioni è la query, con il suo piano di esecuzione e i suoi file di input. Il segnale che osservi sono i GB scansionati e il tempo di risposta. La baseline è il costo della query prima dell’intervento. La soglia decisionale è il risparmio che giustifica il lavoro, fissato prima di iniziare. Il rischio residuo è ottimizzare una query che gira di rado, 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 porta statistiche incorporate 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 diventano 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 ti ritrovi con tanti file piccoli, compattali con un CREATE TABLE AS SELECT.

Caching dei risultati

Athena conserva automaticamente i risultati per 24 ore quando la query e i parametri coincidono, salvandoli su S3. Le query ripetute costano zero e tornano istantanee. Per una dashboard che si aggiorna spesso, questo comportamento fa la differenza tra un report fluido e una bolletta che cresce.

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 calcolare 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, il costo e la 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

Esercizio

Per il livello base, scrivi in cinque righe quale query vuoi rendere più veloce: indica i GB scansionati oggi, l’intervento previsto e il risparmio atteso.

Per il livello intermedio, costruisci una tabella con quattro colonne: query osservata, costo attuale, ottimizzazione proposta, costo atteso. Includi almeno un caso in cui l’intervento non vale lo sforzo.

Per il livello research-grade, prepara un memo che includa baseline misurata, ipotesi sul risparmio, soglia di convenienza e piano di monitoraggio della spesa dopo il rollout. 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.

Errore tipico da evitare

L’errore più comune è cambiare il motore o aggiungere infrastruttura prima di misurare dove va il tempo. Si finisce per ottimizzare 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 sai rispondere con un numero, ti manca ancora la baseline.

Checkpoint

1. Quanti GB scansiona oggi la query che vuoi ottimizzare?
2. Da quanti file legge e in quale formato?
3. Quale leva riduce di più la scansione nel tuo caso?
4. Quale risparmio giustifica il lavoro di ottimizzazione?
5. Come verifichi che il guadagno regga nel tempo?

Riepilogo

Le prestazioni su S3 si governano misurando prima quanto e da dove legge una query, poi agendo su formato, dimensione dei file, partizionamento, statistiche e caching. Parquet ben dimensionato, file tra 200 e 500 MB, pruning sfruttato e risultati pre-aggregati spostano latenza e costo molto più di un cambio di motore. Una buona ottimizzazione si chiude con un numero: GB scansionati prima e dopo, sulla stessa query.

---

Riferimenti:

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