Il data engineering letto di fila

Questo editoriale attraversa il cluster Data engineering come un unico documento da leggere di fila. Le diciotto voci del cluster restano gli approfondimenti di riferimento: qui ogni concetto è introdotto quanto serve a seguire il filo, e il link alla voce, alla prima occorrenza, porta al dettaglio completo e alle fonti. Il materiale deriva in gran parte dalla serie “Stop using Slowly-changing Dimensions!” di Sahar Massachi su DataExpert.io, che traduce in linguaggio piano il paradigma funzionale di Maxime Beauchemin, più le tassonomie kimballiane del data modeling e tre letture del 2026 sul futuro del ruolo (Massachi, Tristan Handy, Joe Reis). La bibliografia aggregata sta in fondo.

Un sistema separato per l’analisi

Il punto di partenza è una separazione. Il database di produzione di un’azienda serve il prodotto e i suoi utenti: è veloce, ottimizzato per il codice, e di norma non conserva la storia. Il data warehouse è il sistema separato che raccoglie tutti i dati utili in un unico posto e serve le persone dentro l’azienda: analisti, data scientist, management. La distinzione tecnica è quella tra OLTP (transazioni) e OLAP (analisi), ma il senso è organizzativo prima che tecnico: due sistemi, due pubblici, due criteri di ottimizzazione.

Dentro il warehouse il dato scorre verso il basso. In cima entrano le copie raw, repliche esatte delle sorgenti, non affidabili per definizione e mai modificate. In mezzo lavorano le pipeline: codice che prende tabelle in input e produce tabelle in output, deduplicando, pulendo, incrociando. In fondo vivono le tabelle che gli analisti interrogano davvero. Il pattern moderno è ELT, non ETL: il dato si copia grezzo nel warehouse e si trasforma lì dentro, in SQL. La scelta del linguaggio non è di gusto: SQL è abbastanza vincolato da permettere ai motori di parallelizzarlo automaticamente, cosa che con un linguaggio imperativo non è garantita.

Serve anche una coordinata storica, perché data l’epoca cambiano le regole. Fino a metà anni duemiladieci costruire un warehouse imponeva un compromesso tra capienza e velocità, e risolverlo costava ingegneria: cubi preaggregati, indici su misura, processi ETL pesanti. Attorno al 2015, con Presto/Trino, Spark, BigQuery e Snowflake, quel compromesso è praticamente scomparso: dati arbitrariamente grandi si interrogano in secondi. Massachi chiama questo periodo la “golden age” del data warehousing, e da qui parte la tesi che regge metà dell’editoriale: molte pratiche storiche del data modeling, progettate per risparmiare storage costoso, oggi sono complessità senza beneficio.

Il vocabolario di base: entità ed eventi

Le tabelle in fondo al warehouse sono di due specie, e il test per distinguerle è lapidario: una riga per sostantivo o una riga per “è successa una cosa”. La dimension table tiene una riga per entità (un utente, un prodotto), e oltre all’anagrafica può includere aggregati derivati dagli eventi, come il totale dei post o i commenti degli ultimi sette giorni: se un analista vorrebbe costantemente quel dato, conviene calcolarlo di notte nella pipeline piuttosto che farlo ricalcolare a ogni query. La fact table tiene una riga per evento, ed è la forma pulita e arricchita di un log: una buona fact porta con sé tutto il contesto che serve ad analizzare l’evento senza join aggiuntivi, anche a costo di qualche ridondanza. In entrambi i casi il principio economico è lo stesso: spendere storage ed elaborazione notturna per comprare fluidità di analisi diurna.

Il problema del tempo

Con il vocabolario in mano si può porre la domanda attorno a cui il cluster ruota: cosa succede quando i dati cambiano? Un utente cambia paese, un prodotto cambia categoria, e la dimension deve conservare sia la versione vecchia sia la nuova. La risposta tradizionale sono le Slowly Changing Dimensions, una famiglia di tecniche della tradizione di Ralph Kimball. Il Type-1 sovrascrive e perde la storia. Il Type-4 sdoppia la tabella in una corrente e una storica, due fonti di verità da tenere sincronizzate. Il Type-2, il più diffuso, aggiunge colonne valid_from e valid_to: quando il dato cambia, la riga vecchia si “chiude” e se ne inserisce una nuova.

Il Type-2 conserva la storia, ma a un prezzo che conviene guardare da vicino, perché è il prezzo che il resto del cluster elimina. Le pipeline richiedono logica custom per chiudere le righe, e un errore nei valid_to produce buchi o sovrapposizioni. Ogni query storica ripete la logica degli intervalli a ogni join, e dimenticarne uno produce risultati silenziosamente sbagliati. Soprattutto, ogni giorno dipende dallo stato del giorno precedente: riprocessare un mese significa trenta esecuzioni in fila. Tutte queste tecniche condividono un obiettivo, risparmiare storage, che nell’era post 2015 non vale più la complessità che costa.

Il trucco: il tempo come dato

L’alternativa che Massachi propone come “one weird trick” è il date stamping: organizzare le tabelle per snapshot giornalieri append-only. Ogni tabella ha una colonna ds (datestamp) che marca il giorno di validità; ogni giorno si appende lo snapshot nuovo senza toccare i precedenti; lo stato al primo ottobre è la riga con ds='2024-10-01', un filtro invece di una ricostruzione. Per incrociare più tabelle storiche, ognuna filtra sulla propria ds e il join avviene su ds, senza BETWEEN né colonne di validità. Il precedente storico è Facebook dei primi anni 2010: snapshot giornaliero di MySQL copiato in Hive con un date stamp, un’architettura che funziona identica oggi con Iceberg, Delta o Hudi.

La pipeline datestampata fa due mosse simmetriche: filtra l’input sul giorno che sta processando (WHERE ds={today}) e appende l’output marcandolo con lo stesso ds. Il giorno smette di essere una circostanza dell’esecuzione (“i dati che ci sono adesso”) e diventa un parametro esplicito, iniettato dall’orchestratore. Da qui discendono due proprietà che sembrano tecnicismi e sono invece il cuore di tutto: la pipeline è deterministica (eseguita con ds='2024-11-15' produce sempre lo stesso risultato, oggi o fra tre mesi) e i giorni sono indipendenti l’uno dall’altro, perché il 15 novembre ha bisogno solo dello snapshot del 15 novembre.

Questa è l’implementazione concreta del functional data engineering, il paradigma che Beauchemin, creatore di Airflow, ha formulato nel 2017: pipeline come funzioni pure, stesso input stesso output, nessuno stato nascosto, tempo come dato esplicito invece che come stato mutabile da aggiornare. La serie di Massachi è dichiaratamente il tentativo di tradurre quell’articolo teorico in pratica diffusa. Capire il principio, oltre alle regole, serve nei casi che le regole non coprono.

Il dividendo: backfill, bug, storia gratis

Il ritorno dell’investimento si vede sul backfilling, cioè il riprocessare dati storici. Con SCD-2 è una catena: ogni giorno aspetta il precedente, il backfill richiede SQL diverso dal run giornaliero (due codebase da mantenere), e su intervalli lunghi i tempi esplodono. Con le tabelle datestampate i giorni partono in parallelo, ognuno legge e scrive la propria partizione, e lo stesso SQL serve il run di oggi e il backfill di tre mesi fa: cambia solo il parametro. Un mese si riprocessa nel tempo di un giorno.

Le conseguenze pratiche si accumulano: un bug nei dati storici si corregge sistemando la logica e rieseguendo l’intervallo, con il dato corretto che sovrascrive quello sbagliato partizione per partizione; una correzione a monte si propaga a valle backfillando le tabelle dipendenti; una tabella creata oggi si popola all’indietro di un anno, perché gli snapshot raw dei giorni passati sono ancora lì. L’anti-pattern che rompe il meccanismo è la dipendenza dal giorno precedente della propria stessa tabella (in Airflow, depends_on_past=True): reintroduce la catena. L’eccezione legittima sono le metriche cumulative, dove la dipendenza è strutturale.

A completare la cassetta degli attrezzi c’è il “secondo one weird trick” della serie: le Common Table Expressions, la clausola WITH che dà un nome alle subquery e le rende componibili come funzioni. Le query storiche complesse, con gli snapshot datestampati e le CTE, restano complesse solo nella logica di business.

Classificare gli eventi

Un secondo filo, più tassonomico, riguarda come si modellano le fact table, e opera su due livelli. A livello di tabella, i tipi di fact table: transaction (una riga per evento, massimo dettaglio), aggregate (sommari pre-calcolati), periodic snapshot (l’attività su un intervallo fisso), accumulating snapshot (processi a stadi, aggiornati a ogni traguardo) e factless (puri accadimenti senza misure, che per differenza rivelano anche ciò che non è accaduto). A livello di colonna, i fatti additivi, semi-additivi e non additivi: le vendite si sommano lungo qualsiasi dimensione, l’inventario si somma tra negozi ma mai lungo il tempo, una percentuale non si somma affatto. La domanda operativa dietro entrambe le tassonomie: si può rispondere con un semplice GROUP BY? Sommare lungo la dimensione sbagliata produce numeri sbagliati che sembrano giusti, l’errore analitico più difficile da individuare.

Accanto alla fisica delle tabelle sta un processo di lavoro: l’analytics engineering, reso popolare da dbt, che porta nella pipeline le pratiche del software engineering (modularità, test, documentazione, version control) e modella i dati per l’usabilità oltre che per la velocità. Il date stamping dice come devono essere fatte le tabelle; l’analytics engineering dice come si lavora attorno ad esse.

Cosa resta del ruolo

Il terzo filo è la domanda del 2026: se gli LLM scrivono SQL più velocemente e meglio di un data engineer medio, fanno root cause analysis e debuggano l’infrastruttura, cosa resta del lavoro? Il cluster raccoglie tre risposte che descrivono lo stesso spostamento di valore da angolazioni diverse.

La risposta di Massachi è la tesi del data engineer come product owner: il prodotto è il dato, i clienti sono i colleghi che lo usano per decidere, e se i colleghi non usano il lavoro la responsabilità è di chi l’ha costruito. La parte ingegneristica del ruolo si è commoditizzata; restano capire cosa costruire, per chi, e con quali priorità. La tesi si scompone in tre meccanismi. Trust vs trustworthy: dati accurati e persona percepita come affidabile sono cose diverse, e la fiducia si costruisce con la reattività nell’interazione ripetuta, come mostra l’aneddoto del collega “Moriarty” che non lasciava mai una domanda senza risposta per più di qualche minuto. The surface they obsess about: chi eredita un sistema dati precario ma fidato, fosse anche un Excel girato via email, deve curare quella superficie invece di sostituirla, perché chi minaccia il pilastro di verità del management raccoglie ostilità, non gratitudine. Credibility economy: la credibilità accumulata con i primi due meccanismi è una valuta, e il punto della valuta è spenderla sulle priorità che contano davvero, non sull’estetica dell’architettura.

La risposta di Handy, fondatore di dbt, guarda all’infrastruttura: il prossimo problema dei dati è il context layer, il layer condiviso di definizioni metriche, semantica di business e lineage che permette a umani e agenti AI di ottenere risposte affidabili. Un agente genera SQL sintatticamente valido, ma non sa quale campo di revenue sia quello di cui la finanza si fida: è un problema di conoscenza organizzativa, non di sintassi. La proposta operativa, dopo la fusione dbt-Fivetran, si chiama Agents Schema: definizioni e semantica in tabelle SQL che gli agenti interrogano.

La risposta di Reis è il contrappunto critico: the post-literate engineer è l’ingegnere che spedisce sistemi che non sa leggere, spiegare o possedere. Produrre artefatti è diventato economico, capirli è il collo di bottiglia, e l’assunzione “posso produrlo, quindi lo capisco” è falsa. Per chi ha la comprensione di base l’AI è leva reale; per chi non ce l’ha è leva falsa, un raggio d’azione più ampio senza comprensione corrispondente. Il confine che Reis traccia chiude bene il cluster: l’ingegneria può diventare post-literate, ma non post-responsibility. Qualcuno deve capire cosa fa il sistema, decidere se farlo, e possederne le conseguenze.

Come proseguire

Il portale del cluster dichiara il percorso di studio completo, diciotto tappe con avanzamento salvato nel browser: è lo strumento per riprendere gli stessi argomenti voce per voce, con le fonti annotate affermazione per affermazione. Il cluster privato da cui il portale deriva copre anche pattern non ancora pubblicati, tra cui il cumulative table design, la medallion architecture e il framework AI-native di Shridhar Iyer: le voci arriveranno man mano, e questo editoriale verrà esteso nei punti corrispondenti.

Bibliografia e sitografia

Le fonti primarie da cui derivano le voci attraversate dall’editoriale; il dettaglio degli ancoraggi sta nelle singole voci.

• Sahar Massachi, The data warehouse setup no one taught you (Stop using Slowly-changing Dimensions! Part 1), DataExpert.io, 24 ottobre 2025. blog.dataexpert.io
• Sahar Massachi, SCD-2 considered harmful! (Stop using Slowly-changing Dimensions! Part 2), DataExpert.io, 4 novembre 2025. blog.dataexpert.io
• Sahar Massachi, Junior data engineers build pipelines. Seniors build trust, DataExpert.io, 30 giugno 2026. blog.dataexpert.io
• Maxime Beauchemin, Functional Data Engineering: A Modern Paradigm for Batch Data Processing, Medium, 2017.
• Sleekdatasolutions, How to Design a Perfect Fact Table — Deep Dive into Fact Types & Fact Table Types, Medium, 3 aprile 2026. medium.com
• Metabase, Analytics engineering for fact tables, Metabase Learn. metabase.com
• Olga Berezovsky, When AI Builds the Data Models, What Happens to Analytics Engineering? (intervista a Tristan Handy), Data Analysis Journal, numero 326, 29 luglio 2026.
• Data lessons from inside Meta (intervista a Shridhar Iyer), The Analytics Engineering Podcast, dbt Labs, 30 luglio 2026.
• Joe Reis, The Post-Literate Engineer, The Weekend Windup, numero 40, 2 agosto 2026.