Se stai creando una pipeline di dati per alimentare uno strumento di business intelligence o addestrare un modello di machine learning, una delle prime decisioni che devi prendere è dove avviene la trasformazione: prima che i dati arrivino nel tuo warehouse o dopo. Ciò significa che devi scegliere tra pipeline di estrazione, trasformazione e caricamento (ETL) e di estrazione, caricamento e trasformazione (ELT).

La scelta determina la rapidità con cui gli analisti possono accedere ai dati grezzi, la quantità di risorse di calcolo utilizzate e dove, nonché la facilità di adattamento quando il modello di dati cambia. Si prevede che il mercato globale degli strumenti per pipeline di dati raggiungerà un valore di 48,33 miliardi di $ entro il 2030 e l'ETL sta perdendo terreno rispetto all'ELT e ad altri tipi di pipeline.

Di seguito, analizzeremo il funzionamento di ciascun modello, quando ha più senso utilizzare l'ETL o l'ELT e come i connettori appositamente creati si integrano in entrambi gli approcci per origini dati specifiche.

In evidenza

• L'ETL trasforma i dati prima che raggiungano la destinazione. L'ELT carica i dati grezzi e li trasforma all'interno del warehouse utilizzando le proprie risorse di calcolo.

• L'ELT è il modello predefinito per la maggior parte dei moderni team che si occupano di dati. L'ETL rimane popolare per destinazioni limitate, requisiti di governance rigorosi e pipeline legacy.

• I connettori creati appositamente per origini dati specifiche possono ridurre il rischio di problemi di qualità dei dati che talvolta vengono introdotti dai connettori generici.

Pipeline ETL ed ELT: qual è la differenza?

ETL sta per "extract, transform, load" (estrazione, trasformazione e caricamento). In un modello ETL, i dati vengono estratti da un sistema di origine, eseguiti attraverso un livello di trasformazione che li pulisce, li rimodella e li filtra, quindi il risultato elaborato viene caricato in una destinazione, come un data warehouse o un data mart.

Con il modello ETL, un motore di elaborazione separato si occupa della maggior parte del lavoro prima che i dati raggiungano la destinazione. Il data warehouse riceve dati strutturati e pronti per essere interrogati anziché record di origine non elaborati. Rielaborare dall'origine significa dover estrarre di nuovo i dati o mantenere una copia non elaborata separata da qualche altra parte.

ELT, che sta per "extract, load, transform" (estrazione, caricamento e trasformazione), inverte gli ultimi due passaggi. I dati non elaborati arrivano prima nella destinazione, quindi le trasformazioni vengono eseguite all'interno del data warehouse utilizzando la relativa elaborazione.

Questo passaggio è diventato pratico quando i data warehouse basati sul cloud hanno reso economico e veloce eseguire le trasformazioni SQL (Structured Query Language) in set di dati di grandi dimensioni. Invece di avere un motore di trasformazione separato tra origine e destinazione, il data warehouse funge da ambiente di trasformazione.

Come funziona il modello ETL?

Una pipeline ETL viene eseguita in tre fasi, ciascuna con una responsabilità distinta.

Ecco come funziona il modello ETL:

• Extract (Estrazione): un connettore o un processo di importazione estrae dati dall'origine, come un database, un'API (Application Programming Interface) di pagamento, una piattaforma Software-as-a-Service (SaaS) o un file flat. Questo passaggio gestisce l'autenticazione, la paginazione, la logica di aggiornamento incrementale rispetto a quello completo e i limiti di frequenza.

• Transform (Trasformazione): i dati estratti si spostano in un livello di elaborazione in cui vengono puliti (ad esempio, gestione dei valori nulli, cast dei tipi), rimodellati (ad esempio, join, aggregazioni, ridenominazione delle colonne), filtrati e a volte arricchiti con dati di riferimento provenienti da altre origini.

• Load (Caricamento): il set di dati elaborato viene caricato nella destinazione come sovrascrittura completa, come upsert o come accodamento, a seconda di come è configurata la pipeline.

L'uso dell'architettura ETL ha ancora senso in queste situazioni specifiche:

• Destinazioni vincolate: i data warehouse meno recenti o i sistemi locali con elaborazione limitata non possono eseguire in modo efficiente grandi trasformazioni in locale, quindi caricare dati pre-trasformati è l'unica opzione realistica.

• Requisiti di governance rigorosi: alcune organizzazioni devono garantire che le informazioni sull'identità o i dati finanziari sensibili non arrivino mai nel data warehouse in formato non elaborato. La trasformazione e il mascheramento a monte soddisfano questo requisito a livello di architettura.

• Ambienti edge: i sistemi IoT (Internet of Things) e i sistemi incorporati che inviano dati all'infrastruttura centrale spesso non possono inviare grandi payload non elaborati, il che rende la trasformazione locale prima della trasmissione una necessità pratica.

• Debito tecnico per le pipeline preesistenti: molte organizzazioni consolidate dispongono di pipeline ETL che funzionano in modo affidabile da anni. La ricostruzione come ELT comporta un rischio che potrebbe non valere la pena di correre.

Come funziona il modello ELT?

Le pipeline ELT estraggono e caricano i dati di origine non elaborati o con formattazione leggera direttamente nella destinazione. Le trasformazioni vengono eseguite successivamente, attivate in base a una pianificazione o su richiesta, utilizzando l'elaborazione del data warehouse.

Ad esempio, un connettore può estrarre i dati da un'origine e scriverli in uno schema non elaborato nel data warehouse. Un ingegnere del team di analisi scrive modelli di dbt (Data Build Tool) che leggono da quello schema non elaborato, applicano la logica di business e creano tabelle pulite su cui gli strumenti di business intelligence (BI) possono eseguire query. Quando la logica deve essere modificata, è sufficiente aggiornare il modello ed eseguirlo nuovamente sui dati che sono già lì.

Il modello ELT è una scelta intelligente per i seguenti motivi:

• Accesso più rapido ai dati non elaborati: i dati arrivano rapidamente nel data warehouse, in modo che i team possano iniziare a esplorarli e convalidarli prima che il livello di trasformazione sia terminato.

• Miglioramenti più economici: modificare una trasformazione in un'architettura ETL spesso significa modificare una pipeline, rielaborare i dati e ricaricarli. Con il modello ELT, è sufficiente aggiornare un modello SQL ed eseguirlo nuovamente sui dati che già possiedi.

• Elaborazione su scala di warehouse: i data warehouse nel cloud sono progettati per elaborare rapidamente set di dati di grandi dimensioni, il che significa applicare elaborazioni importanti alla trasformazione anziché far crescere un livello di middleware separato in modo indipendente.

• Cronologia completa dei dati non elaborati: poiché i dati non elaborati si trovano sempre nel data warehouse, puoi ricavare da zero qualsiasi tabella downstream. Questo è importante quando le definizioni aziendali cambiano o quando devi eseguire il debug di un problema di qualità dei dati.

Come scegliere tra ETL ed ELT?

Le grandi organizzazioni di solito eseguono entrambi i modelli di elaborazione dei dati in parallelo per fonti diverse. Le esigenze della tua organizzazione ti aiuteranno a decidere quale metodo è più adatto.

Ecco cosa devi considerare.

Volume e velocità dei dati

I dati ad alto volume e ad alta frequenza generalmente prediligono una pipeline di dati ELT. I data warehouse nel cloud li gestiscono bene e il costo di esecuzione di un motore di trasformazione pesante a monte cresce rapidamente. Come compromesso, i costi di calcolo del warehouse aumentano quando le trasformazioni sono pesanti e l'archiviazione dei dati grezzi comporta dei costi.

Le pipeline a basso volume con logiche di trasformazione stabili e ben definite possono rimanere su ETL senza troppi problemi.

Proprietà della trasformazione

Se le tue trasformazioni sono basate su SQL e di proprietà di analytics engineer che devono adattarsi rapidamente, l'ELT con dbt o uno strumento simile è probabilmente la scelta migliore.

Se le tue trasformazioni sono codificate in Python o Java e sono di proprietà di un team di data engineering, l'ETL potrebbe integrarsi naturalmente nella tua toolchain esistente.

Accesso ai dati grezzi

Se gli analisti hanno bisogno di accedere ai dati di origine grezzi (ad es. per esplorazioni ad hoc, controlli o perché la logica di trasformazione è ancora in fase di sviluppo), l'ELT è l'impostazione predefinita migliore. Le pipeline ETL che non conservano i dati grezzi rendono difficile integrare a posteriori questo tipo di accesso.

Governance e compliance

Se dati specifici devono essere mascherati o resi anonimi prima di raggiungere una destinazione condivisa, l'ETL ti offre l'applicazione architettonica di questo requisito.

L'ELT può soddisfare molti degli stessi requisiti attraverso la sicurezza a livello di colonna e i controlli di accesso a livello di warehouse, ma l'implementazione differisce e vale la pena esaminarla rispetto ai tuoi obblighi di compliance.

Flusso di lavoro del team

Un team con una profonda padronanza di SQL e abitudini di controllo della versione con dbt trarrà più valore da una configurazione ELT rispetto al mantenimento di una pipeline ETL personalizzata che non ha creato. La compatibilità con il modo di lavorare del tuo team è un fattore legittimo.

Come si inseriscono i connettori di dati nelle pipeline ETL ed ELT?

Gli strumenti ETL ed ELT generici gestiscono un'ampia gamma di origini tramite connettori configurabili. Questa ampiezza è utile, ma comporta dei compromessi.

I dati sui pagamenti sono un buon esempio. Il modello dei dati di Stripe include eventi, addebiti, rimborsi, contestazioni, transazioni del saldo, clienti, abbonamenti e fatture. Un connettore generico che non tiene il passo con il controllo delle versioni dell'API di Stripe o che gestisce in modo errato la logica di sincronizzazione incrementale può produrre errori difficili da intercettare prima che incidano su una dashboard o su una riconciliazione finanziaria.

Stripe Data Pipeline risolve direttamente questo problema:

• Creato e gestito da Stripe: poiché Stripe possiede il connettore e rispecchia direttamente la sua infrastruttura interna, puoi sincronizzare i dati in modo affidabile e continuativo, garantendone la completezza e la precisione, indipendentemente dalla quantità di dati di cui disponi e senza limiti di frequenza delle API.

• Sincronizzazione diretta del data warehouse: i dati vengono trasferiti ad Amazon Redshift, Snowflake, Databricks e ad altre soluzioni senza passare tramite un connettore di terze parti, il che evita di dover gestire i dati finanziari sensibili tramite infrastrutture aggiuntive dei fornitori.

• Set di dati Stripe completo: la sincronizzazione copre oggetti Stripe, report finanziari predefiniti e set di dati selezionati per accelerare analisi e report.

• Configurazione leggera: la connessione viene configurata nella Dashboard Stripe, in modalità no-code. Se esegui già pipeline ELT per altre origini, i dati di Stripe rientrano nello stesso modello.