Cos'è l'architettura delle pipeline di dati?

L'architettura delle pipeline di dati è la progettazione end-to-end di come i dati vengono raccolti, elaborati, archiviati e distribuiti dai sistemi di origine alle persone, alle applicazioni e ai modelli che li utilizzano. La parola "architettura" si riferisce al progetto, non alla pipeline stessa. Copre le decisioni su come fluiscono i dati, dove vengono trasformati e quali strumenti gestiscono ogni fase del percorso.

Una buona architettura è adattata al caso d'uso specifico, anziché essere una soluzione standard pronta all'uso. Una pipeline di dati creata per il rilevamento delle frodi in tempo reale è molto diversa da una che genera un report delle vendite notturno, anche se entrambe spostano i dati dall'origine alla destinazione. Questa pagina del glossario illustra i livelli fondamentali comuni a ogni pipeline, i modelli di fase tipici, i principali pattern architetturali e le best practice per mantenere le pipeline affidabili man mano che scalano.

Come funziona l'architettura delle pipeline di dati?

Una pipeline di dati sposta i dati attraverso una serie di fasi, e ogni fase ha un compito specifico: raccogliere i dati, pulirli, archiviarli e renderli utilizzabili. L'architettura è il piano che stabilisce come si collegano queste fasi. Definisce cosa succede ai dati in ogni passaggio, in quale ordine e secondo quali regole.

Le decisioni di architettura si collocano su due livelli. Il design logico definisce quali fasi esistono e cosa fa ciascuna di esse: questo è il "cosa". Il design fisico definisce quali strumenti e infrastrutture specifici eseguono ciascuna fase: questo è il "come". L'orchestrazione (la pianificazione e il coordinamento automatici di ogni passaggio) e il monitoraggio non appartengono a una singola fase, ma vengono eseguiti sull'intera pipeline. Le piattaforme moderne hanno inoltre superato una vecchia divisione. Con Lakeflow, Databricks unifica le pipeline batch e in streaming su un'unica base, evitando ai team di dover creare e gestire due sistemi paralleli.

I livelli fondamentali di una pipeline di dati

Indipendentemente dal pattern scelto da un team, ogni pipeline di dati si basa sui quattro stessi livelli. Ciascun livello risponde a una domanda diversa sui dati: come entrano, come diventano utili, dove risiedono e chi li consuma.

Ingestione

L'ingestione estrae i dati nella pipeline dai sistemi di origine: database, applicazioni, API, file nel cloud storage, stream di eventi e sensori. L'ingestione dei dati si presenta in due modalità. L'ingestione batch estrae i dati in base a una pianificazione, ad esempio ogni ora o ogni notte. L'ingestione in streaming acquisisce i dati continuamente, man mano che si verificano gli eventi. Molte pipeline utilizzano anche il change data capture (CDC), un metodo che traccia le modifiche a livello di riga in un database di origine, in modo che la pipeline sposti solo i dati nuovi o aggiornati anziché ricaricare tutto.

Elaborazione e trasformazione

In questo livello i dati grezzi vengono puliti, rimodellati, arricchiti e preparati per l'uso. Le attività tipiche includono la correzione dei valori mancanti, la standardizzazione dei formati, l'unione di dataset e l'applicazione della logica di business, ovvero le stesse attività alla base dell'ETL. L'elaborazione segue la stessa suddivisione dell'ingestione. L'elaborazione batch lavora su grandi blocchi di dati contemporaneamente, mentre l'elaborazione stream gestisce i record uno alla volta o in piccolissimi micro-batch man mano che arrivano.

Archiviazione

L'archiviazione è il punto in cui arrivano i dati elaborati per poter essere interrogati, analizzati o inseriti nei modelli. La destinazione è in genere un data lake, un data warehouse o un lakehouse, un singolo sistema che unisce i punti di forza di entrambi. Il formato conta tanto quanto la posizione. I formati aperti come Lakehouse Storage e Apache Iceberg consentono a più strumenti di leggere gli stessi dati senza doverli copiare da un sistema all'altro. Delta Lake aggiunge inoltre funzionalità di affidabilità come le transazioni ACID (una garanzia che le scritture vadano completamente a buon fine o falliscano del tutto, prevenendo la corruzione dei dati) e il time travel (la capacità di interrogare versioni precedenti di una tabella).

Distribuzione e consumo

L'ultimo livello distribuisce i dati preparati alle persone e ai sistemi che ne hanno bisogno: analisti che eseguono query SQL, utenti aziendali che lavorano su dashboard, data scientist che addestrano modelli e applicazioni che richiamano API. Le destinazioni variano dagli strumenti di BI alle piattaforme di ML fino ai sistemi operativi, con un data warehouse che spesso si trova al centro dei carichi di lavoro di analisi. In tutti e quattro i livelli, l'orchestrazione e l'osservabilità svolgono il lavoro di collegamento: pianificazione dei job, tracciamento della qualità dei dati e generazione di avvisi in caso di problemi.

Quante fasi ci sono in una pipeline di dati? (3 vs 4 vs 5)

Fonti diverse descrivono le pipeline di dati come composte da tre, quattro o cinque fasi, il che genera molta confusione. La realtà è più semplice: tutti e tre i modelli descrivono lo stesso lavoro di base a diversi livelli di dettaglio.

Il numero di fasi è una scelta di classificazione. Il lavoro svolto dalla pipeline è lo stesso.

Pattern comuni di architettura delle pipeline di dati

I pattern architetturali sono i modelli consolidati tra cui i team scelgono quando creano le pipeline. Quello giusto dipende dai requisiti di latenza, dal volume dei dati e da come i dati verranno utilizzati a valle.

Architettura batch

L'architettura batch elabora i dati in blocchi pianificati: ogni ora, ogni notte o ogni settimana. È adatta per la reportistica, l'analisi storica, i dati di addestramento ML e qualsiasi caso d'uso in cui siano accettabili ritardi di minuti o ore. Le pipeline batch sono più semplici da creare, più economiche da eseguire e più facili da sottoporre a debug rispetto alle controparti in streaming. Il compromesso riguarda la freschezza dei dati: quando le decisioni dipendono da ciò che è accaduto pochi secondi prima, il batch non riesce a tenere il passo.

Architettura in streaming

L'architettura in streaming elabora i dati in modo continuo, record per record, man mano che vengono generati. Serve per i casi d'uso in cui è fondamentale una risposta inferiore al minuto: rilevamento delle frodi, personalizzazione in tempo reale e monitoraggio IoT. Il compromesso è il costo: le pipeline in streaming in genere costano di più da eseguire e gestire rispetto alle pipeline batch perché richiedono un'infrastruttura sempre attiva.

Architettura Lambda

L'architettura Lambda esegue due percorsi paralleli. Un percorso batch fornisce dati storici accurati, un percorso in streaming fornisce dati rapidi e freschi, e un livello di serving unisce i risultati. Il design funziona, ma comporta un noto svantaggio: gestire due pipeline significa duplicare il codice, duplicare la logica e raddoppiare il carico operativo.

Architettura Kappa

L'architettura Kappa semplifica la Lambda utilizzando un'unica pipeline in streaming per tutto. Quando è necessaria l'analisi storica, lo stream viene riprodotto dall'inizio. Kappa è adatta ai team che desiderano una freschezza dei dati di livello streaming senza i costi di gestione di due sistemi paralleli.

Architettura Medallion (pattern lakehouse)

L'architettura Medallion è un pattern diffuso sulle piattaforme lakehouse che organizza i dati in tre livelli di qualità: Bronze (grezzi, così come inseriti), Silver (puliti e conformati) e Gold (curati e pronti per il business). Come indicato nella documentazione di Databricks, "l'architettura medallion utilizza tre livelli: bronze, silver e gold, ciascuno con uno scopo distinto nella pipeline". Ogni livello può essere eseguito come una propria pipeline, il che semplifica la pianificazione, il monitoraggio e la risoluzione dei problemi, poiché questi ultimi rimangono isolati in un singolo livello.

ETL vs ELT: come l'ordine di trasformazione modella l'architettura

ETL ed ELT si differenziano per il momento in cui i dati vengono trasformati. L'ETL (extract, transform, load) trasforma i dati prima di caricarli nell'archiviazione. L'ELT (extract, load, transform) carica prima i dati grezzi e li trasforma all'interno della destinazione. Le moderne piattaforme cloud come Databricks, Snowflake e BigQuery hanno reso l'ELT il pattern dominante, poiché l'archiviazione e l'elaborazione cloud sono ormai sufficientemente economiche ed elastiche da consentire la trasformazione dei dati in loco. Per un confronto più approfondito, vedi ETL vs ELT.

L'ETL è la stessa cosa di una pipeline di dati?

No. L'ETL è un tipo di pipeline di dati, ma non tutte le pipeline di dati sono ETL. Una pipeline di dati è la categoria generale: qualsiasi sistema che sposta i dati da un punto a un altro. L'ETL è un approccio specifico all'interno di questa categoria, caratterizzato dalla trasformazione dei dati prima che vengano archiviati. Le pipeline possono anche essere ELT, in streaming, di sola replica (che spostano i dati senza alcuna trasformazione) o reverse ETL (che inviano i dati del data warehouse ai sistemi operativi).

Best practice per l'architettura delle pipeline di dati

Questi 10 principi di progettazione distinguono le pipeline scalabili da quelle che si interrompono.

1. Separa l'ingestione dalla trasformazione. Mantieni la ricezione dei dati grezzi e la pulizia dei dati in fasi diverse, in modo che i problemi di una non si ripercuotano sull'altra.
2. Progetta per l'idempotenza. Una pipeline deve poter essere eseguita nuovamente in sicurezza senza creare record duplicati o compromettere i risultati. Questo è fondamentale per gestire i guasti e i backfill.
3. Integra controlli sulla qualità dei dati. Controlli rigorosi sulla qualità dei dati convalidano lo schema, gli intervalli di valori, il conteggio dei valori nulli e la freschezza in ogni fase, segnalando chiaramente gli errori anziché consentire il passaggio di dati non corretti a valle.
4. Pianifica per lo schema drift. I sistemi di origine cambiano. Le pipeline devono rilevare l'aggiunta, la rimozione o la ridenominazione delle colonne e gestire il cambiamento in modo fluido anziché bloccarsi.
5. Usa formati di archiviazione aperti. Formati come Delta Lake e Apache Iceberg evitano il lock-in e consentono a più strumenti di leggere gli stessi dati senza creare copie.
6. Disaccoppia i livelli della pipeline. La suddivisione dei livelli medallion (Bronze, Silver e Gold) in pipeline separate rende ciascuna di esse più facile da pianificare, monitorare e risolvere in modo indipendente.
7. Sottoponi tutto a controllo di versione. Archivia il codice e la configurazione della pipeline in Git in modo che le modifiche siano revisionate, tracciabili e reversibili.
8. Tratta la governance come una priorità assoluta. Applica autorizzazioni coerenti, tracciamento della lineage e controlli di audit in ogni fase con uno strumento come Unity Catalog, anziché aggiungerli solo alla fine.
9. Dimensiona correttamente lo streaming rispetto al batch. Usa lo streaming solo dove la freschezza dei dati è davvero fondamentale e imposta il batch come predefinito in tutti gli altri casi per controllare i costi.
10. Monitora end-to-end. Traccia la freschezza, il volume e la qualità dei dati, nonché i tempi di esecuzione delle pipeline, in modo da individuare i problemi prima che se ne accorgano gli utenti a valle.

Perché l'architettura delle pipeline di dati è importante

L'architettura delle pipeline determina se i team possono fidarsi dei propri dati, se le decisioni si basano su informazioni fresche e se i progetti di AI e ML passano dal prototipo alla produzione. È la differenza tra una piattaforma dati che acquisisce valore nel tempo e una che genera continuamente ticket di assistenza.

Un'architettura fragile comporta costi reali: dashboard obsolete, metriche contrastanti, deployment di ML falliti e ingegneri che passano più tempo a risolvere emergenze che a sviluppare. L'approccio lakehouse moderno affronta la causa alla radice. Unificando batch e streaming, analytics e AI, e la governance su un'unica piattaforma come la piattaforma Databricks, i team eliminano i passaggi fragili tra i sistemi che causano l'interruzione delle architetture tradizionali.

Architettura delle pipeline di dati su Databricks

Databricks offre ogni livello dell'architettura delle pipeline in un'unica piattaforma. Lakeflow Connect gestisce l'ingestione da database, applicazioni SaaS, sorgenti di file e stream di eventi. Lakeflow Spark Declarative Pipelines consente di creare pipeline ETL batch e streaming con controlli integrati sulla qualità dei dati, mentre Lakeflow Jobs orchestra e pianifica le esecuzioni delle pipeline sull'intera piattaforma. Alla base, Delta Lake fornisce il formato di archiviazione aperto insieme a funzionalità di affidabilità come le transazioni ACID e il time travel, mentre Unity Catalog applica governance, lineage e controllo degli accessi in ogni fase.

Poiché le pipeline batch e streaming vengono eseguite sullo stesso motore e scrivono nello stesso spazio di archiviazione, i team non devono gestire sistemi paralleli in stile Lambda. Un'unica definizione di pipeline può servire sia il report notturno che la dashboard in tempo reale.

Domande frequenti

Che cos'è l'architettura delle pipeline di dati in parole semplici?

È il piano che stabilisce come i dati si spostano dal punto in cui vengono creati a quello in cui diventano utili. Il piano definisce come i dati vengono raccolti, puliti e preparati, dove vengono archiviati e come vengono distribuiti alle persone e alle applicazioni che ne hanno bisogno.

Qual è la differenza tra l'architettura Lambda e quella Kappa?

L'architettura Lambda esegue due pipeline parallele, una batch e una streaming, e unisce i loro risultati in un serving layer. Kappa utilizza un'unica pipeline di streaming per tutto e riproduce lo stream quando è necessaria un'analisi storica. Kappa è più semplice da gestire, mentre Lambda persiste negli ambienti in cui i percorsi batch e streaming si sono evoluti separatamente.

Quando si dovrebbero usare le pipeline batch rispetto a quelle in streaming?

Usa lo streaming quando il valore dei dati diminuisce nel giro di pochi secondi o minuti, come nel rilevamento delle frodi, nella personalizzazione in tempo reale o nel monitoraggio delle apparecchiature. Usa il batch per tutto il resto, inclusi reportistica, analisi storica e dati di addestramento per il ML. Il batch è più semplice ed economico, quindi rappresenta la scelta predefinita più sensata finché un caso d'uso non dimostri la necessità di dati in tempo reale.

Qual è la differenza tra l'architettura logica e fisica di una pipeline?

L'architettura logica definisce le fasi di una pipeline e ciò che ciascuna di esse fa, indipendentemente da qualsiasi strumento. L'architettura fisica mappa tali fasi su tecnologie e infrastrutture specifiche. Di solito i team definiscono prima il design logico, per poi scegliere le piattaforme che lo implementano.

Adatta l'architettura al tipo di lavoro

L'architettura delle pipeline di dati è il progetto alla base del modo in cui i dati si spostano e diventano utili. L'architettura giusta è quella che bilancia freschezza, costi e affidabilità per lo specifico compito da svolgere, che si tratti di un report sulle vendite notturno o di un controllo antifrode eseguito in pochi millisecondi.

Scopri come Databricks unifica pipeline batch e streaming, archiviazione e governance su un'unica piattaforma.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale