Performance e cost management nelle trasformazioni

Questa lezione appartiene al binario ml-tabellare: il tema è quanto costano le nostre tabelle e come farle girare più veloci. La buona notizia è che i guadagni più grandi arrivano prima di toccare una riga di codice.

L’idea in una frase

Il cost management delle trasformazioni riduce i dati letti e le operazioni sprecate prima di toccare il codice, perché sul warehouse ogni riga scansionata ha un prezzo. Ottimizzare, insomma, significa prima leggere meno, poi leggere meglio.

La sequenza di intervento

1. Filtra le date e seleziona le sole colonne necessarie già nei modelli a monte, prima di qualsiasi join.
2. Pre-aggrega le tabelle grandi prima di unirle e usa anti-join efficienti per escludere i record già presenti.
3. Applica le leve native del motore sulle colonne più filtrate: chiavi di clustering, partizionamento e chiavi di distribuzione.
4. Rivedi la materializzazione solo alla fine, perché su tabelle piccole la ricostruzione piena resta la scelta più semplice.
5. Misura tempo e costo per esecuzione prima e dopo l’intervento, con un guardrail sulla precisione che non puoi superare.

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, ridurre i dati letti, con impatto da dieci a cento volte. Applica i filtri sulle date già nei modelli sorgente e non a valle. Seleziona le sole colonne necessarie ed evita SELECT *.

Fase 2, ottimizzare le join, con impatto da due a dieci volte. Pre-aggrega prima della join per ridurre le righe coinvolte. Per escludere i record già presenti preferisci un anti-join con NOT EXISTS al classico LEFT JOIN con controllo di nullità.

Fase 3, sfruttare le ottimizzazioni native del warehouse, con impatto da due a cinque volte. Su Snowflake usa le clustering key sulle colonne più filtrate. Su BigQuery usa partizionamento e clustering su colonne ad alta cardinalità. Su Redshift imposta distribution key e sort key.

Fase 4, rivedere la strategia di materializzazione. Il modello incremental non è sempre la risposta giusta: su modelli piccoli una tabella ricostruita da zero è più rapida da gestire e da capire.

Strumenti di profiling

dbt non include un profiler nativo, ma pochi strumenti coprono il bisogno.

Il flag dbt --debug produce log dettagliati con i tempi di esecuzione. La cronologia delle query del warehouse mostra costi e durata reali. Il file target/run_results.json permette di analizzare i tempi a posteriori.

Dopo aver ottimizzato, fissa una metrica primaria e due guardrail. La metrica primaria misura il miglioramento in tempo o costo per esecuzione. I guardrail impediscono di comprare quel miglioramento al prezzo di qualità o sostenibilità.

L’errore che costa caro

Il rischio più frequente è usare performance e cost management come etichetta invece che come pratica: grafici senza decisione collegata, metriche senza baseline, conclusioni che non dichiarano le assunzioni critiche. Si ottimizza per sport, senza mai chiedersi quale numero deve cambiare.

La domanda di controllo è sempre la stessa, cioè quale scelta sbaglieresti se il risultato fosse instabile. Se l’ottimizzazione non regge quella domanda, non è un miglioramento, è un azzardo.

Verdetto: prima leggi meno dati, poi unisci meglio, poi sfrutta il motore; la materializzazione si cambia per ultima, solo con numeri di costo alla mano.

Il caso GitLab

GitLab, fondata nel 2014 come piattaforma remota per lo sviluppo software, documenta pubblicamente le linee guida del suo team dati sull’uso di dbt. Le guide prescrivono modelli incrementali per le tabelle grandi e pipeline di integrazione che ricostruiscono solo i modelli modificati e quelli a valle, invece di rieseguire l’intero progetto a ogni proposta di modifica. È la stessa logica delle quattro fasi: il risparmio maggiore viene dal non leggere e dal non ricostruire ciò che non è cambiato. Il caso mostra che il cost management è disciplina di processo prima che tecnica di query.

Domande per metterti alla prova

1. Qual è il primo intervento per ridurre il costo di un modello lento e perché viene prima degli altri?
2. Come verificheresti che un’ottimizzazione non abbia alterato i numeri in uscita?
3. Quando una tabella ricostruita da zero resta preferibile a un modello incrementale?
4. Quali leve native useresti sul tuo warehouse per le colonne più filtrate?