Un mesh di dati è un framework architetturale e organizzativo che tratta i dati come un prodotto (indicato in questo documento come prodotto di 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 eseguito il deployment dei prodotti di dati nel mesh di dati, 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 mesh di dati efficiente, devi prima stabilire i componenti dell'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 abbia familiarità con i concetti descritti in Crea un mesh di dati moderno e distribuito con Google Cloud.
La serie è composta dalle seguenti parti:
- Architettura e funzioni in un mesh di dati (questo documento)
- Progetta una piattaforma dati self-service per un mesh di dati
- Crea prodotti di dati in un mesh di dati
- Scopri e utilizza i 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 di dati a terze parti, questo approccio esteso non rientra nell'ambito di questo documento. L'estensione di un mesh di dati comporta considerazioni aggiuntive 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 di dati: un prodotto di dati è un container 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 genera 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 componenti chiave 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 dei prodotti di dati, tra cui le policy dell'organizzazione che interessano i partecipanti al mesh di dati, i controlli degli accessi (tramite i gruppi di Identity and Access Management) e gli artefatti specifici dell'infrastruttura. Esempi di questi impegni e prenotazioni e dell'infrastruttura che facilita il funzionamento del mesh di dati sono descritti in Crea componenti e soluzioni della piattaforma.
- I servizi centrali utilizzano Knowledge Catalog per fornire il Data Catalog per tutti i prodotti di dati nel mesh di dati e il meccanismo di rilevamento per i potenziali consumer 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 potrebbero essere una tabella, una vista, 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. Possono esistere 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 analitici sono discussi in Crea prodotti di dati in un mesh di dati.
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 dimostrano i 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.
- Creare modelli di Data Catalog per descrivere le interfacce dei prodotti.
- Interfacce dei prodotti di tag con questi modelli.
- Concedi le autorizzazioni ai consumer di prodotti.
Per le interfacce dei prodotti, l'implementazione di riferimento crea e utilizza i seguenti tipi di interfaccia:
- Viste autorizzate sulle tabelle BigQuery.
- Flussi di dati basati su argomenti Pub/Sub.
Per ulteriori dettagli, consulta il file README nel repository.
Funzioni in un mesh di dati
Per un funzionamento ottimale di un mesh di dati, devi definire ruoli chiari per le persone che eseguono attività all'interno del mesh di dati. La proprietà viene assegnata ad archetipi o funzioni del team. Queste funzioni contengono i percorsi dell'utente principali per le persone che lavorano nel mesh di dati. Per descrivere chiaramente i percorsi degli utenti, questi 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 i dipendenti o i team della tua organizzazione.
Un dominio di dati è allineato a un'unità aziendale (BU) 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 risorse RU di un'azienda. Concettualmente, in un mesh di dati esistono due funzioni relative al dominio: i team di producer di dati e i team di consumer di dati. È importante capire che un singolo dominio di dati probabilmente svolgerà entrambe le funzioni contemporaneamente. Un team di dominio di dati produce prodotti di dati dai dati di sua proprietà. Il team utilizza anche i prodotti di dati per ottenere insight aziendali e per generare prodotti di dati derivati da utilizzare in 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 tra domini. Riducono l'onere 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 mesh di dati.
Questo documento descrive solo le funzioni che hanno un ruolo specifico per il mesh di dati. Esistono diversi 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 di un mesh di dati sono le seguenti:
- Team di produttori basati su domini di dati: creano e gestiscono i prodotti di dati nel corso del loro ciclo di vita. Questi team sono spesso definiti produttori di dati.
- Team di consumatori basati su domini di dati: scoprono i prodotti di dati e li utilizzano in varie applicazioni di analisi. Questi team potrebbero utilizzare i prodotti di dati per crearne di nuovi. Questi team vengono spesso definiti consumer di dati.
- Team centrale di governance dei dati: definisce e applica le policy di governance dei dati tra i producer di dati, garantendo un'elevata qualità e affidabilità dei dati per i consumer. Questo team viene spesso definito team di governance dei dati.
- Team centrale della piattaforma di infrastruttura dei dati self-service: fornisce una piattaforma di dati self-service per i producer di dati. Questo team fornisce anche gli strumenti per il rilevamento centrale dei dati e l'osservabilità dei prodotti dati utilizzati sia dai consumer sia dai producer di dati. Questo team viene spesso definito team della piattaforma dati.
Un'ulteriore funzione facoltativa da considerare è quella di un centro di eccellenza (COE) per il mesh di dati. 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 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, data lake o stream). Un'organizzazione ha bisogno di ruoli tradizionali della piattaforma di dati per creare e gestire questi repository fisici. Tuttavia, queste figure tradizionali della piattaforma dati non sono in genere quelle che creano il prodotto dati.
Per creare prodotti di dati da questi repository fisici, un'organizzazione ha bisogno di un mix di Data Practitioner, come Data Engineer e Data Architect. La tabella seguente elenca tutti i ruoli utente specifici del dominio necessari nei team dei producer di dati.
Ruolo |
Responsabilità |
Competenze richieste |
Risultati desiderati |
|---|---|---|---|
Proprietario del prodotto di dati |
|
Analisi dei dati Architettura dei dati Gestione dei prodotti |
|
Responsabile tecnico dei prodotti di dati |
|
Data engineering Data architecture Software engineering |
|
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 consumer basati su domini di dati
In un mesh di dati, le persone che utilizzano un prodotto di dati sono in genere utenti di dati che non fanno parte del dominio del prodotto di dati. Questi consumer 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 consumer di dati possono finire per sottoscrivere più prodotti di dati.
Se i consumer di 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 questa consultazione, i consumatori di dati possono sollevare le loro esigenze in materia di dati e chiedere consigli su come soddisfarle in uno o più domini.
Quando cercano un prodotto di dati, i consumer di dati cercano dati che li aiutino a realizzare vari casi d'uso, come dashboard e report di analisi persistenti, report sul rendimento individuale e altre metriche sul rendimento aziendale. In alternativa, i consumer di dati potrebbero essere alla ricerca di 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 consumer di dati hanno bisogno di un mix di profili di Data Practitioner, che sono i seguenti:
Ruolo |
Responsabilità |
Competenze richieste |
Risultati desiderati |
|---|---|---|---|
Analista 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. |
Analytics engineering Business analytics |
|
Sviluppatore di applicazioni |
Sviluppa un framework di applicazioni per l'utilizzo dei 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 |
|
ML engineering Analytics engineering |
|
Team centrale di governance dei dati
Il team di governance dei dati consente ai produttori e ai consumatori di dati di condividere, aggregare ed elaborare i dati in modo sicuro e in modalità 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 Data Practitioner, che sono i seguenti:
Ruolo |
Responsabilità |
Competenze richieste |
Risultati desiderati |
|---|---|---|---|
Specialista della governance dei dati |
|
Esperto in materia legale Esperto in materia di sicurezza Esperto in materia di privacy dei dati |
|
Data steward (all'interno di ogni dominio) |
|
Architettura dei dati Stewardship dei dati |
|
Data governance engineer |
|
Ingegneria del software |
|
Team della piattaforma centrale dell'infrastruttura dei dati self-service
Il team della piattaforma di infrastruttura di dati self-service, o semplicemente il team della piattaforma di dati, è responsabile della creazione di un insieme di componenti dell'infrastruttura di dati. I team di dominio dati distribuiti utilizzano questi componenti per creare ed eseguire il deployment dei propri prodotti di dati. Il team della piattaforma di dati promuove anche 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à globali. In alternativa, l'infrastruttura dovrebbe facilitare questa integrazione per consentire ai team distribuiti di ottenere risultati ottimali.
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 dati.
Poiché la piattaforma di dati è essa stessa un prodotto interno, non supporta tutti i casi d'uso. Invece, 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 set standard di componenti in uso e in fase di sviluppo. Tuttavia, i team dei domini di 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 dei domini di dati scelgono un approccio diverso, devono assicurarsi che l'infrastruttura della piattaforma che creano e gestiscono sia conforme alle policy e alle misure 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 potrebbe scegliere di co-investire o di integrare i propri ingegneri nei team di dominio. La scelta del team della piattaforma di dati di co-investire o integrare gli ingegneri potrebbe dipendere dall'importanza strategica dell'infrastruttura della piattaforma del dominio di dati per l'organizzazione. Rimanendo coinvolte nello sviluppo dell'infrastruttura da parte dei team dei domini di dati, le organizzazioni possono fornire l'allineamento e le competenze tecniche necessarie per riorganizzare i nuovi componenti dell'infrastruttura della piattaforma in fase di sviluppo per un riutilizzo futuro.
Potresti dover limitare l'autonomia nelle prime fasi di creazione di un mesh di dati se il tuo obiettivo iniziale è ottenere l'approvazione degli stakeholder per lo scale up del mesh di dati. Tuttavia, limitare l'autonomia rischia di creare un collo di bottiglia nel team della piattaforma dati centrale. Questo collo di bottiglia può impedire la scalabilità del mesh di dati. Pertanto, qualsiasi decisione di centralizzazione deve essere presa con attenzione. Per i produttori di dati, effettuare le scelte tecniche da un insieme limitato di opzioni disponibili potrebbe essere preferibile rispetto 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 governato. 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ù importanti che consigliamo ai team della piattaforma dati centrale di intraprendere:
- Promuovere revisioni regolari della progettazione dell'architettura per nuovi progetti funzionali e proporre metodi di sviluppo comuni tra i team di sviluppo.
- Condividere conoscenze ed esperienze e definire collettivamente best practice e linee guida per l'architettura.
- Assicurarsi che gli ingegneri dispongano degli strumenti giusti per convalidare e verificare le insidie comuni, come problemi con il codice, bug e peggioramento delle prestazioni.
- Organizzare hackathon interni in modo che i team di sviluppo possano presentare i propri requisiti per le esigenze di strumenti interni.
Ecco alcuni esempi di ruoli e responsabilità del team della piattaforma di 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 degli stakeholder |
|
Data platform engineer |
|
Data engineering Software engineering |
|
Platform and Security Engineer (un rappresentante dei team IT centrali, come networking 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 di 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 di mesh di dati, consigliamo alla tua organizzazione di seguire le best practice descritte in questa sezione.
Acquisire finanziamenti per la piattaforma
Come spiegato nel blog post "If you want to transform start with finance", la piattaforma non è mai finita: opera 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 mesh di dati sostiene i costi. In genere, il costo viene condiviso tra l'azienda che forma il primo dominio di dati per avviare il mesh di dati e il team tecnologico centrale, che generalmente ospita il team della piattaforma di dati centrale.
Per convincere i team Finance ad approvare i finanziamenti per la 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 stessi componenti nei singoli team di distribuzione.
Definisci la piattaforma minima funzionante per il mesh di dati
Per aiutarti a definire la piattaforma minima funzionante per il mesh di dati, ti consigliamo di eseguire un progetto pilota e di eseguire l'iterazione con uno o più business case. Per il tuo progetto pilota, trova i casi d'uso necessari e dove c'è un consumer pronto ad adottare il prodotto di dati risultante. I casi d'uso dovrebbero già disporre di finanziamenti per sviluppare i prodotti di dati, ma dovrebbe esserci la necessità di un contributo da parte dei team tecnici.
Assicurati che il team che sta implementando il progetto pilota comprenda il modello operativo del mesh di dati come segue:
- L'azienda (ovvero il team di produttori di dati) è responsabile 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 aziendale (i domini producono, i domini consumano). 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 dei team trunk e branch per raggruppare le conoscenze, ma consentire comunque lo sviluppo di servizi e prodotti della piattaforma specializzati.
Ti consigliamo inoltre di procedere come segue:
- Pianificare roadmap anziché lasciare che i servizi e le funzionalità si evolvano in modo organico.
- Definisci le funzionalità minime della piattaforma per l'importazione, l'archiviazione, l'elaborazione, l'analisi e il machine learning.
- Integra la governance dei dati in ogni fase, non come un flusso di lavoro separato.
- Implementa le funzionalità minime per la governance, la piattaforma, il flusso di valore e la gestione delle modifiche. Le funzionalità minime sono quelle che soddisfano l'80% dei business case.
Pianifica la coesistenza del mesh di dati con una piattaforma dati esistente
Molte organizzazioni che vogliono implementare un mesh di dati 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 mesh di dati, queste organizzazioni devono pianificare l'evoluzione della piattaforma dati esistente man mano che il mesh di dati 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 gli asset devono essere spostati o se possono essere mantenuti sulla piattaforma esistente e continuare a partecipare al mesh di dati.
Passaggi successivi
- Per saperne di più sulla progettazione e sulla gestione di una topologia cloud, consulta il Well-Architected FrameworkGoogle Cloud .
- Per ulteriori architetture di riferimento, diagrammi e best practice, esplora Cloud Architecture Center.