Qual è la differenza tra ETL ed ELT?
L'ETL trasforma i dati su un motore di elaborazione dedicato prima di caricarli, così solo dati puliti e conformati arrivano nella destinazione; l'ELT carica prima i dati grezzi nella destinazione e li trasforma sul posto usando il calcolo della destinazione stessa. L'ETL aveva senso quando storage e calcolo erano costosi e accoppiati, mentre l'ELT sfrutta object storage cloud economico e motori warehouse elastici, motivo per cui strumenti come dbt eseguono le trasformazioni dentro il warehouse. L'ELT preserva inoltre i dati grezzi, così le trasformazioni possono essere rieseguite o corrette senza ri-estrarre dalla sorgente.
Quando dovrei usare un data lake, un warehouse o un lakehouse?
Usa un data warehouse quando i tuoi dati sono perlopiù strutturati e i carichi sono BI e analytics SQL che richiedono query aggregate veloci e una governance solida. Usa un data lake quando devi far atterrare grandi volumi di dati grezzi, semi-strutturati o non strutturati a basso costo e rimandare le decisioni sullo schema, accettando di dover aggiungere catalogazione e controlli di qualità per evitare un data swamp. Un lakehouse punta a darti entrambi: storage aperto a basso costo con funzionalità da warehouse come transazioni ACID, enforcement dello schema e time travel tramite open table format, servendo BI e machine learning da una sola copia dei dati.
Perché l'idempotenza conta così tanto nelle data pipeline?
Le pipeline falliscono e i task vengono rieseguiti, quindi qualunque passo eseguito più di una volta deve produrre lo stesso risultato di un'esecuzione singola, altrimenti otterrai dati duplicati o corrotti. L'idempotenza è ciò che rende sicuri retry, catchup e backfill, e di solito si ottiene sovrascrivendo una partizione deterministica o facendo merge su una chiave di business stabile invece di un append cieco. Progettare per l'idempotenza fin dall'inizio è molto più economico che ripulire i duplicati dopo un guasto parziale.
Come evito record duplicati ingerendo dati in streaming?
La maggior parte dei sistemi di messaggistica consegna at-least-once, quindi i consumer devono tollerare di vedere lo stesso messaggio due volte. L'approccio standard è rendere idempotente il consumer: deduplicare su una chiave di messaggio stabile, o rendere idempotente la scrittura a valle con un upsert (MERGE) su una chiave primaria. Per garanzie più forti, combina sink idempotenti con commit transazionali degli offset, così un input influisce sul risultato esattamente una volta anche in presenza di guasti.
Cos'è una slowly changing dimension e quando serve il Tipo 2?
Una slowly changing dimension è una tabella dimensione i cui attributi cambiano occasionalmente, e il tipo SCD definisce come registrare quei cambiamenti. Il Tipo 1 sovrascrive semplicemente il valore vecchio e perde la storia, mentre il Tipo 2 preserva la storia completa inserendo una nuova riga con date di validità (e spesso un flag di riga corrente) a ogni cambio di attributo. Usa il Tipo 2 quando gli analisti devono riprodurre com'era un'entità al momento di un fatto passato, per esempio riportando le vendite per la regione del cliente com'era alla data dell'ordine.
Come dovrei partizionare le mie tabelle?
Partiziona su una colonna su cui le tue query filtrano spesso, il più delle volte una data, così il motore può potare le partizioni e scansionare molti meno dati. Mira a partizioni abbastanza grandi da essere efficienti ma non così grossolane da far comunque scansionare dati irrilevanti; evita l'over-partitioning, che crea molti file minuscoli e pesante overhead di metadati. Il partizionamento abilita inoltre overwrite idempotenti a livello di partizione, mattone chiave per job batch e backfill affidabili.
Cos'è il problema dei small files e come lo risolvo?
Il problema dei small files si verifica quando un data lake accumula molti file minuscoli, gonfiando overhead di metadati, listing e scheduling dei task e rallentando le letture. Deriva tipicamente da scritture streaming ad alta frequenza o dall'over-partitioning. La soluzione è la compaction, riscrivere periodicamente molti file piccoli in pochi file più grandi, e usare un open table format che gestisca le dimensioni dei file e permetta di eseguire operazioni di optimize/compaction in sicurezza.
Quando dovrei scegliere lo streaming rispetto al batch?
Imposta il batch come default a meno che tu non abbia un requisito concreto di latenza, perché il batch è più semplice da costruire, testare, ragionare e recuperare. Scegli lo streaming quando il business ha davvero bisogno di bassa latenza end-to-end, per esempio rilevamento frodi, personalizzazione in tempo reale o alerting operativo, e puoi investire nella gestione di tempo evento, dati fuori ordine, windowing ed exactly-once. Molti team adottano un ibrido: ingestione streaming per la freschezza con job batch periodici per aggregazioni pesanti e critiche per la correttezza.
Come gestisco i dati in ritardo in uno stream?
Elabora per tempo evento anziché per tempo di elaborazione, e usa un watermark per dichiarare quanto a lungo attenderai i ritardatari prima di chiudere una finestra ed emettere i risultati. Il watermark è un compromesso: attendere di più cattura più eventi in ritardo ma aumenta la latenza, mentre emettere prima è più rapido ma può scartare o richiedere la rielaborazione dei record in ritardo. Per gli eventi che arrivano dopo il watermark tipicamente li scarti, li instradi a un output laterale o consenti aggiornamenti limitati della finestra a seconda del motore e delle esigenze di correttezza.
Cos'è il change data capture e perché usarlo?
Il Change Data Capture trasmette insert, update e delete a livello di riga da un database sorgente, di solito leggendone il transaction log invece di interrogare le tabelle. Ti dà replica incrementale quasi in tempo reale senza eseguire query pesanti sulla sorgente operativa né scansionare tabelle intere. È il modo standard per mantenere un warehouse, un indice di ricerca o una cache sincronizzati con un sistema transazionale, con Debezium come implementazione open-source comune su Kafka.
Come evito che la qualità dei dati degradi nel tempo?
Tratta la qualità dei dati come codice: aggiungi test e vincoli automatici che verifichino accuratezza, completezza, unicità e validità, ed eseguili nella pipeline così i dati cattivi falliscono o vengono messi in quarantena prima di raggiungere i consumatori. Aggiungi data observability per monitorare freschezza, volume, schema e distribuzione così le anomalie vengono colte automaticamente invece che tramite lamentele a valle. Sposta la qualità "a sinistra" con i data contract, così i produttori si impegnano su uno schema versionato e garanzie e non possono fare cambiamenti breaking silenziosi.
Cos'è un data contract e quale problema risolve?
Un data contract è un accordo esplicito e versionato tra un produttore di dati e i suoi consumatori che specifica schema, semantica, aspettative di qualità e SLA di un dataset. Risolve il problema ricorrente di team a monte che cambiano una colonna o il suo significato senza preavviso, rompendo silenziosamente ogni pipeline e dashboard a valle. Rendendo l'interfaccia un artefatto di prima classe e testabile, i contratti spostano l'enforcement della qualità al punto di produzione e permettono di versionare e negoziare i cambiamenti breaking.
Cos'è la medallion architecture?
L'architettura medallion organizza un lakehouse in livelli di qualità progressiva: bronze contiene i dati grezzi ingeriti esattamente come ricevuti, silver contiene dati puliti, conformati e deduplicati, e gold contiene aggregati curati a livello di business pronti per il consumo. Ogni livello aggiunge struttura e fiducia isolando l'atterraggio grezzo dalle tabelle che gli analisti interrogano. Rende le pipeline più facili da ragionare, rielaborare e debuggare, perché puoi sempre ricostruire un livello a valle da quello soprastante.
Devo normalizzare o denormalizzare le mie tabelle analitiche?
Per carichi analitici e read-heavy su motori colonnari generalmente si denormalizza, usando star schema o tabelle larghe per ridurre i join e velocizzare le query, accettando un po' di ridondanza e scritture più complesse. La normalizzazione appartiene ai sistemi transazionali (OLTP) dove l'integrità in scrittura ed evitare anomalie di aggiornamento contano più della velocità in lettura. La decisione segue il pattern di accesso: modella per come i dati saranno interrogati, non per un ideale astratto di purezza.
Come rendo i backfill sicuri ed economici?
Rendi ogni task idempotente e con ambito di partizione così rieseguire un intervallo di date sovrascrive esattamente quell'intervallo invece di appendere duplicati. Esegui il backfill partizione per partizione con concorrenza limitata così controlli costi e carico sull'infrastruttura condivisa, e valida un campione prima di elaborare l'intera storia. Un orchestratore che supporta catchup e riesecuzioni partizionate, più un table format che supporta overwrite atomici di partizione, rende i grandi backfill ordinaria amministrazione invece che un rischio.
Cosa causa il data skew e come lo mitigo?
Il data skew è la distribuzione non uniforme dei dati tra chiavi o partizioni, così pochi task gestiscono molto più lavoro e diventano straggler che dominano il tempo del job, il più delle volte su join o aggregazioni su chiavi calde. Mitigalo con il salting della chiave skewata per distribuirla tra le partizioni, con il repartizionamento per bilanciare il carico, o con un broadcast join quando un lato è abbastanza piccolo da replicare. I motori moderni offrono anche l'adaptive query execution che può rilevare e dividere automaticamente le partizioni skewate.
Cos'è il data lineage e perché dovrei preoccuparmene?
Il data lineage è il record tracciabile di da dove vengono i dati e di come sono stati trasformati tra i sistemi fino allo stato attuale, catturato a livello di tabella o persino di colonna. Ti permette di fare analisi d'impatto prima di un cambiamento, debuggare dove ha avuto origine un numero sbagliato, provare la conformità e costruire fiducia mostrando ai consumatori la provenienza di un dataset. Senza lineage, ogni cambiamento a monte è un gioco di indovinelli e ogni incidente sui dati è un esercizio manuale di archeologia.