In passato, le pipeline di dati seguivano una sequenza rigorosa, ovvero estraevano i dati dai sistemi di origine, li trasformavano in un formato pulito e strutturato, quindi caricavano il prodotto finito in un database. Questa sequenza (estrazione, trasformazione, caricamento o ETL) aveva senso quando l'archiviazione era costosa e i sistemi di destinazione non erano abbastanza potenti per eseguire calcoli pesanti.

Tuttavia, i cloud warehouse hanno cambiato le cose e l'ELT (estrazione, caricamento, trasformazione) è diventato il modello predefinito per molti team di analisi. Sebbene l'ETL tradizionale mantenga una quota di mercato di quasi il 40%, sta rapidamente perdendo terreno rispetto ad altri tipi di pipeline di dati come l'ELT.

Di seguito, analizziamo cos'è l'ELT, come funziona e quando è o non è adatto.

In evidenza

• Un processo ELT (estrazione, caricamento, trasformazione) carica innanzitutto i dati grezzi in un cloud warehouse e successivamente li trasforma. Ciò offre agli analisti un accesso più rapido ai dati e una maggiore flessibilità per migliorare i modelli.

• I cloud warehouse sono molto adatti per l'ELT perché separano l'archiviazione dal calcolo, si espandono in modo elastico e consentono agli analisti di scrivere la logica di trasformazione in Structured Query Language (SQL).

• Lavorare con un fornitore di servizi di pagamento che si sincronizza direttamente con il warehouse senza il routing attraverso un'infrastruttura di terze parti riduce la complessità della pipeline e l'esposizione in termini di sicurezza.

Cos'è l'ELT e come funziona?

L'ELT (estrazione, caricamento, trasformazione) è un modello di integrazione dei dati basato su tre passaggi: l'estrazione dei dati dai sistemi di origine, il caricamento allo stato grezzo in una destinazione centrale, quindi la trasformazione all'interno della destinazione per l'analisi, il reporting o il machine learning.

Ecco come si svolge in pratica un tipico flusso di lavoro ELT:

• Estrazione: un connettore o un processo della pipeline estrae i record da un sistema di origine (in modo incrementale, in base a una pianificazione o ad attivazione tramite eventi) e li scrive nella destinazione nella loro struttura originale.

• Caricamento: le tabelle grezze arrivano nel warehouse, spesso in uno schema dedicato, preservando i nomi dei campi, i tipi di dati e le relazioni esattamente come esistevano nell'origine.

• Trasformazione: la logica di trasformazione viene eseguita all'interno del warehouse in quanto gli strumenti basati su SQL, come lo strumento di compilazione dei dati (dbt), consentono ai team di controllare le versioni di questi modelli, di testarli e di creare dataset sul livello grezzo.

Poiché i dati grezzi vengono caricati per primi, gli analisti possono eseguire immediatamente query su di essi e inoltre, possono creare più visualizzazioni a valle da un'unica origine senza dover estrarre di nuovo i dati. Se un modello di trasformazione è sbagliato, è possibile riscriverlo ed eseguirlo nuovamente sui dati già presenti nel warehouse.

Qual è la differenza in pratica tra ELT ed ETL?

La principale differenza architetturale tra ETL ed ELT consiste nel punto in cui avviene la trasformazione: all'esterno della destinazione nell'ETL, all'interno della destinazione nell'ELT.

Ecco le principali differenze tra ETL ed ELT:

• Disponibilità dei dati: in una pipeline ETL non è possibile eseguire query sui dati finché non vengono trasformati e caricati. Nell'ELT, i dati grezzi vengono caricati per primi, in modo che gli analisti possano lavorarci mentre i processi di trasformazione vengono eseguiti separatamente.

• Velocità di miglioramento: la modifica di una trasformazione in una pipeline ETL spesso significa dover ricostruire la pipeline stessa. Nell'ELT, aggiorni un modello SQL e lo esegui nuovamente rispetto ai dati già presenti nel warehouse.

• Posizione delle risorse di calcolo: le trasformazioni ETL vengono eseguite nell'infrastruttura della pipeline (un server separato o un servizio di cui viene eseguito il provisioning a tale scopo). Le trasformazioni ELT vengono eseguite nelle risorse di calcolo del data warehouse, che si espande in modo elastico ed è già pagato.

• Conservazione dei dati grezzi: l'ETL in genere scarta gli stati intermedi una volta prodotto l'output trasformato. Per impostazione predefinita, l'ELT mantiene il livello grezzo, il che significa che puoi rielaborare i dati storici quando i requisiti cambiano.

Perché l'approccio ELT è adatto ai moderni data warehouse cloud?

Le seguenti proprietà rendono l'ELT una scelta naturale per i warehouse cloud:

• Archiviazione ed elaborazione separate: piattaforme come Snowflake e BigQuery addebitano costi separati per l'archiviazione dei dati e per le query. Puoi archiviare tutti i dati grezzi che desideri e i processi di trasformazione consumano risorse di calcolo solo quando vengono eseguiti.

• Scalabilità elastica: puoi creare le risorse di calcolo necessarie, eseguire il processo e ridurle nuovamente. Il warehouse gestisce la parallelizzazione.

• Archiviazione colonnare: i warehouse cloud archiviano i dati in formato colonnare, il che rende le query analitiche (aggregazioni, filtri, join su set di dati di grandi dimensioni) notevolmente più veloci rispetto all'archiviazione basata su righe.

• SQL nativo: la maggior parte degli analisti e degli ingegneri analytics conosce già SQL. L'esecuzione delle trasformazioni all'interno del warehouse significa che le persone che comprendono la logica dell'attività possono scrivere e gestire direttamente i modelli di trasformazione.

Quando l'ELT è la scelta giusta?

L'ELT non è la risposta giusta per ogni pipeline di dati, ma si adatta a una serie di condizioni specifiche.

Ecco quando l'ELT tende a funzionare bene:

• Dataset di grandi dimensioni o in rapida crescita: se sincronizzi milioni di eventi al giorno, l'esecuzione delle trasformazioni prima del caricamento richiede una notevole infrastruttura di pipeline. Il caricamento di dati grezzi e la trasformazione all'interno del warehouse sono più pratici su larga scala.

• Logica di trasformazione che cambia di frequente: se le trasformazioni si trovano all'interno del warehouse come modelli SQL, l'aggiornamento dei requisiti di analisi non richiede la ridistribuzione dell'infrastruttura della pipeline.

• Molteplici casi d'uso a valle: i dati grezzi nel warehouse possono alimentare contemporaneamente una dashboard di business intelligence, un archivio delle funzioni di machine learning e un report operativo. Crei un'unica pipeline e modelli i dati in modo diverso per ciascun utente.

• Team con funzionalità di progettazione analitica: l'ELT sposta la proprietà della trasformazione al livello di analisi. I team che utilizzano strumenti come dbt sono particolarmente adatti a questo scopo.

L'ELT non è la scelta adatta nelle seguenti circostanze:

• Vincoli normativi sui dati grezzi: alcuni ambienti di assistenza sanitaria e dati finanziari vietano l'arrivo di dati sensibili prima del mascheramento o del filtro. In questi casi, le trasformazioni devono avvenire a monte.

• Schemi di destinazione rigidi: se la tua destinazione non è in grado di accogliere dati grezzi o semi-strutturati, l'approccio con caricamento iniziale dell'ELT crea più problemi di quanti ne risolva.

• Dataset stabili e di piccole dimensioni: se una semplice pipeline ETL fa il suo lavoro, l'aggiunta dell'infrastruttura di trasformazione del warehouse rappresenta un sovraccarico senza grandi vantaggi.

Quali sfide comporta l'ELT?

Il caricamento di dati grezzi in un warehouse è uno strumento potente, ma può comportare sfide in termini di governance e di costi.

Considera queste potenziali sfide dell'ELT.

Controllo degli accessi

Le tabelle grezze spesso contengono dati che non dovrebbero essere ampiamente accessibili, come le informazioni sull'identità, i record finanziari o gli identificatori interni. Nell'ETL, i campi sensibili possono essere mascherati o eliminati prima che i dati raggiungano la destinazione. Nell'ELT, tuttavia, i dati vengono prima caricati. Senza la sicurezza a livello di riga, il mascheramento delle colonne o ruoli del warehouse rigorosamente definiti, gli analisti possono eseguire query su campi che non dovrebbero poter vedere.

Qualità dei dati

Dati errati provenienti da origini a monte arrivano nel warehouse prima dell'esecuzione di qualsiasi controllo. I campi nulli, i record duplicati, le modifiche allo schema e le mancate corrispondenze di tipo possono propagarsi nei modelli a valle se non crei test di qualità nel livello di trasformazione con il framework di test di dbt o le funzioni di qualità dei dati native del warehouse.

Gestione dei costi

I processi di trasformazione vengono eseguiti nel calcolo del warehouse e l'SQL scritto in modo errato (come le scansioni illimitate, i filtri di partizione mancanti o gli aggiornamenti ridondanti dell'intera tabella) può generare costi sostanziali. Vale la pena integrare fin dall'inizio nel flusso di lavoro i limiti per i costi delle query, l'utilizzo di modelli incrementali ove possibile e il monitoraggio dell'uso delle risorse di calcolo.

In che modo un flusso di lavoro ELT gestisce i dati dei pagamenti?

Molti team creano un'integrazione personalizzata rispetto all'interfaccia di programmazione dell'applicazione (API) del proprio fornitore di servizi di pagamento o utilizzano un connettore di terze parti. Tuttavia, le integrazioni personalizzate richiedono una manutenzione continua al variare dell'API e i connettori di terze parti implicano il routing di dati finanziari sensibili tramite un'infrastruttura di fornitori aggiuntiva.

Stripe Data Pipeline è un'opzione nativa integrata direttamente nella Dashboard Stripe. Sincronizza i dati e i report di Stripe su Snowflake, Databricks, Amazon Redshift e altri ancora in pochi clic. Presenta un approccio no-code e non sono previste configurazioni del connettore né credenziali separate da gestire. La sincronizzazione viene eseguita utilizzando la stessa infrastruttura di Stripe, quindi nessun sistema di terze parti gestisce i tuoi dati finanziari in transito.

Ecco alcune specifiche che vale la pena conoscere:

• Copertura storica: Stripe Data Pipeline include i dati storici dall'inizio del tuo account Stripe, anziché dal momento in cui abiliti la sincronizzazione.

• Schema: i dati arrivano in tabelle che rispecchiano il modello dei dati di Stripe (ad es. addebiti, clienti, abbonamenti), in questo modo è semplice creare modelli di trasformazione a un livello superiore senza un'estesa pulizia del livello grezzo.

• Completezza dei dati: oltre ai dati grezzi degli oggetti, Stripe Data Pipeline include l'accesso a report finanziari predefiniti e dataset curati, in grado di accelerare la creazione di report e ridurre il lavoro di trasformazione per casi d'uso comuni come i ricavi mensili ricorrenti (RMR) e l'analisi delle frodi.