Creare prodotti dati in un mesh di dati

Last reviewed 2024-09-03 UTC

Per garantire che i casi d'uso dei consumatori di dati vengano soddisfatti, è essenziale che i prodotti di dati in un data mesh vengano progettati e realizzati con cura. La progettazione di un prodotto di dati inizia con la definizione di come i consumatori di dati utilizzerebbero il prodotto e di come questo viene poi mostrato ai consumatori. I prodotti di dati in un mesh di dati vengono creati su un datastore (ad esempio un data warehouse o un data lake di dominio). Quando crei prodotti di dati in un data mesh, esistono alcuni fattori chiave che ti consigliamo di prendere in considerazione durante questa procedura. Queste considerazioni sono 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 Architettura e funzioni in un mesh di dati e Creare un mesh di dati moderno e distribuito con Google Cloud.

La serie è composta dalle seguenti parti:

Quando crei prodotti di dati da un data warehouse di dominio, consigliamo ai produttori di dati di progettare attentamente le interfacce di analisi (consumo) per questi prodotti. Queste interfacce di consumo sono un insieme di garanzie sulla qualità dei dati e sui parametri operativi, oltre a un modello di assistenza e documentazione del prodotto. Il costo della modifica delle interfacce di consumo è solitamente elevato a causa della necessità sia del produttore di dati sia di più potenziali consumatori di dati di modificare le proprie applicazioni e procedure di consumo. Dato che i consumatori di dati si trovano molto probabilmente in unità organizzative diverse da quelle dei produttori di dati, il coordinamento delle modifiche può essere difficile.

Le sezioni seguenti forniscono informazioni di base su ciò che devi considerare quando crei un warehouse di dominio, definisci le interfacce di consumo ed esponi queste interfacce ai consumatori di dati.

Creare un data warehouse di dominio

Non esiste una differenza fondamentale tra la creazione di un data warehouse autonomo e la creazione di un data warehouse di dominio da cui il team di produttori di dati crea i prodotti di dati. L'unica differenza reale tra i due è che quest'ultimo espone un sottoinsieme dei suoi dati tramite le interfacce di consumo.

In molti data warehouse, i dati non elaborati importati dalle origini dati operative vengono sottoposti al processo di arricchimento e verifica della qualità dei dati (cura). Nei data lake gestiti da Dataplex, i dati selezionati vengono in genere archiviati in zone selezionate. Al termine della selezione, un sottoinsieme di dati dovrebbe essere pronto per essere utilizzato al di fuori del dominio tramite diversi tipi di interfacce. Per definire queste interfacce di consumo, un'organizzazione deve fornire un insieme di strumenti ai team di dominio che non hanno mai adottato un approccio di data mesh. Questi strumenti consentono ai produttori di dati di creare nuovi prodotti di dati in modalità self-service. Per le pratiche consigliate, consulta Progettare una piattaforma di dati self-service.

Inoltre, i prodotti di dati devono soddisfare i requisiti di governance dei dati definiti a livello centrale. Questi requisiti influiscono sulla qualità, sulla disponibilità e sulla gestione del ciclo di vita dei dati. Poiché questi requisiti fanno sì che i consumatori di dati si fidino dei prodotti di dati e ne incoraggiano l'utilizzo, i vantaggi dell'implementazione di questi requisiti valgono la pena dell'impegno necessario per sostenerli.

Definisci le interfacce di consumo

Consigliamo ai produttori di dati di utilizzare più tipi di interfacce anziché definirne solo una o due. Ogni tipo di interfaccia in data analytics presenta vantaggi e svantaggi e non esiste un unico tipo di interfaccia che eccelle in tutto. Quando i produttori di dati valutano l'idoneità di ciascun tipo di interfaccia, devono prendere in considerazione quanto segue:

  • Capacità di eseguire l'elaborazione dei dati necessaria.
  • Scalabilità per supportare i casi d'uso attuali e futuri dei consumatori di dati.
  • Rendimento richiesto dai consumatori di dati.
  • Costo di sviluppo e manutenzione.
  • Costo di gestione dell'interfaccia.
  • Supporto per le lingue e gli strumenti utilizzati dalla tua organizzazione.
  • Supporto per la separazione di archiviazione e calcolo.

Ad esempio, se il requisito aziendale è essere in grado di eseguire query analitiche su un set di dati di dimensioni pari a un petabyte, l'unica interfaccia pratica è una vista BigQuery. Tuttavia, se i requisiti sono fornire dati in streaming quasi in tempo reale, è più appropriata un'interfaccia basata su Pub/Sub.

Molte di queste interfacce non richiedono di copiare o replicare i dati esistenti. La maggior parte di questi ti consente anche di separare lo spazio di archiviazione e l'elaborazione, una funzionalità fondamentale degli strumenti di analisi di Google Cloud. I consumatori dei dati esposti tramite queste interfacce li elaborano utilizzando le risorse di calcolo a loro disposizione. I produttori di dati non devono eseguire alcun provisioning aggiuntivo dell'infrastruttura.

Esistono molte interfacce di consumo. Le seguenti interfacce sono quelle più comuni utilizzate in un data mesh e sono descritte nelle sezioni seguenti:

L'elenco delle interfacce in questo documento non è esaustivo. Esistono anche altre opzioni che potresti prendere in considerazione per le interfacce di consumo (ad esempio Analytics Hub). Tuttavia, queste altre interfacce non rientrano nell'ambito di questo documento.

Visualizzazioni e funzioni autorizzate

Per quanto possibile, i prodotti di dati devono essere esposti tramite visualizzazioni autorizzate e funzioni autorizzate,incluse le funzioni con valori di tabella. I set di dati autorizzati offrono un modo pratico per autorizzare automaticamente più visualizzazioni. L'utilizzo delle viste autorizzate impedisce l'accesso diretto alle tabelle di base e consente di ottimizzare le tabelle e le query sottostanti, senza influire sull'utilizzo da parte dei consumatori di queste viste. Gli utenti di questa interfaccia utilizzano SQL per eseguire query sui dati. Il seguente diagramma illustra l'utilizzo dei set di dati autorizzati come interfaccia di consumo.

Interfacce di consumo.

I set di dati e le visualizzazioni autorizzati consentono di abilitare una facile gestione delle versioni delle interfacce. Come mostrato nel seguente diagramma, esistono due approcci principali alla gestione delle versioni che i produttori di dati possono adottare:

Controllo delle versioni di set di dati e visualizzazioni.

Gli approcci possono essere riassunti come segue:

  • Controllo delle versioni dei set di dati:in questo approccio, esegui il controllo delle versioni del nome del set di dati. Non gestisci le versioni delle visualizzazioni e delle funzioni all'interno del set di dati. Mantieni gli stessi nomi per le visualizzazioni e le funzioni indipendentemente dalla versione. Ad esempio, la prima versione di un set di dati sulle vendite è definita in un set di dati chiamato sales_v1 con due visualizzazioni, catalog e orders. Per la seconda versione, il set di dati sulle vendite è stato rinominato sales_v2 e le visualizzazioni precedenti nel set di dati mantengono i nomi precedenti, ma hanno nuovi schemi. Alla seconda versione del set di dati potrebbero essere state aggiunte nuove visualizzazioni o potrebbe essere stata rimossa qualsiasi visualizzazione precedente.
  • Controllo delle versioni delle visualizzazioni:in questo approccio, le visualizzazioni all'interno del set di dati vengono controllate in base alla versione anziché il set di dati stesso. Ad esempio, il set di dati sulle vendite mantiene il nome sales indipendentemente dalla versione. Tuttavia, i nomi delle visualizzazioni all'interno del set di dati cambiano per riflettere ogni nuova versione della visualizzazione (ad esempio catalog_v1, catalog_v2, orders_v1, orders_v2 e orders_v3).

L'approccio di gestione delle versioni migliore per la tua organizzazione dipende dalle norme della tua organizzazione e dal numero di visualizzazioni rese obsolete con l'aggiornamento dei dati sottostanti. Il controllo delle versioni dei set di dati è ideale quando è necessario un aggiornamento sostanziale del prodotto e la maggior parte delle visualizzazioni deve essere modificata. Il controllo delle versioni delle visualizzazioni comporta un numero inferiore di visualizzazioni con lo stesso nome in set di dati diversi, ma può generare ambiguità, ad esempio su come capire se un'unione tra set di dati funziona correttamente. Un approccio ibrido può essere un buon compromesso. In un approccio ibrido, le modifiche dello schema compatibili sono consentite all'interno di un singolo set di dati, mentre quelle incompatibili richiedono un nuovo set di dati.

Considerazioni sulle tabelle BigLake

Le visualizzazioni autorizzate possono essere create non solo nelle tabelle BigQuery, ma anche nelle tabelle BigLake. Le tabelle BigLake consentono ai consumatori di eseguire query sui dati archiviati in Cloud Storage utilizzando l'interfaccia SQL di BigQuery. Le tabelle BigLake supportano controllo dell'accesso granulare senza che i consumatori di dati debbano disporre delle autorizzazioni di lettura per il bucket Cloud Storage sottostante.

I produttori di dati devono considerare quanto segue per le tabelle BigLake:

  • Il design dei formati dei file e il layout dei dati influiscono sul rendimento delle query. I formati basati su colonne, ad esempio Parquet o ORC, in genere hanno un rendimento molto migliore per le query di analisi rispetto ai formati JSON o CSV.
  • Un layout partizionato Hive ti consente di eliminare le partizioni e velocizzare le query che utilizzano le colonne di partizionamento.
  • Nella fase di progettazione devono essere presi in considerazione anche il numero di file e il rendimento delle query preferito per le dimensioni dei file.

Se le query che utilizzano le tabelle BigLake non soddisfano i requisiti del contratto di livello di servizio (SLA) per l'interfaccia e non possono essere ottimizzate, consigliamo di svolgere le seguenti azioni:

  • Per i dati che devono essere esposti all'utente che li utilizza, convertili in spazio di archiviazione BigQuery.
  • Ridefinisci le visualizzazioni autorizzate per utilizzare le tabelle BigQuery.

In genere, questo approccio non causa interruzioni per i consumatori di dati né richiede modifiche alle loro query. Le query nello spazio di archiviazione BigQuery possono essere ottimizzate utilizzando tecniche non possibili con le tabelle BigLake. Ad esempio, con lo spazio di archiviazione BigQuery, gli utenti possono eseguire query sulle viste materializzate con partizioni e raggruppamenti diversi rispetto alle tabelle di base e possono utilizzare BigQuery BI Engine.

API di lettura diretta

Sebbene in genere sconsigliamo ai produttori di dati di concedere ai consumatori di dati accesso di lettura diretto alle tabelle di base, a volte potrebbe essere pratico consentire questo accesso per motivi quali rendimento e costi. In questi casi, è necessario prestare particolare attenzione per garantire la stabilità dello schema della tabella.

Esistono due modi per accedere direttamente ai dati in un data warehouse standard. I produttori di dati possono utilizzare l'API BigQuery Storage Read o le API JSON o XML di Cloud Storage. Il diagramma seguente illustra due esempi di consumatori che utilizzano queste API. Uno è un caso d'uso di machine learning (ML) e l'altro è un job di elaborazione dei dati.

Casi d'uso di ML ed elaborazione dei dati, spiegati nel testo che segue.

La gestione delle versioni di un'interfaccia di lettura diretta è complessa. In genere, i produttori di dati devono creare un'altra tabella con uno schema diverso. Inoltre, devono gestire due versioni della tabella finché tutti i consumatori di dati della versione ritirata non eseguono la migrazione a quella nuova. Se i consumatori possono tollerare l'interruzione della tabella e il passaggio al nuovo schema, è possibile evitare la duplicazione dei dati. Nei casi in cui le modifiche allo schema possono essere compatibili con le versioni precedenti, la migrazione della tabella di base può essere evitata. Ad esempio, non devi eseguire la migrazione della tabella di base se vengono aggiunte solo nuove colonne e i dati in queste colonne vengono sottoposti a backfill per tutte le righe.

Di seguito è riportato un riepilogo delle differenze tra l'API Storage di lettura e l'API Cloud Storage. In generale, se possibile, consigliamo ai produttori di dati di utilizzare l'API BigQuery per le applicazioni di analisi.

  • API Storage Read: l'API Storage Read può essere utilizzata per leggere i dati nelle tabelle BigQuery e nelle tabelle BigLake. Questa API supporta i filtri e controllo dell'accesso granulare e può essere una buona opzione per i consumatori di ML o di analisi dei dati stabili.

  • API Cloud Storage: i produttori di dati potrebbero dover condividere un determinato bucket Cloud Storage direttamente con i consumatori di dati. Ad esempio, i produttori di dati possono condividere il bucket se i consumatori di dati non possono utilizzare l'interfaccia SQL per qualche motivo o se il bucket ha formati di dati non supportati dall'API Storage Read.

In generale, sconsigliamo ai produttori di dati di consentire l'accesso diretto tramite le API di archiviazione perché l'accesso diretto non consente il filtraggio e il controllo granulare degli accessi. Tuttavia, l'approccio di accesso diretto può essere una scelta valida per set di dati stabili di piccole dimensioni (gigabyte).

Consentire a Pub/Sub di accedere al bucket offre ai consumatori di dati un modo semplice per copiare i dati nei loro progetti ed elaborarli al loro interno. In generale, non consigliamo di copiare i dati se è possibile evitarlo. Più copie dei dati aumentano il costo di archiviazione e aumentano il carico di lavoro per la manutenzione e il monitoraggio della sequenza.

Dati sotto forma di stream

Un dominio può esporre i dati in streaming pubblicandoli in un argomento Pub/Sub. Gli abbonati che vogliono utilizzare i dati creano sottoscrizioni per utilizzare i messaggi pubblicati in quell'argomento. Ogni abbonato riceve e utilizza i dati in modo indipendente. Il seguente diagramma mostra un esempio di questi stream di dati.

Stream di dati per ricevere e utilizzare i dati.

Nel diagramma, la pipeline di importazione legge gli eventi non elaborati, li arricchisce (seleziona) e salva questi dati selezionati nel data store di analisi (tabella di base BigQuery). Allo stesso tempo, la pipeline pubblica gli eventi arricchiti in un argomento dedicato. Questo argomento viene utilizzato da più abbonati, ognuno dei quali potrebbe potenzialmente filtrare questi eventi per ottenere solo quelli pertinenti. La pipeline aggrega e pubblica anche le statistiche sugli eventi nel proprio argomento per essere elaborate da un altro consumatore di dati.

Di seguito sono riportati alcuni casi d'uso di esempio per le sottoscrizioni Pub/Sub:

  • Eventi arricchiti, ad esempio la fornitura di informazioni complete sul profilo del cliente insieme ai dati su un determinato ordine del cliente.
  • Notifiche di aggregazione quasi in tempo reale, ad esempio le statistiche degli ordini totali negli ultimi 15 minuti.
  • Avvisi a livello di attività, ad esempio la generazione di un avviso se il volume degli ordini è diminuito del 20% rispetto a un periodo simile del giorno precedente.
  • Notifiche di variazione dei dati (concetto simile alle notifiche di acquisizione dei dati sulle variazioni), ad esempio quando lo stato di un determinato ordine cambia.

Il formato dei dati utilizzato dai produttori di dati per i messaggi Pub/Sub influisce sui costi e sulla modalità di elaborazione di questi messaggi. Per gli stream ad alto volume in un'architettura data mesh, i formati Avro o Protobuf sono ottime opzioni. Se i produttori di dati utilizzano questi formati, possono assegnare schemi agli argomenti Pub/Sub. Gli schemi contribuiscono a garantire che i consumatori ricevano messaggi ben formattati.

Poiché una struttura di dati in streaming può cambiare costantemente, il controllo delle versioni di questa interfaccia richiede il coordinamento tra i produttori e i consumatori di dati. Esistono diversi approcci comuni che i produttori di dati possono adottare, come segue:

  • Viene creato un nuovo argomento ogni volta che la struttura del messaggio cambia. Questo argomento spesso ha uno schema Pub/Sub esplicito. I consumatori di dati che hanno bisogno della nuova interfaccia possono iniziare a utilizzare i nuovi dati. La versione del messaggio è implicita nel nome dell'argomento, ad esempio click_events_v1. I formati dei messaggi sono fortemente tipiizzati. Non esistono variazioni nel formato dei messaggi all'interno dello stesso argomento. Lo svantaggio di questo approccio è che potrebbero esserci utenti che non possono passare al nuovo abbonamento. In questo caso, il produttore di dati deve continuare a pubblicare eventi in tutti gli argomenti attivi per un po' di tempo e i consumatori di dati che si abbonano all'argomento devono gestire una lacuna nel flusso di messaggi o deduplicare i messaggi.
  • I dati vengono sempre pubblicati nello stesso argomento. Tuttavia, la struttura del messaggio può cambiare. Un attributo messaggio Pub/Sub (separato dal payload) definisce la versione del messaggio. Ad esempio, v=1.0. Questo approccio elimina la necessità di gestire lacune o duplicati. Tuttavia, tutti i consumatori di dati devono essere pronti a ricevere messaggi di un nuovo tipo. Inoltre, i publisher di dati non possono utilizzare gli schemi degli argomenti Pub/Sub per questo approccio.
  • Un approccio ibrido. Lo schema del messaggio può avere una sezione di dati arbitraria che può essere utilizzata per nuovi campi. Questo approccio può offrire un equilibrio ragionevole tra l'utilizzo di dati fortemente tipizzati e modifiche alle versioni frequenti e complesse.

API di accesso ai dati

I produttori di dati possono creare un'API personalizzata per accedere direttamente alle tabelle di base in un data warehouse. In genere, questi produttori espongono questa API personalizzata come API REST o gRPC ed eseguono il deployment su Cloud Run o su un cluster Kubernetes. Un gateway API come Apigee può fornire altre funzionalità aggiuntive, come la limitazione del traffico o un livello di memorizzazione nella cache. Queste funzionalità sono utili quando espandi l'API di accesso ai dati ai consumatori esterni a un'organizzazione Google Cloud. I potenziali candidati per un'API di accesso ai dati sono query sensibili alla latenza e ad alta concorrenza, che restituiscono entrambe un risultato relativamente piccolo in un'unica API e possono essere memorizzate nella cache in modo efficace.

Ecco alcuni esempi di API personalizzate per l'accesso ai dati:

  • Una visualizzazione combinata delle metriche SLA della tabella o del prodotto.
  • I 10 record principali (potenzialmente memorizzati nella cache) di una determinata tabella.
  • Un set di dati di statistiche delle tabelle (numero totale di righe o distribuzione dei dati all'interno delle colonne chiave).

Eventuali linee guida e norme dell'organizzazione per la creazione di API di applicazioni sono applicabili anche alle API personalizzate create dai produttori di dati. Le linee guida e la governance dell'organizzazione devono coprire aspetti come hosting, monitoraggio, controllo dell'accesso e versionamento.

Lo svantaggio di un'API personalizzata è che i produttori di dati sono responsabili di qualsiasi infrastruttura aggiuntiva necessaria per ospitare questa interfaccia, nonché della codifica e della manutenzione dell'API personalizzata. Consigliamo ai produttori di dati di valutare altre opzioni prima di decidere di creare API di accesso ai dati personalizzate. Ad esempio, i produttori di dati possono utilizzare BigQuery BI Engine per ridurre la latenza di risposta e aumentare la concorrenza.

Looker Blocks

Per prodotti come Looker, che vengono utilizzati molto negli strumenti di business intelligence (BI), potrebbe essere utile mantenere un insieme di widget specifici per gli strumenti BI. Poiché il team di produzione dei dati conosce il modello di dati sottostante utilizzato nel dominio, è il più adatto a creare e manutenere un insieme di visualizzazioni predefinite.

Nel caso di Looker, questa visualizzazione potrebbe essere un insieme di blocchi di Looker (modelli di dati LookML predefiniti). I blocchi di Looker possono essere facilmente incorporati nelle dashboard ospitate dai consumatori.

personalizzati

Poiché i team che lavorano nei domini di dati hanno una conoscenza approfondita dei propri dati, sono spesso i migliori per creare e gestire modelli ML addestrati sui dati di dominio. Questi modelli ML possono essere esposti tramite diverse interfacce, tra cui:

  • I modelli BigQuery ML possono essere implementati in un set di dati dedicato e condivisi con i consumatori di dati per le previsioni batch di BigQuery.
  • I modelli BigQuery ML possono essere esportati in Vertex AI per essere utilizzati per le previsioni online.

Considerazioni sulla posizione dei dati per le interfacce di consumo

Un aspetto importante da considerare quando i produttori di dati definiscono le interfacce di consumo per i prodotti di dati è la posizione dei dati. In generale, per ridurre al minimo i costi, i dati devono essere elaborati nella stessa regione in cui sono archiviati. Questo approccio consente di evitare gli addebiti per il traffico in uscita di dati tra regioni. Questo approccio presenta anche la latenza di consumo dei dati più bassa. Per questi motivi, i dati archiviati in località BigQuery multiregionali sono in genere i candidati migliori per essere esposti come prodotto di dati.

Tuttavia, per motivi di prestazioni, i dati archiviati in Cloud Storage e esposti tramite le tabelle BigLake o le API di lettura diretta devono essere archiviati in bucket regionali.

Se i dati esposti in un prodotto si trovano in una regione e devono essere uniti ai dati di un altro dominio in un'altra regione, i consumatori di dati devono tenere conto delle seguenti limitazioni:

  • Le query tra regioni che utilizzano BigQuery SQL non sono supportate. Se il metodo di consumo principale per i dati è BigQuery SQL, tutte le tabelle nella query devono trovarsi nella stessa posizione.
  • Gli impegni a tariffa fissa di BigQuery sono regionali. Se un progetto utilizza solo un impegno a tariffa fissa in una regione, ma esegue query su un prodotto di dati in un'altra regione, si applicano i prezzi on demand.
  • I consumatori di dati possono utilizzare le API di lettura diretta per leggere i dati di un'altra regione. Tuttavia, si applicano gli addebiti per il traffico in uscita dalla rete tra regioni e i consumatori di dati molto probabilmente riscontreranno una latenza per i trasferimenti di dati di grandi dimensioni.

I dati a cui si accede di frequente in più regioni possono essere replicati in queste regioni per ridurre il costo e la latenza delle query sostenute dai consumatori del prodotto. Ad esempio, i set di dati BigQuery possono essere copiati in altre regioni. Tuttavia, i dati devono essere copiati solo quando sono necessari. Ti consigliamo di fare in modo che i produttori di dati rendano disponibile solo un sottoinsieme dei dati di prodotto disponibili per più regioni quando copi i dati. Questo approccio consente di minimizzare la latenza e i costi di replica. Questo approccio può comportare la necessità di fornire più versioni dell'interfaccia di consumo con la regione della posizione dei dati esplicitamente indicata. Ad esempio, le viste autorizzate di BigQuery possono essere esposte tramite nomi come sales_eu_v1 e sales_us_v1.

Le interfacce di stream di dati che utilizzano gli argomenti Pub/Sub non richiedono alcuna logica di replica aggiuntiva per consumare i messaggi in regioni diverse da quella in cui è archiviato il messaggio. Tuttavia, in questo caso si applicano costi di uscita tra regioni aggiuntivi.

Esporre le interfacce di consumo ai consumatori di dati

Questa sezione spiega come rendere le interfacce di consumo rilevabili dai potenziali consumatori. Data Catalog è un servizio completamente gestito che le organizzazioni possono utilizzare per fornire i servizi di gestione dei metadati e di rilevamento dei dati. I produttori di dati devono rendere disponibili per la ricerca le interfacce di consumo dei propri prodotti di dati e annotarli con i metadati appropriati per consentire ai consumatori di prodotti di accedervi in modalità self-service. mer

Le sezioni seguenti illustrano come ogni tipo di interfaccia viene definito come voce di Data Catalog.

Interfacce SQL basate su BigQuery

I metadati tecnici, come un nome di tabella o uno schema di tabella completo, vengono registrati automaticamente per le viste autorizzate, le viste BigLake e le tabelle BigQuery disponibili tramite l'API Storage Read. Consigliamo ai produttori di dati di fornire anche informazioni aggiuntive nella documentazione dei prodotti di dati per aiutare i consumatori di dati. Ad esempio, per aiutare gli utenti a trovare la documentazione del prodotto per una voce, i produttori di dati possono aggiungere un URL a uno dei tag applicati alla voce. I produttori possono anche fornire quanto segue:

  • Set di colonne clusterizzate da utilizzare nei filtri delle query.
  • Valori di enumerazione per i campi con tipo di enumerazione logica, se il tipo non è fornito nella descrizione del campo.
  • Join supportati con altre tabelle.

Stream di dati

Gli argomenti Pub/Sub vengono registrati automaticamente in Data Catalog. Tuttavia, i produttori di dati devono descrivere lo schema nella documentazione del prodotto di dati.

API Cloud Storage

Data Catalog supporta la definizione delle voci dei file Cloud Storage e del relativo schema. Se un set di file di un data lake è gestito da Dataplex, viene registrato automaticamente in Data Catalog. I set di file non associati a Dataplex vengono aggiunti utilizzando un approccio diverso.

Altre interfacce

Puoi aggiungere altre interfacce che non dispongono del supporto integrato di Data Catalog creando voci personalizzate.

Passaggi successivi