Data Fabric contro tutti: ETL – La rivoluzione dell’integrazione dei dati
Il Data Fabric è un concetto piuttosto recente; eccezion fatta per gli addetti ai lavori, molte altre figure potrebbero non avere familiarità con questo paradigma. Per questo motivo abbiamo deciso di creare una serie di post sul blog per confrontare Data Fabric con strumenti più noti e facilitare la comprensione di questo nuovo paradigma. Questo articolo è il secondo della serie, dopo il confronto tra Data Fabric and iPaaS. Prima di leggere questo articolo consigliamo di leggere il precedente, in quanto qui alcuni concetti saranno dati per scontati.
In questo articolo, continuiamo a confrontare il paradigma del Data Fabric con un altro modello di integrazione dei dati, ossia l’ETL (Extract, Transform, Load). Illustreremo cosa sono l’ETL e l’ELT (Extract, Load, Transform), le loro principali funzionalità e le differenze con il Data Fabric.
Che cos’è ETL (Extract, Transform, Load)?
Secondo la definizione di IBM, ETL, acronimo di Extract, Transform e Load, è un processo di integrazione dei dati che combina i dati provenienti da più origini dati in un singolo archivio dati coerente che viene caricato in un data warehouse o su altri sistemi di destinazione
. È importante notare che questa definizione evidenzia il fatto che, purché si segua il processo, è possibile personalizzare ogni fase in base alle proprie esigenze specifiche.
Che cos’è ELT (Extract, Load, Transform)?
L’ELT è simile all’ETL, ma le fasi vengono eseguite in un ordine diverso. I dati grezzi vengono caricati nel data store finale (che sia un database, un data lake, un data warehouse o altro), il quale si occupa del processo di trasformazione.
La trasformazione dei dati è la fase più complessa e pesante dell’intero processo: rimandarla alla fine ha il vantaggio di rendere più veloci le due fasi precedenti. Per questo motivo, l’ELT è più indicato per la gestione di grandi quantità di dati non strutturati. Inoltre, l’ELT è adatto a casi d’uso in cui la trasformazione non è un processo ad alto consumo e non richiede troppe risorse computazionali.
Tuttavia, è importante notare che i dati vengono salvati nella fase di caricamento: se la trasformazione avviene dopo il salvataggio, significa che i dati trasformati non sono persistenti. Perciò, l’ELT è consigliato per scopi che non richiedono la persistenza dei dati trasformati.
Data Fabric vs ETL: differenze e sinergie
Per la definizione di Data Fabric rimandiamo al precedente articolo.
Poiché stiamo confrontando i due paradigmi, è importante precisare che Data Fabric può essere considerato un’evoluzione di ETL/ELT. Infatti questi ultimi sono consolidati da più tempo, mentre il primo è un paradigma recente. Quindi, in generale, un Data Fabric può eseguire tutte e tre le fasi che compongono un processo ETL/ELT, ma non solo. Tra le altre funzionalità del Data Fabric, oltre a quelle dell’ETL, ricordiamo:
- Virtualizzazione dei dati;
- Gestione dei metadati;
- Sicurezza dei dati;
- Distribuzione dei dati in near real-time.
Nelle sezioni che seguono, esamineremo le principali funzionalità di ETL/ELT e Data Fabric, mostrando le differenze tra loro. Nel farlo, evidenzieremo anche le possibili sinergie che emergeranno.
Disclaimer: d’ora in poi, per migliorare leggibilità, parleremo solo di ETL riferendoci però anche all’ELT. Di fatto, l’ETL è più ampiamente adottato e l’ELT può essere considerato un suo sottoinsieme.
Change Data Capture (CDC)
Una delle principali differenze tra Data Fabric ed ETL è che, in generale, quest’ultimo non dispone di un meccanismo di Change Data Capture (CDC). Ad eccezione di alcuni degli ETL più recenti che possono averlo, per la maggior parte di essi è necessario implementare un CDC separato che notifichi l’ETL in modo che estragga i dati quando serve. Senza un CDC di supporto, l’ETL deve estrarre i dati su base periodica. Inoltre, alcuni sistemi di origine non possono notificare o tenere traccia dei dati modificati: in questi casi, è necessario estrarre tutti i dati. Per grandi quantità di dati questa fase può richiedere molto tempo e risorse, anche se le modifiche effettive sono poche.
Invece, il Data Fabric ha un meccanismo di CDC integrato, quindi può concentrarsi solo sui dati che devono essere estratti. Soprattutto, il Data Fabric è in grado di automatizzare il processo di estrazione dall’origine dei dati. Come abbiamo già detto in un altro articolo, l’automazione è una delle principali responsabilità del Data Fabric, soprattutto grazie ai metadati.
Inoltre, i dati estratti non vengono memorizzati in un’area di staging dedicata come nei sistemi ETL, il che conferisce al Data Fabric prestazioni molto elevate.
Dati in tempo reale
Un’altra grande differenza è che le soluzioni ETL non sono in grado di supportare i dati in tempo reale, soprattutto perché non dispongono di un meccanismo CDC. Indipendentemente dall’ordine esatto dei passaggi, l’intero processo è lungo e richiede temposoprattutto per grandi quantità di dati: quindi, i dati aggiornati sono disponibili sul data store finale dopo un certo lasso di tempo. Considerando che per un ETL senza CDC possono passare settimane o mesi tra una scansione e l’altra, diventa chiaro che questi processi non possono funzionare per i moderni servizi cloud che devono essere sempre aggiornati.
D’altra parte, rendere disponibili i dati in tempo reale è una delle funzionalità chiave del Data Fabric. Il processo di rilevamento dei dati modificati sul sistema di origine, l’aggiornamento della single view e la sua pubblicazione richiede pochi millisecondi. Con un Data Fabric è possibile costruire servizi complessi sfruttando i dati in tempo reale.
Architettura a microservizi
Poiché l’ETL è un paradigma più datato, in genere non è costruito con un’architettura a microservizi.. Ciò si traduce in un processo più semplice, in quanto non è necessario affrontare la complessità portata dai microservizi, ma presenta anche degli svantaggi. Ad esempio, non è possibile scalare verticalmente solo la sezione software responsabile di una delle fasi, ma è necessario scalare l’intero sistema. Questo può essere molto costoso in termini di risorse utilizzate. Ma, soprattutto, in genere l’ETL non fornisce API per comunicare con altri sistemi. Pertanto, l’esposizione dei dati può essere lunga e difficile e richiede molto lavoro manuale.
Il Data Fabric, invece, può essere costruito seguendo un’architettura a microservizi. In questo modo, è possibile scalare solo i microservizi che lo richiedono, ottenendo un consumo di risorse più ottimizzato e sostenibile. Inoltre, è possibile utilizzare il linguaggio e la tecnologia cloud-native più appropriati per ogni microservizio, ottimizzando ulteriormente l’intero sistema. Inoltre, poiché i microservizi comunicano tra loro tramite API, è molto facile esporre i dati ad altri servizi che potrebbero averne bisogno.
Conclusione
In questo secondo articolo della serie “Data Fabric vs All”, lo abbiamo confrontato con il paradigma dell’ETL/ELT. Abbiamo analizzato le principali differenze tra loro, evidenziando come Data Fabric possa essere considerato un’evoluzione dell’ETL, in quanto offre le stesse funzionalità ampliandole con ulteriori capacità.
Mia-Platform Fast Data è la nostra soluzione Data Fabric costruita con un’architettura a microservizi. Si basa fortemente su un approccio No-Code, in modo che il team possa concentrarsi maggiormente sulla risoluzione dei problemi piuttosto che sul funzionamento delle cose. Per esplorare tutte le caratteristiche di Mia-Platform Fast Data, consulta la documentazione e richiedi una demo gratuita per vederlo in azione.

