ETL vs ELT Moderno: dbt, Airbyte e Fivetran
Le pipeline dati sono il sistema circolatorio di ogni architettura data-driven. Senza un flusso affidabile, documentato e testato di dati dalla sorgente al warehouse, i modelli di machine learning producono previsioni errate, i report di business mostrano numeri inconsistenti e le decisioni strategiche si basano su fondamenta instabili. Eppure, nella maggior parte delle aziende italiane, le pipeline dati sono ancora un groviglio di script SQL schedulati con cron, fogli Excel aggiornati a mano e processi ETL costruiti decenni fa che nessuno osa toccare.
Il panorama e cambiato radicalmente negli ultimi cinque anni. L'avvento del cloud computing ha ribaltato il paradigma fondamentale del data movement: non ha più senso trasformare i dati prima di caricarli nel warehouse, come si faceva con l'ETL tradizionale, quando la potenza di calcolo del cloud e disponibile a costi irrisori e il warehouse moderno può eseguire trasformazioni complesse in secondi. E nato cosi il paradigma ELT (Extract, Load, Transform), che inverte l'ordine delle operazioni spostando la trasformazione dentro il warehouse stesso.
Il mercato delle pipeline dati riflette questa trasformazione: il segmento ELT cresce al 26% annuo, con il mercato complessivo dei data pipeline tools stimato a $12 miliardi nel 2024 e proiettato a $48 miliardi entro il 2030. Fivetran, il principale attore ELT managed, ha raggiunto $300 milioni di ARR con una crescita del 50% anno su anno. Non si tratta di una nicchia: e il nuovo standard.
In questo articolo esploreremo i due paradigmi a fondo, analizzeremo gli strumenti che dominano il mercato (dbt, Airbyte, Fivetran), costruiremo un'architettura di riferimento completa e forniremo raccomandazioni pratiche per scegliere lo stack giusto in base alle dimensioni e alle competenze del team.
Cosa Imparerai in Questo Articolo
- Le differenze fondamentali tra ETL tradizionale ed ELT moderno, con pro/contro e casi d'uso
- Come funziona dbt (Data Build Tool): modelli SQL, testing, documentazione, lineage
- dbt Core vs dbt Cloud: quale scegliere e a quale costo
- Airbyte: connettori open-source, architettura e deployment per il self-hosting
- Fivetran: il modello SaaS managed e il nuovo pricing MAR (2025)
- Confronto dettagliato tra i tre strumenti per diversi scenari aziendali
- L'architettura ELT moderna di riferimento: Airbyte/Fivetran + Warehouse + dbt + BI
- Best practices per testing, documentazione e orchestrazione delle pipeline
ETL Tradizionale: Come Funziona e perchè Non Basta Più
Per quasi trent'anni, l'ETL (Extract, Transform, Load) e stato il paradigma dominante per il movimento dei dati aziendali. Il processo si articola in tre fasi sequenziali:
- Extract (Estrazione): I dati vengono estratti dai sistemi sorgente, tipicamente database OLTP (ERP, CRM, e-commerce), file flat (CSV, XML) o API esterne. Questa fase legge i dati senza modificarli.
- Transform (Trasformazione): I dati estratti vengono trasformati in un sistema intermedio, detto staging area o ETL engine, separato sia dalla sorgente che dalla destinazione. Le trasformazioni includono pulizia, normalizzazione, arricchimento, aggregazione e conformazione agli standard del warehouse.
- Load (Caricamento): I dati trasformati vengono caricati nel data warehouse di destinazione. La struttura del dato e già quella finale, ottimizzata per le query analitiche.
Gli Strumenti ETL Tradizionali
| Strumento | Vendor | Costo Indicativo | Target |
|---|---|---|---|
| SSIS | Microsoft | Incluso in SQL Server | PMI con ecosistema Microsoft |
| Informatica PowerCenter | Informatica | $50.000-$500.000/anno | Enterprise banking/insurance |
| Oracle Data Integrator | Oracle | Bundled con Oracle DB | Ecosistema Oracle |
| Talend Open Studio | Qlik | Free (core) / $1.170+/mese | PMI, open source |
| Pentaho Data Integration | Hitachi Vantara | Free (CE) / Custom (EE) | PMI, open source |
Questi strumenti funzionano. Sono stati (e in molti casi sono ancora) il backbone di sistemi critici che movimentano miliardi di euro di transazioni ogni giorno. Ma hanno dei limiti strutturali che il paradigma cloud ha reso sempre più evidenti.
I Limiti Strutturali dell'ETL Classico
perchè l'ETL Tradizionale Fatica nel Contesto Moderno
- Compute esterno costoso: Le trasformazioni avvengono su un server separato (ETL server), che deve essere dimensionato per il picco di carico. Se il batch notturno processa 100 milioni di righe, il server deve essere abbastanza potente da reggere quella finestra temporale, anche se per 22 ore al giorno resta quasi inattivo.
- Rigidita e costo del cambiamento: Aggiungere un campo a una trasformazione SSIS richiede di modificare il flusso visuale, testarlo in staging, coordinare il rilascio con chi gestisce il warehouse di destinazione. In team strutturati, questo richiede settimane.
- Nessun versionamento nativo: I flussi ETL non sono codice testabile e versionabile come il software applicativo. La governance diventa difficile: chi ha modificato questa trasformazione? Quando? perchè?
- Debug complesso: Quando una trasformazione produce risultati inaspettati, tracciare il problema attraverso un flusso ETL visuale può richiedere ore. Non esiste un "data lineage" standard che mostri da dove viene ogni colonna.
- Spreco della potenza del warehouse: Si investe in un Snowflake o un BigQuery da decine di migliaia di euro l'anno per la loro potenza computazionale, ma poi si fa elaborare i dati su un server separato. Il paradigma ELT riconosce che il warehouse stesso e il motore di trasformazione più efficiente.
ELT Moderno: perchè il Cloud ha Cambiato Tutto
L'ELT (Extract, Load, Transform) inverte l'ordine delle ultime due fasi: i dati vengono prima estratti dalle sorgenti e caricati nel warehouse nella loro forma grezza, e solo successivamente trasformati usando la potenza di calcolo del warehouse stesso.
Questo cambio di paradigma e stato reso possibile da tre fattori convergenti:
- Storage cloud economico: Amazon S3, Azure Blob Storage e Google Cloud Storage costano $20-23 per TB al mese. Non ha più senso essere parsimoniosi nello storage: meglio caricare tutto e decidere dopo cosa trasformare.
- Compute elastico: Snowflake, BigQuery, Databricks scalano automaticamente il compute. Una query di trasformazione complessa viene eseguita in secondi sfruttando cluster da centinaia di nodi, pagando solo per il tempo di esecuzione effettivo.
- SQL come linguaggio universale: I data analyst conoscono SQL molto meglio degli strumenti ETL proprietari. Con ELT, le trasformazioni sono semplici query SQL che chiunque nel team può leggere, modificare e revisionare.
Confronto ETL vs ELT: Tabella Decisionale
ETL vs ELT: Confronto Completo
| Dimensione | ETL Tradizionale | ELT Moderno |
|---|---|---|
| Dove avviene la trasformazione | Server ETL dedicato (esterno al warehouse) | Dentro il data warehouse (SQL nativo) |
| Quando trasformare | Prima del caricamento | Dopo il caricamento nel raw layer |
| Volume dati supportato | Limitato dalla capacità dell'ETL server | Scala con il warehouse (potenzialmente illimitato) |
| Dati non strutturati | Difficile o impossibile | Supportato (JSON nativo, semi-structured) |
| Linguaggio | GUI proprietaria / Java / Python | SQL standard (+ Jinja in dbt) |
| Versionamento | Difficile, spesso assente | Git nativo (i modelli sono file .sql) |
| Testing | Manuale o limitato | Framework di test integrato (dbt test) |
| Data lineage | Spesso assente o manuale | Automatico (DAG visuale in dbt) |
| Sicurezza / Compliance | Dati sensibili mai nel warehouse in chiaro | Raw data nel warehouse: serve masking e governance |
| Latenza trasformazione | Dipende dall'ETL server | Dipende dal warehouse (batch o on-demand) |
| Curva di apprendimento | Alta (GUI proprietarie) | Bassa per chi conosce SQL |
| Ideale per | Dati sensibili, sistemi legacy, compliance stretta | Cloud-first, team SQL, elevato volume dati |
Quando Scegliere ETL vs ELT
- Scegli ETL quando: hai requisiti di compliance che vietano di caricare dati grezzi nel cloud (es: PII senza anonimizzazione), lavori con sistemi legacy on-premise dove il warehouse e troppo lontano dalla sorgente, o hai trasformazioni computazionalmente intensive che non beneficiano del warehouse SQL.
- Scegli ELT quando: il tuo warehouse e cloud (Snowflake, BigQuery, Databricks, Redshift), il team ha competenze SQL solide, vuoi versionare le trasformazioni con Git, lavori con volumi di dati crescenti e vuoi sfruttare l'elasticita del cloud.
- Approccio ibrido: Molte aziende adottano un approccio misto: ETL per l'anonimizzazione dei dati sensibili prima del caricamento, ELT per tutte le trasformazioni analitiche successive.
dbt: Il Layer di Trasformazione dello Stack Moderno
dbt (Data Build Tool) e lo strumento che ha definito il paradigma ELT moderno. Creato da dbt Labs nel 2016, dbt trasforma il modo in cui i data analyst scrivono le trasformazioni: invece di procedure SQL sparse senza struttura, dbt introduce un framework di sviluppo ispirato al software engineering, con modelli versionati, test automatici e documentazione generata automaticamente.
Il concetto fondamentale e semplice: ogni modello dbt e un file .sql che contiene una SELECT. dbt si occupa di creare la tabella o la vista nel warehouse, gestire le dipendenze tra modelli e costruire un DAG (Directed Acyclic Graph) delle trasformazioni.
Architettura dbt: Come Funziona
dbt non ha un proprio runtime di calcolo: utilizza il compute del warehouse di destinazione. Funziona come un compilatore SQL + orchestratore: prende i file .sql con le macro Jinja, li compila in SQL puro, e li esegue sul warehouse nell'ordine corretto basandosi sulle dipendenze dichiarate. Il risultato e una serie di tabelle e view nel warehouse, costruite in modo riproducibile.
-- models/staging/stg_orders.sql
-- Modello di staging: pulizia e standardizzazione degli ordini
-- dbt crea una view (o tabella) chiamata 'stg_orders' nel warehouse
WITH source AS (
-- Riferimento alla tabella sorgente raw (caricata da Airbyte/Fivetran)
SELECT * FROM {{ source('erp', 'raw_orders') }}
),
cleaned AS (
SELECT
order_id::BIGINT AS order_id,
customer_id::INT AS customer_id,
product_id::INT AS product_id,
quantity::INT AS quantity,
unit_price::DECIMAL(10, 2) AS unit_price,
COALESCE(discount, 0.0)::DECIMAL(5, 2) AS discount,
CAST(order_date AS TIMESTAMP) AS order_date,
LOWER(TRIM(status)) AS status,
-- Importo netto calcolato
quantity * unit_price * (1 - COALESCE(discount, 0))
AS net_amount,
-- Metadati di audit
_loaded_at AS ingested_at
FROM source
WHERE order_id IS NOT NULL
AND customer_id IS NOT NULL
AND quantity > 0
AND unit_price > 0
)
SELECT * FROM cleaned-- models/marts/finance/fct_orders_monthly.sql
-- Modello fatto: aggregazione mensile per il team finance
-- Dipende da stg_orders e dim_customers (risoluzione automatica dipendenze)
{{ config(
materialized='table',
schema='finance',
tags=['finance', 'monthly']
) }}
WITH orders AS (
SELECT * FROM {{ ref('stg_orders') }}
),
customers AS (
SELECT * FROM {{ ref('dim_customers') }}
),
monthly_metrics AS (
SELECT
DATE_TRUNC('month', o.order_date) AS month,
c.region,
c.segment,
COUNT(DISTINCT o.order_id) AS total_orders,
COUNT(DISTINCT o.customer_id) AS unique_customers,
SUM(o.net_amount) AS gross_revenue,
AVG(o.net_amount) AS avg_order_value,
SUM(o.quantity) AS units_sold
FROM orders o
LEFT JOIN customers c ON o.customer_id = c.customer_id
GROUP BY 1, 2, 3
)
SELECT
*,
gross_revenue / NULLIF(unique_customers, 0) AS revenue_per_customer
FROM monthly_metrics
ORDER BY month DESC, gross_revenue DESCTesting in dbt: Garantire la qualità dei Dati
Uno dei punti di forza più importanti di dbt e il suo sistema di test nativo. I test in dbt
sono dichiarativi: si definiscono in un file YAML e vengono eseguiti automaticamente dopo ogni
run con il comando dbt test.
# models/staging/schema.yml
# Definizione dei test per il modello stg_orders
version: 2
models:
- name: stg_orders
description: >
Ordini puliti e standardizzati dal sistema ERP sorgente.
Caricati ogni ora da Airbyte, trasformati da questo modello.
columns:
- name: order_id
description: "Identificativo univoco dell'ordine (PK)"
tests:
- unique # Nessun duplicato ammesso
- not_null # Ogni riga deve avere un order_id
- name: customer_id
description: "Riferimento alla dimensione clienti"
tests:
- not_null
- relationships: # Referential integrity check
to: ref('dim_customers')
field: customer_id
- name: status
description: "Stato dell'ordine"
tests:
- accepted_values:
values: ['pending', 'confirmed', 'shipped', 'delivered', 'cancelled']
- name: net_amount
description: "Importo netto dell'ordine (quantità * prezzo * (1 - sconto))"
tests:
- not_null
- dbt_utils.expression_is_true:
expression: "net_amount >= 0"
- name: order_date
description: "Data e ora dell'ordine"
tests:
- not_null
- dbt_utils.expression_is_true:
expression: "order_date <= CURRENT_TIMESTAMP"
- name: fct_orders_monthly
description: "Aggregazioni mensili per il reporting finance"
columns:
- name: month
tests:
- not_null
- name: gross_revenue
tests:
- not_null
- dbt_utils.expression_is_true:
expression: "gross_revenue >= 0"
sources:
- name: erp
description: "Dati grezzi caricati dall'ERP tramite Airbyte"
schema: raw_erp
tables:
- name: raw_orders
loaded_at_field: _loaded_at
freshness:
warn_after: {count: 12, period: hour}
error_after: {count: 24, period: hour}dbt Core vs dbt Cloud
dbt esiste in due varianti: dbt Core (open-source, gratuito) e dbt Cloud (SaaS managed, a pagamento). La scelta dipende dalle esigenze del team in termini di infrastruttura e funzionalità avanzate.
dbt Core vs dbt Cloud: Confronto Completo
| Funzionalità | dbt Core (Open Source) | dbt Cloud Team | dbt Cloud Enterprise |
|---|---|---|---|
| Costo | Gratuito | $100/seat/mese + $0.01 per modello oltre 15.000 | Custom (contatta sales) |
| Esecuzione job | Manuale / Orchestratore esterno (Airflow, Dagster) | Scheduler nativo, CI/CD integrato | Scheduler avanzato + SLA monitoring |
| IDE web | No (solo editor locale) | dbt Cloud IDE (browser-based) | dbt Cloud IDE |
| Documentazione | Generata localmente (dbt docs generate) | Hosted automaticamente | Hosted + Data Catalog avanzato |
| Lineage visuale | Locale | Cloud hosted, condivisibile | Cloud hosted + Cross-project lineage |
| Collaborazione team | Tramite Git (manuale) | Multi-user, PR-based workflow | RBAC, SSO, audit logs |
| Semantic Layer | No | Incluso (5.000 metriche/mese) | Incluso (20.000 metriche/mese) |
| dbt Mesh | No | Limitato | Completo (cross-project refs) |
| SOC 2 compliance | N/A (self-managed) | Incluso | Incluso + PrivateLink |
| Ideale per | Team tecnici, budget limitato, già hanno Airflow | Team 2-20 persone senza infrastruttura ETL | Enterprise, multi-team, compliance stretta |
La raccomandazione pratica: le PMI italiane con un team di 1-3 data engineers dovrebbero iniziare con dbt Core + Airflow o Dagster, che offre piena flessibilità a costo zero. Se il team cresce o si vuole evitare la gestione dell'infrastruttura di orchestrazione, dbt Cloud diventa conveniente già con 2-3 developer seat.
Airbyte: Il Layer di Ingestione Open-Source
Se dbt si occupa della T (trasformazione) nell'ELT, Airbyte gestisce la E (estrazione) e la L (caricamento). Fondato nel 2020 e oggi con oltre $180 milioni di funding, Airbyte e la piattaforma di integrazione dati open-source più adottata del mercato, con 600+ connettori pre-built e un SDK Python per costruire connettori custom.
Il punto di forza principale di Airbyte rispetto ai concorrenti e la combinazione di open-source (zero vendor lock-in, codice modificabile) con un'architettura cloud-native che supporta Change Data Capture (CDC) per la replica in tempo reale dei database.
Architettura di Airbyte
Airbyte e composto da diversi componenti che lavorano in tandem. Ogni sincronizzazione viene eseguita da un Worker che istanzia due container Docker separati: il Source Connector (che legge dalla sorgente) e il Destination Connector (che scrive nella destinazione). I dati fluiscono tra i due attraverso lo Airbyte Protocol, un formato standard JSON.
# Esempio: Configurazione connettore Airbyte via API (YAML/JSON)
# Creazione di una connessione PostgreSQL -> Snowflake
# 1. Configurazione Source (PostgreSQL)
POST /api/v1/sources/create
{
"sourceDefinitionId": "decd338e-5647-4c0b-adf4-da0e75f5a750",
"connectionConfiguration": {
"host": "db.produzione.miazienda.it",
"port": 5432,
"database": "erp_production",
"username": "airbyte_reader",
"password": "{{ secrets.POSTGRES_PASSWORD }}",
"schemas": ["public", "orders"],
"replication_method": {
"method": "CDC",
"replication_slot": "airbyte_slot",
"publication": "airbyte_publication"
}
},
"name": "ERP Production PostgreSQL",
"workspaceId": "workspace-uuid"
}
# 2. Configurazione Destination (Snowflake)
POST /api/v1/destinations/create
{
"destinationDefinitionId": "424892c4-daac-4491-b35d-c6688ba547ba",
"connectionConfiguration": {
"host": "abc12345.eu-west-1.snowflakecomputing.com",
"role": "AIRBYTE_ROLE",
"warehouse": "AIRBYTE_WH",
"database": "RAW_DATA",
"schema": "erp",
"username": "airbyte_user",
"credentials": {
"auth_type": "key_pair",
"private_key": "{{ secrets.SNOWFLAKE_PRIVATE_KEY }}"
}
},
"name": "Snowflake Production",
"workspaceId": "workspace-uuid"
}
# 3. Creazione della connessione
POST /api/v1/connections/create
{
"sourceId": "source-uuid",
"destinationId": "destination-uuid",
"syncCatalog": {
"streams": [
{
"stream": {"name": "orders", "namespace": "public"},
"config": {
"syncMode": "incremental",
"destinationSyncMode": "append_dedup",
"cursorField": ["updated_at"],
"primaryKey": [["order_id"]]
}
},
{
"stream": {"name": "customers", "namespace": "public"},
"config": {
"syncMode": "full_refresh",
"destinationSyncMode": "overwrite"
}
}
]
},
"scheduleType": "cron",
"scheduleData": {"cron": {"cronExpression": "0 */1 * * *", "cronTimeZone": "Europe/Rome"}},
"namespaceDefinition": "customformat",
"namespaceFormat": "raw_{{SOURCE_NAMESPACE}}"
}Airbyte: Deploy Options
Airbyte offre tre modalità di deployment, ciascuna con caratteristiche diverse in termini di costo, controllo e manutenzione:
Airbyte: Open Source vs Cloud vs Enterprise
| Aspetto | Open Source (Self-hosted) | Airbyte Cloud | Airbyte Enterprise |
|---|---|---|---|
| Costo | Gratuito (infrastruttura a carico tuo) | Pay-per-use ($2.50-$10 per credito) | Custom (contatta sales) |
| Manutenzione | A carico del team | Gestita da Airbyte | Gestita da Airbyte |
| Connettori | 600+ | 600+ | 600+ + connettori certificati premium |
| CDC | Supportato | Supportato | Supportato + CDC avanzato |
| RBAC | Basico | Incluso | Avanzato (SSO, audit logs) |
| SLA | N/A | 99.9% uptime | 99.99% uptime |
| Ideale per | Team tecnici, budget limitato, dati sensibili | PMI che vogliono velocità senza ops | Enterprise con compliance stretta |
# Deploy Airbyte Open Source con Docker Compose
# Prerequisiti: Docker, Docker Compose, 8GB RAM, 20GB disk
# 1. Clona il repository
git clone --depth=1 https://github.com/airbytehq/airbyte.git
cd airbyte
# 2. Avvia Airbyte (prima esecuzione: ~15 minuti per download immagini)
./run-ab-platform.sh
# Airbyte e accessibile su http://localhost:8000
# Username: airbyte / Password: password (da cambiare in produzione!)
# 3. Per deployment in produzione su Kubernetes con Helm
helm repo add airbyte https://airbytehq.github.io/helm-charts
helm install airbyte airbyte/airbyte \
--namespace airbyte \
--create-namespace \
--set global.state.storage.type=MINIO \
--set global.storage.bucket.log=airbyte-logs \
--values custom-values.yaml
# 4. Configurazione variabili di ambiente per produzione (.env)
# DATABASE_URL=postgresql://airbyte:password@postgres:5432/airbyte
# SECRET_PERSISTENCE=GOOGLE_SECRET_MANAGER
# LOG_LEVEL=INFO
# TRACKING_STRATEGY=segmentFivetran: La Semplicita del SaaS Managed
Mentre Airbyte punta sulla flessibilità e il controllo open-source, Fivetran ha scelto la strada opposta: massima semplicità, zero manutenzione, connettori enterprise-grade gestiti completamente dal vendor. Fondato nel 2012, Fivetran e oggi il leader del segmento ELT managed con $300 milioni di ARR, 6.300+ clienti e una valutazione di $5.6 miliardi.
Il value proposition di Fivetran e chiaro: un connettore Fivetran verso Salesforce, Shopify o qualsiasi altro sistema SaaS viene mantenuto da un team dedicato di ingegneri Fivetran che gestiscono ogni cambiamento dell'API sorgente, ogni breaking change, ogni aggiornamento di schema. Il cliente non deve fare nulla.
Il Nuovo Modello di Pricing Fivetran 2025
A marzo 2025, Fivetran ha aggiornato significativamente il proprio modello di pricing. I piani Starter e Private Deployment sono stati eliminati e sostituiti con quattro tier: Free, Standard, Enterprise e Business Critical. La metrica di fatturazione rimane il MAR (Monthly Active Rows), ma il calcolo e cambiato: ora ogni connessione viene fatturata separatamente, non più aggregata per account.
Fivetran: Piani e Prezzi 2025
| Piano | MAR inclusi | Costo aggiuntivo | Features chiave |
|---|---|---|---|
| Free | 500.000 MAR/mese | N/A | Tutte le features Standard, fino a 5.000 model runs |
| Standard | Illimitati (pay-per-use) | $5 base/connessione + MAR pricing | 600+ connettori, CDC, dbt integration, scheduling |
| Enterprise | Negoziabile | Custom (sconto volume) | SSO/SAML, RBAC, VPN, priority support, SLA |
| Business Critical | Negoziabile | Custom | PrivateLink, HIPAA compliance, dedicated support, 99.99% SLA |
Come Funziona il Calcolo MAR in Fivetran
Il MAR (Monthly Active Row) conta le righe distinte sincronizzate in un mese di calendario, tracciate tramite primary key. Una riga modificata 30 volte in un mese conta come 1 MAR, non come 30. Il vantaggio: il costo non esplode con la frequenza di sincronizzazione, ma con il numero di record unici che cambiano.
Esempio pratico: Un'azienda con 50.000 ordini attivi al mese e 500.000 prodotti nel catalogo (aggiornati raramente) paga principalmente per i 50.000 ordini che cambiano stato ogni mese, non per l'intero catalogo prodotti.
dbt vs Airbyte vs Fivetran: Quale Scegliere?
E importante capire che dbt, Airbyte e Fivetran non sono strumenti alternativi che si escludono a vicenda: risolvono problemi diversi all'interno dello stesso stack. dbt si occupa delle trasformazioni, Airbyte e Fivetran si occupano dell'ingestione. La domanda corretta e: Airbyte vs Fivetran per l'ingestione?
Airbyte vs Fivetran: Confronto per Scenari
| Dimensione | Airbyte Open Source | Airbyte Cloud | Fivetran Standard |
|---|---|---|---|
| Costo base | $0 (infrastruttura a parte) | Pay-per-use | $5/connessione/mese + MAR |
| Connettori | 600+ (community maintained) | 600+ | 650+ (enterprise-grade) |
| Manutenzione connettori | Community / team interno | Airbyte team | Fivetran team (SLA garantito) |
| CDC | Supportato (Debezium) | Supportato | Supportato (log-based) |
| Connettori custom | SDK Python (free) | SDK Python | Custom connector SDK (a pagamento) |
| Data residency | Completa (self-hosted) | Region-specific | Region-specific |
| Setup time | 1-4 ore (infrastruttura) | 30 minuti | 15 minuti |
| dbt integration | Manuale / Airflow | Nativa | Nativa (dbt Cloud) |
| Ideale per | Team tecnici, sorgenti custom, GDPR locale | PMI tech-savvy, budget variabile | PMI/Enterprise con sorgenti SaaS standard |
Regola Pratica per la Scelta
- Usa Fivetran se le tue sorgenti sono SaaS standard (Salesforce, HubSpot, Shopify, Stripe, Google Analytics, Facebook Ads) e il team non vuole occuparsi di manutenzione dei connettori. La produttività guadagnata vale il costo.
- Usa Airbyte Cloud se hai un mix di sorgenti standard e custom, o se stai iniziando e vuoi controllare i costi con pay-per-use.
- Usa Airbyte Open Source se hai requisiti GDPR/data residency che impediscono il transito dei dati attraverso infrastrutture di terze parti, o se hai sorgenti altamente custom che richiedono connettori scritti internamente.
Architettura ELT Moderna di Riferimento
Unendo tutti i componenti, ecco l'architettura ELT moderna che le aziende leader adottano oggi. Ogni livello dello stack ha uno scopo preciso e degli strumenti di riferimento.
Lo Stack ELT Moderno: Layer per Layer
| Layer | Funzione | Strumenti Principali |
|---|---|---|
| 1. Ingestione | Estrarre e caricare dati grezzi nel warehouse | Fivetran, Airbyte, Stitch, custom scripts |
| 2. Storage (Raw) | Dati grezzi non modificati (Bronze layer) | Snowflake, BigQuery, Databricks, Redshift |
| 3. Trasformazione | Modelli SQL, testing, documentazione, lineage | dbt Core, dbt Cloud |
| 4. Serving (Gold) | Tabelle ottimizzate per analytics e ML | Snowflake, BigQuery, Databricks (warehouse) |
| 5. Orchestrazione | Scheduling, dipendenze, monitoring pipeline | Airflow, Dagster, Prefect, dbt Cloud |
| 6. BI e Reporting | Dashboard, query ad hoc, self-service analytics | Looker, Metabase, Power BI, Tableau |
| 7. Data Quality | Monitoring, alerting, anomaly detection | dbt tests, Great Expectations, Monte Carlo |
# Esempio: Pipeline ELT completa orchestrata con Dagster
# Dagster definisce i job come grafo di asset
from dagster import asset, AssetIn, define_asset_job, ScheduleDefinition
# Asset 1: Raw data (caricato da Fivetran/Airbyte - esterno a Dagster)
# Dagster può "osservare" le tabelle caricate da Fivetran come asset esterni
@asset(
group_name="raw",
description="Ordini grezzi caricati da Fivetran (ERP)"
)
def raw_orders():
# Fivetran scrive qui automaticamente ogni ora
# Questo asset "dichiara" la tabella per il lineage visuale
pass
# Asset 2: dbt staging (trasformazione con dbt)
@asset(
group_name="staging",
deps=["raw_orders"],
description="Ordini puliti e standardizzati (modello dbt stg_orders)"
)
def stg_orders(context):
# Esegue il modello dbt stg_orders
context.log.info("Running dbt model: stg_orders")
# In pratica: dbt_cloud_run_op o subprocess dbt run --select stg_orders
return {"rows_processed": 15000}
# Asset 3: dbt marts (modello gold pronto per il business)
@asset(
group_name="marts",
ins={"staging": AssetIn("stg_orders")},
description="Fatturato mensile per il reporting finance"
)
def fct_orders_monthly(context, staging):
context.log.info(f"Building monthly metrics from {staging['rows_processed']} rows")
# dbt run --select fct_orders_monthly
return {"mart_rows": 360} # 30 giorni * 12 segmenti regionali
# Scheduling: esegue ogni ora, aggiorna tutti gli asset
elt_pipeline_job = define_asset_job(
name="elt_pipeline",
selection=["stg_orders", "fct_orders_monthly"]
)
elt_schedule = ScheduleDefinition(
job=elt_pipeline_job,
cron_schedule="0 * * * *", # Ogni ora
execution_timezone="Europe/Rome"
)Best Practices per Pipeline Dati Affidabili
Costruire una pipeline ELT che funziona in demo e semplice. Costruire una pipeline che scala, e monitorabile, e mantenibile da un team nel tempo richiede disciplina e l'applicazione di pratiche ingegneristiche consolidate.
1. Stratificazione e Naming Convention
Adotta una struttura di directory dbt chiara e consistente che rispecchi l'architettura a livelli (Medallion o equivalente):
# Struttura di progetto dbt raccomandata
dbt_project/
├── models/
│ ├── staging/ # Layer Silver: pulizia sorgenti
│ │ ├── erp/
│ │ │ ├── stg_orders.sql
│ │ │ ├── stg_customers.sql
│ │ │ └── schema.yml # Test + documentazione
│ │ ├── crm/
│ │ │ ├── stg_contacts.sql
│ │ │ └── schema.yml
│ │ └── ecommerce/
│ │ ├── stg_sessions.sql
│ │ └── schema.yml
│ ├── intermediate/ # Modelli intermedi (join complesse)
│ │ ├── int_customer_orders.sql
│ │ └── schema.yml
│ └── marts/ # Layer Gold: pronti per il business
│ ├── finance/
│ │ ├── fct_orders_monthly.sql
│ │ ├── fct_revenue_by_product.sql
│ │ └── schema.yml
│ ├── marketing/
│ │ ├── fct_campaign_performance.sql
│ │ └── schema.yml
│ └── operations/
│ ├── fct_fulfillment_kpis.sql
│ └── schema.yml
├── seeds/ # Dati statici (tabelle di lookup, mapping)
│ ├── country_codes.csv
│ └── product_categories.csv
├── snapshots/ # SCD Type 2 (Slowly Changing Dimensions)
│ └── snap_customers.sql
├── tests/ # Test custom SQL
│ └── assert_revenue_positive.sql
├── macros/ # Macro Jinja riutilizzabili
│ ├── generate_schema_name.sql
│ └── audit_columns.sql
└── dbt_project.yml # Configurazione globale2. Testing Come Contratto di qualità
I test dbt non sono opzionali: sono il contratto che garantisce che le trasformazioni producano dati affidabili. Ogni modello dovrebbe avere almeno questi test:
- unique + not_null sulla primary key: Garantisce l'integrità di ogni modello.
- relationships: Verifica l'integrità referenziale tra modelli.
- accepted_values: Controlla che i campi categoriali contengano solo valori validi.
- freshness su source: Avvisa se i dati non vengono aggiornati nei tempi previsti.
- dbt_utils.expression_is_true: Per vincoli business-specifici (es: revenue >= 0).
3. Versioning e CI/CD per le Pipeline Dati
# .github/workflows/dbt-ci.yml
# CI/CD per validare i modelli dbt a ogni PR
name: dbt CI Pipeline
on:
pull_request:
branches: [main]
paths:
- 'dbt_project/**'
jobs:
dbt-lint-and-test:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Setup Python
uses: actions/setup-python@v4
with:
python-version: '3.11'
- name: Install dbt
run: |
pip install dbt-snowflake==1.8.0
pip install sqlfluff==3.0.0
- name: dbt debug (connection test)
run: dbt debug
env:
DBT_SNOWFLAKE_ACCOUNT: {{ secrets.SNOWFLAKE_ACCOUNT }}
DBT_SNOWFLAKE_USER: {{ secrets.SNOWFLAKE_USER }}
DBT_SNOWFLAKE_PASSWORD: {{ secrets.SNOWFLAKE_PASSWORD }}
DBT_SNOWFLAKE_DATABASE: DBT_CI_DB
DBT_SNOWFLAKE_SCHEMA: CI_{{ github.event.pull_request.number }}
- name: sqlfluff lint (SQL style check)
run: sqlfluff lint models/ --dialect snowflake
- name: dbt compile (syntax check)
run: dbt compile
- name: dbt run (solo modelli modificati)
run: dbt run --select state:modified+
env:
DBT_DEFER_TO_PROD: true
- name: dbt test (test sui modelli modificati)
run: dbt test --select state:modified+
- name: dbt docs generate
run: dbt docs generate
- name: Cleanup CI schema
if: always()
run: dbt run-operation drop_schema --args '{"schema": "CI_{{ github.event.pull_request.number }}"}'4. Data Freshness Monitoring
Una pipeline ELT rotta che nessuno sa essere rotta e peggio di non avere la pipeline. Il monitoring proattivo della freshness dei dati deve essere parte integrante dello stack:
Anti-Pattern da Evitare nelle Pipeline ELT
- Modelli senza test: Un modello dbt senza almeno un test unique + not_null e una time bomb. Prima o poi produrra dati duplicati o null che invalideranno i report.
- Assenza di schema.yml: senza documentazione, i modelli diventano incomprensibili per chiunque non li abbia scritti, incluso il loro autore dopo 6 mesi.
- Full refresh sempre: Ricaricare sempre l'intera tabella anziché fare append/upsert incrementale e costoso e fragile per dataset grandi.
- Logica di business nel layer staging: Lo staging deve solo pulire e standardizzare. Aggregazioni e logica business vanno nei marts. Mescolare i livelli crea dipendenze difficili da gestire.
- Ignorare la data lineage: Quando un report mostra un numero sbagliato, senza lineage documentata tracciare il problema richiede ore. Con dbt docs, si arriva alla sorgente in pochi click.
- Nessun alerting su freshness: Se Fivetran smette di sincronizzare di notte e nessuno lo monitora, i report del mattino mostreranno dati di ieri senza alcun warning visibile agli utenti business.
Raccomandazioni per le PMI Italiane
Il landscape delle pipeline dati può sembrare sopraffacente per una PMI italiana con risorse limitate e team piccoli. La buona notizia e che non serve adottare tutto lo stack in una volta. Ecco un percorso progressivo in tre fasi:
Percorso di Adozione per PMI (3 Fasi)
| Fase | Timeline | Stack Consigliato | Costo Mensile Indicativo |
|---|---|---|---|
| Fase 1: Fondamenta | Mese 1-3 | Fivetran Free + BigQuery sandbox + dbt Core | €0 - €200 |
| Fase 2: Produzione | Mese 4-9 | Fivetran Standard + Snowflake/BigQuery + dbt Core + Airflow managed | €800 - €3.000 |
| Fase 3: Scale | Mese 10+ | Fivetran Enterprise + Snowflake + dbt Cloud + Dagster Cloud | €3.000 - €15.000 |
Fase 1 - Fondamenta: Inizia con il piano free di Fivetran (500.000 MAR/mese) per connettere 2-3 sorgenti critiche (ERP, CRM, e-commerce). Usa BigQuery nella versione sandbox (gratuita fino a 10 GB storage + 1 TB query/mese). Installa dbt Core localmente e scrivi i primi 10-15 modelli. L'obiettivo e imparare i pattern e dimostrare valore al business senza investimento iniziale.
Fase 2 - Produzione: Quando il PoC ha dimostrato valore, scala a Fivetran Standard per gestire più connettori, passa a un warehouse cloud con SLA (Snowflake o BigQuery production) e aggiungi orchestrazione con Airflow managed (Cloud Composer su GCP o MWAA su AWS). Il costo mensile e contenuto e l'impatto sul business e misurabile.
Fase 3 - Scale: Quando il team dati cresce a 3-5 persone, vale la pena aggiungere dbt Cloud per l'IDE collaborativo e il CI/CD automatico, e Dagster Cloud per un'orchestrazione più sofisticata con observability. A questo punto la pipeline diventa un asset strategico aziendale gestito con standard engineering professionali.
Conclusioni e Prossimi Passi
L'evoluzione da ETL a ELT non e semplicemente un cambio di ordine delle lettere: e una trasformazione fondamentale nel modo di progettare, sviluppare e mantenere le pipeline dati aziendali. Il cloud ha reso il compute elastico e conveniente, rendendo obsoleto il modello di trasformazione pre-caricamento su server dedicati.
Lo stack moderno dbt + Airbyte/Fivetran + warehouse cloud rappresenta lo stato dell'arte del 2025 ed e adottato da migliaia di aziende, dalle startup alle Fortune 500. I vantaggi concreti sono misurabili: pipeline versionabili come codice, test automatici che garantiscono la qualità dei dati, documentazione e lineage generati automaticamente, e costi scalabili che crescono con il business invece di richiedere investimenti upfront.
Punti Chiave da Ricordare
- ETL non e morto: ha ancora senso per dati sensibili che non devono transitare in chiaro nel cloud o per sorgenti legacy on-premise con bassa latenza richiesta.
- ELT e il nuovo standard per architetture cloud-first: carica tutto grezzo, trasforma dove hai più potenza (il warehouse).
- dbt e il layer di trasformazione: porta software engineering best practices (versionamento, test, documentazione) al mondo SQL.
- Airbyte e la scelta open-source per team tecnici con sorgenti custom o requisiti GDPR di data residency.
- Fivetran e la scelta managed per chi vuole zero manutenzione sui connettori verso sorgenti SaaS standard (Salesforce, HubSpot, Shopify, ecc.).
- Per le PMI italiane: inizia con Fivetran Free + BigQuery + dbt Core per validare il valore prima di investire nell'infrastruttura completa.
Il prossimo articolo della serie approfondisce l'orchestrazione delle pipeline: Airflow, Dagster e Prefect a confronto. Se dbt e il motore di trasformazione e Airbyte/Fivetran sono il sistema di ingestione, l'orchestratore e il cervello che coordina tutto: chi esegue cosa, quando, in quale ordine, e cosa fare quando qualcosa va storto. Un componente critico che merita una trattazione dedicata.
Esercizio Pratico: Setup dbt Core in 30 Minuti
Prima di passare all'articolo successivo, prova a configurare dbt Core su un warehouse esistente (anche BigQuery sandbox gratuito):
# 1. Installa dbt con il profilo per il tuo warehouse
pip install dbt-bigquery # per BigQuery
# oppure: pip install dbt-snowflake, dbt-redshift, dbt-duckdb
# 2. Crea un nuovo progetto dbt
dbt init mio_progetto_dbt
# 3. Configura il profilo (~/.dbt/profiles.yml per BigQuery)
# mio_progetto_dbt:
# target: dev
# outputs:
# dev:
# type: bigquery
# method: oauth
# project: mio-progetto-gcp
# dataset: dbt_dev
# threads: 4
# timeout_seconds: 300
# 4. Testa la connessione
cd mio_progetto_dbt
dbt debug
# 5. Crea il tuo primo modello
cat > models/staging/stg_example.sql << 'EOF'
SELECT
id,
name,
created_at,
UPPER(TRIM(email)) AS email_normalized
FROM {{ source('raw', 'users') }}
WHERE id IS NOT NULL
EOF
# 6. Esegui e testa
dbt run
dbt test
dbt docs generate
dbt docs serve # Apre il lineage visuale su http://localhost:8080