Il Data Mesh e la spinta verso una gestione dati distribuita
Abstract
Questo è il sesto articolo di una serie di blog post finalizzata a trasmettere i punti salienti della visione delle architetture IT enterprise e del Data Management che, come Quantyca, proponiamo ai nostri clienti.
Per chi non li avesse letti, consiglio di leggere gli articoli precedenti della serie, dai titoli:
- “I principi di un moderno Data Management”: descrive le sfide dell’IT nella nuova era di digitalizzazione e i driver che spingono verso la ricerca di un cambio di paradigma nella progettazione delle architetture dati
- “L’approccio data-centrico che cambia l’IT”: descrive i principi e i vantaggi di un orientamento di progettazione delle architetture IT che considera i dati come asset centrale e riusabile e le applicazioni come elementi effimeri che producono o consumano dati di interesse per l’intera azienda
- “L’esigenza di governo nella gestione dei dati”: descrive i principali aspetti di governance da considerare per abilitare architetture IT data centriche e distribuite e mantenere il controllo dei dati a riposo e in movimento
- “L’adattabilità della piattaforma di integrazione in un modello Data Fabric”: descrive un modello emergente di progettazione delle piattaforme dati basato sull’uso avanzato dei metadati per rendere la piattaforma più automatizzata, self-service e versatile alle diverse esigenze degli utilizzatori
- “Il Domain Driven Design applicato ai dati per una maggiore agilità nella progettazione”: descrive i principi basilari del modello di progettazione software Domain Driven Design, che ha introdotto l’idea della decentralizzazione delle responsabilità e ha avuto grande influenza sul Data Management
Negli articoli successivi chiuderemo la discussione sui pillar del Data Mesh e trarremo le conclusioni su quella che può essere una strategia di Data Management in linea con le esigenze delle organizzazioni moderne.
I prossimi due articoli saranno:
- “Il Data Mesh e il principio di consumo self-service dei dati come prodotti”: descrive la visione dei dati come prodotti, che formano una rete di domain-oriented Data Product e sono fruiti tramite una piattaforma self-service e un modello di governance federato;
- “La Data Strategy come motore dell’IT”: chiude la serie con un riassunto dei principi architetturali che riteniamo basilari per una strategia di Data Management efficace e una visione del ruolo dell’Enterprise Architect nel delineare l’evoluzione delle architetture dati
Data Mesh: un radicale cambio di paradigma verso la democratizzazione dei dati
Nell’ambito dello sviluppo e dell’integrazione di applicazioni i principi del Domain Driven Design si sono concretizzati nella tendenza ad approcciare i progetti software distribuendo le responsabilità sui diversi Bounded Context a team cross-funzionali, allineati ai domini di business, che gestiscono il ciclo di vita end-to-end dei (micro)servizi di propria competenza: si è affermato pertanto un modello organizzativo decentralizzato e domain-oriented.
Formare dei team cross-funzionali significa prevedere all’interno del team stesso figure con specializzazione funzionale e tecnica differente: sviluppatori (Dev), specialisti di Continuous Integration e Continuous Deployment (Ops), specialisti di amministrazione di database (dbadmin), esperti di web user interface e user experience (UI/UX), esperti di dominio (Business) e subject matter expert (SME) di tematiche specifiche come, ad esempio, la web security.
Al contrario, nell’ambito del Data Management e delle analytics, si è consolidato negli anni un paradigma fortemente centralizzato, sia sotto l’aspetto tecnologico e delle piattaforme, sia sotto l’aspetto organizzativo. Esaminando infatti lo scenario tradizionale di suddivisione delle responsabilità sulle fasi di una data pipeline che abilita casi d’uso di Business Intelligence o Advanced Analytics, si delinea facilmente il quadro mostrato nella figura seguente.
Si nota che la pipeline è composta da tre blocchi principali:
- ad un’estremità della pipeline si collocano le applicazioni sorgenti (data provider) e i relativi team di dominio che le gestiscono, i quali considerano i dati prodotti dalle applicazioni di propria competenza come un by-product, di cui vengono chieste delle estrazioni per esigenze di altri gruppi di lavoro, senza avere visibilità sulle finalità dell’utilizzatore finale e sulle modalità di utilizzo;
- nella parte centrale della pipeline si collocano una serie di team con una forte caratterizzazione tecnica e competenze specifiche su determinate aree di Data Management, che si mappano sulle diverse fasi di ETL / ELT: il team di Data Engineering si occupa dello sviluppo della pipeline, oltre che della definizione e ottimizzazione del modello dati, il team esperto di tecnologie Big Data si occupa dell’organizzazione e l’elaborazione dei dati nel Data Lake, il team di Data Governance definisce centralmente le policy e gli standard di gestione dei dati, il team di Data Security e Data Privacy stabilisce quali tecniche di Data Protection implementare sui dati personali e quali politiche di controllo di accesso prevedere. A questi team nel loro complesso viene chiesto di integrare e consolidare una serie di entità dati di cui non conoscono il significato di business, nè le finalità e le modalità di utilizzo da parte degli utilizzatori finali che ne hanno fatto richiesta;
- all’estremità finale della pipeline si colloca una pletora di team di analisti, esperti di Business Intelligence e Data Science, che chiedono ai team centrali responsabili dell’integrazione la messa a disposizione dei dati, esprimendo ciascuno le sue esigenze in termini di priorità e deadline di delivery: questi team non hanno alcuna visibilità sulla provenienza, sulla qualità e sull’affidabilità dei dati che vengono loro forniti.
A livello architetturale e tecnologico, si è passati dalle prime architetture incentrate sull’Enterprise Data Warehouse, in cui si mirava alla raccolta e l’integrazione di dati consolidati e ben strutturati in un repository centralizzato quale era appunto l’EDW, che avrebbe assolto a tutte le necessità analitiche, all’avvento dei Big Data e alla diffusione dei Data Lake, in cui si pensava di poter superare i limiti del Data Warehouse collezionando nel lake ingenti moli di dati, non obbligatoriamente strutturati, e demandando a query time (schema on read) l’onere di interpretarne correttamente il contenuto ed estrarne le informazioni di interesse. Successivamente sono state proposte le più moderne architetture Data Lakehouse, che cercano di sfruttare i punti di forza di entrambe le famiglie di tecnologie che si erano affermate in precedenza (Data Warehouse, tipicamente basati su data store colonnari, MPP e OLAP da un lato, cloud object store, virtualizzatori, query engine Big Data e framework di calcolo distribuito dall’altro), per fornire una migliore esperienza analitica a supporto di vari use case.
In ogni caso, le evoluzioni tecnologiche che si sono succedute hanno una caratteristica comune, ovvero la presenza di un componente di data storage centralizzato che avrebbe la funzione di rappresentare tutti i dati aziendali in un unico modello enterprise-wide. Si è però osservato che, con l’aumentare del numero e della varietà delle applicazioni data provider e data consumer, ma soprattutto della complessità di dominio, in molti contesti non è più realistico pensare di progettare un unico modello dati aziendale, in quanto non riuscirebbe a rappresentare in modo esaustivo le sfaccettature delle diverse aree del dominio e diventerebbe un punto di accoppiamento forte tra le diverse sorgenti e i diversi target, rendendo poco agile l’evoluzione della base dati.
Zhamak Dehghani, negli articoli How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh e Data Mesh Principles and Logical Architecture, ha proposto un cambio di paradigma radicale per il mondo del Data Management, che ha poi ripreso ed esteso nel libro Data Mesh. Il paradigma, chiamato appunto Data Mesh, si basa su quattro pillar basilari:
- domain ownership
- data as a product
- selve-serve data platform
- federated computational governance
In Quantyca riteniamo che le idee alla base del paradigma Data Mesh siano interessanti e che questo rappresenti una direzione di pensiero architetturale e organizzativo per il mondo del Data Management in linea con le aspettative di un business che intende essere sempre più data-driven. Nella prossima sezione introduciamo il primo pillar, quello della Domain Ownership, lasciando al prossimo articolo la discussione sugli altri.
Domain Ownership
Il paradigma Data Mesh propone di ricondurre la responsabilità end-to-end sui dati analitici al team che gestisce il dominio di business (il Bounded Context, in termini Domain Driven Design) a cui i dati appartengono.
Invece di occuparsi solamente dello sviluppo del software di dominio e delle integrazioni operazionali, lasciando l’onere di estrarre, integrare, consolidare e distribuire i dati ad un team centrale di data engineer non a conoscenza delle logiche di dominio e del significato semantico dei dati, il team che gestisce il Bounded Context e le sue applicazioni dovrebbe prendersi in carico anche la generazione, la condivisione e la manutenzione dei dati analitici di propria competenza. In quest’ottica, i domini di business richiedono di essere gestiti da team cross-funzionali non solo sul piano dei sistemi operazionali, ma anche per il mondo del data management, affiancando allo staff Dev-Ops che gestisce le applicazioni di dominio figure di data engineer, data-ops, data analyst, data scientist ed esperti di data privacy.
Avendo una conoscenza diretta del significato dei dati prodotti dal Bounded Context e ricevendo direttamente le richieste di utilizzo dei dati di propria competenza da parte dei team consumatori (analisti, data scientist, partner esterni, ad esempio), il team responsabile di un dominio di business può condividere i dati core di dominio secondo i principi dei Data On The Outside in modo maggiormente efficace e consumer-oriented.
Un altro obiettivo di questo principio è quello di rimuovere colli di bottiglia nella gestione del ciclo di vita dei dati, rappresentati dai team centrali, aumentando l’autonomia, l’agilità e la velocità di sperimentazione e delivery di servizi data-driven a beneficio del business aziendale.
Il raggiungimento di un modello organizzativo di Data Management completamente decentralizzato può avvenire in modo incrementale, passando per periodi transitori più o meno lunghi in cui l’azienda, in base alle esigenze particolari e ai vincoli del contesto in cui opera, può strutturarsi con modelli ibridi, in base ai quali la decentralizzazione delle responsabilità in ottica domain-oriented viene applicata solo ad alcune tipologie di dati e non ad altre. Una possibile distinzione può essere data dalla gestione dei dati grezzi, intesi come i dati che spesso vengono estratti dai sistemi data provider, non secondo i principi di Data On The Outside consumer-oriented ma secondo un approccio di integrazione tradizionale, dai dati elaborati, intesi come gli eventi di dominio, che sono già passati per le fasi di modellazione semantica, standardizzazione e cleansing, o gli eventi di business arricchiti che sono pronti a supportare le analisi.
La figura seguente rappresenta alcuni esempi di scenari che si possono collocare sulla scala di Data Mesh.
Il quadrante in basso a sinistra nella figura rappresenta lo scenario di completa assenza di Data Mesh, in cui sia l’offloading dei dati dalle sorgenti e l’alimentazione della data platform, così come lo sviluppo dei data mart per le analisi sono gestiti da team centrali, specialisti delle funzioni di data engineering e data analysis.
Il quadrante in basso a destra nella figura rappresenta un modello ibrido verso il Data Mesh, in cui le prime fasi di estrazione dati dalle sorgenti e alimentazione dei livelli bassi della data platform sono ancora in carico ad un team centrale che, ad esempio, racchiude le competenze sulle tecnologie di elaborazione dei big data e sulle tecniche di data offloading da sistemi legacy, mentre le fasi di alimentazione dei modelli dimensionali specifici dei diversi domini è gestito dai team verticali delle singole linee di business, in modo indipendente e federato, ciascuno secondo le particolari esigenze e priorità.
Il quadrante in alto a sinistra rappresenta invece la situazione opposta, in cui i diversi Bounded Context hanno la responsabilità di produrre sulla piattaforma di integrazione dati i Data On The Outside dei rispettivi domini, prevedendo le fasi di cleansing e standardizzazione del formato e della semantica internamente ai Bounded Context, precedentemente alla pubblicazione dei dati sulla piattaforma di integrazione; al contrario, la fase di consolidamento dei dati e la traduzione in un modello analitico enterprise è ancora gestita da un team centrale di esperti di modellazione di data warehouse. Questo modello può essere utile quando si vuole centralizzare la gestione dei dati elaborati per dare garanzie forti di consistenza e integrità dei dati messi a disposizione delle analisi.
Il quadrante in alto a destra rappresenta lo scenario Data Mesh puro, in cui sia i dati grezzi sia i dati elaborati sono gestiti in modo decentralizzato, portando alla formazione di una rete di architectural quanta rappresentati da domain-oriented Data Product, la cui responsabilità è assegnata ai team di dominio.
Nel prossimo articolo tratteremo gli altri tre pillar, rispettivamente Data as a Product, Self-Serve Data Platform e Federated Computational Governance, tracciando anche un confronto con il modello di piattaforma Data Fabric, discusso in uno dei precedenti articoli.
