Benvenuto al Modulo 5. Il Modulo 4 ci ha lasciato con un insieme di database ben replicati, ben partizionati, ben shardati, e un caso di studio su Discord che mostra che aspetto hanno quelle astrazioni alla scala vera. Lo storage è il pavimento. Adesso dobbiamo parlare di cosa ci scorre sopra.
Il Modulo 5 copre il batch processing: la famiglia di job che leggono un input finito (e di solito grande), ci fanno del lavoro sopra, e scrivono un output finito, senza la pretesa di terminare in millisecondi. Il job parte, finisce, e si ferma. Aggregati orari, report giornalieri, dati di training per machine learning, le colonne che la dashboard di BI legge alle 7 del mattino: tutto questo è batch. Il duale del batch è lo stream processing, che il Modulo 6 copre. Per ora i dati sono fermi, e il job ha tempo per pensare.
Si parte dalla domanda che organizza ogni batch pipeline mai scritta: dove vive lo step di trasformazione? Nel 1995 la risposta era diversa da quella del 2026, e lo spostamento tra le due risposte è il modo più pulito per capire perché il modern data stack ha la forma che ha.
I due ordini di lettere
Una batch pipeline che muove dati da un sistema di origine a uno store analitico ha tre step. Si extractano i record dalla sorgente (un database transazionale, una API SaaS, un CSV che atterra in una cartella FTP, uno stream di log archiviato su disco). Si transformano: pulizia dei null, deduplicazione, parsing delle date, join con dati di riferimento, calcolo di colonne derivate, conformazione a uno schema di destinazione. E si fa il load del risultato nella destinazione analitica, che è quasi sempre un data warehouse.
I due ordini di lettere che danno il nome alle pipeline riguardano dove avviene il transform.
ETL sta per extract, transform, load. Lo step di transform gira in un layer di compute separato tra la sorgente e il warehouse: un server ETL dedicato, un cluster Spark, una flotta di worker Python. I dati lasciano la sorgente, vengono rimodellati in volo, e arrivano al warehouse già nella loro forma analitica. Il warehouse memorizza solo l’output pulito, conformato, pronto per le query.
ELT sta per extract, load, transform. Lo step di transform gira dentro il warehouse, su dati che ci sono già atterrati in qualcosa di simile alla loro forma raw. I dati lasciano la sorgente, vengono scaricati nel warehouse con il minimo di processing, e il transform avviene come una sequenza di statement SQL che leggono tabelle raw e ne scrivono altre derivate.
Le pipeline sembrano quasi identiche viste da lontano. Le stesse tre scatole, le stesse tre frecce. La posizione di una sola scatola è tutta la storia di come il data stack si è ricostruito tra il 2015 e il 2025.
flowchart LR
subgraph ETL[ETL]
S1[(Source)] --> T1[Transform layer<br/>Informatica, Talend, Spark]
T1 --> W1[(Warehouse<br/>cleaned only)]
end
subgraph ELT[ELT]
S2[(Source)] --> W2[(Warehouse<br/>raw + derived)]
W2 --> T2[Transform in-warehouse<br/>dbt, SQL]
T2 --> W2
endL’era dell’ETL
Per tutti gli anni ‘90 e 2000, ETL non era una scelta. Era l’unica architettura che aveva un senso economico, e il motivo era il warehouse.
I warehouse dominanti di quell’epoca erano Teradata, Oracle, e le edizioni data-warehouse di SQL Server, con IBM Db2 in qualche shop. Erano venduti come appliance o come software con licenze costose, dimensionati per un workload fisso, con storage e compute accoppiati in un’unica scatola. Aggiungere capacità significava comprare un’appliance più grande, che significava un ciclo di procurement misurato in trimestri. Il compute del warehouse era la risorsa più scarsa nel building, ed era riservata alle query che il business eseguiva davvero.
Caricare dati raw in quel warehouse e poi farci girare contro le query di pulizia sarebbe stato un atto di vandalismo. Le query di pulizia avrebbero competuto con le query degli analisti per gli stessi core costosi, i dati raw avrebbero mangiato gli stessi dischi costosi che il business si aspettava avrebbero ospitato i modelli dimensionali, e l’appliance sarebbe stata dimensionata per il workload sbagliato entro un anno. Quindi i dati si pulivano da qualche altra parte.
Quel “qualche altra parte” era il tier ETL. Informatica PowerCenter (ancora il più grande vendor ETL per fatturato quando è tornato privato nel 2023), IBM DataStage, Microsoft SSIS, e Talend hanno definito la categoria. Sotto la GUI, un job ETL era un grafo di operatori, ognuno che leggeva righe da monte, faceva del lavoro, e spingeva righe a valle, con l’operatore finale che scriveva nel warehouse. Molti shop bypassavano del tutto i vendor e scrivevano i job ETL come script Python o di shell guidati da cron, che tiravano dalle sorgenti, trasformavano in pandas o PL/SQL, e inserivano il risultato.
La proprietà architetturale dell’era ETL è che il warehouse vede solo dati puliti, mai altro. Le righe raw del sistema di origine non ci atterrano mai. Se una regola di trasformazione era sbagliata, si fixava la regola nel layer ETL e si rieseguiva il job, il che significava ri-extractare dalla sorgente. Non c’era nessun layer “raw” su cui ripiegare.
Cosa è cambiato
I cloud warehouse hanno cambiato l’economia, e l’ordine delle operazioni è andato dietro.
Snowflake (general availability 2014), BigQuery (pubblico 2012), e Redshift (2013) hanno spostato i warehouse a un modello di separation-of-storage-and-compute che gira su object storage e compute on-demand. Lo storage è diventato economico (centesimi per gigabyte al mese, su commodity object store sotto il cofano). Il compute è diventato elastico (avvii un warehouse per una query, lo spegni quando è idle). Aggiungere capacità ha smesso di essere un ciclo di procurement ed è diventato un’impostazione in un file di config. Databricks SQL (2021) ha portato lo stesso modello sul lato lakehouse del mondo.
Una volta che il compute del warehouse è diventato economico ed elastico, l’argomento per tenere i dati raw fuori è evaporato. Si poteva atterrare tutto, conservarlo per sempre per pochi spiccioli, e far girare le query di pulizia sullo stesso engine che faceva girare le query di BI. La trasformazione ha smesso di essere uno step di pre-processing esterno ed è diventata una sequenza di statement SQL che vivevano accanto al resto del codice analitico.
Il tooling si è riorganizzato attorno alla nuova forma. Il modern ELT stack ha tre layer.
Extract e load. Fivetran, Airbyte, Stitch, e Meltano dominano il business dei managed connector. Si occupano della parte brutta dell’integrazione: le stranezze delle API SaaS, lo schema drift, la logica di pull incrementale, la rotazione delle credenziali. L’output sono tabelle raw nel warehouse che assomigliano alla sorgente quanto è ragionevole. Molti team integrano i managed connector con ingestion Python custom per la coda lunga dei sistemi interni, che atterra nello stesso layer raw.
Warehouse. Snowflake, BigQuery, Redshift, Databricks SQL. Lo stesso engine memorizza i dati raw, fa girare le trasformazioni, e serve il tool di BI. Non c’è un compute tier separato per i transform.
Transform. dbt è il tool dominante del modern data stack nel 2026. Un progetto dbt è una directory di file SQL. Ogni file è uno statement select che definisce un model. dbt compila il progetto in un grafo di dipendenze e fa girare i model in ordine, materializzando ognuno come tabella o view nel warehouse. Versionato in git, testato con assertion, documentato in automatico, eseguito da CI. La logica di trasformazione smette di essere una black box dentro un tool ETL e diventa un repository di codice che il data team possiede nello stesso modo in cui il team applicativo possiede i suoi servizi.
Perché ELT vince nella maggior parte dei casi
Si sommano un po’ di motivi.
Il layer raw è preservato. Una volta che i dati atterrano nel warehouse in qualcosa di simile alla loro forma sorgente, si può ri-derivare qualunque cosa a valle. Una nuova definizione di metrica non richiede una ri-extract; si scrive un nuovo SQL model. Un bug in una trasformazione storica si può fixare e i model affetti si possono ricostruire senza tornare alla sorgente. Il layer raw è la single source of truth, e il sistema di origine non è più nel loop per le domande analitiche.
Le trasformazioni vivono in SQL. Le persone che conoscono le domande di business sono di solito gli analisti, e gli analisti sanno SQL. ELT mette il codice di trasformazione nel linguaggio che la gente più vicina ai dati già parla, invece di farlo passare per un tool ETL separato che richiede uno skill set separato.
Lo stesso warehouse serve la dashboard e il transform. Operativamente si ha un sistema da scalare, un sistema da monitorare, un sistema di cui fare backup. Le trasformazioni e le query di BI condividono un workload manager e un modello di access control. I tool di lineage (i docs di dbt, più i nuovi entranti come Atlan, OpenMetadata, e Datafold) possono tracciare una colonna su una dashboard a ritroso attraverso ogni model che l’ha prodotta, perché sono tutte query contro lo stesso engine.
Il costo è per lo più storage, che è economico. L’intuizione economica si è ribaltata: tenere i dati raw è quasi gratis, e le trasformazioni girano solo quando qualcosa ha bisogno di essere refreshato. Il compute si paga al secondo sulle query che girano davvero, non con un’appliance statica che sta idle tre notti a settimana.
Quando ETL è ancora la scelta giusta
ELT è il default nel 2026, ma i casi in cui il transform appartiene a monte sono reali.
I dati di origine sono sensibili. Se l’input contiene dati personali che il warehouse non è autorizzato a tenere (campi specifici di health record, numeri di pagamento raw, certi identificatori sotto scope GDPR, HIPAA, o PCI), non si possono atterrare i dati raw e poi pulirli. I dati devono essere filtrati, anonimizzati, o tokenizzati prima di lasciare l’ambiente di origine. Quella è una pipeline ETL per necessità, anche se il resto dello stack è ELT.
Il volume è così grande che il compute del warehouse è troppo costoso. I cloud warehouse sono economici per query, ma un ingest a scala petabyte con processing pesante per riga può ancora costare di più in warehouse credit che far girare lo stesso transform su un cluster Spark contro object storage raw. Il pattern lakehouse (lezione 37 del Modulo 5) affronta questo spostando i transform su compute economico contro open table format, ma il principio è lo stesso: quando il compute del warehouse è il collo di bottiglia, il lavoro pesante si fa altrove.
Il transform richiede qualcosa che il warehouse non sa fare. Image processing, trascrizione audio, ML inference, chiamate ad API esterne per arricchire le righe: gli engine SQL del warehouse non li gestiscono bene, se proprio li gestiscono. La trasformazione vive in un tier Spark o Python a monte, e nel warehouse atterra solo il risultato.
La sorgente non può permettersi di mandare dati raw. Una flotta IoT che genera terabyte di letture di sensori all’ora di solito non può permettersi la banda per spedire raw nel cloud. L’aggregazione edge riduce il volume prima che lasci il device, che è ETL con un altro nome.
L’ibrido è la realtà comune. Il grosso delle pipeline è ELT verso il warehouse; i casi speciali (filtering di PII, arricchimento ML, aggregazione edge) sono pre-processing di sapore ETL che atterrano una versione leggermente cotta del layer raw.
Cosa ci lascia tutto questo
Lo spostamento da ETL a ELT non è stato un cambio di moda. Ha tracciato un cambio reale nelle curve di costo dello storage e del compute del warehouse, e ha tirato lo step di trasformazione da un tool chiuso a un repository SQL che il data team può revisionare, testare, e versionare come qualunque altro codice.
Il pavimento architetturale sotto il modern ELT è l’engine warehouse-or-lakehouse che fa girare le query di trasformazione. Quell’engine ha la sua storia. I discendenti di MapReduce, i batch processor distribuiti open source di cui i cloud warehouse hanno copiato delle parti internamente, sono il soggetto della lezione 34. Prima che Snowflake rendesse il batch invisibile dietro un prompt SQL, qualcuno ha dovuto inventare l’idea che mille macchine economiche potessero rimpiazzarne una costosa. Quel qualcuno era Google, e la community open source ha passato il decennio successivo a recuperare.
Citazioni e letture aggiuntive
- dbt Labs, “What is dbt?”,
https://docs.getdbt.com/docs/introduction(consultato 2026-05-01). Il riferimento per il pattern moderno di trasformazione in-warehouse. - Snowflake, “Key Concepts and Architecture”,
https://docs.snowflake.com/en/user-guide/intro-key-concepts(consultato 2026-05-01). La separazione di storage e compute che ha reso ELT economico alla scala vera. - Google Cloud, “BigQuery overview”,
https://cloud.google.com/bigquery/docs/introduction(consultato 2026-05-01). - Fivetran, “ETL vs. ELT”,
https://www.fivetran.com/learn/etl-vs-elt(consultato 2026-05-01). Riassunto dal punto di vista del vendor, utile per la timeline storica. - “Fundamentals of Data Engineering” (Joe Reis e Matt Housley, O’Reilly, 2022), capitoli su ingestion e transformation. Il riferimento contemporaneo standard per il modern data stack.