Un mesh di dati è un framework architetturale e organizzativo che tratta i dati come un prodotto (in questo documento definito "prodotti dati"). In questo framework, i prodotti dati sono sviluppati dai team che meglio comprendono i dati e che seguono un set di standard di governance dei dati a livello di organizzazione. Una volta eseguito il deployment dei prodotti dati nel mesh di dati, i team distribuiti di un'organizzazione possono rilevare e accedere ai dati pertinenti alle loro esigenze in modo più rapido ed efficiente. Per ottenere un mesh di dati ben funzionante, devi prima definire 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 mesh di dati su Google Cloud. Si presuppone che tu abbia letto e 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 dati self-service per un mesh di dati
- Crea prodotti dati in un mesh di dati
- Scoprire e utilizzare prodotti di dati in un mesh di dati
In questa serie, il mesh di dati descritto è interno a un'organizzazione. Sebbene sia possibile estendere un'architettura di mesh di dati per fornire prodotti dati a terze parti, questo approccio esteso non rientra nell'ambito di questo documento. L'estensione di un mesh di dati richiede ulteriori considerazioni oltre al semplice utilizzo all'interno di un'organizzazione.
Architettura
I seguenti termini chiave vengono utilizzati per definire i componenti dell'architettura descritti in questa serie:
- Prodotto dati: un prodotto dati è un contenitore logico o un raggruppamento di una o più risorse di 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 fornisce una panoramica dei principali componenti architetturali 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 gruppi Identity and Access Management) e gli artefatti specifici dell'infrastruttura. Esempi di impegni e prenotazioni, nonché l'infrastruttura che facilita il funzionamento del mesh di dati, sono descritti in Creare componenti e soluzioni di piattaforma.
- I servizi centrali forniscono principalmente Data Catalog per tutti i prodotti dati nel mesh di dati e il meccanismo di rilevamento per i potenziali clienti di questi prodotti.
- I domini di dati espongono sottoinsiemi di dati come prodotti dati tramite interfacce di consumo dei dati ben definite. Questi prodotti di dati possono essere tabelle, viste, file strutturati, argomenti o stream. In BigQuery è un set di dati, mentre in Cloud Storage una cartella o un bucket. Ci possono essere diversi tipi di interfacce che possono essere esposte come prodotto dati. Un esempio di interfaccia è la 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 mesh di dati.
Implementazione dei riferimenti 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 dimostrano i concetti di base del mesh di dati e non sono destinati all'uso in produzione. Eseguendo questi script, imparerai a svolgere le seguenti operazioni:
- Separa le definizioni del prodotto 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 dei prodotti.
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, fai riferimento al file README nel repository.
Funzioni in un mesh di dati
Affinché un mesh di dati funzioni correttamente, devi definire ruoli chiari per le persone che svolgono attività all'interno del mesh di dati. La proprietà è assegnata agli archetipi o funzioni dei team. Queste funzioni contengono i percorsi principali dell'utente per le persone che lavorano nel mesh di dati. Per descrivere chiaramente i percorsi degli utenti, agli 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 con i dipendenti o i team della tua organizzazione.
Un dominio dati è allineato con un'unità aziendale (BU) o una funzione all'interno di un'azienda. Esempi comuni di domini aziendali potrebbero essere l'ufficio ipotecari di una banca o i reparti dedicati ai clienti, ai reparti di distribuzione, finanziari o alle risorse umane di un'azienda. Concettualmente, ci sono due funzioni correlate al dominio in una mesh di dati: i team di produttore di dati e i team di consumatore di dati. È importante comprendere che è probabile che un singolo dominio di dati serva entrambe le funzioni contemporaneamente. Un team che si occupa del dominio dati produce prodotti dati dai dati di sua proprietà. Il team consuma anche prodotti dati per insight aziendali e per generare prodotti di dati derivati da utilizzare per altri domini.
Oltre alle funzioni basate sul dominio, un mesh di dati ha anche un insieme di funzioni eseguite da team centralizzati all'interno dell'organizzazione. Questi team centrali consentono il funzionamento del mesh di dati fornendo supervisione, servizi e governance interdominio. Riducono il carico operativo dei domini di dati per la produzione e il consumo di prodotti dati e facilitano le 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 ogni azienda, indipendentemente dall'architettura utilizzata per la piattaforma. Questi altri ruoli, tuttavia, non rientrano nell'ambito di questo documento.
Le quattro funzioni principali in un mesh di dati sono le seguenti:
- Team di producer basati su dominio dati: creano e mantengono i prodotti dati durante il loro ciclo di vita. Questi team sono spesso indicati come produttori di dati.
- Team di consumatori basati sul dominio dei dati: scopri i prodotti dati e utilizzali in varie applicazioni di analisi. Questi team potrebbero utilizzare prodotti di dati per crearne di nuovi. Questi team sono spesso definiti consumatori dei dati.
- Team centrale per la governance dei dati: definisce e applica criteri di governance dei dati tra i produttori, garantendo un'elevata qualità e affidabilità dei dati ai consumatori. Questo team è spesso indicato come team di governance dei dati.
- Team centrale per la piattaforma di infrastruttura dati self-service: fornisce una piattaforma dati self-service per i produttori di dati. Questo team fornisce inoltre gli strumenti per la rilevabilità centralizzata dei dati e l'osservabilità dei prodotti dati utilizzati sia dai consumatori che dai produttori di dati. Questo team viene spesso indicato come team della piattaforma dati.
Una funzione extra facoltativa da considerare è quella di un centro di eccellenza (COE) per il mesh di dati. Lo scopo del COE è fornire la gestione della rete di dati. Il COE è anche il team arbitrale designato che risolve eventuali conflitti sollevati da una qualsiasi delle altre funzioni. Questa funzione è utile per collegare le altre quattro funzioni.
Team di producer basato su 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 nelle piattaforme di dati per creare e mantenere questi repository fisici. Tuttavia, questi ruoli delle piattaforme dati tradizionali non sono in genere quelli 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 tabella riportata di seguito elenca tutti i ruoli utente specifici del dominio necessari nei team del producer di dati.
Ruolo |
Responsabilità |
Competenze richieste |
Risultati auspicati |
|---|---|---|---|
Proprietario del prodotto dati |
|
Analisi dei dati Architettura dei dati Gestione dei prodotti |
|
Responsabile 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 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 esterni al dominio del prodotto dati. Usano un catalogo dati centrale 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 dati.
Se i consumatori dei dati non riescono a trovare il prodotto dati richiesto per il loro caso d'uso, è loro responsabilità consultare direttamente il COE del mesh di dati. Durante la consultazione, i consumatori dei dati possono aumentare le loro esigenze in termini 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 raggiungere vari casi d'uso, come dashboard e report di analisi permanenti, report sul rendimento individuale e altre metriche sulle prestazioni aziendali. In alternativa, i consumatori dei dati potrebbero essere alla ricerca di prodotti di dati da utilizzare nei casi d'uso di intelligenza artificiale (AI) e machine learning (ML). Per ottenere questi vari casi d'uso, i consumatori dei dati richiedono una combinazione di utenti tipo di professionisti dei dati, che sono i seguenti:
Ruolo |
Responsabilità |
Competenze richieste |
Risultati auspicati |
|---|---|---|---|
Analista di dati |
Cerca, identifica, valuta e sottoscrive prodotti dati per un singolo dominio o interdominio per creare una base per il funzionamento dei framework di business intelligence. |
Analytics engineering Analisi aziendale |
|
Sviluppatore di applicazioni |
Sviluppa un framework dell'applicazione 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 della visualizzazione dei dati |
|
Analisi dei requisiti Visualizzazione dei dati |
|
Data scientist |
|
ML engineering Ingegneria dell'analisi |
|
Team centrale per la governance dei dati
Il team per la governance dei dati consente a produttori e consumer di dati di condividere, aggregare e calcolare in sicurezza 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, ovvero:
Ruolo |
Responsabilità |
Competenze richieste |
Risultati auspicati |
|---|---|---|---|
Specialista 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 della piattaforma per l'infrastruttura dati self-service centrale
Il team self-service della piattaforma per l'infrastruttura dati, o solo il team della piattaforma dati, è responsabile della creazione di un insieme di componenti dell'infrastruttura dei dati. I team dei domini di dati distribuiti utilizzano questi componenti per creare e distribuire i propri prodotti dati. Inoltre, il team della piattaforma dati promuove le best practice e introduce strumenti e metodologie che aiutano 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à, la strumentazione e l'automazione della conformità a livello globale. In alternativa, l'infrastruttura deve facilitare tale integrazione per preparare i team distribuiti per il successo.
Il team della piattaforma dati ha un modello di responsabilità condivisa che utilizza con i team dei domini distribuiti e il team dell'infrastruttura sottostante. Il modello mostra le responsabilità che ci si aspetta dai consumatori della piattaforma e i componenti della piattaforma 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 aver implementato e in fase di sviluppo un set standard di componenti. Tuttavia, i team dei domini di dati potrebbero scegliere di utilizzare un insieme diverso e univoco di componenti se le esigenze di un team non sono in linea con quelle fornite dalla piattaforma dati. Se i team del dominio dati scelgono un approccio diverso, devono assicurarsi che qualsiasi 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 centrale della piattaforma dati, il team della piattaforma dati può scegliere di co-investire o incorporare i propri ingegneri nei team di dominio. La scelta di co-investire o incorporare gli engineer può dipendere dall'importanza strategica dell'infrastruttura della piattaforma del dominio dati per l'organizzazione. Rimanendo coinvolti nello sviluppo dell'infrastruttura da parte dei team di domini dati, le organizzazioni possono fornire l'allineamento e le competenze tecniche necessarie per riproporre tutti i nuovi componenti dell'infrastruttura della piattaforma che sono in fase di sviluppo per il 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 della rete di dati. Tuttavia, la limitazione dell'autonomia rischia di creare un collo di bottiglia per il team centrale della piattaforma dei dati. Questo collo di bottiglia può impedire la scalabilità del mesh di dati. Pertanto, tutte le decisioni di centralizzazione devono essere prese con attenzione. Per i produttori di dati, la scelta tecnica da un insieme limitato di opzioni disponibili potrebbe essere preferibile alla valutazione e alla scelta da un elenco illimitato di opzioni. Promuovere l'autonomia dei produttori di dati non equivale a creare un panorama tecnologico non superato. L'obiettivo è promuovere la conformità e l'adozione della piattaforma trovando il giusto equilibrio tra libertà di scelta e standardizzazione.
Infine, un buon team per la piattaforma dati è una fonte centrale di formazione e best practice per il resto dell'azienda. Ecco alcune delle attività di maggiore impatto che consigliamo dai team centrali delle piattaforme di dati:
- Promuovere revisioni periodiche della progettazione dell'architettura per nuovi progetti funzionali, nonché proporre metodi di sviluppo comuni.
- Condividere conoscenze ed esperienze, per definire collettivamente best practice e linee guida per l'architettura.
- Garantire che gli ingegneri dispongano degli strumenti giusti per convalidare e verificare la presenza di insidie comuni come problemi di codice, bug e riduzioni delle prestazioni.
- Organizzare hackathon interni in modo che i team di sviluppo possano far emergere i requisiti per le esigenze di strumentazione interna.
I ruoli e le responsabilità di esempio per il team della piattaforma dati centrale potrebbero includere i seguenti:
| Role | Responsabilità | Competenze richieste |
Risultati auspicati |
|---|---|---|---|
Proprietario del prodotto della piattaforma dati |
|
Strategia e operazioni relative ai dati Gestione dei prodotti Gestione degli stakeholder |
|
Data Platform Engineer |
|
Data engineering Software engineering |
|
Platform and Security Engineer (un rappresentante dei team IT centrali, come networking e sicurezza, incorporato nel team della piattaforma dati) |
|
Ingegneria dell'infrastruttura Ingegneria del software |
|
Architettore aziendale |
|
Architettura dei dati iterazione della soluzione e risoluzione dei problemi Creazione del consenso |
|
Considerazioni aggiuntive per un mesh di dati
Esistono più opzioni di architettura per una piattaforma di dati di analisi, ognuna con prerequisiti diversi. Per abilitare ogni architettura del mesh di dati, consigliamo alla tua organizzazione di seguire le best practice descritte in questa sezione.
Acquisisci finanziamenti per la piattaforma
Come spiegato nel post del blog, "Se vuoi trasformare iniziare con la finanza", la piattaforma non termina mai: funziona sempre sulla base di una roadmap prioritaria. Pertanto, 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 dati ad avviare il mesh di dati e il team tecnologico centrale, che in genere ospita il team della piattaforma dati centrale.
Per convincere i team finanziari ad approvare i finanziamenti per la piattaforma centrale, ti consigliamo di creare un business case che tenga conto del valore della piattaforma centralizzata realizzata nel tempo. Questo valore deriva dal reimplementazione degli stessi componenti nei singoli team di distribuzione.
Definire la piattaforma minima utilizzabile per il mesh di dati
Per aiutarti a definire la piattaforma minima utilizzabile per il mesh di dati, ti consigliamo di eseguire un progetto pilota e di eseguire l'iterazione di uno o più casi aziendali. Per il tuo progetto pilota, trova i casi d'uso necessari e in cui c'è un consumatore pronto ad adottare il prodotto di dati risultante. I casi d'uso dovrebbero già disporre di fondi per lo sviluppo dei prodotti dati, ma dovrebbero essere necessari input da parte dei team tecnici.
Assicurati che il team che implementa il progetto pilota comprenda il modello operativo del mesh di dati come segue:
- L'azienda (ovvero il team del produttore dei dati) è proprietaria di arretrati, assistenza e manutenzione.
- Il team centrale definisce i pattern self-service e aiuta l'azienda a creare il prodotto dati, ma passa il prodotto dati all'azienda affinché possa gestirlo e acquisirne la proprietà una volta completato.
- L'obiettivo principale è dimostrare il modello operativo aziendale (prodotti domini, domini consumati). L'obiettivo secondario è dimostrare il modello tecnico-operativo (pattern self-service sviluppati dal team centrale).
- Poiché le risorse del team della piattaforma sono limitate, utilizza il modello team di trunk e di ramo per raggruppare le conoscenze, ma consentire comunque lo sviluppo di servizi e prodotti di piattaforma specializzati.
Ti consigliamo inoltre di procedere nel seguente modo:
- Pianifica le roadmap invece di lasciare che servizi e funzionalità si evolvano in modo organico.
- Definire le funzionalità minime della piattaforma valide per importazione, archiviazione, elaborazione, analisi e ML.
- Incorpora la governance dei dati in ogni fase, non come un flusso di lavoro separato.
- Implementare le funzionalità minime per governance, piattaforma, flusso di valore e gestione dei cambiamenti. Le funzionalità minime soddisfano l'80% dei business case.
Pianificare la coesistenza del mesh di dati con una piattaforma dati esistente.
Molte organizzazioni che desiderano implementare un mesh di dati probabilmente dispongono già di una piattaforma dati, ad esempio un data lake, un data warehouse o una combinazione di entrambi. Prima di implementare un mesh di dati, queste organizzazioni devono fare un piano relativo all'evoluzione della loro piattaforma dati esistente all'espansione del mesh di dati.
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 gli asset devono essere spostati o se possono essere mantenuti sulla piattaforma esistente e continuare a partecipare al mesh di dati.
Passaggi successivi
- Per ulteriori informazioni 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 Cloud Architecture Center.