Data Pipeline
Una data pipeline è una sequenza di passi di elaborazione che sposta i dati da una o più sorgenti verso una o più destinazioni, applicando trasformazioni lungo il percorso. Può essere batch o streaming ed è tipicamente espressa come grafo aciclico diretto di task dipendenti. Le sue preoccupazioni centrali sono correttezza, idempotenza, osservabilità e recuperabilità dopo un guasto.
ETL (Extract, Transform, Load)
L'ETL è un pattern in cui i dati vengono estratti dalle sorgenti, trasformati nella forma di destinazione su un motore di elaborazione dedicato e poi caricati nel datastore di destinazione. La trasformazione avviene prima del caricamento, così solo dati conformati arrivano nel warehouse. L'ETL era il pattern dominante quando storage e calcolo erano costosi e fortemente accoppiati.
ELT (Extract, Load, Transform)
L'ELT estrae i dati dalle sorgenti e li carica grezzi nella destinazione per primi, poi li trasforma sul posto usando il calcolo del warehouse stesso. Sfrutta lo storage cloud economico e i motori warehouse elastici, così i dati grezzi sono preservati e le trasformazioni possono essere rieseguite. Strumenti come dbt hanno reso popolare l'ELT eseguendo trasformazioni SQL direttamente nel warehouse.
Data Warehouse
Un data warehouse è uno store analitico centrale ottimizzato per query aggregate veloci su grandi dati storici e strutturati, di solito con storage colonnare. Serve carichi di business intelligence e reporting più che transazionali. Esempi sono Snowflake, Google BigQuery e Amazon Redshift.
Data Lake
Un data lake memorizza dati grezzi di qualunque struttura (strutturati, semi-strutturati, non strutturati) a basso costo su object storage, rimandando la definizione dello schema al momento della lettura (schema-on-read). È flessibile ed economico ma rischia di diventare un "data swamp" senza governance, catalogazione e controlli di qualità. Backing comuni sono Amazon S3, Azure Data Lake Storage e Google Cloud Storage.
Data Lakehouse
Un lakehouse combina lo storage aperto a basso costo di un data lake con funzionalità di gestione tipiche del warehouse come transazioni ACID, enforcement dello schema e time travel, implementate tramite open table format. Punta a servire carichi sia di BI sia di machine learning da una singola copia dei dati. Delta Lake, Apache Iceberg e Apache Hudi sono i table format dominanti.
Schema-on-Read
Lo schema-on-read rimanda l'interpretazione della struttura dei dati al momento dell'interrogazione, memorizzando i byte grezzi e applicando uno schema in lettura. Rende l'ingestione veloce e flessibile per strutture in evoluzione o sconosciute, al costo di spostare parsing e validazione sui consumatori. Si contrappone allo schema-on-write, dove i dati devono conformarsi prima di essere memorizzati.
Schema-on-Write
Lo schema-on-write impone una struttura definita al momento dell'ingestione, rifiutando o coercendo i dati non conformi prima della persistenza. Garantisce che i dati memorizzati siano puliti e interrogabili ma rende l'ingestione meno flessibile ai cambiamenti delle sorgenti. I database relazionali e i warehouse tradizionali usano schema-on-write.
Idempotenza
In data engineering un'operazione è idempotente se eseguirla più volte produce lo stesso risultato di eseguirla una volta sola. L'idempotenza è essenziale per retry e backfill sicuri, perché le pipeline falliscono e i task vengono rieseguiti. Si ottiene comunemente con overwrite deterministici di partizione, chiavi di merge/upsert o deduplicazione su una chiave di business stabile.
Backfill
Un backfill rielabora dati storici attraverso una pipeline, tipicamente per popolare una nuova colonna, correggere un bug passato o ricostruire una tabella dopo un cambio di logica. I backfill sicuri richiedono task idempotenti e con ambito di partizione, così una riesecuzione non duplica né corrompe i dati. Spesso si eseguono partizione per partizione con concorrenza limitata per controllare i costi.
Partitioning
Il partizionamento divide fisicamente una tabella in segmenti, comunemente per una colonna data o categoria, così le query possono potare i dati irrilevanti e scansionare meno. Un buon partizionamento riduce drasticamente costo e tempo delle query e abilita overwrite idempotenti a livello di partizione. L'over-partitioning (troppe partizioni minuscole, il problema dei small files) danneggia performance e overhead dei metadati.
Scrittura Idempotente
Una scrittura idempotente produce lo stesso stato finale della tabella indipendentemente da quante volte viene eseguita, di solito sovrascrivendo un target deterministico (una partizione) o facendo merge su una chiave. È il fondamento delle pipeline batch affidabili, che devono tollerare i retry. Le scritture append-only non sono idempotenti se non abbinate a deduplicazione.
Slowly Changing Dimension (SCD)
Una slowly changing dimension è una tabella dimensione i cui valori cambiano di rado nel tempo, e i tipi SCD definiscono come registrare quei cambiamenti. Il Tipo 1 sovrascrive il valore vecchio, il Tipo 2 conserva la storia completa aggiungendo una nuova riga con date di validità, il Tipo 3 mantiene valori precedenti limitati in colonne aggiuntive. Lo SCD Tipo 2 è il modo standard per preservare l'accuratezza storica in un warehouse.
Star Schema
Uno star schema è un modello dimensionale con una tabella fatti centrale che referenzia tabelle dimensione circostanti tramite chiavi esterne, formando una stella. È denormalizzato per le performance di query ed è intuitivo per l'analisi. È il design Kimball classico per il reporting di warehouse.
Tabella Fatti
Una tabella fatti memorizza gli eventi misurabili e quantitativi di un processo di business (come vendite o click), con chiavi esterne verso le dimensioni e misure numeriche. I fatti sono tipicamente additivi e memorizzati a una granularità definita (una riga per evento o per livello di aggregazione). Scegliere la granularità è il primo e più importante passo della modellazione dimensionale.
Tabella Dimensione
Una tabella dimensione contiene il contesto descrittivo e testuale dei fatti, come cliente, prodotto, data o località, su cui gli analisti filtrano e raggruppano. Le dimensioni sono denormalizzate e relativamente larghe e possono tracciare la storia con tecniche di slowly changing dimension. Forniscono il "chi, cosa, dove, quando" attorno a ogni fatto.
Data Modeling
Il data modeling è la disciplina di strutturare i dati in tabelle e relazioni adatte a come saranno interrogati e mantenuti. La modellazione analitica predilige design dimensionali (star/snowflake) o tabelle larghe denormalizzate; quella transazionale predilige la normalizzazione per ridurre la ridondanza. Il modello giusto dipende dal pattern di accesso, non da un ideale universale.
Normalizzazione
La normalizzazione organizza i dati relazionali per eliminare la ridondanza decomponendo le tabelle secondo le forme normali, così ogni fatto è memorizzato una sola volta. Ottimizza l'integrità in scrittura e lo storage al costo di più join in lettura. I sistemi transazionali (OLTP) normalizzano; i sistemi analitici spesso denormalizzano deliberatamente per la velocità in lettura.
Denormalizzazione
La denormalizzazione introduce intenzionalmente ridondanza, come pre-join o duplicazione di colonne, per ridurre i join e velocizzare le letture. Scambia storage e complessità di scrittura per performance di query, adatta a sistemi analitici e colonnari. Tabelle larghe e star schema sono design denormalizzati comuni.
OLAP (Online Analytical Processing)
OLAP indica carichi e sistemi ottimizzati per query aggregate complesse su grandi dataset storici, come reportistica e dashboard. I motori OLAP usano tipicamente storage colonnare e sono read-heavy con caricamenti bulk infrequenti. Si contrappone all'OLTP, che gestisce molte piccole letture e scritture transazionali.
OLTP (Online Transaction Processing)
OLTP indica sistemi ottimizzati per operazioni transazionali ad alto volume e bassa latenza, come inserire un ordine o aggiornare un saldo. I database OLTP sono di solito orientati alle righe e fortemente normalizzati per l'integrità in scrittura. I sistemi sorgente operativi sono tipicamente OLTP; i loro dati vengono poi spostati negli store OLAP per l'analisi.
Storage Colonnare
Lo storage colonnare dispone fisicamente i valori di una tabella per colonna anziché per riga, così le query analitiche leggono solo le colonne necessarie. Questo abilita forte compressione e scansioni veloci per le aggregazioni, motivo per cui warehouse e formati come Parquet sono colonnari. È poco adatto ai carichi transazionali riga per riga.
Apache Parquet
Parquet è un formato file aperto, colonnare e binario progettato per storage e query analitiche efficienti, con compressione, encoding e statistiche di colonna integrati. Le statistiche a livello di colonna e la struttura a row group permettono ai motori di saltare dati (predicate pushdown). È lo standard de facto per il formato fisico di data lake e lakehouse.
Apache Spark
Apache Spark è un motore di calcolo distribuito per elaborazione batch e streaming su larga scala, con API DataFrame, SQL e RDD in più linguaggi. Esegue i job come DAG di stage su dati partizionati, con caching in memoria e un ottimizzatore basato sui costi (Catalyst). È molto usato per ETL/ELT, machine learning e trasformazioni lakehouse.
Apache Kafka
Apache Kafka è un commit log distribuito e append-only usato come backbone durevole e ad alto throughput per dati in streaming e sistemi event-driven. I producer scrivono record su topic partizionati e i consumer li leggono al proprio offset, abilitando il replay e il disaccoppiamento. Fornisce ordinamento all'interno di una partizione e retention e replica configurabili.
Apache Airflow
Apache Airflow è un orchestratore open-source che pianifica e monitora workflow definiti come DAG Python di task con dipendenze esplicite. Gestisce retry, backfill, scheduling e osservabilità delle pipeline batch. Ogni task dovrebbe essere idempotente così riesecuzioni e catchup sono sicuri.
Orchestrazione
L'orchestrazione coordina l'ordine di esecuzione, lo scheduling, i retry e le dipendenze dei task di una pipeline. Risponde a cosa gira, in che ordine, quando e cosa succede in caso di guasto. Strumenti includono Apache Airflow, Dagster e Prefect; l'orchestrazione è distinta dal motore di calcolo che fa il lavoro.
dbt (data build tool)
dbt è un framework di trasformazione che permette agli analisti di definire trasformazioni del warehouse come modelli SQL versionati con dipendenze, test e documentazione. Compila i modelli in SQL, li esegue in ordine di dipendenza dentro il warehouse (la T di ELT) e li materializza come tabelle o viste. Porta pratiche di ingegneria del software (test, CI, lineage) all'analytics.
Change Data Capture (CDC)
Il Change Data Capture rileva e trasmette i cambiamenti a livello di riga (insert, update, delete) da un database sorgente, di solito leggendone il transaction log. Abilita replica quasi in tempo reale e ingestione incrementale senza scansioni complete delle tabelle né query pesanti sulla sorgente. Debezium è una piattaforma CDC open-source comune basata su Kafka Connect.
Stream Processing
Lo stream processing calcola su dati illimitati che arrivano in continuazione, producendo risultati in modo incrementale e a bassa latenza. Deve gestire la semantica del tempo evento, eventi fuori ordine, windowing e consegna exactly-once o at-least-once. I motori includono Apache Flink, Kafka Streams e Spark Structured Streaming.
Batch Processing
Il batch processing esegue calcoli su un dataset finito e limitato, tipicamente a intervalli pianificati (ogni ora, giornaliero). Predilige throughput e semplicità rispetto alla latenza ed è il default per la maggior parte delle pipeline analitiche. Il compromesso rispetto allo streaming è freschezza contro complessità operativa.
Windowing
Il windowing raggruppa eventi di stream illimitati in blocchi finiti per l'aggregazione, per tempo (finestre tumbling, sliding, di sessione) o per conteggio. Le finestre temporali devono scegliere tra tempo evento e tempo di elaborazione e gestire i dati in ritardo. Il windowing è ciò che rende trattabili le aggregazioni su uno stream infinito.
Watermark
Un watermark è un timestamp euristico nello stream processing che asserisce che non sono più attesi eventi precedenti a esso, permettendo alle finestre di chiudersi ed emettere risultati. Scambia completezza per latenza: un watermark più tardivo attende più a lungo i ritardatari, uno più precoce emette prima ma può scartare eventi in ritardo. I watermark sono centrali per una corretta elaborazione a tempo evento in motori come Flink.
Semantica Exactly-Once
La semantica exactly-once garantisce che ogni record in input influisca sul risultato esattamente una volta nonostante guasti e retry, evitando sia perdite sia duplicazioni. Si ottiene tipicamente con scritture idempotenti più commit transazionali degli offset, oppure con sink a two-phase commit. Il vero exactly-once end-to-end richiede la cooperazione tra sorgente, processore e sink.
Data Governance
La data governance è il framework di policy, ruoli e processi che assicurano che i dati siano accurati, sicuri, conformi e ben definiti in tutta l'organizzazione. Copre ownership, controllo degli accessi, classificazione, retention, privacy e standard. La governance trasforma dati sparsi in un asset affidabile e auditabile.
Data Catalog
Un data catalog è un inventario ricercabile dei dataset di un'organizzazione arricchito di metadati come schemi, owner, descrizioni, lineage e stato di qualità. Aiuta gli utenti a scoprire, comprendere e fidarsi dei dati e sostiene la governance. Strumenti includono DataHub, Amundsen e OpenMetadata.
Data Lineage
Il data lineage è il record tracciabile di dove i dati hanno avuto origine e di come sono fluiti e stati trasformati tra i sistemi fino allo stato attuale. Supporta analisi d'impatto, debugging, conformità e fiducia mostrando sorgenti a monte e consumatori a valle. Può essere catturato a livello di tabella o di colonna.
Data Quality
La data quality è il grado in cui i dati sono adatti all'uso previsto, misurata lungo dimensioni come accuratezza, completezza, consistenza, tempestività, validità e unicità. Si fa rispettare con test automatici, vincoli e monitoraggio che fanno fallire o mettono in quarantena i dati cattivi presto. I framework includono Great Expectations, i test dbt e Soda.
Data Observability
La data observability è la pratica di monitorare la salute di dati e pipeline su freschezza, volume, schema, distribuzione e lineage per rilevare i problemi prima dei consumatori. Estende i concetti di osservabilità del software al dominio dei dati. L'obiettivo è cogliere automaticamente dati rotti o anomali invece che tramite lamentele a valle.
Data Contract
Un data contract è un accordo esplicito e versionato tra un produttore di dati e i suoi consumatori che specifica schema, semantica, garanzie di qualità e SLA. Previene cambiamenti breaking silenziosi rendendo l'interfaccia un artefatto di prima classe e testabile. I contratti spostano la qualità dei dati a sinistra, al punto di produzione.
Medallion Architecture
L'architettura medallion organizza un lakehouse in livelli di qualità progressiva: bronze (dati grezzi ingeriti), silver (puliti, conformati, deduplicati) e gold (curati, aggregati a livello di business). Ogni livello aggiunge struttura e fiducia, isolando l'atterraggio grezzo dal consumo. È un pattern comune di raffinamento incrementale in Delta Lake e piattaforme simili.
Apache Iceberg
Apache Iceberg è un open table format che aggiunge funzionalità simili a un database ai file di un data lake, incluse transazioni ACID, evoluzione di schema e partizione, snapshot e time travel. Traccia lo stato della tabella tramite file di metadati e manifest invece che listing di directory, evitando problemi di correttezza basati sul listing. Permette a più motori (Spark, Trino, Flink) di leggere e scrivere in sicurezza le stesse tabelle.
Delta Lake
Delta Lake è un layer di storage aperto che porta transazioni ACID, enforcement dello schema e time travel ai file Parquet tramite un transaction log. Abilita upsert affidabili (MERGE), delete e letture/scritture concorrenti su un data lake. È il fondamento del pattern lakehouse su piattaforme come Databricks.
Time Travel
Il time travel è la capacità di interrogare una tabella così com'era in una versione o timestamp precedente, abilitata da table format che mantengono snapshot immutabili e un transaction log. Supporta auditing, riproduzione di risultati passati, debugging e rollback di scritture errate. Delta Lake, Iceberg e Hudi espongono tutti query di time travel.
Consumatore Idempotente
Un consumatore idempotente elabora lo stesso messaggio più di una volta senza cambiare l'esito, cosa richiesta perché la maggior parte dei sistemi di messaggistica consegna at-least-once. Si implementa deduplicando su una chiave di messaggio o rendendo idempotente l'effetto a valle. Questo pattern permette ai sistemi streaming di ottenere risultati effectively-once.
Data Mesh
Il data mesh è un approccio socio-tecnico decentralizzato che tratta i dati come prodotto posseduto dai team di dominio, supportato da una piattaforma self-serve e da una governance federata. Sposta la responsabilità da un team dati centrale ai domini che conoscono meglio i dati. I suoi quattro principi sono ownership di dominio, dati come prodotto, piattaforma self-serve e governance computazionale federata.
Reverse ETL
Il reverse ETL sposta i dati trasformati e modellati dal warehouse di nuovo negli strumenti operativi come CRM, piattaforme pubblicitarie e sistemi di supporto. Operativizza l'analytics portando le metriche curate dove gli utenti di business agiscono. È l'inverso dell'ingestione tradizionale, con il warehouse come fonte di verità.
Data Skew
Il data skew è la distribuzione non uniforme dei dati tra partizioni o chiavi, che porta alcuni task o reducer a gestire molto più lavoro di altri e a diventare straggler. È una causa primaria di job distribuiti lenti, specialmente su join e aggregazioni su chiavi calde. Le mitigazioni includono il salting delle chiavi, il repartizionamento e i broadcast join per tabelle piccole.
Problema dei Small Files
Il problema dei small files sorge quando un data lake accumula molti file minuscoli, gonfiando overhead di metadati, listing e scheduling dei task e degradando le performance di lettura. Deriva comunemente da scritture streaming ad alta frequenza o dall'over-partitioning. Si affronta con la compaction (unione dei file) e con table format che gestiscono le dimensioni dei file.
Vista Materializzata
Una vista materializzata memorizza fisicamente il risultato precalcolato di una query, così le letture sono veloci al costo di mantenerla aggiornata al variare dei dati sottostanti. Scambia storage e complessità di refresh per latenza di query, utile per aggregazioni ricorrenti costose. Alcuni motori la aggiornano in modo incrementale, altri richiedono il ricalcolo completo.
Data Freshness
La data freshness misura quanto recentemente i dati sono stati aggiornati rispetto agli eventi che rappresentano, spesso espressa come ritardo tra sorgente e destinazione. È una dimensione centrale di qualità dei dati e di SLA che si scambia con costo e complessità della pipeline. Lo streaming migliora la freschezza; gli scheduling batch la limitano alla lunghezza dell'intervallo.
Apache Flink
Apache Flink è un motore di stream processing distribuito costruito per calcoli stateful a tempo evento con garanzie exactly-once e bassa latenza. Tratta il batch come caso particolare dello streaming e usa il checkpointing per recuperare lo stato dopo un guasto. È molto usato per analytics in tempo reale, elaborazione CDC e applicazioni event-driven.