Se osserviamo questo flusso generico di dati in un’organizzazione che utilizza un’architettura dati centralizzata, ci rendiamo conto che esistono 3 punti di contatto per i dati:
- Produttori di dati
- Squadra dati centrale
- Consumatori di dati
Ora poniamoci alcune domande per cominciare:
- Chi gestisce il data warehouse?
- Quale squadra risponde alle richieste di dati?
- Quale team è responsabile di garantire la qualità dei dati?
- Quale team dovrebbe essere la PMI per i dati?
Quando ho posto queste domande a un gruppo di persone, ho ottenuto una risposta comune a tutte le domande (in combinazione con altre): opzione B, Central Data Team.
Possiamo quindi dedurre che il team dei dati centrali deve:
- Gestire il magazzino dati
- Servire richieste di dati
- Garantire la qualità dei dati
- Essere PMI per i dati nel data warehouse
E la lista continua.
Quindi cosa mancava?
Man mano che un’azienda continua a crescere, il team centrale dei dati tende a diventare il collo di bottiglia nell’ottenere informazioni utili dai dati.
I team di dati centrali finiscono per avere un carico di conoscenze elevato e una pressione di consegna sempre crescente.
Ciò rafforza la mia tesi per giustificare l’esistenza dell’architettura dei dati decentralizzata popolarmente conosciuta come Data Mesh.
Data Mesh è un tipo di architettura analitica ma soprattutto un modello operativo che trasferisce la proprietà dei dati analitici ai team che conoscono e possiedono i dati più intimamente: i produttori e i consumatori di dati.
Questa immagine mostra una vista di alto livello dell’architettura Data Mesh:
https://martinfowler.com/articles/data-monolith-to-mesh/data-mesh.png
Non entrerò nei principi o nell’architettura logica di Data Mesh poiché ci sono molti articoli là fuori che gli rendono giustizia. Ecco alcuni dei miei preferiti:
Fonte: towardsdatascience.com
