Una guida di Fivetran dell’agosto 2025 rimette in fila cosa sia dbt, dove si collochi nel modern data stack e quando abbia senso adottarlo. Il contenuto è divulgativo, ma il decision tree finale è la parte più utile: quattro domande secche che valgono più di molte demo.
Cosa è e cosa non è
dbt è uno strumento SQL-based, open source, sviluppato da dbt Labs, che trasforma i dati grezzi in modelli pronti per l’analisi dentro il data warehouse. Il post lo delimita esplicitamente: è un layer di trasformazione e modeling, pensato per analisti che lavorano in SQL, con workflow modulari, testabili e documentati. Non è un tool di ETL, non è una piattaforma di BI, non è un servizio di ingestion.
In pratica dbt permette di riusare la stessa logica di trasformazione tra progetti invece di ripartire da zero, documentare i modelli così che tutti sappiano cosa rappresenta una tabella, e testare automaticamente i dati per intercettare errori — per esempio ID che non combaciano — prima che finiscano in dashboard.
Struttura, YAML, package
I modelli si costruiscono con SELECT statement dentro il warehouse: selezionare le colonne necessarie, filtrare le righe, unire tabelle. La differenza rispetto a una query estemporanea è che questi statement vengono salvati, versionati e riusati.
La struttura di un progetto dbt prevede cartelle per models, tests, snapshots, seeds, macros e il file di configurazione dbt_project.yml. Dentro models il layout tipico separa staging per la pulizia dei dati grezzi, intermediate per combinazione e shaping, e data mart per le tabelle business-ready. I progetti si collegano di solito a Git per version control e rollback, ma il post nota correttamente che GitLab, Bitbucket o Gogs funzionano allo stesso modo, e che chi lavora da solo può anche partire da una cartella locale.
YAML aggiunge il contesto che SQL da solo non copre: definizione dei test — per esempio unicità o assenza di null — documentazione di modelli e colonne, e configurazione della materializzazione (table, view, incremental). I dbt package, infine, sono trasformazioni pre-costruite da innestare nel proprio progetto, con modelli, macro e test già pronti, esattamente come una libreria di codice.
Le quattro domande
Il decision tree proposto è sequenziale. Prima: la tua organizzazione usa un’architettura ELT, cioè carica i dati grezzi in un cloud data warehouse prima di trasformarli? Se no, ci si ferma qui — dbt non è pensato per manipolazioni pre-load. Seconda: il team sa scrivere SQL? Se no, serve un percorso di upskilling prima dell’adozione. Terza: testing, documentazione e version control fanno parte della strategia di governance? Quarta: serve logica di trasformazione modulare e riusabile? Solo con quattro sì dbt è probabilmente la scelta giusta.
È un filtro onesto e vale la pena applicarlo davvero: dbt su un team che non ha né SQL né cultura di testing produce solo un altro layer da mantenere.
In sintesi
- dbt è un layer di trasformazione e modeling in SQL dentro il warehouse: non fa ingestion, non fa BI, non fa orchestrazione pre-load.
- La struttura tipica separa staging, intermediate e data mart, con YAML per test, documentazione e materializzazione.
- Prima di adottarlo, verifica architettura ELT, competenze SQL, cultura di testing e reale bisogno di logica modulare.
Fonte: Data build tool (dbt) explained: Role, use case, and stack fit — https://www.fivetran.com/blog/dbt-explained
Hai qualcosa da aggiungere? Unisciti alla discussione.