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

Last reviewed 2022-10-06 UTC

In un mesh di dati, una piattaforma dati self-service consente agli utenti di generare valore dai dati consentendo loro di creare, condividere e utilizzare in modo autonomo i prodotti di dati. Per sfruttare appieno questi vantaggi, consigliamo alla tua piattaforma di dati self-service di fornire le funzionalità descritte 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 Creare un moderno mesh di dati distribuito con Google Cloud e Architettura e funzioni in un mesh di dati.

La serie è composta dalle seguenti parti:

In genere i team dedicati alle piattaforme dati creano piattaforme di dati self-service centrali, come descritto in questo documento. Questo team crea le soluzioni e i componenti che i team di dominio (sia i producer di dati sia i consumatori dei dati) possono utilizzare per creare e utilizzare prodotti di dati. I team del dominio rappresentano parti funzionali di un mesh di dati. Creando questi componenti, il team della piattaforma dati consente un'esperienza di sviluppo fluida e riduce la complessità di creazione, deployment e gestione di prodotti di dati sicuri e interoperabili.

Infine, il team responsabile della piattaforma dati deve consentire ai team del 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 dati elimina l'onere di creare e reperire autonomamente gli strumenti di dominio. Le scelte di strumentazione devono essere personalizzabili in base alle diverse esigenze e non forzare un modo inflessibile di lavoro con i team dei domini di dati.

Il team dedicato alla piattaforma dati non deve concentrarsi sulla creazione di soluzioni personalizzate per gli orchestratori di pipeline di dati o per i sistemi di integrazione continua e deployment continuo (CI/CD). Soluzioni come i sistemi CI/CD sono prontamente disponibili come servizi cloud gestiti, ad esempio Cloud Build. L'uso dei servizi cloud gestiti può ridurre i costi operativi generali per il team della piattaforma dati e consentire agli utenti di concentrarsi sulle esigenze specifiche dei team dedicati ai domini di dati. Con un carico di lavoro operativo ridotto, il team dedicato alla piattaforma dati può concentrarsi su come rispondere più rapidamente alle esigenze specifiche dei team di dominio dei dati.

Il seguente diagramma illustra i componenti dell'architettura di una piattaforma dati self-service. Il diagramma mostra anche come questi componenti possono supportare i team mentre sviluppano e consumano prodotti di dati nel mesh di dati.

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

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

  • Soluzioni per piattaforma: queste soluzioni sono costituite da componenti componibili per il provisioning di progetti e risorse Google Cloud, che gli utenti selezionano e assemblano in diverse combinazioni per soddisfare i propri requisiti specifici. Anziché interagire direttamente con i componenti, gli utenti della piattaforma possono interagire con le soluzioni della piattaforma per aiutarli a raggiungere un obiettivo specifico. I team di dominio dei dati dovrebbero progettare soluzioni per piattaforma per risolvere i punti critici e le aree di attrito comuni che causano rallentamenti nello sviluppo e nel consumo dei prodotti di dati. Ad esempio, i team di dominio dei dati che eseguono l'onboarding sul mesh di dati possono utilizzare un modello Infrastructure as a Code (IaC). L'uso dei modelli IaC consente di creare rapidamente un insieme di progetti Google Cloud con autorizzazioni standard di Identity and Access Management (IAM), networking, criteri di sicurezza e API Google Cloud pertinenti abilitate per lo sviluppo di prodotti di dati. Consigliamo di fare in modo che ogni soluzione sia accompagnata da documentazione, come istruzioni introduttive ed esempi di codice. Le soluzioni delle piattaforme dati e i relativi componenti devono essere sicuri e conformi per impostazione predefinita.

  • Servizi comuni: questi servizi offrono visibilità, gestione, condivisione e osservabilità dei prodotti di dati. Questi servizi facilitano la fiducia dei consumatori nei dati e sono un modo efficace per consentire ai producer di avvisare i consumatori dei problemi relativi ai loro prodotti di dati.

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

  • Modelli IaC per configurare ambienti di Workspace per lo sviluppo di prodotti di base, che includono quanto segue:
    • IAM
    • Logging e monitoraggio
    • Networking
    • Protezioni e sicurezza
    • Tagging delle risorse per l'attribuzione della fatturazione
    • Archiviazione, trasformazione e pubblicazione di prodotti di dati
    • Registrazione dei prodotti, catalogazione e tagging dei metadati
  • Modelli IaC che rispettano le misure di protezione dell'organizzazione e le best practice che possono essere utilizzate per eseguire il deployment delle risorse Google Cloud in aree di lavoro di sviluppo dei prodotti esistenti.
  • Modelli di applicazioni e pipeline di dati che possono essere utilizzati per eseguire il bootstrap di nuovi progetti o come riferimento per progetti esistenti. Ecco alcuni esempi:
    • Utilizzo di librerie e framework comuni
    • Integrazione con strumenti di logging, monitoraggio e osservabilità della piattaforma
    • Crea e testa gli strumenti
    • Gestione della configurazione
    • Packaging e pipeline CI/CD per il deployment
    • Autenticazione, deployment e gestione delle credenziali
  • Servizi comuni per fornire osservabilità e governance dei prodotti dati che possono includere quanto segue:
    • Controlli di uptime per mostrare lo stato generale dei prodotti di dati.
    • Metriche personalizzate per fornire utili indicatori sui prodotti di dati.
    • Assistenza operativa da parte del team centrale in modo che i team dei consumatori di dati vengano avvisati delle modifiche ai prodotti di dati che utilizzano.
    • Prospetti dei prodotti per mostrare il rendimento dei prodotti di dati.
    • Un catalogo di metadati per scoprire i prodotti di dati.
    • Un insieme definito a livello centrale di criteri di calcolo che possono essere applicati a livello globale nel mesh di dati.
    • Un marketplace di dati per facilitare la condivisione dei dati tra team di dominio.

Creare soluzioni e componenti della piattaforma utilizzando i modelli IaC illustra i vantaggi dei modelli IaC per esporre ed eseguire il deployment dei prodotti di dati. Servizi comuni spiega perché è utile fornire ai team di dominio componenti di infrastruttura comuni creati e gestiti dal team della piattaforma dati.

Crea soluzioni e componenti per piattaforme utilizzando i modelli IaC

L'obiettivo dei team che utilizzano piattaforme di dati è configurare le piattaforme di dati self-service per ottenere di più 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 eseguire il deployment dei propri ambienti di sviluppo e consumo dei dati. I modelli IaC aiutano i team della piattaforma dati a raggiungere tale obiettivo e consentire la scalabilità. L'utilizzo di modelli IaC verificati e affidabili semplifica il processo di deployment delle risorse per i team del dominio, consentendo a questi team di riutilizzare le pipeline CI/CD esistenti. Questo approccio consente ai team di dominio di iniziare rapidamente e diventare produttivi all'interno del mesh di dati.

I modelli IaC possono essere creati utilizzando uno strumento IaC. Anche se sono disponibili più strumenti IaC, tra cui Cloud Config Connector, Pulumi, Chef e Ansible, questo documento fornisce esempi di strumenti IaC basati su Terraform. Terraform è uno strumento IaC open source che consente al team della piattaforma dati di creare in modo efficiente componenti e soluzioni di piattaforma componibili per le risorse Google Cloud. Utilizzando Terraform, il team della piattaforma dati scrive codice che specifica lo stato finale desiderato e consente allo strumento di capire come ottenere questo stato. Questo approccio dichiarativo consente al team della piattaforma dati di trattare le risorse dell'infrastruttura come artefatti immutabili per il deployment in diversi ambienti. Inoltre, consente di ridurre il rischio di incongruenze tra le risorse di cui è stato eseguito il deployment e il codice dichiarato nel controllo del codice sorgente (noto come deviazione della configurazione). La deviazione 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 delle piattaforme componibili includono l'utilizzo di moduli Terraform per il deployment di risorse come set di dati BigQuery, bucket Cloud Storage o 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 sottoposte a deployment utilizzando i moduli componibili. Esempi di moduli Terraform sono disponibili nei progetti di Terraform per Google Cloud.

Ogni modulo Terraform dovrebbe soddisfare, per impostazione predefinita, criteri di sicurezza e criteri di conformità utilizzati dalla tua organizzazione. Queste restrizioni e criteri possono essere espressi anche come codice e essere automatizzati utilizzando strumenti di verifica automatica della conformità come lo strumento di convalida dei criteri di Google Cloud.

L'organizzazione deve testare continuamente i moduli Terraform forniti dalla piattaforma, utilizzando gli stessi sistemi di protezione automatica utilizzati per promuovere le modifiche alla produzione.

Per rendere i componenti e le soluzioni IaC rilevabili e consumabili per i team di dominio che hanno un'esperienza minima con Terraform, ti consigliamo di utilizzare servizi come Service Catalog. Gli utenti con requisiti di personalizzazione significativi devono essere autorizzati a 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 per Google Cloud come descritto in Best practice per l'utilizzo di Terraform.

Per illustrare il modo in cui Terraform può essere utilizzato per creare componenti della piattaforma, nelle sezioni seguenti vengono illustrati alcuni esempi di come Terraform può essere utilizzato per esporre le interfacce di consumo e per consumare 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 del dominio di dati per consentire ad altri team di scoprire e utilizzare i loro prodotti di dati. Ogni interfaccia di consumo include anche un modello di supporto del prodotto e la documentazione del prodotto. Un prodotto dati può avere diversi tipi di interfacce di consumo, come API o flussi, come descritto in Creare prodotti di dati in un mesh di dati. L'interfaccia di consumo più comune potrebbe essere un set di dati autorizzato di BigQuery, una visualizzazione autorizzata o una funzione autorizzata. Questa interfaccia espone una tabella virtuale di sola lettura, espressa come query nella rete dati. L'interfaccia non concede al lettore le autorizzazioni per accedere direttamente ai dati sottostanti.

Google offre un esempio di modulo Terraform per la creazione di viste autorizzate senza concedere ai team le autorizzazioni per i set di dati autorizzati sottostanti. Il codice seguente in questo modulo Terraform concede queste autorizzazioni IAM sulla visualizzazione autorizzata di 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ù viste, l'accesso a ogni visualizzazione autorizzata può richiedere tempo e richiedere interventi di manutenzione più complessi. Anziché creare più viste autorizzate, puoi utilizzare un set di dati autorizzato per autorizzare automaticamente le viste create nel set di dati autorizzato.

Consumare un prodotto di dati

Per la maggior parte dei casi d'uso di analisi, i modelli di consumo sono determinati dall'applicazione in cui vengono utilizzati i dati. L'utilizzo principale di un ambiente di consumo fornito a livello centrale è per l'esplorazione dei dati prima che i dati vengano utilizzati all'interno dell'applicazione a consumo. Come descritto in Scoprire e utilizzare i prodotti in un mesh di dati, SQL è il metodo più comunemente utilizzato per eseguire query sui prodotti di dati. Per questo motivo, la piattaforma dati deve fornire ai consumatori dei 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 data science è un caso d'uso comune per i consumatori dei dati. Puoi usare Terraform per eseguire il deployment dei blocchi note gestiti dall'utente di Vertex AI da utilizzare come ambiente di sviluppo di data science. Dai blocchi note di data science, i consumatori dei dati possono utilizzare le proprie credenziali per accedere al mesh di dati al fine di esplorare i dati a cui hanno accesso e sviluppare modelli di machine learning basati su questi dati.

Per scoprire come utilizzare Terraform per eseguire il deployment e proteggere un ambiente blocco note su Google Cloud, consulta Protezione dei dati riservati nei blocchi note gestiti dall'utente di Vertex AI Workbench.

Fornire servizi comuni

Oltre ai componenti e alle soluzioni IaC self-service, il team della piattaforma dati potrebbe anche assumere la proprietà della creazione e della gestione di servizi comuni della piattaforma condivisa utilizzati da più team di domini di dati. Gli esempi più comuni di servizi per piattaforme condivise includono software di terze parti in hosting come strumenti di visualizzazione di business intelligence o un cluster Kafka. In Google Cloud, il team dedicato alla piattaforma dati può scegliere di gestire risorse come i sink di Dataplex e Cloud Logging per conto dei team di domini di dati. La gestione delle risorse per i team del dominio di dati consente al team della piattaforma dati di gestire e controllare centralmente i criteri in tutta l'organizzazione.

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

Dataplex per la governance dei dati

Dataplex fornisce una piattaforma di gestione dei dati che consente di creare domini di dati indipendenti all'interno di un mesh di dati che copre l'intera organizzazione. Dataplex consente di mantenere i controlli centralizzati per la gestione e il monitoraggio dei dati tra i domini.

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

Asset organizzati da Dataplex.

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

  • Dataplex consente ai team del dominio di dati di gestire costantemente i propri asset di dati in un gruppo logico chiamato data lake. Il team dedicato al dominio dati può organizzare gli 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 a bucket Cloud Storage e 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 archiviati in un data lake analitico o un data warehouse. Nel diagramma sono presenti data lake per il dominio di vendita, il dominio della catena di fornitura e il dominio del prodotto.
  • 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 raggruppare gli asset di dati associati in un prodotto dati. Il raggruppamento degli asset di dati in una singola zona Dataplex consente ai team del dominio di dati di gestire i criteri di accesso e i criteri di governance dei dati in modo coerente in tutta la zona come un unico prodotto di dati. Nel diagramma ci sono le zone dati per le vendite offline, le vendite online, i warehouse della catena di fornitura e i prodotti.

I data lake e le zone Dataplex consentono a un'organizzazione di unificare i dati distribuiti e organizzarli in base al contesto aziendale. Questo accordo 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 mesh di dati.

Osservabilità dei dati

Ogni dominio di dati dovrebbe implementare i propri meccanismi di monitoraggio e avviso, possibilmente utilizzando un approccio standardizzato. Ogni dominio può applicare le pratiche di monitoraggio descritte in Concetti sul monitoraggio dei servizi, apportando le modifiche necessarie ai domini di dati. L'osservabilità è un argomento di grandi dimensioni che non rientra nell'ambito di questo documento. Questa sezione riguarda solo i pattern utili nelle implementazioni del mesh di dati.

Per i prodotti con consumatori multipli di dati, fornire informazioni tempestive a ogni consumatore sullo stato del prodotto può diventare un onere operativo. Le soluzioni di base, come le distribuzioni email gestite manualmente, sono generalmente soggette a errori. Possono essere utili per avvisare i consumatori di interruzioni pianificate, lanci di prodotti imminenti e deprecazioni, ma non forniscono consapevolezza operativa in tempo reale.

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

Osservabilità del mesh di dati.

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

Controlli di uptime

I prodotti di dati possono creare semplici applicazioni personalizzate che implementano i controlli di uptime. Questi controlli possono fungere da indicatori di alto livello dello stato generale del prodotto. Ad esempio, se il team di prodotto di dati rileva un calo improvviso della qualità dei dati, può contrassegnarlo come non integro. I controlli di uptime quasi in tempo reale sono particolarmente importanti per i consumatori dei dati che hanno derivato prodotti che si basano sulla disponibilità costante dei dati nel prodotto dati a monte. I producer di dati dovrebbero creare controlli di uptime per includere il controllo delle dipendenze dipendenti a monte, fornendo così un quadro accurato dell'integrità del loro prodotto ai consumatori di dati.

I consumatori di dati possono includere i controlli di uptime del prodotto nel loro trattamento. Ad esempio, un job di composizione che genera un report basato sui dati forniti da un prodotto di dati può, come primo passaggio, verificare se il prodotto è in stato "in esecuzione". Consigliamo che l'applicazione del controllo di uptime restituisca un payload strutturato nel corpo del messaggio della risposta HTTP. Questo payload strutturato dovrebbe indicare se c'è un problema, la causa principale del problema in forma leggibile e, se possibile, il tempo stimato per ripristinare il servizio. Questo payload strutturato può anche fornire informazioni più granulari sullo stato del prodotto. Ad esempio, può contenere informazioni sullo stato di integrità per ciascuna delle viste nel set di dati autorizzato esposte come prodotto.

Metriche personalizzate

I prodotti dati possono avere varie metriche personalizzate per misurarne l'utilità. I team di producer di dati possono pubblicare queste metriche personalizzate nei propri progetti Google Cloud designati per il dominio. Per creare un'esperienza di monitoraggio unificata per tutti i prodotti di dati, è possibile concedere accesso a un progetto di monitoraggio mesh di dati centrale ai progetti specifici del dominio.

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

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

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

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

Supporto operativo da parte del team responsabile della piattaforma dati

Il team della piattaforma dati centrale può esporre dashboard personalizzate per visualizzare diversi livelli di dettagli per i consumatori dei dati. Una semplice dashboard dello stato che elenca i prodotti nel mesh di dati e lo stato di uptime per questi prodotti può aiutare a rispondere a più richieste dell'utente finale.

Il team centrale può anche servire come hub di distribuzione delle notifiche per notificare ai consumatori dei dati i vari eventi nei prodotti di dati che utilizzano. In genere, questo hub viene creato creando criteri di avviso. Centralizzare questa funzione può ridurre il lavoro che deve essere fatto da ogni team di produttori di dati. La creazione di questi criteri non richiede la conoscenza dei domini di dati e dovrebbe contribuire a evitare colli di bottiglia nel consumo dei dati.

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

Prospetti dei prodotti

Nell'ambito dell'accordo di governance centrale, le quattro funzioni di un mesh di dati possono definire i criteri per creare prospetti per i prodotti di dati. Questi prospetti possono diventare una misurazione oggettiva del rendimento dei prodotti di dati.

Molte delle variabili utilizzate per calcolare i prospetti rappresentano la percentuale di tempo in cui i prodotti di dati soddisfano lo SLO. I criteri utili possono essere la percentuale di uptime, i punteggi medi di qualità dei dati e la percentuale di prodotti con aggiornamento dei dati che non scendono al di sotto di una soglia. Per calcolare queste metriche automaticamente utilizzando Monitoring Query Language (MQL), le metriche personalizzate e i risultati dei controlli di uptime dal progetto di monitoraggio centrale dovrebbero essere sufficienti.

Passaggi successivi