Un data mesh è un framework architetturale e organizzativo che tratta i dati come un prodotto (indicato in questo documento come prodotti dati). In questo framework, i prodotti di dati vengono sviluppati dai team che comprendono meglio i dati e che seguono un insieme di standard di governance dei dati a livello di organizzazione. Una volta distribuiti i prodotti di dati nel data mesh, i team distribuiti di un'organizzazione possono scoprire e accedere ai dati pertinenti alle loro esigenze in modo più rapido ed efficiente. Per ottenere una mesh di dati così efficiente, devi prima stabilire i componenti architetturali 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. Presuppone che tu abbia letto e conosca i concetti descritti in Crea 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 una 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 ulteriori considerazioni oltre all'utilizzo all'interno di un'organizzazione.
Architettura
I seguenti termini chiave vengono utilizzati per definire i componenti architetturali descritti in questa serie:
- Prodotto di dati:un prodotto di dati è un contenitore logico o un raggruppamento 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 memorizza una query che genera dati strutturati.
- Attributo dei dati:un campo o un elemento di una risorsa dati.
Il seguente diagramma fornisce una panoramica dei componenti architetturali chiave in un data mesh implementato su Google Cloud.
Il diagramma precedente mostra quanto segue:
- I servizi centrali consentono la creazione e la gestione di prodotti di dati, tra cui policy dell'organizzazione che interessano i partecipanti al data mesh, controlli dell'accesso (tramite i gruppi Identity and Access Management) e gli artefatti specifici dell'infrastruttura. Esempi di questi impegni e prenotazioni e dell'infrastruttura che facilita il funzionamento del data mesh sono descritti in Crea 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 di 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, sarebbe un set di dati, mentre in Cloud Storage una cartella o 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 a fini analitici 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 del prodotto, l'implementazione di riferimento crea e utilizza i seguenti tipi di interfacce:
- 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, sono stati assegnati a ruoli utente. 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 di dati è allineato a un'unità aziendale o a una funzione all'interno di un'azienda. Esempi comuni di domini aziendali potrebbero essere il reparto mutui di una banca o i reparti clienti, distribuzione, finanza o risorseRUe di un'azienda. A livello concettuale, in una data mesh esistono due funzioni correlate al dominio: i team produttori di dati e i team consumatori di dati. È importante comprendere che un singolo dominio di dati probabilmente servirà entrambe le funzioni contemporaneamente. Un team di dominio dei dati produce prodotti dati a partire dai dati di sua proprietà. Il team utilizza anche prodotti di dati per ottenere informazioni sull'attività e per produrre prodotti di dati derivati per l'utilizzo di altri domini.
Oltre alle funzioni basate sul dominio, un data mesh ha anche 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 cross-domain. Riduce il carico operativo per i domini di dati nella produzione e nel consumo di prodotti di dati e facilita le relazioni cross-domain necessarie per il funzionamento del data mesh.
Questo documento descrive solo le funzioni che hanno un ruolo specifico per il data mesh. Esistono diversi altri ruoli necessari in qualsiasi impresa, indipendentemente dall'architettura utilizzata per la piattaforma. Tuttavia, questi altri ruoli non rientrano nell'ambito di questo documento.
Le quattro funzioni principali di una 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 chiamati produttori di dati.
- Team di consumatori basati sul dominio dei dati: Scopri i prodotti di dati e utilizzali in varie applicazioni di analisi. Questi team potrebbero utilizzare i prodotti di dati per crearne di nuovi. Questi team vengono spesso indicati come consumatori di dati.
- Team centrale di governance dei dati: definisce e applica le norme di governance dei dati tra i produttori di dati, garantendo un'elevata qualità e affidabilità dei dati per i consumatori. Questo team viene spesso chiamato team di governance dei dati.
- Team della piattaforma centrale self-service per l'infrastruttura dei dati: fornisce una piattaforma di dati self-service per i produttori di dati. Questo team fornisce anche gli strumenti per l'individuazione centralizzata dei dati e l'osservabilità dei prodotti di dati utilizzati sia dai consumatori che dai produttori di dati. Questo team è spesso chiamato 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 del mesh di dati. Il COE è anche il team di arbitrato designato che risolve eventuali conflitti sollevati da una qualsiasi delle altre funzioni. Questa funzione è utile per aiutare a collegare le altre quattro funzioni.
Team di producer basato sul dominio dei dati
In genere, i prodotti di dati vengono creati sopra un repository fisico di dati (uno o più data warehouse, data lake o stream). Un'organizzazione ha bisogno di ruoli della piattaforma di dati tradizionali per creare e gestire questi repository fisici. Tuttavia, questi ruoli tradizionali della piattaforma dati non sono in genere le 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 |
|
Analisi dei dati Architettura dei dati Gestione dei prodotti |
|
Data product technical lead |
|
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 dei dati |
|
Analisi di dati Architettura dei dati |
|
Proprietario dei dati |
|
|
|
Team di consumer basati sul dominio dei dati
In un data mesh, le persone che consumano un prodotto dati sono in genere utenti di dati che non fanno parte del dominio del prodotto dati. Questi consumatori di dati utilizzano un catalogo di dati centrale per trovare i prodotti dati pertinenti alle loro esigenze. Poiché è possibile che più di un prodotto di dati soddisfi 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à consultarsi direttamente con il COE del data mesh. Durante la consulenza, i consumatori di dati possono esprimere le loro esigenze di dati e chiedere consigli su come soddisfarle da uno o più domini.
Quando cercano un prodotto di dati, i consumatori di dati cercano dati che li aiutino a raggiungere vari casi d'uso, come dashboard e report di analisi persistenti, report sul rendimento individuale 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 realizzare questi vari casi d'uso, i consumatori di dati richiedono un mix di profili di professionisti dei dati, che sono i seguenti:
Ruolo |
Responsabilità |
Competenze richieste |
Risultati desiderati |
|---|---|---|---|
Analista di dati |
Cerca, identifica, valuta e sottoscrive prodotti di dati cross-domain o di un singolo dominio per creare una base per il funzionamento dei framework di business intelligence. |
Ingegneria di Analytics Analisi aziendale |
|
Sviluppatore di applicazioni |
Sviluppa un framework applicativo per il consumo di dati in uno o più prodotti di dati, all'interno o all'esterno del dominio. |
Sviluppo di applicazioni Data engineering |
|
Specialista di visualizzazione dei dati |
|
Analisi dei requisiti Visualizzazione dei dati |
|
Data scientist |
|
Ingegneria ML Ingegneria dell'analisi |
|
Team centrale di governance dei dati
Il team di governance dei dati consente a produttori e consumatori di condividere, aggregare e calcolare i dati in modo 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 un mix di profili di professionisti dei dati, che sono i seguenti:
Ruolo |
Responsabilità |
Competenze richieste |
Risultati desiderati |
|---|---|---|---|
Specialista della governance dei dati |
|
Esperto legale Esperto di sicurezza Esperto di privacy dei dati |
|
Data steward (all'interno di ogni dominio) |
|
Architettura dei dati Gestione e controllo dei dati |
|
Data governance engineer |
|
Ingegneria del software |
|
Team della piattaforma di infrastruttura dei dati self-service centrale
Il team della piattaforma di infrastruttura dei dati self-service, o semplicemente il team della piattaforma di dati, è responsabile della creazione di un insieme di componenti dell'infrastruttura dei dati. I team di domini di dati distribuiti utilizzano questi componenti per creare ed eseguire il deployment dei loro prodotti di dati. Il team della piattaforma di dati promuove anche le best practice e introduce strumenti e metodologie che contribuiscono a ridurre il carico cognitivo per i team distribuiti quando adottano nuove tecnologie.
L'infrastruttura della piattaforma deve fornire una facile integrazione con gli strumenti operativi per l'osservabilità globale, l'instrumentazione e l'automazione della conformità. In alternativa, l'infrastruttura dovrebbe facilitare l'integrazione per configurare team distribuiti per il successo.
Il team della piattaforma di dati ha un modello di responsabilità condivisa che utilizza con i team di dominio distribuiti e il team dell'infrastruttura sottostante. Il modello mostra quali responsabilità sono previste per i consumatori della piattaforma e quali componenti della piattaforma sono supportati dal team della piattaforma di dati.
Poiché la piattaforma di dati è un prodotto interno, non supporta tutti i casi d'uso. Il team della piattaforma di dati rilascia invece continuamente nuovi servizi e funzionalità in base a una roadmap con priorità.
Il team della piattaforma dati potrebbe avere un insieme standard di componenti in fase di sviluppo. Tuttavia, i team del dominio dei dati potrebbero scegliere di utilizzare un insieme di componenti diverso e unico se le esigenze di un team non sono in linea con quelle fornite dalla piattaforma di dati. Se i team del dominio dei dati scelgono un approccio diverso, devono assicurarsi che qualsiasi infrastruttura della piattaforma che creano e gestiscono sia conforme ai criteri e alle misure di protezione 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 centrale della piattaforma di dati, quest'ultimo potrebbe 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 integrare gli ingegneri potrebbe dipendere dall'importanza strategica dell'infrastruttura della piattaforma del dominio di dati per l'organizzazione. Se le organizzazioni rimangono coinvolte nello sviluppo dell'infrastruttura da parte dei team del dominio dei dati, possono fornire l'allineamento e le competenze tecniche necessarie per riconfezionare qualsiasi nuovo componente dell'infrastruttura della piattaforma in fase di sviluppo per il riutilizzo futuro.
Potresti dover limitare l'autonomia nelle prime fasi della creazione di un data mesh se il tuo obiettivo iniziale è ottenere l'approvazione degli stakeholder per scalare il data mesh. Tuttavia, limitare l'autonomia rischia di creare un collo di bottiglia nel team della piattaforma centrale per i dati. Questo collo di bottiglia può impedire la scalabilità del data mesh. Pertanto, qualsiasi decisione di centralizzazione deve essere presa con attenzione. Per i produttori di dati, effettuare le proprie scelte tecniche da un insieme limitato di opzioni disponibili potrebbe essere preferibile rispetto alla valutazione e alla scelta da un elenco illimitato di opzioni in autonomia. Promuovere l'autonomia dei produttori di dati non significa creare un panorama tecnologico non regolamentato. L'obiettivo è invece quello di promuovere la conformità e l'adozione della piattaforma trovando il giusto equilibrio tra libertà di scelta e standardizzazione.
Infine, un buon team della piattaforma 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 dati centralizzata di intraprendere:
- Promuovere revisioni regolari della progettazione dell'architettura per nuovi progetti funzionali e proporre metodi di sviluppo comuni per i team di sviluppo.
- Condividere conoscenze ed esperienze e definire collettivamente best practice e linee guida architetturali.
- Assicurarsi che gli ingegneri dispongano degli strumenti giusti per convalidare e verificare la presenza di problemi comuni come errori di codice, bug e cali di rendimento.
- Organizzare hackathon interni in modo che i team di sviluppo possano esprimere i propri requisiti per le esigenze di strumenti interni.
Esempi di ruoli e responsabilità per il team della piattaforma dati centrale potrebbero includere quanto segue:
| Role | Responsabilità | Competenze richieste |
Risultati desiderati |
|---|---|---|---|
Product owner della piattaforma di dati |
|
Strategia e operazioni sui dati Gestione dei prodotti Gestione delle parti interessate |
|
Data platform engineer |
|
Data engineering Ingegneria del software |
|
Ingegnere della piattaforma e della sicurezza (un rappresentante dei team IT centrali, come quelli di rete e sicurezza, che fa parte del team della piattaforma dati) |
|
Ingegneria delle infrastrutture Ingegneria del software |
|
Enterprise Architect |
|
Architettura dei dati Iterazione della soluzione e risoluzione dei problemi Creazione del consenso |
|
Considerazioni aggiuntive per un mesh di dati
Esistono diverse opzioni di architettura per una piattaforma di dati di analisi, ognuna con prerequisiti diversi. Per abilitare ogni architettura 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 dalla finanza", la piattaforma non è mai finita: funziona sempre in base a una roadmap con priorità. Pertanto, la piattaforma deve essere finanziata come un prodotto, non come un progetto con un endpoint fisso.
Il primo ad adottare il data mesh si fa carico del costo. In genere, il costo viene condiviso tra l'attività che forma il primo dominio di dati per avviare il mesh di dati e il team tecnologico centrale, che in genere ospita il team della piattaforma di dati centrale.
Per convincere i team finanziari ad approvare i finanziamenti per la piattaforma centrale, ti consigliamo di creare un business case per il valore della piattaforma centralizzata che viene realizzato nel tempo. Questo valore deriva dalla reimplementazione degli stessi componenti nei singoli team di pubblicazione.
Definisci la piattaforma minima praticabile per il data mesh
Per aiutarti a definire la piattaforma minima praticabile per il data mesh, ti consigliamo di eseguire un progetto pilota e di iterare con uno o più casi d'uso. Per il tuo progetto pilota, trova i casi d'uso necessari e in cui un consumatore è pronto ad adottare il prodotto di dati risultante. I casi d'uso devono già disporre di finanziamenti per sviluppare i prodotti di dati, ma deve essere necessario l'input dei team tecnici.
Assicurati che il team che implementa il progetto pilota comprenda il modello operativo del data mesh come segue:
- L'attività (ovvero il team di produzione dei dati) è proprietaria del backlog, dell'assistenza e della manutenzione.
- Il team centrale definisce i pattern self-service e aiuta l'azienda a creare il prodotto di dati, ma lo passa all'azienda per l'esecuzione e la proprietà una volta completato.
- L'obiettivo principale è dimostrare il modello operativo dell'attività (domini di produzione, domini di consumo). 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 trunk e branch per mettere in comune le conoscenze, ma consentire comunque lo sviluppo di servizi e prodotti della piattaforma specializzati.
Ti consigliamo inoltre di procedere come segue:
- Pianifica le roadmap anziché lasciare che servizi e funzionalità si evolvano in modo organico.
- Definisci le funzionalità minime della piattaforma che coprono l'importazione, l'archiviazione, l'elaborazione, l'analisi e il machine learning.
- Incorpora la governance dei dati in ogni passaggio, non come flusso di lavoro separato.
- Implementa le funzionalità minime in termini di governance, piattaforma, value stream e gestione del cambiamento. Le funzionalità minime sono quelle che soddisfano l'80% dei casi aziendali.
Pianificare la coesistenza del data mesh con una piattaforma di 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 pianificare come può evolvere la loro piattaforma di dati esistente man mano che il data mesh cresce.
Queste organizzazioni devono prendere in considerazione fattori come i seguenti:
- Le risorse di dati più efficaci nella data mesh.
- Gli asset che devono rimanere all'interno della piattaforma dati esistente.
- Se gli asset devono essere spostati o se possono essere mantenuti 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 Google Cloud Well-Architected Framework.
- Per ulteriori architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.