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 così 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 mesh di dati 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
- Crea prodotti 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 di dati: una risorsa di dati è un asset fisico in uno spazio di archiviazione che contiene dati strutturati o archivia una query che restituisce dati e i dati di Google Cloud.
- Attributo dei dati:un attributo dei dati è un campo o un elemento di un dati risorsa.
Il seguente diagramma fornisce una panoramica dei principali componenti dell'architettura in un mesh di dati implementato su Google Cloud.
Il diagramma precedente mostra quanto segue:
- I servizi centrali consentono la creazione e la gestione di prodotti dati, tra cui: Criteri dell'organizzazione che interessano i partecipanti al mesh di dati, i 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 Creare componenti e soluzioni della piattaforma.
- I servizi centrali forniscono principalmente Data Catalog per tutte le prodotti dati nel mesh di dati e il meccanismo di rilevamento per potenziali clienti di questi prodotti.
- I domini di dati espongono sottoinsiemi di dati come prodotti dati tramite interfacce di consumo dati ben definite. Questi prodotti dati possono essere tabella, visualizzazione, file strutturato, argomento o flusso. In BigQuery, si tratta di un set di dati, mentre in Cloud Storage si tratta di una cartella o di un bucket. Ci possono essere diversi tipi di interfacce che possono essere esposte sotto forma di prodotto 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 dei riferimenti del mesh di dati
Puoi trovare un'implementazione di riferimento di questa architettura in
il repository data-mesh-demo.
Gli script Terraform utilizzati nell'implementazione di riferimento dimostrano
concetti di mesh di dati 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.
- Stream di dati basati su argomenti Pub/Sub.
Per ulteriori dettagli, consulta il file README nel repository.
Funzioni in un mesh di dati
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 dei team o funzioni. Queste funzioni contengono i percorsi principali dell'utente per le persone che lavorano il mesh di dati. Per descrivere chiaramente i percorsi degli utenti, sono stati assegnati a ruoli utente. Questi ruoli utente possono essere suddivisi e combinati in base circostanze di ciascuna impresa. 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 umane di un'azienda. Concettualmente, in un data ci sono due funzioni legate al dominio mesh: i team di produttore 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 dati dominio per la produzione e il consumo di prodotti dati e agevolare relazioni interdominio necessarie per il funzionamento del mesh di dati.
Questo documento descrive solo le funzioni che hanno un ruolo specifico per il mesh di dati. Esistono molti altri ruoli richiesti in qualsiasi azienda, indipendentemente dal l'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 producer basati sul dominio dati: Crea e gestisci 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. Queste squadre sono spesso definiti consumatori dei 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 centrale per la piattaforma per l'infrastruttura dati self-service: Offre una piattaforma 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 definito come team della piattaforma 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 dei dati mesh. Il COE è anche il team arbitrale designato che risolve qualsiasi conflitti generati da una qualsiasi delle altre funzioni. Questa funzione è utile per per aiutare a collegare le altre quattro funzioni.
Team di producer basato su dominio 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 tradizionali nelle piattaforme di dati per creare e mantenere questi repository. Tuttavia, questi ruoli tradizionali delle piattaforme 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 la seguente tabella elenca tutti i ruoli utente specifici del dominio necessari nei dati dei produttori.
Ruolo |
Responsabilità |
Competenze richieste |
Risultati auspicati |
|---|---|---|---|
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 dei dati |
|
Analisi dei dati Architettura dei dati |
|
Proprietario dei dati |
|
|
|
Team dei consumatori basati sul dominio dei dati
In un mesh di dati, le persone che utilizzano un prodotto di dati sono in genere utenti di dati che si trovano 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 dei dati non riescono a trovare il prodotto dati richiesto per il loro utilizzo in questo caso, è sua responsabilità consultare direttamente il COE del mesh di dati. Durante la consulenza, i consumatori di dati possono comunicare le proprie 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 dei dati potrebbero essere alla ricerca di prodotti di dati che utilizzata nei casi d'uso di intelligenza artificiale (AI) e machine learning (ML). A vari casi d'uso, i consumatori dei dati hanno bisogno di una combinazione utenti tipo dei professionisti, ovvero:
Ruolo |
Responsabilità |
Competenze richieste |
Risultati auspicati |
|---|---|---|---|
Analista di dati |
Cerca, identifica, valuta e si iscrive Prodotti dati per un singolo dominio o interdominio per creare una base il funzionamento dei framework di business intelligence. |
Ingegneria dell'analisi Analisi dell'attività |
|
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 dati |
|
Analisi dei requisiti Visualizzazione dei dati |
|
Data scientist |
|
Ingegneria ML Ingegneria di analisi |
|
Team di governance dei dati centrali
Il team di governance dei dati consente a produttori e consumer di dati di condividere, aggregare ed elaborare dati in modo self-service, senza introdurre di conformità per l'organizzazione.
Per soddisfare i requisiti di conformità dell'organizzazione, il team di governance dei dati è un mix di utenti tipo 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 |
|
Gestore dati (si trova all'interno di ciascun dominio) |
|
Architettura dei dati Stewardship dei dati |
|
Data governance engineer |
|
Ingegneria del software |
|
Team della piattaforma per l'infrastruttura dati self-service centrale
Il team della piattaforma per l'infrastruttura dati self-service o solo la piattaforma 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 dati promuove inoltre best practice e introduce strumenti e metodologie che aiutano a ridurre il carico cognitivo per da 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 dati ha un modello di responsabilità condivisa che utilizza i team di domini distribuiti e il team dell'infrastruttura sottostante. Il modello mostra le responsabilità che ci si aspetta dai consumatori della piattaforma i componenti della piattaforma supportati dal team della piattaforma dati.
Poiché la piattaforma di dati è essa stessa un prodotto interno, non supporta ogni caso d'uso. Al contrario, il team della piattaforma dati rilascia continuamente nuovi servizi e funzionalità secondo una roadmap prioritaria.
Il team della piattaforma di dati potrebbe avere un insieme standard di componenti implementati e in sviluppo. Tuttavia, i team dei domini di dati potrebbero scegliere di utilizzare un modello un insieme di componenti se le esigenze di un team non sono in linea con quelle fornite completamente gestita. 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 dati sviluppata al di fuori della piattaforma dati centrale team della piattaforma dati, può scegliere di co-investire o incorporare i propri ingegneri nei team del dominio. Se il team della piattaforma dati sceglie di co-investire o incorporare tecnici potrebbero dipendere dall'importanza strategica dell'infrastruttura della piattaforma di dominio dati all'organizzazione. Restando coinvolti nello sviluppo dell'infrastruttura da parte dei team del dominio dati, le organizzazioni possono fornire l'allineamento e le competenze tecniche necessarie per rielaborare tutti i nuovi componenti dell'infrastruttura della piattaforma in fase di sviluppo per un riutilizzo futuro.
Potresti dover limitare l'autonomia nelle prime fasi della creazione di un mesh di dati se il tuo obiettivo iniziale è ottenere l'approvazione degli stakeholder per lo scale up dei dati 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 mesh di dati. Quindi, qualsiasi le decisioni di centralizzazione devono essere prese con attenzione. Per i produttori di dati, le scelte tecniche rispetto a una serie limitata di opzioni disponibili è preferibile valutare e scegliere tra un elenco illimitato di opzioni le istanze server autonomamente. Promuovere l'autonomia dei produttori di dati non equivale a creare una panorama tecnologico non regolamentato. L'obiettivo è promuovere la conformità e l'adozione della piattaforma, trovando il giusto equilibrio tra libertà di scelta e standardizzazione.
Infine, un buon team di piattaforma dati è una fonte centrale di istruzione e offre 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, per definire collettivamente le migliori pratiche e linee guida sull'architettura.
- Assicurarsi che gli ingegneri dispongano degli strumenti giusti per la convalida e il controllo alla ricerca di inconvenienti comuni, come problemi di codice, bug e riduzioni 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 Ingegneria del software |
|
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 delle soluzioni e problem solving Aumento 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à. Di conseguenza, la piattaforma deve essere finanziata come un prodotto, non come un progetto con un endpoint fisso.
I costi sono a carico del primo utilizzatore del mesh di dati. Di solito, il costo viene condiviso tra l'azienda che forma il primo dominio di dati che avvia il mesh di dati e il team tecnologico centrale, che generalmente ospita i dati centrali dal team della piattaforma Google Cloud.
Per convincere i team finanziari ad approvare i finanziamenti per la piattaforma centrale, di creare un caso aziendale per valore della piattaforma centralizzata realizzata nel tempo. Questo valore deriva reimplementare gli stessi 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 pilota, trovare i casi d'uso necessari e i casi in cui c'è un consumatore pronto adottare il prodotto di dati risultante. I casi d'uso dovrebbero già disporre di finanziamenti sviluppare i prodotti dati, ma dovrebbe essere necessario l'input dei tecnici i team di sicurezza.
Assicurati che il team che implementa il progetto pilota comprenda il mesh di dati operativo come segue:
- L'azienda (ovvero il team del produttore dei dati) è proprietaria del backlog, assistenza e manutenzione.
- Il team centrale definisce i pattern self-service e aiuta business crea il prodotto dati, ma lo passa allo l'attività da gestire e possedere quando sarà completata.
- 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 consentendo comunque lo sviluppo di servizi e prodotti della piattaforma specializzati.
Ti consigliamo inoltre di procedere nel seguente modo:
- Pianifica le roadmap anziché lasciare che i servizi e le funzionalità si evolvano in modo organico.
- Definire le funzionalità minime della piattaforma utilizzabili tra importazione, archiviazione elaborazione, analisi e ML.
- Integra la governance dei dati in ogni passaggio, non come flusso di lavoro separato.
- Implementare le funzionalità minime in termini di governance, piattaforma flusso di valore e gestione dei cambiamenti. Le capacità minime sono quelle che per soddisfare l'80% dei business case.
Pianifica la coesistenza del data mesh con una piattaforma dati esistente
Molte organizzazioni che desiderano implementare un mesh di dati probabilmente dispongono già di un una piattaforma dati esistente, ad esempio un data lake, un data warehouse o una combinazione 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 dovrebbero prendere in considerazione fattori quali:
- Le risorse di dati più efficaci sul mesh di dati.
- Gli asset che devono rimanere all'interno della piattaforma 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 il funzionamento di una topologia cloud, consulta il Framework dell'architettura Google Cloud.
- Per altre architetture di riferimento, diagrammi e best practice, esplora il Centro architetture cloud.