Il Problema che dbt Risolve

Immagina un data warehouse pieno di query SQL scritte da analisti diversi nel corso di tre anni. Centinaia di view chiamate final_v3_DEFINITIVO_bis, logiche di calcolo duplicate in dieci posti diversi, nessun test che garantisca la qualità dei dati, e zero documentazione su cosa significhi realmente quella colonna net_revenue_adjusted.

Questo è il punto di partenza per la maggior parte dei team data nel 2026. E è esattamente il problema che dbt (data build tool) è stato progettato per risolvere.

dbt non è un nuovo ETL tool, non è un orchestratore di pipeline e non è un data warehouse. È uno strumento di trasformazione: prende dati già caricati nel warehouse e li trasforma in modelli analitici pronti per il consumo, usando SQL e le pratiche dell'ingegneria del software.

ELT vs ETL: Perché il Mondo è Cambiato

Per decenni il paradigma dominante è stato ETL: Extract, Transform, Load. I dati venivano estratti dalle sorgenti, trasformati in un layer intermedio (spesso su server dedicati) e poi caricati nel data warehouse già nella forma finale.

L'avvento di data warehouse cloud come Snowflake, BigQuery e Amazon Redshift ha ribaltato questa logica. Questi sistemi hanno potenza di calcolo praticamente illimitata e costi di storage bassissimi. Non ha più senso trasformare i dati prima di caricarli: meglio caricarli grezzi e trasformarli dopo, direttamente nel warehouse. Nasce così ELT.

Cos'è dbt in Concreto

dbt è uno strumento a riga di comando (e cloud) che ti permette di:

• Scrivere trasformazioni SQL come modelli versionati in Git
• Definire dipendenze automatiche tra modelli con il macro ref()
• Aggiungere test di qualità ai dati direttamente nel codice
• Generare automaticamente documentazione e lineage graph
• Eseguire tutto questo in un pipeline CI/CD

Un modello dbt è semplicemente un file SQL con un SELECT. dbt lo materializza nel warehouse come view, table, o tabella incrementale, in base alla configurazione.

-- models/marts/finance/orders_daily.sql
-- dbt materializza questo come una tabella nel warehouse

SELECT
    DATE_TRUNC('day', created_at) AS order_date,
    SUM(total_amount) AS revenue,
    COUNT(*) AS order_count,
    AVG(total_amount) AS avg_order_value
FROM {{ ref('stg_orders') }}          -- ref() crea la dipendenza
WHERE status = 'completed'
GROUP BY 1

Nota il {{ ref('stg_orders') }}: dbt sa che questo modello dipende da stg_orders, costruisce automaticamente il grafo delle dipendenze (DAG) e garantisce che i modelli vengano eseguiti nell'ordine corretto.

Il Ruolo dell'Analytics Engineer

L'ascesa di dbt ha creato una nuova figura professionale: l'analytics engineer. È il profilo a metà strada tra data analyst e data engineer:

• Conosce SQL profondamente come un analyst
• Applica pratiche di ingegneria del software (Git, testing, CI/CD) come un engineer
• Costruisce e mantiene il layer di trasformazione del data warehouse
• Collabora con data analyst (che consumano i modelli) e data engineer (che gestiscono le pipeline di ingestion)

Secondo il State of Data Engineering 2025, il ruolo di analytics engineer è cresciuto del 340% negli ultimi tre anni su LinkedIn, rendendolo uno dei profili più ricercati nel mondo data.

L'Ecosistema dbt nel 2026

dbt non è solo un tool: è diventato un ecosistema completo con due distribuzioni principali:

dbt Core

La versione open-source e gratuita di dbt. Si installa via pip, funziona da riga di comando e si integra con qualsiasi sistema CI/CD. Supporta tutti i principali data warehouse: Snowflake, BigQuery, Redshift, Databricks, DuckDB, PostgreSQL e molti altri tramite adapter.

dbt Cloud

Il servizio managed di dbt Labs, l'azienda dietro dbt. Aggiunge un IDE web, scheduler integrato, monitoring, dbt Explorer (lineage avanzato) e il dbt Semantic Layer per metriche consistenti. Disponibile con piano gratuito per developers e piani enterprise da $100/mese per team.

I Pilastri del Progetto dbt

Un progetto dbt ha una struttura standard che porta ordine dove prima c'era chaos:

jaffle_shop/                    # nome del progetto
├── dbt_project.yml             # configurazione del progetto
├── profiles.yml               # credenziali di connessione (locale)
├── models/
│   ├── staging/               # modelli vicini alla sorgente
│   │   ├── stg_orders.sql
│   │   ├── stg_customers.sql
│   ├── marts/                 # modelli business-oriented
│       ├── finance/
│       │   └── orders_daily.sql
│       └── marketing/
│           └── customer_ltv.sql
├── tests/                     # test SQL personalizzati
├── seeds/                     # CSV statici come reference data
├── macros/                    # funzioni SQL riutilizzabili
└── analyses/                 # query ad hoc (non materializzate)

Questa struttura a livelli (staging → intermediate → marts) è una best practice dbt chiamata layered architecture:

• Staging: 1-a-1 con le sorgenti, solo rinominare e castare i tipi
• Intermediate: join e aggregazioni complesse tra staging models
• Marts: modelli finali pronti per il consumo da parte di BI e analytics

Testing e Documentazione: Le Killer Feature di dbt

Due feature di dbt che trasformano completamente il ciclo di sviluppo dei dati:

Testing Automatico

Definisci test direttamente nel file YAML che accompagna ogni modello:

# models/staging/schema.yml
models:
  - name: stg_orders
    columns:
      - name: order_id
        tests:
          - unique
          - not_null
      - name: status
        tests:
          - accepted_values:
              values: ['completed', 'pending', 'cancelled']
      - name: customer_id
        tests:
          - not_null
          - relationships:
              to: ref('stg_customers')
              field: customer_id

Con dbt test, dbt esegue questi test come query SQL nel warehouse e fallisce la pipeline se qualcosa non va. Zero codice Python, zero framework esterni.

Documentazione Auto-Generata

Aggiungi descrizioni nello stesso file YAML:

# models/marts/schema.yml
models:
  - name: orders_daily
    description: "Aggregazione giornaliera degli ordini completati"
    columns:
      - name: order_date
        description: "Data dell'ordine, troncata al giorno"
      - name: revenue
        description: "Totale ricavi per il giorno, al netto dei resi"

dbt docs generate && dbt docs serve genera un sito statico con documentazione completa e il DAG interattivo che mostra le dipendenze tra tutti i modelli. Ogni colonna è documentata e tracciabile fino alla sorgente.

dbt nel Data Stack Moderno

dbt è tipicamente il layer T dello stack ELT moderno:

• Ingestion: Airbyte, Fivetran, Stitch o script Python caricano i dati raw nel warehouse
• Storage: Snowflake, BigQuery, Redshift, Databricks Delta Lake
• Transformation: dbt trasforma i dati raw in modelli analitici
• BI & Analytics: Looker, Metabase, Tableau o notebooks consumano i modelli dbt

Nel 2026, dbt è presente nel data stack di oltre 30.000 aziende (dati dbt Labs), dalle startup ai colossi come GitLab, JetBlue, Conde Nast e Shopify.

Perché Imparare dbt nel 2026

Le ragioni concrete per investire tempo nell'apprendimento di dbt:

• Domanda di mercato: "dbt" appare nel 45% delle offerte di lavoro per data engineer e analytics engineer su LinkedIn in Europa
• Produttività: team dbt riportano una riduzione del 60-70% del tempo dedicato al debugging di pipeline dati grazie a test automatici
• Ecosistema: oltre 200 package dbt su dbt Hub, incluso dbt-utils (la libreria standard) e dbt-expectations per test avanzati
• Osservabilità: integrazione nativa con Elementary, re_data e tool di data observability per monitoring della qualità in produzione

Conclusioni e Prossimi Passi

dbt ha ridefinito come i team data costruiscono e mantengono le loro pipeline analitiche, portando le pratiche mature dell'ingegneria del software - testing, versioning, documentazione, CI/CD - in un mondo che per decenni ha vissuto senza di esse.

Il concetto chiave da portare a casa: dbt non è uno strumento di nicchia per grandi enterprise. È accessibile, open-source e funziona anche su un singolo laptop con DuckDB come backend. La curva di apprendimento è bassa per chi conosce SQL, alta la ricompensa.

Nel prossimo articolo della serie configureremo un progetto dbt Core da zero: installeremo dbt, scriveremo il profiles.yml, creeremo i nostri primi modelli e vedremo il ref() macro in azione su un dataset reale.