Data engineering

Il data engineering è la disciplina che costruisce i sistemi con cui un’azienda raccoglie, trasforma e serve i propri dati per l’analisi. Le voci di questo portale seguono tre fili che si intrecciano. Il primo è tecnico: com’è fatto un data warehouse moderno, dopo che il crollo dei costi di storage e compute (post 2015, con Presto/Trino, Spark, BigQuery, Snowflake) ha reso obsolete le pratiche pensate per il disco costoso. Il filo conduttore qui è la serie “Stop using Slowly-changing Dimensions!” di Sahar Massachi su DataExpert.io, che traduce in linguaggio piano il paradigma funzionale di Maxime Beauchemin: snapshot giornalieri append-only, pipeline idempotenti, backfill come bottone.

Il secondo filo è la classificazione: come si modellano le tabelle che gli analisti interrogano, dalle tassonomie kimballiane delle fact table alle pratiche di analytics engineering rese popolari da dbt. Il terzo è il ruolo: cosa resta del lavoro del data engineer ora che gli LLM scrivono SQL meglio di un professionista medio. La risposta di Massachi (fare da product owner del dato), quella di Tristan Handy (costruire il context layer per umani e agenti) e quella di Joe Reis (non diventare post-literate) descrivono lo stesso spostamento di valore da tre angolazioni.

Il punto di partenza consigliato è Data warehouse per le basi, poi Date stamping per la prescrizione operativa centrale, e Data engineer come product owner per il ruolo.

Le fondamenta del warehouse

• Data warehouse — il sistema separato dalla produzione, OLTP contro OLAP, la struttura a tier e la “golden age” post 2015. Punto di partenza consigliato.
• Pipeline (data engineering) — lo strumento numero uno: SQL come lingua franca, ELT invece di ETL, pipeline ds-aware.
• Dimension table — una riga per entità: la forma pulita di una tabella di sostantivi.
• Fact table — una riga per evento: la forma pulita e arricchita di un log.

Il tempo come dato: date stamping e idempotenza

• Date stamping — il “one weird trick” centrale: snapshot giornalieri append-only con colonna ds, query storiche come semplici filtri.
• Slowly Changing Dimensions — la pratica storica (Type-1, 2, 4) e la critica che la considera obsoleta.
• Backfilling — riprocessare la storia: catena sequenziale con SCD-2, bottone con i datestamp.
• Functional data engineering — il paradigma di Beauchemin: pipeline come funzioni pure, tempo come dato esplicito.
• Common Table Expressions — il “secondo one weird trick”: subquery nominate, SQL componibile.

Classificare le fact table

• Tipi di fact table — transaction, aggregate, periodic snapshot, accumulating snapshot, factless: la tassonomia a livello tabella.
• Fatti additivi, semi-additivi e non additivi — come le misure si comportano all’aggregazione: la tassonomia a livello colonna.

Il ruolo nell’era dell’AI

• Data engineer come product owner — la tesi di Massachi: l’AI commoditizza le pipeline, resta il giudizio su clienti e priorità.
• Trust vs trustworthy — dati corretti e persona percepita come affidabile sono cose diverse: l’aneddoto Moriarty.
• The surface they obsess about — non sostituire il sistema precario ma fidato: migliorarlo da dietro.
• Credibility economy — la credibilità come valuta da spendere sulle priorità che contano.
• Analytics engineering — modellare per l’usabilità con le pratiche del software engineering; nell’era AI si sposta dal codice al contesto.
• Context layer — il prossimo problema dei dati secondo Handy: definizioni e semantica di business per umani e agenti.
• The post-literate engineer — la diagnosi di Reis: produrre artefatti è economico, capirli è il collo di bottiglia.

In arrivo

Il cluster privato da cui questo portale deriva copre anche pattern non ancora maturi per la pubblicazione: il cumulative table design (l’eccezione legittima all’indipendenza tra giorni), la medallion architecture di Databricks, il framework AI-native di Shridhar Iyer con i suoi archetypes, e la proposta Agents Schema di dbt e Fivetran. Le voci verranno pubblicate man mano.