Un data mesh è un framework architetturale e organizzativo che tratta i dati come un prodotto (definito in questo documento come "prodotti dati"). In questo framework, i prodotti dati vengono sviluppati dai team che comprendono meglio i dati e che seguono una serie di standard di governance dei dati a livello di organizzazione. Una volta eseguito il deployment dei 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 un data mesh così ben funzionante, è necessario innanzitutto 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 dimestichezza con i concetti descritti in Creare un data mesh moderno e distribuito con Google Cloud.
La serie è costituita dai seguenti componenti:
- Architettura e funzioni in un data mesh (questo documento)
- Progetta una piattaforma dati self-service per un data mesh
- Crea prodotti dati in un data mesh
- Scopri e utilizza i prodotti dati in un data mesh
In questa serie, il data mesh descritto è interno a un'organizzazione. Sebbene sia possibile estendere un'architettura di 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 dati: un prodotto dati è un container logico o un raggruppamento di una o più risorse dati correlate.
- Risorsa di dati: una risorsa di dati è un asset fisico in un sistema di archiviazione che contiene dati strutturati o archivia una query che restituisce dati strutturati.
- Attributo dei dati: un attributo dei dati è un campo o un elemento di una risorsa di dati.
Il seguente diagramma offre 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 dati, inclusi i criteri dell'organizzazione che interessano i partecipanti del data mesh, i controlli dell'accesso (tramite i gruppi di Identity and Access Management) e gli artefatti specifici dell'infrastruttura. Esempi di tali impegni e prenotazioni, nonché l'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. Per scoprire come registrare i prodotti dati nel catalogo dati, consulta Descrivere e organizzare i prodotti e le risorse dati in un data mesh.
- I domini di dati espongono sottoinsiemi dei loro dati come prodotti dati tramite interfacce di consumo dati ben definite. Questi prodotti dati possono essere una tabella, una visualizzazione, un file strutturato, un argomento o un flusso. In BigQuery sarebbe un set di dati, mentre in Cloud Storage sarebbe una cartella o un bucket. Possono essere presenti diversi tipi di interfacce che possono essere esposte come prodotto dati. Un esempio di interfaccia è la vista di BigQuery su una tabella BigQuery. I tipi di interfacce più comunemente utilizzati per scopi analitici sono descritti in Creare prodotti dati in un mesh di dati.
Implementazione di riferimento del data mesh
Puoi trovare un'implementazione di riferimento di questa architettura nel repository data-mesh-demo
.
Gli script Terraform utilizzati nell'implementazione dei riferimenti dimostrano i concetti del data mesh e non sono destinati all'uso in produzione. Eseguendo questi script, imparerai a:
- Separa le definizioni dei prodotti dai dati sottostanti.
- Creare modelli di Data Catalog per descrivere le interfacce dei prodotti.
- Applica il tagging alle interfacce dei prodotti con questi modelli.
- Concedi le autorizzazioni ai consumatori del prodotto.
Per le interfacce del prodotto, l'implementazione del 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 data mesh
Affinché un data mesh funzioni correttamente, devi definire ruoli chiari per le persone che eseguono attività all'interno del data mesh. La proprietà è assegnata agli archetipi o funzioni del team. Queste funzioni contengono i percorsi degli utenti principali per le persone che lavorano nel data mesh. Per descrivere chiaramente i percorsi degli utenti, sono stati assegnati ruoli utente. Questi ruoli utente possono essere suddivisi e combinati in base alle circostanze di ciascuna azienda. Non è necessario mappare i ruoli direttamente ai dipendenti o ai team della tua organizzazione.
Un dominio dati è allineato a una business unit (BU) o a una funzione all'interno di un'azienda. Esempi comuni di domini aziendali possono essere il reparto mutui in una banca o i reparti clienti, di distribuzione, finanziari o delle risorse RU di un'azienda. A livello concettuale, in una rete di dati ci sono due funzioni correlate al dominio: i team data producer e data consumer team. È importante capire che è probabile che un singolo dominio di dati utilizzi entrambe le funzioni contemporaneamente. Un team che si occupa del dominio dati genera prodotti dati dai dati di sua proprietà. Il team consuma anche prodotti dati per insight aziendali 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 dai team centralizzati all'interno dell'organizzazione. Questi team centrali consentono il funzionamento del data mesh fornendo supervisione, servizi e governance interdominio. Riducono il carico operativo per i domini di dati nella produzione e nell'utilizzo di prodotti dati e facilitano le relazioni interdominio necessarie per il funzionamento del data mesh.
Questo documento descrive solo le funzioni che hanno un ruolo specifico per il data mesh. Esistono molti altri ruoli richiesti 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 in un data mesh sono le seguenti:
- Team di produttori basati sul dominio di dati: crea e gestisci i prodotti dati per tutto il loro ciclo di vita. Questi team sono spesso indicati come produttori di dati.
- Team dei consumatori basati sul dominio dei dati: scopri i prodotti dati e utilizzali in varie applicazioni di analisi. Questi team potrebbero utilizzare prodotti dati per creare nuovi prodotti dati. Questi team sono spesso indicati come consumatori di dati.
- Team centrale per la governance dei dati: definisce e applica le norme di governance dei dati tra i produttori di dati, garantendo alta qualità e affidabilità dei dati per i consumatori. Questo team è spesso indicato come team per la governance dei dati.
- Team della piattaforma di infrastruttura dati self-service centrale: fornisce una piattaforma dati self-service per i data producer. Questo team fornisce anche gli strumenti per l'individuazione centralizzata dei dati e l'osservabilità dei prodotti dati, utilizzati sia dai consumatori che dai produttori di dati. Questo team viene spesso indicato come il team della piattaforma dati.
Una funzione aggiuntiva facoltativa da considerare è quella di un centro di eccellenza (COE) per il data mesh. Lo scopo del COE è fornire la gestione della rete di dati. Il COE è inoltre il team arbitrale designato che risolve qualsiasi conflitto sollevato da una qualsiasi delle altre funzioni. Questa funzione è utile per collegare le altre quattro funzioni.
Team di produttori basato sul dominio dati
In genere, i prodotti dati sono basati su un repository fisico di dati (uno o più data warehouse, data lake o flussi). Un'organizzazione ha bisogno di ruoli tradizionali nella piattaforma dati 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 dati da questi repository fisici, un'organizzazione ha bisogno di un mix di professionisti dei dati, come data engineer e data architect. La seguente tabella elenca tutti i ruoli utente specifici del dominio necessari nei team dei produttori di dati.
Ruolo |
Responsabilità |
Competenze richieste |
Risultati desiderati |
---|---|---|---|
Proprietario del prodotto dati |
|
Analisi dei dati Architettura dei dati Gestione dei prodotti |
|
Lead tecnico del prodotto dati |
|
Data engineering Architettura dei dati Software Engineering |
|
Assistenza per i prodotti 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 consumatori basati sul dominio dei dati
In un data mesh, le persone che utilizzano un prodotto dati sono in genere utenti dati esterni al dominio del prodotto dati. I consumatori utilizzano un catalogo dati centrale per trovare prodotti dati pertinenti alle loro esigenze. Poiché è possibile che più di un prodotto dati possa soddisfare le loro esigenze, i consumatori di dati possono abbonarsi a più prodotti dati.
Se i consumatori di dati non riescono a trovare il prodotto dati richiesto per il loro caso d'uso, è loro responsabilità consultare direttamente il COE del data mesh. Durante la consulenza, i consumatori dei dati possono aumentare le loro esigenze di dati e chiedere consigli su come soddisfarle da uno o più domini.
Quando cercano un prodotto dati, i consumatori dei dati cercano dati che li aiutino a realizzare vari casi d'uso, come dashboard e report di analisi permanente, report sul rendimento individuali e altre metriche sulle prestazioni aziendali. In alternativa, i consumatori di dati potrebbero cercare prodotti da usare nei casi d'uso di intelligenza artificiale AIA) e machine learning (ML). Per ottenere questi vari casi d'uso, i consumatori dei dati richiedono una combinazione di utenti tipo di dati, che sono i 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 le basi per il funzionamento dei framework di business intelligence. |
Ingegneria dell'analisi Analisi dell'attività |
|
Sviluppatore di applicazioni |
Sviluppa un framework dell'applicazione per il consumo di dati in uno o più prodotti dati, all'interno o all'esterno del dominio. |
Sviluppo di applicazioni Data engineering |
|
Esperto della visualizzazione dei dati |
|
Analisi dei requisiti Visualizzazione dei dati |
|
Data scientist |
|
Ingegneria ML Ingegneria di analisi |
|
Team centrale per la governance dei dati
Il team per la governance dei dati consente a produttori e consumatori di dati di condividere, aggregare e calcolare in modo sicuro 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 è un mix di utenti tipo di professionisti dei dati, i quali sono i seguenti:
Ruolo |
Responsabilità |
Competenze richieste |
Risultati desiderati |
---|---|---|---|
Esperto di governance dei dati |
|
SME legale SME per la sicurezza SME per la privacy dei dati |
|
Gestore dei dati (si trova all'interno di ciascun dominio) |
|
Architettura dei dati Stewardship dei dati |
|
Data Governance Engineer |
|
Ingegneria del software |
|
Team centrale della piattaforma self-service per l'infrastruttura dati
Il team della piattaforma self-service per l'infrastruttura dati, o solo il team della piattaforma dati, è responsabile della creazione di un set di componenti dell'infrastruttura dati. I team nei domini dei dati distribuiti utilizzano questi componenti per creare i propri prodotti dati ed eseguirne il deployment. Il team della piattaforma dati promuove anche best practice e introduce strumenti e metodologie che aiutano a ridurre il carico cognitivo per i team distribuiti al momento di adottare nuove tecnologie.
L'infrastruttura della piattaforma deve integrarsi facilmente con gli strumenti operativi per l'osservabilità, la strumentazione e l'automazione della conformità a livello globale. In alternativa, l'infrastruttura dovrebbe facilitare questa integrazione per preparare team distribuiti per il successo.
Il team della piattaforma dati utilizza un modello di responsabilità condivisa con i team dei domini distribuiti e il team dell'infrastruttura sottostante. Il modello mostra quali responsabilità ci si aspetta dai consumatori della piattaforma e quali componenti della piattaforma sono supportati dal team della piattaforma dati.
Poiché la piattaforma dati è di per sé un prodotto interno, non supporta tutti i casi d'uso. il team della piattaforma dati rilascia continuamente nuovi servizi e funzionalità in base a una roadmap prioritaria,
Il team della piattaforma dati potrebbe avere un insieme standard di componenti in atto e in fase di sviluppo. Tuttavia, i team nel dominio dei dati potrebbero scegliere di utilizzare un insieme univoco di componenti diverso se le esigenze di un team non sono in linea con quelle fornite dalla piattaforma dati. Se i team del dominio dei dati scelgono un approccio diverso, devono assicurarsi che l'infrastruttura della piattaforma che creano e gestiscono sia conforme ai criteri e ai sistemi di protezione a livello di organizzazione per la sicurezza e la governance dei dati. Per l'infrastruttura della piattaforma dati sviluppata al di fuori del team della piattaforma dati centrale, il team della piattaforma dati potrebbe scegliere di co-investire o incorporare i propri ingegneri nei team di dominio. La scelta del team della piattaforma dati di co-investire o di incorporare ingegneri potrebbe dipendere dall'importanza strategica dell'infrastruttura della piattaforma del dominio dati per l'organizzazione. Rimanendo coinvolti nello sviluppo dell'infrastruttura da parte dei team dei domini dei dati, le organizzazioni possono fornire l'allineamento e le competenze tecniche necessarie per riformulare 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 lo scale up del data mesh. Tuttavia, limitare l'autonomia rischia di creare un collo di bottiglia per il team della piattaforma dati centrale. Questo collo di bottiglia può impedire la scalabilità del data mesh. Pertanto, tutte le decisioni di centralizzazione devono essere prese con attenzione. Per i produttori di dati, potrebbe essere preferibile prendere le loro scelte tecniche da un insieme limitato di opzioni disponibili anziché valutare e scegliere personalmente da un elenco illimitato di opzioni. Promuovere l'autonomia dei produttori di dati non equivale a creare un panorama tecnologico non esteso. L'obiettivo è favorire la conformità e l'adozione della piattaforma trovando il giusto equilibrio tra libertà di scelta e standardizzazione.
Infine, un buon team dedicato alla piattaforma dati è una fonte centrale di istruzione e best practice per il resto dell'azienda. Ecco alcune delle attività di maggior impatto che consigliamo ai team delle piattaforme dati centrali di eseguire:
- Promuovere revisioni periodiche 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 sull'architettura.
- Garantire agli ingegneri di disporre degli strumenti giusti per convalidare e verificare la presenza di insidie comuni, come problemi relativi al codice, bug e riduzioni delle prestazioni.
- Organizzazione di hackathon interni in modo che i team di sviluppo possano far emergere i requisiti per le esigenze relative agli strumenti interni.
I ruoli e le responsabilità di esempio per il team della piattaforma dati centrale potrebbero includere quanto segue:
Role | Responsabilità | Competenze richieste |
Risultati desiderati |
---|---|---|---|
Proprietario del prodotto della piattaforma dati |
|
Strategia e operazioni sui dati Gestione dei prodotti Gestione degli stakeholder |
|
Data Platform Engineer |
|
Data engineering Software Engineering |
|
Ingegnere di piattaforma e di sicurezza (rappresentante dei team IT centrali come networking e sicurezza, membro del team della piattaforma dati) |
|
Ingegneria dell'infrastruttura Ingegneria del software |
|
Enterprise Architect |
|
Architettura dei dati iterazione della soluzione e risoluzione dei problemi Creazione del consenso |
|
Considerazioni aggiuntive per un data mesh
Una piattaforma di dati di analisi offre architetture diverse, ognuna con prerequisiti diversi. Per abilitare ogni architettura di data mesh, ti consigliamo che la tua organizzazione segua le best practice descritte in questa sezione.
Acquisisci finanziamenti della piattaforma
Come spiegato nel post del blog, "If you you want to transform start with finance", la piattaforma non è mai finita: funziona sempre secondo una roadmap prioritaria. Di conseguenza, la piattaforma deve essere finanziata come un prodotto, non come un progetto con un endpoint fisso.
Il costo è a carico del primo utente del data mesh. Di solito, il costo è condiviso tra l'attività che costituisce il primo dominio dati ad avviare il data mesh e il team tecnologico centrale, che in genere ospita il team della piattaforma dati centrale.
Per convincere i team finanziari ad approvare il finanziamento per la piattaforma centrale, ti consigliamo di creare un business case per il valore della piattaforma centralizzata realizzato nel tempo. Questo valore deriva dal reimplementazione degli stessi componenti nei singoli team di distribuzione.
Definire la piattaforma minima utilizzabile per il data mesh
Per aiutarti a definire la piattaforma minima utilizzabile per il data mesh, ti consigliamo di eseguire un progetto pilota e di eseguire l'iterazione con uno o più business case. Per il tuo pilota, trova i casi d'uso necessari e dove c'è un consumatore pronto ad adottare il prodotto dati risultante. I casi d'uso dovrebbero già disporre di fondi per sviluppare i prodotti dati, ma dovrebbe essere necessario il contributo dei team tecnici.
Assicurati che il team che implementa il progetto pilota comprenda il modello operativo del data mesh come segue:
- L'azienda (ossia il team del produttore di 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 dati, ma lo passa all'azienda affinché venga eseguito e posseduto quando è completo.
- L'obiettivo principale è dimostrare il modello operativo aziendale (prodotti dei domini, uso dei domini). L'obiettivo secondario è dimostrare il modello operativo tecnico (pattern self-service sviluppati dal team centrale).
- Poiché le risorse dei team della piattaforma sono limitate, utilizza il modello team di trunk e filiali per raccogliere 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.
- Definire funzionalità di piattaforma minime attuabili che comprendono importazione, archiviazione, elaborazione, analisi e ML.
- Integra la governance dei dati in ogni fase, non come un flusso di lavoro separato.
- Implementa le funzionalità minime per governance, piattaforma, flusso di valore e gestione dei cambiamenti. Le funzionalità minime sono quelle che soddisfano l'80% dei casi aziendali.
Pianifica la coesistenza del data mesh con una piattaforma dati esistente
Molte organizzazioni che desiderano implementare un data mesh probabilmente dispongono già di 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 fare un piano su come la loro piattaforma dati esistente può evolversi con la crescita del data mesh.
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 dati esistente.
- Indica 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 sulla gestione di una topologia cloud, consulta il framework dell'architettura Google Cloud.
- Per altre architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.