Progettare una piattaforma di dati self-service per un mesh di dati

Last reviewed 2024-09-03 UTC

In un data mesh, una piattaforma di dati self-service consente agli utenti di generare valore dai dati consentendo loro di creare, condividere e utilizzare autonomamente i prodotti di dati. Per sfruttare appieno questi vantaggi, ti consigliamo che la tua piattaforma di dati self-service fornisca le funzionalità descritte in questo documento.

Questo documento fa parte di una serie che descrive come implementare un data mesh 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 e Architettura e funzioni in un data mesh.

La serie è composta dalle seguenti parti:

I team delle piattaforme di dati in genere creano piattaforme di dati self-service centralizzate, come descritto in questo documento. Questo team crea le soluzioni e i componenti che i team di dominio (sia produttori che consumatori di dati) possono utilizzare per creare e consumare prodotti di dati. I team di dominio rappresentano le parti funzionali di un data mesh. Con la creazione di questi componenti, il team della piattaforma di dati offre un'esperienza di sviluppo fluida e riduce la complessità di creazione, implementazione e manutenzione di prodotti di dati sicuri e interoperabili.

In definitiva, il team della piattaforma di dati dovrebbe consentire ai team di dominio di muoversi più velocemente. Contribuiscono ad aumentare l'efficienza dei team di dominio fornendo loro un insieme limitato di strumenti che soddisfano le loro esigenze. Fornendo questi strumenti, il team della piattaforma di dati rimuove l'onere di dover chiedere al team di dominio di creare e reperire autonomamente questi strumenti. Le scelte degli strumenti devono essere personalizzabili in base a diverse esigenze e non imporre un modo di lavorare rigido ai team di dominio dei dati.

Il team della piattaforma di dati non deve concentrarsi sulla creazione di soluzioni personalizzate per gli orchestratori delle pipeline di dati o per i sistemi di integrazione e deployment continui (CI/CD). Soluzioni come i sistemi CI/CD sono subito disponibili come servizi cloud gestiti, ad esempio Cloud Build. L'utilizzo di servizi cloud gestiti può ridurre gli overhead operativi per il team della piattaforma di dati e consentire di concentrarsi sulle esigenze specifiche dei team di dominio dei dati in qualità di utenti della piattaforma. Con un overhead operativo ridotto, il team della piattaforma di dati può dedicare più tempo a soddisfare le esigenze specifiche dei team di dominio dei dati.

Architettura

Il seguente diagramma illustra i componenti dell'architettura di una piattaforma di dati self-service. Il diagramma mostra anche in che modo questi componenti possono supportare i team nello sviluppo e nel consumo di prodotti dati nel data mesh.

Componenti della piattaforma di dati self-service, come descritto nel testo seguente.

Come mostrato nel diagramma precedente, la piattaforma dati self-service fornisce quanto segue:

  • Soluzioni di piattaforma:queste soluzioni sono costituite da componenti composibili per il provisioning di progetti e risorse Google Cloud, che gli utenti scelgono e assemblano in combinazioni diverse per soddisfare i propri requisiti specifici. Anziché interagire direttamente con i componenti, gli utenti della piattaforma possono interagire con le soluzioni della piattaforma per raggiungere un obiettivo specifico. I team di dominio dati devono progettare soluzioni di piattaforma per risolvere i problemi comuni e le aree di attrito che causano rallentamenti nello sviluppo e nel consumo dei prodotti di dati. Ad esempio, i team di dominio dati che eseguono l'onboarding nel mesh di dati possono utilizzare un modello Infrastructure as Code (IaC). L'utilizzo dei modelli IaC consente di creare rapidamente un insieme di progetti Google Cloud con autorizzazioni di Identity and Access Management (IAM) standard, reti, criteri di sicurezza e API Google Cloud pertinenti abilitati per lo sviluppo di prodotti di dati. Consigliamo di accompagnare ogni soluzione con documentazione, ad esempio indicazioni su come iniziare e esempi di codice. Le soluzioni di piattaforme di dati e i relativi componenti devono essere sicuri e conformi per impostazione predefinita.

  • Servizi comuni: questi servizi forniscono la rilevabilità, la gestione, la condivisione e l'osservabilità dei prodotti di dati. Questi servizi facilitano la fiducia dei consumatori nei confronti dei prodotti di dati e sono un modo efficace per i produttori di dati di avvisare i consumatori in caso di problemi con i loro prodotti di dati.

Le soluzioni di piattaforme di dati e i servizi comuni potrebbero includere quanto segue:

  • Modelli IaC per configurare ambienti di lavoro per lo sviluppo di prodotti di dati di base, tra cui:
    • IAM
    • Logging e monitoraggio
    • Networking
    • Limiti di sicurezza e conformità
    • Tagging delle risorse per l'attribuzione della fatturazione
    • Archiviazione, trasformazione e pubblicazione di prodotti di dati
    • Registrazione, catalogazione e tagging dei metadati dei prodotti di dati
  • Modelli IaC che rispettano le best practice e i guardrail di sicurezza delle organizzazioni e che possono essere utilizzati per eseguire il deployment delle risorse Google Cloud negli spazi di lavoro di sviluppo di prodotti di dati esistenti.
  • Modelli di pipeline di dati e applicazioni che possono essere utilizzati per avviare nuovi progetti o come riferimento per i progetti esistenti. Ecco alcuni esempi di questi modelli:
    • Utilizzo di librerie e framework comuni
    • Integrazione con gli strumenti di logging, monitoraggio e osservabilità della piattaforma
    • Strumenti di creazione e test
    • Gestione della configurazione
    • Pipeline di packaging e CI/CD per il deployment
    • Autenticazione, deployment e gestione delle credenziali
  • Servizi comuni per fornire governance e osservabilità dei prodotti di dati, che possono includere quanto segue:
    • Controlli di uptime per mostrare lo stato complessivo dei prodotti di dati.
    • Metriche personalizzate per fornire indicatori utili sui prodotti di dati.
    • Assistenza operativa da parte del team centrale, in modo che i team di consumatori di dati vengano avvisati delle modifiche ai prodotti di dati che utilizzano.
    • Prospetti dei prodotti per mostrare il rendimento dei prodotti dati.
    • Un catalogo di metadati per rilevare i prodotti dati.
    • Un insieme di criteri di calcolo definiti centralmente che possono essere applicati in modo globale al data mesh.
    • Un marketplace di dati per facilitare la condivisione dei dati tra i team di dominio.

Creare componenti e soluzioni della piattaforma utilizzando i modelli IaC illustra i vantaggi dei modelli IaC per esporre e implementare i prodotti di dati. Fornisci servizi comuni spiega perché è utile fornire ai team di dominio componenti di infrastruttura comuni che sono stati creati e sono gestiti dal team della piattaforma di dati.

Crea componenti e soluzioni della piattaforma utilizzando i modelli IaC

L'obiettivo dei team delle piattaforme di dati è configurare piattaforme di dati self-service per ottenere un valore maggiore dai dati. Per creare queste piattaforme, creano e forniscono ai team di dominio modelli di infrastruttura controllati, sicuri e self-service. I team di dominio utilizzano questi modelli per implementare i propri ambienti di sviluppo e consumo dei dati. I modelli IaC aiutano i team delle piattaforme dati a raggiungere questo obiettivo e a abilitare la scalabilità. L'utilizzo di modelli IaC esaminati e attendibili semplifica la procedura di deployment delle risorse per i team di dominio consentendo loro di riutilizzare le pipeline CI/CD esistenti. Questo approccio consente ai team di dominio di iniziare rapidamente a lavorare e diventare produttivi all'interno del data mesh.

I modelli IaC possono essere creati utilizzando uno strumento IaC. Sebbene esistano diversi strumenti IaC, tra cui Cloud Config Connector, Pulumi, Chef e Ansible, questo documento fornisce esempi per gli strumenti IaC basati su Terraform. Terraform è uno strumento IaC open source che consente al team della piattaforma di dati di creare in modo efficiente componenti e soluzioni della piattaforma componibili per le risorse Google Cloud. Con Terraform, il team della piattaforma di dati scrive codice che specifica lo stato finale scelto e consente allo strumento di capire come raggiungerlo. Questo approccio dichiarativo consente al team della piattaforma di dati di trattare le risorse dell'infrastruttura come artefatti immutabili per il deployment in più ambienti. Inoltre, contribuisce a ridurre il rischio di incoerenze tra le risorse di cui è stato eseguito il deployment e il codice dichiarato nel controllo del codice sorgente (chiamato deviazione della configurazione). La deriva della configurazione causata da modifiche ad hoc e manuali all'infrastruttura ostacola il deployment sicuro e ripetibile dei componenti IaC negli ambienti di produzione.

I modelli IaC comuni per i componenti della piattaforma componibili includono l'utilizzo di moduli Terraform per il deployment di risorse come un set di dati BigQuery, un bucket Cloud Storage o un database Cloud SQL. I moduli Terraform possono essere combinati in soluzioni end-to-end per il deployment di progetti Google Cloud completi, incluse le risorse pertinenti di cui è stato eseguito il deployment utilizzando i moduli componibili. Puoi trovare esempi di moduli Terraform nei blueprint Terraform per Google Cloud.

Per impostazione predefinita, ogni modulo Terraform deve soddisfare i criteri di conformità e le limitazioni di sicurezza utilizzati dalla tua organizzazione. Questi guardrail e criteri possono essere espressi anche come codice ed essere automatizzati utilizzando strumenti di verifica della conformità automatica come lo strumento di convalida dei criteri di Google Cloud.

La tua organizzazione deve testare continuamente i moduli Terraform forniti dalla piattaforma, utilizzando gli stessi guardrail di conformità automatici che utilizza per promuovere le modifiche in produzione.

Per rendere rilevabili e utilizzabili componenti e soluzioni IaC per i team di dominio con esperienza minima con Terraform, ti consigliamo di utilizzare servizi come il catalogo dei servizi. Gli utenti con requisiti di personalizzazione significativi devono poter creare le proprie soluzioni di deployment dagli stessi modelli Terraform componibili utilizzati dalle soluzioni esistenti.

Quando utilizzi Terraform, ti consigliamo di seguire le best practice di Google Cloud descritte in Best practice per l'utilizzo di Terraform.

Per illustrare come Terraform può essere utilizzato per creare componenti della piattaforma, le sezioni seguenti illustrano esempi di come Terraform può essere utilizzato per esporre interfacce di consumo e per utilizzare un prodotto di dati.

Esporre un'interfaccia di consumo

Un'interfaccia di consumo per un prodotto di dati è un insieme di garanzie sulla qualità dei dati e sui parametri operativi forniti dal team di dominio dati per consentire ad altri team di scoprire e utilizzare i propri prodotti di dati. Ogni interfaccia di consumo include anche un modello di assistenza e la documentazione del prodotto. Un prodotto dati può avere diversi tipi di interfacce di consumo, ad esempio API o stream, come descritto in Creare prodotti dati in un data mesh. L'interfaccia di consumo più comune potrebbe essere un set di dati, una vista o una funzione autorizzati BigQuery. Questa interfaccia espone una tabella virtuale di sola lettura, che viene espressa come query nella maglia di dati. L'interfaccia non concede ai lettori l'autorizzazione per accedere direttamente ai dati sottostanti.

Google fornisce un esempio di modulo Terraform per la creazione di visualizzazioni autorizzate senza concedere ai team le autorizzazioni per i set di dati autorizzati sottostanti. Il seguente codice di questo modulo Terraform concede queste autorizzazioni IAM nella visualizzazione autorizzata dataset_id:

module "add_authorization" {
  source = "terraform-google-modules/bigquery/google//modules/authorization"
  version = "~> 4.1"

  dataset_id = module.dataset.bigquery_dataset.dataset_id
  project_id = module.dataset.bigquery_dataset.project

  roles = [
    {
      role           = "roles/bigquery.dataEditor"
      group_by_email = "ops@mycompany.com"
    }
  ]

  authorized_views = [
    {
      project_id = "view_project"
      dataset_id = "view_dataset"
      table_id   = "view_id"
    }
  ]
  authorized_datasets = [
    {
      project_id = "auth_dataset_project"
      dataset_id = "auth_dataset"
    }
  ]
}

Se devi concedere agli utenti l'accesso a più visualizzazioni, l'assegnazione dell'accesso a ogni visualizzazione autorizzata può richiedere molto tempo e essere difficile da gestire. Anziché creare più visualizzazioni autorizzate, puoi utilizzare un set di dati autorizzato per autorizzare automaticamente tutte le visualizzazioni create nel set di dati autorizzato.

Utilizzare un prodotto di dati

Per la maggior parte dei casi d'uso di analisi, i pattern di consumo sono determinati dall'applicazione in cui vengono utilizzati i dati. L'uso principale di un ambiente di consumo fornito centralmente è l'esplorazione dei dati prima che vengano utilizzati all'interno dell'applicazione di consumo. Come discusso in Scoprire e utilizzare i prodotti in un data mesh, SQL è il metodo più comunemente utilizzato per eseguire query sui prodotti di dati. Per questo motivo, la piattaforma di dati deve fornire ai consumatori di dati un'applicazione SQL per l'esplorazione dei dati.

A seconda del caso d'uso di analisi, potresti essere in grado di utilizzare Terraform per eseguire il deployment dell'ambiente di consumo per i consumatori di dati. Ad esempio, la scienza dei dati è un caso d'uso comune per i consumatori di dati. Puoi utilizzare Terraform per eseguire il deployment di blocchi note Vertex AI gestiti dall'utente da utilizzare come ambiente di sviluppo della data science. Dai notebook di data science, i consumatori di dati possono utilizzare le proprie credenziali per accedere al data mesh ed esplorare i dati a cui hanno accesso e sviluppare modelli ML in base a questi dati.

Per scoprire come utilizzare Terraform per eseguire il deployment e contribuire a proteggere un ambiente di notebook su Google Cloud, consulta Creare ed eseguire il deployment di modelli di machine learning e AI generativa in un'azienda.

Fornire servizi comuni

Oltre ai componenti e alle soluzioni IaC self-service, il team della piattaforma di dati potrebbe anche assumere la proprietà della creazione e del funzionamento di servizi della piattaforma condivisi comuni utilizzati da più team di dominio dei dati. Esempi comuni di servizi di piattaforme condivise includono software di terze parti self-hosted come strumenti di visualizzazione della business intelligence o un cluster Kafka. In Google Cloud, il team della piattaforma dati potrebbe scegliere di gestire risorse come Dataplex e gli sink Cloud Logging per conto dei team di dominio dati. La gestione delle risorse per i team di dominio dati consente al team della piattaforma di dati di semplificare la gestione e il controllo centralizzati dei criteri in tutta l'organizzazione.

Le sezioni seguenti mostrano come utilizzare Dataplex per la gestione e la governance centralizzate all'interno di un data mesh su Google Cloud, nonché l'implementazione delle funzionalità di osservabilità dei dati in un data mesh.

Dataplex per la governance dei dati

Dataplex fornisce una piattaforma di gestione dei dati che ti aiuta a creare domini di dati indipendenti all'interno di un data mesh che si estende all'intera organizzazione. Dataplex ti consente di mantenere controlli centrali per governare e monitorare i dati nei vari domini.

Con Dataplex un'organizzazione può organizzare logicamente i propri dati (origini dati supportate) e gli artefatti correlati, come codice, notebook e log, in un Lake Dataplex che rappresenta un dominio di dati. Nel seguente diagramma, un dominio di vendita utilizza Dataplex per organizzare i propri asset, incluse metriche e log sulla qualità dei dati, in zone Dataplex.

Asset organizzati da Dataplex.

Come mostrato nel diagramma precedente, Dataplex può essere utilizzato per gestire i dati di dominio nei seguenti asset:

  • Dataplex consente ai team di dominio di dati di gestire in modo coerente i propri asset di dati in un gruppo logico chiamato lake Dataplex. Il team di dominio dati può organizzare i propri asset Dataplex all'interno dello stesso lake Dataplex senza spostare fisicamente i dati o archiviarli in un unico sistema di archiviazione. Gli asset Dataplex possono fare riferimento ai bucket Cloud Storage e ai set di dati BigQuery archiviati in più progetti Google Cloud diversi dal progetto Google Cloud contenente il lake Dataplex. Gli asset Dataplex possono essere strutturati o non strutturati oppure essere archiviati in un data lake o data warehouse di analisi. Nel diagramma sono presenti data lake per il dominio vendite, il dominio della catena di approvvigionamento e il dominio dei prodotti.
  • Le zone Dataplex consentono al team del dominio di dati di organizzare ulteriormente gli asset di dati in sottogruppi più piccoli all'interno dello stesso lake Dataplex e di aggiungere strutture che acquisiscono gli aspetti chiave del sottogruppo. Ad esempio, le zone Dataplex possono essere utilizzate per gruppare gli asset di dati associati in un prodotto dati. Il raggruppamento delle risorse dati in una singola zona Dataplex consente ai team di dominio dati di gestire in modo coerente i criteri di accesso e i criteri di governance dei dati all'interno della zona come un unico prodotto dati. Nel diagramma sono presenti zone di dati per le vendite offline, le vendite online, i magazzini della catena di approvvigionamento e i prodotti.

I lake e le zone Dataplex consentono a un'organizzazione di unificare i dati distribuiti e organizzarli in base al contesto aziendale. Questa disposizione costituisce la base per attività come la gestione dei metadati, la configurazione dei criteri di governance e il monitoraggio della qualità dei dati. Queste attività consentono all'organizzazione di gestire i propri dati distribuiti su larga scala, ad esempio in un data mesh.

Osservabilità dei dati

Ogni dominio di dati deve implementare i propri meccanismi di monitoraggio e avviso, idealmente utilizzando un approccio standardizzato. Ogni dominio può applicare le pratiche di monitoraggio descritte in Concetti relativi al monitoraggio dei servizi, apportando le modifiche necessarie ai domini di dati. L'osservabilità è un argomento ampio e rientra al di fuori dell'ambito di questo documento. Questa sezione tratta solo dei pattern utili nelle implementazioni di data mesh.

Per i prodotti con più utenti di dati, fornire informazioni tempestive a ciascun consumatore sullo stato del prodotto può diventare un onere operativo. Le soluzioni di base, come le distribuzioni email gestite manualmente, sono in genere soggette a errori. Possono essere utili per informare i consumatori di interruzioni pianificate, lanci di prodotti imminenti e ritiri, ma non forniscono informazioni operative in tempo reale.

I servizi centrali possono svolgere un ruolo importante nel monitoraggio dell'integrità e della qualità degli elementi del data mesh. Sebbene non sia un prerequisito per un'implementazione di successo del data mesh, l'implementazione di funzionalità di osservabilità può migliorare la soddisfazione dei produttori e dei consumatori di dati e ridurre i costi operativi e di assistenza complessivi. Il seguente diagramma mostra un'architettura di observability del mesh di dati basata su Cloud Monitoring.

Osservabilità del data mesh.

Le sezioni seguenti descrivono i componenti mostrati nel diagramma, che sono:

Controlli di uptime

I prodotti di dati possono creare semplici applicazioni personalizzate che implementano controlli di uptime. Questi controlli possono fungere da indicatori di alto livello dello stato complessivo del prodotto. Ad esempio, se il team di prodotto dati rileva un improvviso calo della qualità dei dati del suo prodotto, può contrassegnarlo come non valido. I controlli di uptime simili al tempo reale sono particolarmente importanti per i consumatori di dati che hanno prodotti derivati che si basano sulla disponibilità costante dei dati nel prodotto di dati a monte. I produttori di dati devono creare i controlli di uptime in modo da includere le dipendenze upstream, fornendo così ai consumatori di dati un quadro preciso dell'integrità del loro prodotto.

I consumatori di dati possono includere i controlli dell'uptime del prodotto nell'elaborazione. Ad esempio, un job di Composer che genera un report in base ai dati forniti da un prodotto di dati può, come primo passaggio, convalidare se il prodotto è nello stato "in esecuzione". Ti consigliamo di impostare l'applicazione di controllo dell'uptime in modo che restituisca un payload strutturato nel corpo del messaggio della risposta HTTP. Questo payload strutturato deve indicare se esiste un problema, la causa principale del problema in forma leggibile e, se possibile, il tempo stimato per il ripristino del servizio. Questo payload strutturato può anche fornire informazioni più dettagliate sullo stato del prodotto. Ad esempio, può contenere le informazioni sanitarie per ciascuna delle visualizzazioni nel set di dati autorizzato esposto come prodotto.

Metriche personalizzate

I prodotti di dati possono avere varie metriche personalizzate per misurarne l'utilità. I team di produttori di dati possono pubblicare queste metriche personalizzate nei progetti Google Cloud specifici per dominio designati. Per creare un'esperienza di monitoraggio unificata per tutti i prodotti di dati, a un progetto di monitoraggio del mesh di dati centralizzato può essere concesso l'accesso a questi progetti specifici per dominio.

Ogni tipo di interfaccia di consumo dei prodotti di dati ha metriche diverse per misurarne l'utilità. Le metriche possono essere specifiche anche per il dominio dell'attività. Ad esempio, le metriche per le tabelle BigQuery esposte tramite viste o tramite l'API Storage Read possono essere le seguenti:

  • Il numero di righe.
  • Aggiornamento dei dati (espresso come numero di secondi prima del momento della misurazione).
  • Il punteggio della qualità dei dati.
  • I dati disponibili. Questa metrica può indicare che i dati sono disponibili per le query. Un'alternativa è utilizzare i controlli di uptime menzionati in precedenza in questo documento.

Queste metriche possono essere considerate indicatori del livello del servizio (SLI) per un determinato prodotto.

Per gli stream di dati (implementati come argomenti Pub/Sub), questo elenco può essere costituito dalle metriche Pub/Sub standard, disponibili tramite gli argomenti.

Assistenza operativa da parte del team della piattaforma di dati centralizzata

Il team della piattaforma di dati centralizzata può esporre dashboard personalizzate per mostrare ai consumatori di dati diversi livelli di dettagli. Una semplice dashboard dello stato che elenca i prodotti nel data mesh e lo stato di uptime di questi prodotti può essere utile per rispondere a più richieste degli utenti finali.

Il team centrale può anche fungere da hub di distribuzione delle notifiche per informare i consumatori di dati su vari eventi nei prodotti di dati che utilizzano. In genere, questo hub viene creato creando criteri di avviso. La centralizzazione di questa funzione può ridurre il lavoro che deve essere svolto da ogni team di produttori di dati. La creazione di queste norme non richiede conoscenza degli ambiti di dati e dovrebbe contribuire a evitare colli di bottiglia nel consumo di dati.

Uno stato finale ideale per il monitoraggio del data mesh è che il modello di tag del prodotto dati esponga gli SLI e gli scopi di livello del servizio (SLO) supportati dal prodotto quando diventa disponibile. Il team centrale può quindi eseguire automaticamente il deployment degli avvisi corrispondenti utilizzando il monitoraggio del servizio con l'API Monitoring.

prospetti dei prodotti

Nell'ambito del contratto di governance centrale, le quattro funzioni di un data mesh possono definire i criteri per creare prospetti per i prodotti di dati. Queste schede di valutazione possono diventare una misura oggettiva del rendimento dei prodotti di dati.

Molte delle variabili utilizzate per calcolare i prospetti sono la percentuale di volte in cui i prodotti di dati soddisfano i relativi SLO. Alcuni criteri utili possono essere la percentuale di tempo di attività, i punteggi medi di qualità dei dati e la percentuale di prodotti con l'aggiornamento dei dati non inferiore a una soglia. Per calcolare automaticamente queste metriche utilizzando Monitoring Query Language (MQL), le metriche personalizzate e i risultati dei controlli di uptime del progetto di monitoraggio centralizzato dovrebbero essere sufficienti.

Passaggi successivi