Come implementare data fabric, mesh e lakehouse per far evolvere analytics e BI in un ambiente sempre più diversificato e distribuito per la trasformazione digitale. Comprendere i diversi framework architetturali significa trovare soluzioni nuove ai problemi di data delivery
A chi è entrato nelle professioni nell’ambito del data management solo negli ultimi vent’anni, o più in particolare dal 2010, può sembrare naturale iniziare tutte le considerazioni sull’architettura e la governance dai “big data”. Dopotutto, i big data non sono la linfa vitale del business digitale e il cuore pulsante dell’intelligenza artificiale? I volumi, la velocità e la varietà dei big data non sono forse le principali sfide che l’IT deve affrontare nella progettazione e fornitura di soluzioni di trasformazione digitale?
Nella mia qualità di veterano nel settore del data management, sostengo che siano state apprese lezioni significative sulla gestione dei dati negli anni precedenti all’allagamento del data lake. Tuttavia, molte di queste lezioni sono state dimenticate o, almeno, ridotte al minimo dall’ascesa dei big data e dalla corsa al cloud. Le virgolette che poco sopra ho messo su big data danno qualche indizio su ciò che credo sia stato dimenticato o minimizzato. So, ovviamente, che i big data non hanno più il prestigio che detenevano una volta. Non si tratta di big data, ci è stato detto negli ultimi anni. Sono solo dati. C’è del vero in questa affermazione, anche se il ragionamento alla base può spesso essere sbagliato. Vedremo queste interpretazioni errate mentre discutiamo dell’implementazione di un data lakehouse, fabric o mesh.
Dal lago alla casa sul lago, dall’acqua ai mattoni
Secondo i promotori di Databricks (“Frequently Asked Questions About the Data Lakehouse”, 2021), la convinzione alla base del data lakehouse è che “oggi, la stragrande maggioranza dei dati aziendali atterra in data lake, sistemi di storage a basso costo in grado di gestire qualsiasi tipo di dati” e sempre più archiviati in object storage su piattaforme cloud. Questa affermazione è innegabile per qualsiasi azienda che opera, elabora e gestisce la propria attività interamente nel cloud. Il data lake, concepito per la prima volta quando i big data erano centrali, è stato proposto come un modo per gestire la dimensione e l’incertezza dei dati provenienti dall’esterno. Per le aziende che non avevano una storia di data warehousing tradizionale o sistemi operativi on-premise, il data lake era quindi il luogo più ovvio per iniziare a creare sistemi di BI e analytics. Le apparenti e molto enfatizzate opportunità di risparmio di Hadoop e cloud hanno portato le aziende “bricks and mortar”, con data warehouse tradizionali già esistenti, ad adottare il paradigma del data lake. E hanno subito scoperto i problemi di gestione e di qualità dei dati che si sono presentati. Le aziende incentrate sul cloud hanno avuto gli stessi problemi. I data lake sono diventati data swamp.
Le acque cristalline del lago si sono trasformate in paludi. Il data lakehouse è un approccio basato sulla tecnologia che permette di preservare i vantaggi in termini di costo dello storage con archiviazione “a oggetti”, ricreando nell’ambiente cloud il software fondamentale dei data warehouse (database relazionali completi di tutte le funzionalità). Le tecnologie e il pensiero dei big data vengono adattati a problemi che erano stati precedentemente risolti negli ambienti tradizionali. È un approccio che vedo spesso, nel quale le decisioni di platforming basate sugli aspetti finanziari vengono prese senza alcun riferimento alle effettive capacità tecnologiche della nuova piattaforma e ai conseguenti costi crescenti di migrazione. Inoltre, il software necessario è ancora agli esordi.
Un altro mesh in cui siamo capitati
La fondatrice del modello di data mesh, Zhamak Dehghani di Thoughtworks, in un suo famoso articolo che ha fatto scuola (“How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh”, 2019), spiega come “la prossima architettura della enterprise data platform è nella convergenza tra l’architettura guidata dal dominio distribuito, la progettazione self-service delle piattaforme, e il pensare ai prodotti con i dati”. Sebbene apparentemente indipendente dalla piattaforma, gran parte di questo lavoro emerge dall’esperienza di sviluppo di nuovi sistemi operativi in un ambiente ibrido e multi-cloud altamente distribuito e dall’evoluzione dei microservizi e degli approcci DevOps necessari per avere successo. C’è molto pensiero prezioso nel modello di data mesh, in particolare su come affrontare i dati e lo sviluppo in un ambiente altamente distribuito sia fisicamente sia a livello organizzativo. Tuttavia, le lezioni apprese nell’epoca pre-big data, sono raramente menzionate. I microservizi sono figli della Service oriented architecture (SOA) degli anni 90. Sia il pensiero SOA/microservizi sia il pensiero domain-driven / product-centric sono emersi specificamente nei sistemi operativi. L’applicazione diretta dei principi dello sviluppo di sistemi operativi ai sistemi informativi è tutt’altro che semplice. In particolare, il pensiero guidato dal dominio presenta sfide significative per la progettazione e la delivery di risorse di dati interfunzionali riconciliate e coerenti, come i data warehouse aziendali. L’implementazione del data mesh è quindi impegnativa. Il pensiero “big data-like” delle sue fondamenta architetturali non si adatta bene con l’approccio di riconciliazione dei dati del data warehousing. Inoltre, stanno ancora emergendo i software necessari per fornire alcuni dei componenti chiave di un data mesh. Saranno quindi necessari livelli sostanziali di sviluppo interno da nuovi progetti open source.
L’implementazione di un fabric potrebbe essere chiamata fabbricazione?
Dei tre modelli discussi qui, il data fabric è il più lontano dal pensiero sui big data. Le sue origini in grandi società di analisi, come Forrester e, più recentemente, Gartner, assicurano una base più ampia. Tuttavia, queste stesse origini portano a un modello più incentrato sul prodotto, basato sulle capacità esistenti e previste nell’ecosistema dei fornitori di gestione dei dati. Il data fabric è un’estensione del data warehousing logico, incentrato sui metadati e sugli strumenti necessari per gestire e automatizzare la delivery delle informazioni alle persone del business da qualsiasi fonte. Naturalmente, nessuna di queste aree di interesse è nuova, visto che entrambe risalgono ai primi giorni del data warehousing. Due le novità importanti: l’attenzione crescente sulla semantica e le ontologie nei metadati – o meglio le informazioni di impostazione del contesto (CSI, context setting information), considerata la sua portata enormemente ampliata; e il riconoscimento del fatto che le informazioni di impostazione del contesto devono essere attive e riflettere lo stato vivo e in continua evoluzione dell’ambiente informativo. Il data fabric propone inoltre un ruolo importante per il machine learning nell’attivazione delle CSI e nell’automazione di molti aspetti della data delivery. Sebbene numerosi vendor supportino il modello di data fabric e molti prodotti commerciali e progetti open source possano contribuire alla sua implementazione, gli strumenti rimangono frammentati e forniscono funzioni di base invece che data fabric a tutti gli effetti. Lo sviluppo interno sarà ancora necessario nel prossimo futuro per integrare queste offerte.
Conclusioni
In sintesi, possiamo dire che tutti e tre i modelli offrono un pensiero interessante ma divergente su come far evolvere analytics e BI in un ambiente sempre più diversificato e distribuito per la trasformazione digitale. A seconda del punto di partenza e delle competenze, uno potrebbe essere più rilevante degli altri. Tuttavia, il pensiero sottostante a tutti e tre dovrebbe essere studiato da vicino da tutti i dipartimenti di analytics, BI, data warehouse, data lake.
Barry Devlin
Tra i più autorevoli esperti mondiali di Business Insight e Data Warehousing, oltre a essere consulente, speaker e autore del famoso libro “Data Warehouse – from Architecture to Implementation”. L’attività di ricerca di Barry Devlin finalizzata alla creazione di un business completamente integrato, copre ambienti informativi, operativi e collaborativi per offrire una esperienza olistica del business attraverso l’IT. È fondatore di 9sight Consulting, società di consulenza specializzata nel progettare soluzioni di Business Insight, che opera con i principali analisti e vendor in ambito BI e oltre.
Barry Devlin presenterà per Technology Transfer il seminario “Implementare Data Fabric, Mesh o Lakehouse: Capire i Digital Information System” che si terrà online live streaming il 23-24 maggio 2022.
