Performance e cost management nelle trasformazioni

Gestire performance e costi nelle trasformazioni dati è una scelta, non una definizione da memorizzare. Una query che funziona oggi può diventare il problema di domani quando i volumi crescono, e il momento giusto per accorgersene è prima che la bolletta del warehouse lo renda evidente. Questa lezione tiene insieme la domanda di business, il dato che osservi, il controllo che usi per leggerlo e l’azione che ne segue.

Quando una trasformazione corretta diventa un problema

Il mestiere dell’analytics engineering consiste nel trasformare dati grezzi in modelli affidabili, documentati e riusabili dal business. Il punto delicato arriva dopo: una trasformazione corretta dal punto di vista logico può comunque leggere troppi dati, rallentare la pipeline o generare costi che nessuno aveva previsto. Quando utenti, eventi e query crescono, sono proprio questi modelli a diventare insostenibili, e raramente lo fanno con preavviso.

La verifica che la competenza sia davvero tua è semplice. Se al termine del lavoro non sai indicare quale decisione cambia, quale dato stai osservando e quale errore vuoi evitare, hai ottimizzato una query senza capire perché.

Il modello in quattro passi

Prima di entrare nel tecnico conviene fissare uno schema essenziale. Ogni ottimizzazione che fai dovrebbe rafforzare almeno uno di questi quattro punti, altrimenti rischia di essere lavoro fine a se stesso.

Fase	Cosa chiarire	Output
Domanda	Quale scelta reale deve migliorare?	Decisione da prendere
Misura	Quale segnale osservabile rappresenta il problema?	Metrica o dato sorgente
Controllo	Quale baseline rende il risultato interpretabile?	Confronto credibile
Azione	Che cosa cambia dopo l’analisi?	Prossimo passo operativo

Definire i termini con precisione

Per rendere il problema analizzabile servono definizioni chiare. La tabella seguente fissa gli elementi minimi: senza di essi un confronto di performance resta un’impressione. La formalizzazione regge quando un altro analista può riprodurre la logica, mettere in discussione le assunzioni e arrivare alla stessa decisione partendo dagli stessi dati.

Elemento	Specifica richiesta
Unità di analisi	source, model, test, mart, metrica o esposizione
Segnale principale	freshness, lineage, test coverage, costo modello e fiducia stakeholder
Baseline	Periodo precedente, gruppo comparabile, benchmark o scenario controfattuale
Decisione	modello dbt, semantic layer, contratto, test o pipeline di release
Rischio	Scambiare un numero disponibile per una prova sufficiente

Un caso concreto: da 4,3 ore a 12 minuti

Un social network con 50 milioni di utenti attivi mensili aveva un modello dbt che calcolava la “feed relevance score”. Era una metrica complessa: 8 JOIN, 6 window function e aggregazioni su 2 anni di dati, per un totale di 18 miliardi di eventi. Ogni esecuzione richiedeva 4,3 ore e costava 1.400$.

L’ottimizzazione è passata per tre interventi. Il primo è stato la pre-aggregazione: un modello intermedio pre-calcolava le metriche utente per giorno, riducendo da 18 miliardi a 4,6 milioni di righe aggregate al giorno, con una strategia incremental su 7 giorni. Il secondo ha ridotto la finestra temporale, perché il 96% del punteggio dipendeva dagli ultimi 30 giorni: quell’intervallo è stato pesato di più e per il resto è bastata una media storica. Il terzo ha sfruttato una vista materializzata su BigQuery, aggiornata in automatico per le aggregazioni giornaliere.

Il risultato è stato un tempo di esecuzione sceso da 4,3 ore a 12 minuti e un costo passato da 1.400$a 38$ per esecuzione, con una variazione di precisione dello 0,3% irrilevante per l’uso.

Le quattro fasi dell’ottimizzazione in dbt

L’ordine conta, perché le prime fasi liberano gli ordini di grandezza più grandi e rendono spesso superflue le successive.

Fase 1: Riduci i dati letti (impatto 10-100x)

Leggi solo ciò che serve, e il prima possibile. In pratica significa applicare i filtri sulle date già nei modelli sorgente e non a valle, e selezionare le sole colonne necessarie evitando SELECT *.

Fase 2: Ottimizza le JOIN (impatto 2-10x)

Conviene pre-aggregare prima della JOIN per ridurre il numero di righe coinvolte. Per escludere i record già presenti, un anti-join con NOT EXISTS rende meglio del classico LEFT JOIN + IS NULL.

Fase 3: Sfrutta le ottimizzazioni native del warehouse (impatto 2-5x)

Ogni motore ha le sue leve. Su Snowflake sono le clustering keys sulle colonne più filtrate. Su BigQuery valgono partition by e cluster by su colonne ad alta cardinalità. Su Redshift contano distribution key e sort key impostate bene.

Fase 4: Rivedi la strategia di materialization

Incremental non è sempre la risposta giusta. Su modelli piccoli, una semplice table è spesso più rapida da gestire e da capire.

Strumenti di profiling

dbt non include un profiler nativo, ma qualche strumento copre il bisogno. Il flag dbt --debug produce log dettagliati con i tempi di esecuzione. La query history del warehouse mostra costi e durata reali. Il file target/run_results.json permette di analizzare i tempi a posteriori.

Controlli prima di decidere

Prima di prendere una decisione basata su performance e costi, vale la pena verificare la completezza e l’assenza di duplicati, la coerenza dei timezone, l’attualità delle definizioni metriche e gli eventuali segmenti esclusi. Molte analisi falliscono per un motivo banale: il dato misura un comportamento diverso da quello che si crede di stare osservando.

Leggere i segmenti, non solo la media

La media aggregata è un punto di partenza, non una conclusione. Segmenta per canale, coorte, piano, paese, device e maturità utente. Quando due segmenti si muovono in direzioni opposte, la media li annulla a vicenda e ti porta verso la decisione sbagliata.

Chiudere con una scelta

Ogni analisi dovrebbe terminare con una scelta concreta: continuare, fermare, iterare, investire, rimuovere o approfondire. Se il lavoro su performance e costi non cambia nessuna decisione, manca il collegamento tra la metrica e l’azione, e l’ottimizzazione resta un esercizio.

Misurare il risultato dell’intervento

Dopo aver ottimizzato, fissa una metrica primaria e due guardrail. La metrica primaria misura il miglioramento atteso, per esempio il tempo o il costo per esecuzione. I guardrail servono a non comprare quel miglioramento al prezzo di retention, fiducia, qualità dei dati o sostenibilità nel tempo.

Mettere in pratica

Conviene allenarsi su tre livelli di difficoltà crescente. Per cominciare, scrivi una scheda sintetica del problema: la decisione da supportare, la metrica primaria, la baseline, il rischio principale e l’azione prevista se il segnale è confermato. Come passo intermedio, costruisci una tabella con tre segmenti o scenari, e per ciascuno indica cosa cambia, quali spiegazioni alternative sono plausibili e quali controlli eseguiresti prima di raccomandare un’azione. Per arrivare a un livello da decision memo completo, aggiungi ipotesi, dati richiesti, criteri di esclusione, controlli di qualità, soglia decisionale, rischio residuo e piano di monitoraggio.

Per il materiale, lavora su dbt, warehouse, sorgenti CRM, eventi, marts, semantic layer e lineage. In mancanza di dati reali, un dataset sintetico di almeno 200 righe con una dimensione temporale, una dimensione di segmento e una metrica di outcome è sufficiente per esercitarsi.

L’errore tipico

Il rischio più frequente è usare “performance e cost management” come etichetta invece che come pratica. Si riconosce dai grafici senza una decisione collegata, dalle metriche senza baseline e dalle conclusioni che non dichiarano le assunzioni critiche. La domanda di controllo da tenere a mente è questa: se il risultato fosse instabile, quale scelta sbaglierei? Quando la risposta non è concreta, il collegamento tra analisi e azione non c’è.

Riepilogo operativo

Il lavoro su performance e costi diventa utile quando produce decisioni più chiare, non quando aggiunge terminologia. Il percorso che parte dal problema, passa per il modello e la formalizzazione, si appoggia a un esempio reale e si chiude con esercizio e controllo serve proprio a questo: trasformare la lezione in una pratica che puoi verificare.