Executive summary
Quando un'azienda raccoglie dati da molte fonti diverse, gestionali, vendite online, magazzini, deve trasformarli e organizzarli prima di poterli usare per prendere decisioni. Questo lavoro di preparazione, storicamente eseguito con strumenti complessi o con fogli di calcolo manuali, può oggi essere gestito con gli stessi metodi usati nello sviluppo software: versioni tracciate, test automatici, documentazione integrata. Questo articolo analizza lo strumento che ha reso possibile questo approccio, esaminandone l'architettura interna, le strategie per gestire grandi volumi di dati, la capacità di definire metriche aziendali in modo centralizzato, e i limiti che emergono nei progetti di scala crescente.
Background
Il paradigma ETL (Extract-Transform-Load), dominante per oltre due decenni nella data engineering, prevede la trasformazione dei dati in un layer intermedio prima del caricamento nel sistema di destinazione. Con la disponibilità di data warehouse cloud con capacità computazionale elastica, Snowflake, BigQuery, Redshift, il paradigma si è invertito in ELT: i dati vengono caricati nella loro forma grezza e trasformati direttamente nel warehouse, sfruttando la potenza di calcolo del motore SQL nativo [1]. Questa inversione, articolata da Tristan Handy nel contesto del "modern data stack" [15], ha reso economicamente trascurabile il costo del calcolo SQL e ha spostato il collo di bottiglia dalla capacità computazionale alla qualità della logica di trasformazione.
dbt (data build tool), creato da dbt Labs (precedentemente Fishtown Analytics), si inserisce nella fase "T" dell'ELT. Non estrae dati, non li carica: opera esclusivamente sulla trasformazione, assumendo che i dati grezzi siano già presenti nel warehouse [2]. Questa scelta architetturale apparentemente limitante è il fondamento della sua efficacia: concentrandosi su un singolo problema, la trasformazione SQL, dbt applica le best practice del software engineering (version control, modular design, automated testing, CI/CD) a un dominio tradizionalmente gestito con stored procedure, script ad hoc e fogli di calcolo.
Il progetto open-source dbt Core, distribuito sotto licenza Apache 2.0, ha raggiunto oltre 10.000 stelle su GitHub e viene utilizzato da decine di migliaia di organizzazioni [2]. L'ecosistema include oltre 4.000 pacchetti nella dbt Package Hub e una comunità di oltre 75.000 membri [3]. dbt è disponibile in due modalità: dbt Core (CLI open-source, auto-gestito) e dbt Cloud (piattaforma commerciale con IDE web, scheduling, semantic layer gestito e governance).
Architettura e principi di funzionamento
Il DAG come modello computazionale
L'unità fondamentale di dbt è il model: un file .sql che contiene una query SELECT che definisce una trasformazione. I model non contengono istruzioni DDL (CREATE TABLE, INSERT INTO): è dbt a generare il DDL appropriato in base alla strategia di materializzazione configurata. Le dipendenze tra model sono dichiarate attraverso la funzione ref(), che crea un riferimento esplicito a un altro model. L'insieme delle dipendenze forma un DAG (Directed Acyclic Graph) che dbt percorre in ordine topologico durante l'esecuzione [2].
La funzione source() dichiara le tabelle raw nel warehouse come sorgenti esterne al progetto dbt, consentendo il monitoraggio della freshness (quanto tempo è passato dall'ultimo aggiornamento della sorgente) e la documentazione delle dipendenze tra il layer di ingestion e il layer di trasformazione [2]. Questa separazione esplicita tra dati grezzi e dati trasformati è un principio architetturale centrale: il progetto dbt opera esclusivamente sulla trasformazione, rendendo chiaro il confine di responsabilità.
Organizzazione a layer
La struttura convenzionale di un progetto dbt segue una stratificazione in tre layer, formalizzata da dbt Labs nella guida "How we structure our dbt projects" [15] e influenzata dalla metodologia di modellazione dimensionale di Kimball [4] per il mart layer:
- Staging layer: un model per ogni sorgente, con operazioni di pulizia, rinomina delle colonne, casting dei tipi e standardizzazione dei formati. I model di staging sono tipicamente materializzati come view (nessun costo di storage aggiuntivo) e servono come interfaccia pulita tra i dati grezzi e la logica di business.
- Intermediate layer: model che implementano la logica di business, join tra sorgenti diverse, calcolo di metriche derivate, risoluzione di entità, applicazione di regole di business. Questo layer formalizza le regole di business in precedenza disperse in fogli di calcolo o nella conoscenza tacita dei team analitici.
- Mart layer: model finali ottimizzati per il consumo da parte di dashboard, report e applicazioni downstream. Tipicamente materializzati come tabelle per garantire performance di query.
Strategie di materializzazione
La strategia di materializzazione determina come dbt traduce un model SQL in un oggetto fisico nel warehouse. La scelta della strategia ha implicazioni dirette su costi, performance e freshness dei dati.
Table. Il model viene materializzato come una tabella fisica (CREATE TABLE AS SELECT). Ad ogni esecuzione, la tabella viene ricreata da zero. Appropriato per mart di dimensioni moderate dove la ricreazione completa è accettabile in termini di tempo e costo [2].
View. Il model viene creato come una view SQL. Non occupa storage aggiuntivo, ma il calcolo avviene ad ogni query. Appropriato per staging layer e model intermedi consultati raramente o dove la freshness dei dati deve essere massima (la view riflette sempre lo stato corrente delle tabelle sottostanti) [2].
Incremental. Il model elabora solo i dati nuovi o modificati dall'ultima esecuzione, inserendoli o aggiornandoli nella tabella esistente. Richiede la definizione di una colonna temporale o di un meccanismo di identificazione dei record nuovi. Riduce drasticamente i tempi di esecuzione e i costi su dataset di grandi dimensioni, ma introduce complessità nella gestione di late-arriving data e nella logica di merge [2].
Microbatch (dbt Core 1.9+). Evoluzione della strategia incremental per dataset time-series di grandi dimensioni. Invece di processare tutti i dati nuovi in una singola query, dbt suddivide l'elaborazione in batch temporali atomici (tipicamente un giorno) basati su una colonna event_time configurata. Ogni batch è indipendente e idempotente: può essere eseguito, rieseguito o sostituito singolarmente. Questo consente l'esecuzione parallela dei batch, il retry selettivo in caso di fallimento, e il backfill senza logica condizionale complessa [5]. La strategia microbatch rappresenta un avanzamento significativo per i casi d'uso con volumi dell'ordine dei miliardi di righe, dove la strategia incremental tradizionale raggiunge limiti di praticabilità.
Ephemeral. Il model non viene materializzato nel warehouse: viene interpolato come CTE (Common Table Expression) nei model che lo referenziano tramite ref(). Utile per logica intermedia riutilizzata da più model senza creare oggetti fisici nel database [2].
Framework di testing
dbt implementa un framework di testing a tre livelli che porta le pratiche del software engineering nella data transformation.
Data tests (precedentemente "schema tests") validano i dati prodotti dai model: unicità delle chiavi primarie, non-nullità dei campi obbligatori, integrità referenziale tra tabelle, appartenenza a un set di valori accettati. Questi test vengono eseguiti come query SQL che restituiscono le righe che violano l'asserzione, zero righe significa test superato [2]. I data test sono il meccanismo primario per garantire la qualità dei dati in produzione e possono essere estesi con pacchetti come dbt-utils e dbt-expectations [3].
Unit tests (dbt Core 1.8+) validano la logica SQL dei model su input statici definiti nel file YAML, senza eseguire query sul warehouse. Il test definisce un set di dati di input e l'output atteso; dbt verifica che la trasformazione produca esattamente il risultato atteso [6]. A differenza dei data test (che verificano i dati in produzione), gli unit test verificano la correttezza della logica di trasformazione in modo deterministico, indipendente dallo stato del warehouse. Questa capacità, introdotta nella versione 1.8, colma un gap significativo rispetto alle pratiche standard del software engineering.
Source freshness tests monitorano l'aggiornamento delle tabelle sorgente. Per ogni source, si configura una soglia di freshness attesa (es. "i dati non devono essere più vecchi di 6 ore"); dbt verifica l'ultimo timestamp di aggiornamento e genera un warning o un errore se la soglia è superata [2]. Questo meccanismo è critico per la data governance: consente di rilevare automaticamente interruzioni nella pipeline di ingestion prima che i dati stantii contaminino i report downstream.
Semantic layer e MetricFlow
La definizione centralizzata delle metriche di business è un problema irrisolto in molte organizzazioni: la stessa metrica ("fatturato netto") viene calcolata in modo diverso da team diversi, producendo numeri discordanti. dbt affronta questo problema con il semantic layer, un layer di astrazione che definisce metriche e dimensioni come codice versionato.
MetricFlow, il motore del semantic layer di dbt, è stato open-sourced sotto licenza Apache 2.0 nel 2025 come parte dell'iniziativa Open Semantic Interchange (OSI), con l'obiettivo di creare uno standard aperto per la definizione delle metriche [7]. MetricFlow opera su due concetti fondamentali:
- Semantic models: dichiarazioni YAML che descrivono le entità (entity), le dimensioni (dimension) e le misure (measure) di una tabella. Un semantic model mappa una tabella fisica (prodotta da un model dbt) in un modello semantico navigabile.
- Metrics: definizioni YAML che specificano come le misure vengono aggregate, filtrate e combinate per produrre metriche di business. I tipi di metrica supportati includono
simple(aggregazione diretta),derived(combinazione di altre metriche),cumulative(aggregazione su finestra temporale crescente) econversion(funnel analysis) [7].
MetricFlow compila le definizioni YAML in query SQL ottimizzate per il warehouse di destinazione, gestendo automaticamente i join tra semantic model in base alle relazioni definite. Questo consente a strumenti downstream, dashboard, notebook, applicazioni AI, di interrogare le metriche attraverso un'API senza scrivere SQL, con la garanzia che il calcolo sia sempre consistente [8].
L'apertura di MetricFlow sotto licenza Apache 2.0 e il suo allineamento con l'iniziativa OSI (a cui partecipano Snowflake e Salesforce) rappresentano un passo verso l'interoperabilità. Tuttavia, l'adozione dello standard OSI da parte degli strumenti di business intelligence mainstream è ancora limitata, e il rischio di frammentazione rimane concreto fino a quando i principali tool di consumo non implementeranno nativamente il protocollo [7].
dbt Mesh e governance multi-progetto
Con la crescita delle organizzazioni, un singolo progetto dbt monolitico diventa un collo di bottiglia: centinaia di model, decine di contributor, tempi di compilazione e test crescenti. dbt Mesh è l'architettura proposta da dbt Labs per scalare la trasformazione dati attraverso la decomposizione in progetti indipendenti ma interconnessi [9].
I principi fondamentali di dbt Mesh sono:
- Cross-project references: un model in un progetto può referenziare un model "pubblico" di un altro progetto tramite
ref('project_name', 'model_name'), creando dipendenze inter-progetto tracciate nel DAG globale. - Model contracts: i model pubblici (esposti ad altri progetti) dichiarano un contratto esplicito che specifica nomi delle colonne, tipi e vincoli di nullità. Le modifiche che violano il contratto vengono bloccate in fase di compilazione, proteggendo i consumatori downstream da breaking change [9].
- Model access levels: ogni model può essere dichiarato
public(accessibile da altri progetti),protected(accessibile solo all'interno del proprio gruppo), oprivate(accessibile solo all'interno del proprio progetto), implementando il principio di information hiding.
dbt Mesh si allinea concettualmente con il paradigma del data mesh [10], in cui i dati sono gestiti come prodotti da team distribuiti (domain ownership), ma con un'infrastruttura condivisa che garantisce governance e interoperabilità. Le cross-project reference richiedono che il progetto consumatore abbia accesso al manifest del progetto produttore, implicando un artifact store condiviso e un CI/CD coordinato tra i team.
Limiti e problemi aperti
L'adozione di dbt in contesti produttivi evidenzia limiti strutturali che è importante riconoscere.
Performance a scala. dbt Core esegue i model in ordine topologico, parallelizzando fino al numero di thread configurato (--threads, default 1) tra i model le cui dipendenze sono già soddisfatte. Per progetti con centinaia di model, i tempi di compilazione e di esecuzione della suite di test possono diventare significativi. Alternative come SQLMesh (discusse nella sezione seguente) adottano approcci architetturali, parsing SQL a livello di AST, ambienti virtuali senza materializzazione, che mitigano parzialmente questi limiti [2].
Vendor lock-in. L'acquisizione di dbt Labs da parte di Fivetran (annunciata nell'ottobre 2025) solleva interrogativi sulla direzione futura del progetto [16]. dbt Core rimane open-source sotto licenza Apache 2.0, ma le funzionalità più avanzate (semantic layer gestito, dbt Mesh con orchestrazione, IDE web, governance) sono disponibili esclusivamente in dbt Cloud, il prodotto commerciale. La concentrazione di dbt e SQLMesh sotto lo stesso proprietario (Fivetran) riduce la diversità dell'ecosistema.
Supporto limitato a SQL. dbt è fondamentalmente uno strumento SQL. Il supporto per model Python (introdotto nella versione 1.3) consente l'esecuzione di trasformazioni Python all'interno del DAG dbt, ma con limitazioni significative: i model Python vengono eseguiti nel runtime del warehouse (Snowpark per Snowflake, BigFrames per BigQuery) con un overhead di setup e vincoli sulle librerie disponibili. Per pipeline che richiedono trasformazioni non esprimibili in SQL, preprocessing di dati non strutturati, feature engineering complesso, integrazione di modelli ML, dbt non è lo strumento appropriato e deve essere complementato da un orchestratore esterno (Airflow, Dagster) [2].
Testing. Nonostante i progressi con l'introduzione degli unit test in dbt 1.8, il framework di testing rimane meno maturo rispetto agli standard del software engineering. Non esiste un equivalente nativo del coverage metric, i test di integrazione tra model richiedono l'esecuzione su warehouse (con costi associati), e il debugging di fallimenti nei model incrementali resta un'operazione non triviale.
Alternative nell'ecosistema
Il panorama delle alternative a dbt si è evoluto significativamente nel 2024-2026.
SQLMesh, sviluppato da Tobiko Data (acquisita da Fivetran nel 2025), adotta un approccio differente alla gestione degli ambienti: gli ambienti di sviluppo sono virtuali (nessun costo di warehouse per il testing), il parsing SQL avviene a livello di AST tramite SQLGlot (rilevando errori sintattici a compile time, non a runtime), e il piano di esecuzione viene calcolato automaticamente in base alle modifiche rilevate. Secondo benchmark pubblicati da Tobiko Data (fonte primaria, non verificata da terzi indipendenti), l'approccio produrrebbe miglioramenti significativi nei tempi di esecuzione rispetto a dbt Core. La mancanza di un ecosistema di pacchetti paragonabile a quello di dbt e l'incertezza sulla roadmap post-acquisizione sono i principali limiti all'adozione [16].
Dataform (acquisito da Google nel 2020) è il framework di trasformazione nativo per BigQuery. Non ha costi di licenza, ma è limitato all'ecosistema Google Cloud. Per team già interamente su BigQuery, rappresenta un'alternativa con minore overhead operativo rispetto a dbt, ma con un ecosistema significativamente più ridotto [13].
Malloy è un linguaggio sperimentale per l'analisi dati sviluppato da Google, che riunifica query, trasformazione e visualizzazione in un unico paradigma. Non è ancora maturo per la produzione ma rappresenta una direzione interessante per l'evoluzione del settore [14].
Riferimenti
[1] M. Kleppmann, Designing Data-Intensive Applications, O'Reilly Media, 2017.
[2] dbt Labs, "dbt Documentation," 2026. https://docs.getdbt.com/
[3] dbt Labs, "dbt Package Hub," 2026. https://hub.getdbt.com/
[4] R. Kimball, M. Ross, The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling, 3rd ed., Wiley, 2013.
[5] dbt Labs, "About microbatch incremental models," 2025. https://docs.getdbt.com/docs/build/incremental-microbatch
[6] dbt Labs, "Unit tests," 2024. https://docs.getdbt.com/docs/build/unit-tests
[7] dbt Labs, "Announcing open source MetricFlow: Governed metrics to power trustworthy AI and agents," 2025. https://www.getdbt.com/blog/open-source-metricflow-governed-metrics
[8] dbt Labs, "About MetricFlow," 2025. https://docs.getdbt.com/docs/build/about-metricflow
[9] dbt Labs, "Intro to dbt Mesh," 2024. https://docs.getdbt.com/best-practices/how-we-mesh/mesh-1-intro
[10] Z. Dehghani, "Data Mesh: Delivering Data-Driven Value at Scale," O'Reilly Media, 2022.
[11] dbt Labs, "dbt-core," GitHub repository, 2026. https://github.com/dbt-labs/dbt-core
[12] dbt Labs, "Upgrading to v1.8 — Unit tests," 2024. https://docs.getdbt.com/docs/dbt-versions/core-upgrade/upgrading-to-v1.8
[13] Google Cloud, "Dataform Documentation," 2026. https://cloud.google.com/dataform/docs
[14] Malloy, "Malloy Language," GitHub repository. https://github.com/malloydata/malloy
[15] dbt Labs, "How we structure our dbt projects," dbt Developer Hub, 2023. https://docs.getdbt.com/best-practices/how-we-structure/1-guide-overview
[16] Fivetran, "Fivetran and dbt Labs Announce Merger," 2025. https://www.fivetran.com/blog/fivetran-dbt-labs-merger