Un data mesh è un framework di architettura e organizzazione che tratta i dati come un prodotto (in questo documento denominato prodotti dati). In questo strumento, i prodotti di dati vengono sviluppati dai team che comprendono meglio questi dati e che seguono un insieme di standard di governance dei dati a livello di organizzazione. Una volta che i prodotti di dati sono stati implementati nel data mesh, i team distribuiti di un'organizzazione possono scoprire e accedere più rapidamente ed efficacemente ai dati pertinenti alle loro esigenze. Per ottenere un mesh di dati efficiente, devi prima stabilire i componenti di architettura di alto livello e i ruoli organizzativi descritti in questo documento.
Questo documento fa parte di una serie che descrive come implementare un data mesh su Google Cloud. Si presume che tu abbia letto e che tu abbia familiarità con i concetti descritti in Creare un data mesh moderno e distribuito con Google Cloud.
La serie è composta dalle seguenti parti:
- Architettura e funzioni in un mesh di dati (questo documento)
- Progettare una piattaforma di dati self-service per un mesh di dati
- Creare prodotti di dati in un mesh di dati
- Scoprire e utilizzare i prodotti di dati in un data mesh
In questa serie, il mesh di dati descritto è interno a un'organizzazione. Sebbene sia possibile estendere un'architettura data mesh per fornire prodotti dati a terze parti, questo approccio esteso non rientra nell'ambito di questo documento. L'estensione di un data mesh comporta considerazioni aggiuntive oltre all'utilizzo all'interno di un'organizzazione.
Architettura
I seguenti termini chiave vengono utilizzati per definire i componenti dell'architettura descritti in questa serie:
- Prodotto di dati:un prodotto di dati è un contenitore o un raggruppamento logico di una o più risorse di dati correlate.
- Risorsa dati:una risorsa dati è un asset fisico in un sistema di archiviazione che contiene dati strutturati o archivia una query che genera dati strutturati.
- Attributo dati:un attributo dati è un campo o un elemento di una risorsa di dati.
Il seguente diagramma fornisce una panoramica dei componenti di architettura chiave in un mesh di dati implementato su Google Cloud.
Il diagramma precedente mostra quanto segue:
- I servizi centrali consentono la creazione e la gestione dei prodotti di dati, inclusi i criteri dell'organizzazione che interessano i partecipanti al data mesh, i controlli di accesso (tramite i gruppi di Identity and Access Management) e gli elementi specifici dell'infrastruttura. Esempi di questi impegni e prenotazioni e dell'infrastruttura che facilita il funzionamento del data mesh sono descritti in Creare componenti e soluzioni della piattaforma.
- I servizi centrali forniscono principalmente Data Catalog per tutti i prodotti dati nel data mesh e il meccanismo di rilevamento per i potenziali clienti di questi prodotti.
- I domini dati espongono sottoinsiemi dei propri dati come prodotti di dati tramite interfacce di consumo dei dati ben definite. Questi prodotti di dati possono essere una tabella, una visualizzazione, un file strutturato, un argomento o uno stream. In BigQuery, si tratta di un set di dati, mentre in Cloud Storage si tratta di una cartella o di un bucket. Esistono diversi tipi di interfacce che possono essere esposte come prodotto di dati. Un esempio di interfaccia è una vista BigQuery su una tabella BigQuery. I tipi di interfacce più comunemente utilizzati per scopi di analisi sono descritti in Creare prodotti dati in un data mesh.
Implementazione di riferimento del mesh di dati
Puoi trovare un'implementazione di riferimento di questa architettura nel
repository data-mesh-demo.
Gli script Terraform utilizzati nell'implementazione di riferimento mostrano i concetti di data mesh e non sono destinati all'uso in produzione. Eseguendo questi script, imparerai a:
- Separa le definizioni dei prodotti dai dati sottostanti.
- Crea modelli di Data Catalog per descrivere le interfacce dei prodotti.
- Tagga le interfacce dei prodotti con questi modelli.
- Concedi le autorizzazioni ai consumatori del prodotto.
Per le interfacce dei prodotti, l'implementazione di riferimento crea e utilizza i seguenti tipi di interfaccia:
- Visualizzazioni autorizzate sulle tabelle BigQuery.
- Flussi di dati basati su argomenti Pub/Sub.
Per ulteriori dettagli, consulta il file README nel repository.
Funzioni in un data mesh
Affinché un data mesh funzioni correttamente, devi definire ruoli chiari per le persone che svolgono attività al suo interno. La proprietà viene assegnata agli archetipi di team o alle funzioni. Queste funzioni contengono i percorsi utente principali per le persone che lavorano nel data mesh. Per descrivere chiaramente i percorsi degli utenti, questi sono stati assegnati ai ruoli degli utenti. Questi ruoli utente possono essere suddivisi e combinati in base alle circostanze di ogni azienda. Non è necessario mappare i ruoli direttamente con dipendenti o team della tua organizzazione.
Un dominio dati è in linea con un'unità di business (BU) o una funzione all'interno di un'azienda. Esempi comuni di domini aziendali possono essere il reparto mutui di una banca o i reparti clienti, distribuzione, finanza o risorse RU di un'azienda. In un data mesh esistono concettualmente due funzioni correlate al dominio: i team di produttori di dati e i team di consumatori di dati. È importante comprendere che è probabile che un singolo dominio dati esegua entrambe le funzioni contemporaneamente. Un team di dominio dati produce prodotti dati dai dati di sua proprietà. Il team utilizza anche i prodotti di dati per approfondimenti commerciali e per produrre prodotti di dati derivati per l'utilizzo di altri domini.
Oltre alle funzioni basate sul dominio, un data mesh dispone anche di un insieme di funzioni eseguite da team centralizzati all'interno dell'organizzazione. Questi team centrali consentono il funzionamento del data mesh fornendo supervisione, servizi e governance tra domini. Riducono il carico operativo per i domini di dati nella produzione e nel consumo di prodotti di dati e facilitano le relazioni tra domini necessarie per il funzionamento del data mesh.
Questo documento descrive solo le funzioni con un ruolo specifico per il data mesh. Esistono diversi altri ruoli obbligatori in qualsiasi azienda, indipendentemente dall'architettura utilizzata per la piattaforma. Tuttavia, questi altri ruoli non rientrano nell'ambito di questo documento.
Le quattro funzioni principali di un data mesh sono le seguenti:
- Team di produttori basati su domini di dati: creano e gestiscono i prodotti di dati durante il loro ciclo di vita. Questi team vengono spesso indicati come produttori di dati.
- Team di consumatori basati su domini di dati: scopri i prodotti di dati e utilizzali in varie applicazioni di analisi. Questi gruppi potrebbero utilizzare i prodotti di dati per crearne di nuovi. Questi team vengono spesso indicati come consumatori di dati.
- Team di governance dei dati centrali: definisce e applica le norme di governance dei dati tra i produttori di dati, garantendo un'elevata qualità e attendibilità dei dati per i consumatori. Questo team è spesso indicato come team di governance dei dati.
- Team della piattaforma di infrastruttura di dati self-service centrale: fornisce una piattaforma di dati self-service per i produttori di dati. Questo team fornisce inoltre gli strumenti per l'individuazione dei dati centrali e l'osservabilità dei prodotti di dati utilizzati sia dai consumatori che dai produttori di dati. Questo team è spesso indicato come team della piattaforma di dati.
Una funzione extra facoltativa da considerare è quella di un centro di eccellenza (COE) per il data mesh. Lo scopo del COE è fornire la gestione della maglia di dati. Il COE è anche il team di arbitrato designato che risolve eventuali conflitti sollevati da altre funzioni. Questa funzione è utile per collegare le altre quattro funzioni.
Team di producer basato sul dominio di dati
In genere, i prodotti di dati vengono creati su un repository fisico di dati (uno o più data warehouse, lake o stream). Un'organizzazione necessita di ruoli della piattaforma di dati tradizionali per creare e gestire questi repository fisici. Tuttavia, in genere questi ruoli tradizionali della piattaforma di dati non sono costituiti dalle persone che creano il prodotto dati.
Per creare prodotti di dati da questi repository fisici, un'organizzazione ha bisogno di un mix di professionisti dei dati, come data engineer e data architect. La tabella seguente elenca tutti i ruoli utente specifici del dominio necessari nei team di produttori di dati.
Ruolo |
Responsabilità |
Competenze richieste |
Risultati desiderati |
|---|---|---|---|
Proprietario del prodotto di dati |
|
Data analytics Architettura dei dati Gestione dei prodotti |
|
Technical Lead dei prodotti di dati |
|
Data engineering Architettura dei dati Ingegneria del software |
|
Assistenza per i prodotti di dati |
|
Ingegneria del software Site Reliability Engineering (SRE) |
|
Esperto in materia (SME) per il dominio di dati |
|
Analisi dei dati Architettura dei dati |
|
Proprietario dei dati |
|
|
|
Team di consumatori basati sul dominio di dati
In un data mesh, le persone che utilizzano un prodotto dati sono in genere utenti di dati al di fuori del dominio del prodotto dati. Questi utenti utilizzano un catalogo di dati centralizzato per trovare prodotti dati pertinenti alle loro esigenze. Poiché è possibile che più di un prodotto di dati possa soddisfare le loro esigenze, i consumatori di dati possono finire per abbonarsi a più prodotti di dati.
Se i consumatori di dati non riescono a trovare il prodotto dati richiesto per il loro caso d'uso, è loro responsabilità rivolgersi direttamente al COE del data mesh. Durante la consulenza, i consumatori di dati possono comunicare le loro esigenze in materia di dati e chiedere consigli su come soddisfarle con uno o più domini.
Quando cercano un prodotto di dati, i consumatori di dati cercano dati che li aiutino a realizzare vari casi d'uso, come dashboard e report di analisi permanenti, report individuali sul rendimento e altre metriche sul rendimento aziendale. In alternativa, i consumatori di dati potrebbero cercare prodotti di dati che possono essere utilizzati in casi d'uso di intelligenza artificiale (AI) e machine learning (ML). Per ottenere questi diversi casi d'uso, i consumatori di dati richiedono un mix di persone esperte di dati, che sono le seguenti:
Ruolo |
Responsabilità |
Competenze richieste |
Risultati desiderati |
|---|---|---|---|
Analista di dati |
Cerca, identifica, valuta e sottoscrive prodotti di dati a dominio singolo o interdominio per creare una base per il funzionamento dei framework di business intelligence. |
Ingegneria di dati Business analytics |
|
Sviluppatore di applicazioni |
Sviluppa un framework di applicazioni per il consumo di dati in uno o più prodotti di dati, all'interno o all'esterno del dominio. |
Sviluppo di applicazioni Data engineering |
|
Esperto di visualizzazione dei dati |
|
Analisi dei requisiti Visualizzazione dei dati |
|
Data scientist |
|
Data engineering Data engineering |
|
Team di governance dei dati centrali
Il team di governance dei dati consente ai produttori e ai consumatori di dati di condividere, aggregare e calcolare i dati in modo sicuro e self-service, senza introdurre rischi di conformità per l'organizzazione.
Per soddisfare i requisiti di conformità dell'organizzazione, il team di governance dei dati è composto da diversi profili di professionisti dei dati, che sono i seguenti:
Ruolo |
Responsabilità |
Competenze richieste |
Risultati desiderati |
|---|---|---|---|
Esperto di governance dei dati |
|
Esperto legale Esperto in sicurezza Esperto in privacy dei dati |
|
Data steward (si trova all'interno di ogni dominio) |
|
Architettura dei dati Gestione e controllo dei dati |
|
Data governance engineer |
|
Ingegneria del software |
|
Team della piattaforma di infrastruttura di dati self-service centrale
Il team della piattaforma di infrastruttura dati self-service o semplicemente il team della piattaforma di dati è responsabile della creazione di un insieme di componenti dell'infrastruttura dati. I team di dominio dei dati distribuiti utilizzano questi componenti per creare ed eseguire il deployment dei propri prodotti di dati. Il team della piattaforma di dati promuove inoltre le best practice e introduce strumenti e metodologie che aiutano a ridurre il carico cognitivo dei team distribuiti quando adottano nuove tecnologie.
L'infrastruttura della piattaforma deve consentire un'integrazione facile con gli strumenti di gestione per l'osservabilità, la strumentazione e l'automazione della conformità a livello globale. In alternativa, l'infrastruttura dovrebbe facilitare questa integrazione per consentire ai team distribuiti di lavorare al meglio.
Il team della piattaforma di dati ha un modello di responsabilità condivisa che utilizza con i team di dominio distribuiti e con il team di infrastruttura di base. Il modello mostra le responsabilità previste per i consumatori della piattaforma e i componenti della piattaforma supportati dal team della piattaforma di dati.
Poiché la piattaforma di dati è essa stessa un prodotto interno, non supporta ogni caso d'uso. Il team della piattaforma di dati rilascia continuamente nuovi servizi e funzionalità in base a una roadmap con priorità.
Il team della piattaforma di dati potrebbe avere un insieme standard di componenti implementati e in sviluppo. Tuttavia, i team di dominio dati potrebbero scegliere di utilizzare un insieme diverso e unico di componenti se le esigenze di un team non sono in linea con quelle fornite dalla piattaforma di dati. Se i team di dominio dati scelgono un approccio diverso, devono assicurarsi che qualsiasi infrastruttura della piattaforma che creano e gestiscono sia conforme ai criteri e ai guardrail a livello di organizzazione per la sicurezza e la governance dei dati. Per l'infrastruttura della piattaforma di dati sviluppata al di fuori del team della piattaforma di dati centrale, il team della piattaforma di dati può scegliere di investire congiuntamente o di integrare i propri ingegneri nei team di dominio. La scelta del team della piattaforma di dati di investire congiuntamente o di integrare gli ingegneri potrebbe dipendere dall'importanza strategica dell'infrastruttura della piattaforma di dominio dati per l'organizzazione. Mantenendo attivo il coinvolgimento nello sviluppo dell'infrastruttura da parte dei team di dominio dati, le organizzazioni possono fornire l'allineamento e le competenze tecniche necessarie per eseguire il nuovo confezionamento di eventuali nuovi componenti dell'infrastruttura della piattaforma in fase di sviluppo per il riutilizzo futuro.
Potresti dover limitare l'autonomia nelle prime fasi di creazione di un data mesh se il tuo obiettivo iniziale è ottenere l'approvazione degli stakeholder per l'aumento della scalabilità del data mesh. Tuttavia, limitare l'autonomia rischia di creare un collo di bottiglia nel team della piattaforma di dati centralizzata. Questo collo di bottiglia può impedire la scalabilità del data mesh. Pertanto, qualsiasi decisione di centralizzazione deve essere presa con cautela. Per i produttori di dati, fare le proprie scelte tecniche tra un insieme limitato di opzioni disponibili potrebbe essere preferibile alla valutazione e alla scelta tra un elenco illimitato di opzioni. Promuovere l'autonomia dei produttori di dati non equivale a creare un panorama tecnologico senza regole. L'obiettivo è invece promuovere la conformità e l'adozione della piattaforma trovando il giusto equilibrio tra libertà di scelta e standardizzazione.
Infine, un buon team di piattaforme di dati è una fonte centrale di formazione e best practice per il resto dell'azienda. Di seguito sono riportate alcune delle attività più efficaci che consigliamo ai team della piattaforma di dati centrali di intraprendere:
- Favorire revisioni regolari del design dell'architettura per nuovi progetti funzionali e proporre modalità di sviluppo comuni per i team di sviluppo.
- Condividere conoscenze ed esperienze e definire collettivamente best practice e linee guida di architettura.
- Assicurarsi che gli ingegneri dispongano degli strumenti giusti per convalidare e verificare la presenza di errori comuni come problemi di codice, bug e cali delle prestazioni.
- Organizzazione di hackathon interni per consentire ai team di sviluppo di comunicare i propri requisiti per gli strumenti interni.
Ecco alcuni esempi di ruoli e responsabilità per il team della piattaforma dati centrale:
| Role | Responsabilità | Competenze richieste |
Risultati desiderati |
|---|---|---|---|
Proprietario del prodotto della piattaforma di dati |
|
Strategia e operazioni relative ai dati Gestione dei prodotti Gestione delle parti interessate |
|
Data platform engineer |
|
Data engineering Software engineering |
|
Engineer per la piattaforma e la sicurezza (un rappresentante dei team IT centrali come networking e sicurezza, integrato nel team della piattaforma di dati) |
|
Ingegneria delle infrastrutture Ingegneria del software |
|
Architetto enterprise |
|
Architettura dei dati Iterazione della soluzione e risoluzione dei problemi Raccolta del consenso |
|
Considerazioni aggiuntive per un mesh di dati
Esistono più opzioni di architettura per una piattaforma di dati di analisi, ciascuna con prerequisiti diversi. Per abilitare ogni architettura di data mesh, consigliamo alla tua organizzazione di seguire le best practice descritte in questa sezione.
Acquisire finanziamenti per la piattaforma
Come spiegato nel post del blog "Se vuoi trasformare, inizia con la finanza", la piattaforma non è mai completata: opera sempre in base a una roadmap con priorità. Pertanto, la piattaforma deve essere finanziata come prodotto, non come progetto con un endpoint fisso.
Il primo che adotta il data mesh ne sostiene il costo. In genere, il costo è condiviso tra l'azienda che forma il primo dominio dati per avviare il data mesh e il team di tecnologia centrale, che in genere ospita il team della piattaforma di dati centrale.
Per convincere i team finanziari ad approvare il finanziamento della piattaforma centrale, ti consigliamo di creare un business case per il valore della piattaforma centralizzata che verrà realizzato nel tempo. Questo valore deriva dalla reimplementazione degli stessa componenti nei singoli team di pubblicazione.
Definisci la piattaforma minima per il data mesh
Per aiutarti a definire la piattaforma minima per il data mesh, consigliamo di eseguire il progetto pilota e l'iterazione con uno o più casi d'uso. Per il tuo progetto pilota, trova i casi d'uso necessari e i consumatori pronti ad adottare il prodotto di dati risultante. I casi d'uso dovrebbero già disporre di finanziamenti per sviluppare i prodotti di dati, ma dovrebbe essere necessario l'input dei team tecnici.
Assicurati che il team che implementa il progetto pilota comprenda il modello di funzionamento del data mesh come segue:
- L'attività (ovvero il team di produzione dei dati) è proprietaria del backlog, del supporto e della manutenzione.
- Il team centrale definisce i pattern self-service e aiuta l'attività a creare il prodotto di dati, ma lo trasferisce all'attività per la gestione e la proprietà al termine del processo.
- L'obiettivo principale è dimostrare il modello operativo dell'attività (domini prodotti, domini consumati). L'obiettivo secondario è dimostrare il modello operativo tecnico (pattern self-service sviluppati dal team centrale).
- Poiché le risorse del team della piattaforma sono limitate, utilizza il modello di team di trunk e branch per mettere in comune le conoscenze, ma consenti comunque lo sviluppo di servizi e prodotti della piattaforma specializzati.
Ti consigliamo inoltre di procedere come segue:
- Pianifica le roadmap anziché lasciare che i servizi e le funzionalità si evolvano in modo organico.
- Definisci le funzionalità minime di una piattaforma valida che comprendono importazione, archiviazione, elaborazione, analisi e ML.
- Integra la governance dei dati in ogni passaggio, non come flusso di lavoro separato.
- Implementa le funzionalità minime per governance, piattaforma, flusso di valore e gestione del cambiamento. Le funzionalità minime sono quelle che coprono l'80% dei casi d'uso aziendali.
Pianifica la coesistenza del data mesh con una piattaforma dati esistente
Molte organizzazioni che vogliono implementare un data mesh probabilmente hanno già una piattaforma dati esistente, ad esempio un data lake, un data warehouse o una combinazione di entrambi. Prima di implementare un data mesh, queste organizzazioni devono elaborare un piano per l'evoluzione della loro piattaforma di dati esistente man mano che il data mesh cresce.
Queste organizzazioni devono prendere in considerazione fattori quali:
- Le risorse di dati più efficaci nel data mesh.
- Gli asset che devono rimanere all'interno della piattaforma di dati esistente.
- Se le risorse devono essere spostate o se possono essere mantenute sulla piattaforma esistente e continuare a partecipare al data mesh.
Passaggi successivi
- Per scoprire di più sulla progettazione e sul funzionamento di una topologia cloud, consulta il Framework dell'architettura Google Cloud.
- Per altre architetture di riferimento, diagrammi e best practice, visita il Cloud Architecture Center.