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 Il prodotto di dati inizia con la definizione di come i consumatori dei dati utilizzerebbero prodotto e come viene esposto 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 dati in un mesh di dati, sono alcuni fattori chiave che 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 mesh di dati 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 dati da un data warehouse di dominio, è consigliabile produttori di dati progettano con attenzione le interfacce analitiche (consumo) per prodotti di big data e machine learning. 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 è in genere elevata a causa della necessità sia per il produttore di dati sia per per i consumatori dei dati di modificare i processi e le applicazioni che consumano. Dato che i consumatori di dati si trovano molto probabilmente in unità organizzative distinta da quelle dei produttori di dati, il coordinamento delle modifiche può essere difficile.

Le seguenti sezioni forniscono informazioni di base su ciò che devi prendere in considerazione quando si crea un warehouse di dominio, si definiscono le interfacce di consumo ed espongono queste interfacce con i consumatori dei 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 a dominio da cui il team di data producer crea prodotti di dati. L'unica vera differenza tra i due è che quest'ultima espone un sottoinsieme dei suoi dati tramite le interfacce di consumo.

In molti data warehouse, i dati non elaborati importati dalle origini dati operative passa attraverso il processo di arricchimento e di verifica della qualità dei dati (selezione). Nella Gestito da Dataplex data lake, i dati selezionati in genere vengono archiviati in zone curate designate. Al termine della selezione, un sottoinsieme di dati dovrebbe essere pronto per essere utilizzato al di fuori del dominio tramite diversi tipi di interfacce. A definire queste interfacce di consumo, un'organizzazione deve fornire un insieme per i team di dominio che non hanno mai adottato un approccio basato sul mesh di dati. Questi strumenti consente ai produttori di creare nuovi prodotti dati 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 rafforzano la fiducia dei consumatori dei dati nei prodotti dati e incoraggiano per l'utilizzo dei prodotti dati, i vantaggi dell'implementazione di questi requisiti valgono il nostro impegno nel supportarli.

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 nell'analisi dei dati offre vantaggi e gli svantaggi, e non esiste un unico tipo di interfaccia ideale 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.
  • Prestazioni richieste dai consumatori dei dati.
  • Costi di sviluppo e manutenzione.
  • Costo di esecuzione 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. Non è necessario che i produttori di dati eseguano infrastrutture aggiuntive. per eseguire il provisioning.

Esistono molte interfacce di consumo. Le seguenti interfacce sono quelle più comuni utilizzate in un mesh di dati e vengono illustrate sezioni:

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

Il più possibile, i prodotti di dati devono essere esposti attraverso 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. Utilizzo le viste autorizzate impediscono l'accesso diretto alle tabelle di base e ti consentono ottimizzare le tabelle e le query sottostanti, senza influire sull'utilizzo di queste opinioni da parte del consumatore. Gli utenti di questa interfaccia utilizzano SQL per eseguire query sui dati. Il seguente diagramma illustra l'utilizzo dei set di dati autorizzati come di Google Cloud.

Interfacce di consumo.

Le viste e i set di dati autorizzati contribuiscono a semplificare il controllo delle versioni delle interfacce. Come mostrato nel seguente diagramma, esistono due approcci principali alla gestione delle versioni che i produttori di dati possono adottare:

Set di dati e visualizzazione del controllo delle versioni.

Questi approcci possono essere riassunti come segue:

  • Controllo delle versioni del set di dati: in questo approccio devi eseguire la versione del nome del set di dati. Non esegui la versione delle viste 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 delle vendite è definita in un set di dati denominato sales_v1 con due visualizzazioni, catalog e orders. Per la seconda versione, il set di dati sulle vendite è stato rinominato sales_v2 e qualsiasi visualizzazione precedente in mantengono i nomi precedenti ma hanno nuovi schemi. Il secondo del set di dati potrebbe anche avere nuove viste o rimuovere qualsiasi delle viste precedenti.
  • 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 dei le visualizzazioni all'interno del set di dati cambiano per riflettere ogni nuova versione della vista (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 dai criteri della tua organizzazione e dal numero di visualizzazioni rese obsolete con l'aggiornamento dei dati sottostanti. Il controllo delle versioni del set di dati è ottimale quando è necessario un aggiornamento del prodotto e la maggior parte delle visualizzazioni deve cambiare. 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 utilizzando l'interfaccia SQL di BigQuery. Le tabelle BigLake supportano il 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 prendere in considerazione quanto segue per le tabelle BigLake:

  • La progettazione dei formati file e del layout dei dati influenza la le prestazioni delle query. I formati basati su colonne, ad esempio Pacchino o ORC in genere hanno un rendimento migliore per le query analitiche rispetto ai formati JSON o CSV.
  • R Layout partizionato Hive consente di eliminare le partizioni e di velocizzare le query che utilizzano le colonne di partizionamento.
  • Il numero di file e le prestazioni delle query preferite per il file le dimensioni devono essere prese in considerazione anche in fase di progettazione.

Se le query che utilizzano le tabelle BigLake non soddisfano il livello di servizio i requisiti dei contratti SLA (accordo sul livello del servizio) per l'interfaccia e non possono essere ottimizzati, consiglia le seguenti azioni:

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

In genere, questo approccio non causa alcuna interruzione per i consumatori dei dati, o richiedere modifiche alle query. Le query in BigQuery lo spazio di archiviazione può essere ottimizzato utilizzando tecniche che non sono possibili con Tavoli BigLake. Ad esempio, con BigQuery archiviazione, i consumer possono eseguire query su viste materializzate con partizioni diverse e il clustering delle tabelle di base e possono usare BigQuery BI Engine.

API di lettura diretta

Sebbene in genere sconsigliamo ai produttori di dati di concedere ai consumatori di dati accesso diretto in lettura alle tabelle di base, a volte potrebbe essere pratico consentire questo accesso per motivi quali rendimento e costi. In questi casi, le altre assicurati che lo schema della tabella sia stabile.

Esistono due modi per accedere direttamente ai dati in un data warehouse standard. Dati producer possono utilizzare API BigQuery Storage Read, o il 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. Di solito, i produttori di dati crea un'altra tabella con uno schema diverso. Devono inoltre mantenere due della tabella, finché tutti i consumer dei dati della versione deprecata di eseguire la migrazione alla nuova. Se i consumatori possono tollerare l'interruzione della ricreare la tabella e passare al nuovo schema, puoi evitare la duplicazione dei dati. Nei casi in cui le modifiche allo schema possano essere compatibile, puoi evitare la migrazione della tabella di base. 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 in BigQuery e leggere le tabelle BigLake. Questa API supporta i filtri e il 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 particolare bucket Cloud Storage direttamente con i consumatori dei 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 le API di archiviazione perché l'accesso diretto non consente l'applicazione di filtri un controllo dell'accesso granulare. 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, sconsigliamo di copiare i dati, se è possibile evitarla. Più copie dei dati aumentano il costo di archiviazione e aumentano il carico di lavoro per la manutenzione e il monitoraggio della sequenza.

Dati come flussi

Un dominio può esporre flussi di dati pubblicandoli in un Pub/Sub per ogni argomento. 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 (li cura), e li salva nel datastore analitico (tabella di base BigQuery). Allo stesso tempo, la pipeline pubblica gli eventi arricchiti in un argomento dedicato. Questo argomento è utilizzato da più sottoscrittori, ognuno dei quali potrebbe potenzialmente filtrare questi eventi per visualizzare quelli pertinenti. Inoltre, la pipeline aggrega e pubblica gli eventi le statistiche personali al proprio argomento per essere elaborate da un altro consumatore di dati.

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

  • Eventi estesi, come la fornitura di informazioni complete sul profilo del cliente insieme ai dati di un determinato ordine del cliente.
  • Notifiche di aggregazione quasi in tempo reale, ad esempio l'ordine totale statistiche degli ultimi 15 minuti.
  • Avvisi a livello aziendale, 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 publisher di dati per i messaggi Pub/Sub influisce sui costi e sulla modalità di elaborazione di questi messaggi. Per stream ad alto volume in una l'architettura mesh di dati e 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 aiutano a garantire che i consumatori ricevono messaggi ben strutturati.

Poiché una struttura di dati in modalità flusso può cambiare costantemente, questa interfaccia richiede il coordinamento tra i produttori di dati i consumatori. Esistono diversi approcci comuni che i produttori di dati possono adottare, sono i seguenti:

  • Ogni volta che cambia la struttura del messaggio, viene creato un nuovo argomento. Questo 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 caratterizzati da un alto tipo di digitazione. Non è presente alcuna variazione sul formato dei messaggi tra i messaggi dello stesso argomento. Lo svantaggio di questo approccio è che potrebbero esserci dei consumatori dei dati che non possono il 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 un vuoto nel flusso di messaggi o deduplicare i messaggi.
  • I dati vengono sempre pubblicati nello stesso argomento. Tuttavia, la struttura del messaggio può cambiare. Un Pub/Sub attributo messaggio (separata 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 producer di dati non possono utilizzare l'argomento Pub/Sub schemi per questo approccio.
  • Un approccio ibrido. Lo schema del messaggio può avere una sezione di dati arbitraria che può essere utilizzata per i nuovi campi. Questo approccio può offrire un bilanciamento ragionevole tra l'utilizzo di dati fortemente tipizzati e modifiche alle versioni frequenti e complesse.

API Data Access

I produttori di dati possono creare un'API personalizzata per accedere direttamente alle tabelle di base in un e il 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'API come Apigee può fornire altre funzionalità aggiuntive, come la limitazione 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 personalizzata per l'accesso ai dati:

  • Una visualizzazione combinata delle metriche SLA (accordo sul livello del servizio) della tabella o del prodotto.
  • I primi 10 record (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 riguardare questioni quali come hosting, monitoraggio, controllo dell'accesso e controllo delle versioni.

Lo svantaggio di un'API personalizzata è il fatto che i produttori di dati responsabile di eventuali infrastrutture aggiuntive necessarie per ospitare dell'interfaccia, nonché codifica e manutenzione dell'API personalizzate. 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 risposta latenza e aumentare la contemporaneità.

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 di BI. Poiché il team del produttore dei dati conosce i dati sottostanti utilizzato nel dominio, quel team è la persona più adatta a creare un insieme predefinito di visualizzazioni.

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 dei dati hanno una profonda comprensione e conoscenza dei dati, sono spesso i team migliori per creare e mantenere addestrati sui dati del 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 aiuta evitare i costi per il traffico di dati tra regioni. Questo approccio presenta anche la latenza di consumo dei dati più bassa. Per questi motivi, i dati archiviati in più regioni Le località BigQuery sono in genere le più adatte per l'esposizione un prodotto 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 costo fisso di BigQuery sono a livello di regione. Se un progetto utilizza solo un impegno a costo fisso in una regione, ma esegue query su un prodotto di dati in un'altra regione, verranno applicati 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, BigQuery Authorized viste possono essere esposte tramite denominazione come sales_eu_v1 e sales_us_v1.

Non sono necessarie interfacce di stream di dati che utilizzano argomenti Pub/Sub logica di replica aggiuntiva per consumare messaggi in regioni che non sono nella stessa regione in cui è archiviato il messaggio. Tuttavia, ulteriori costi di traffico in uscita tra regioni applicabili in questo caso.

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 dati di rilevamento e gestione dei metadati. 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 discutono di come ogni tipo di interfaccia è definito come un Voce Data Catalog.

Interfacce SQL basate su BigQuery

I metadati tecnici, come il nome completo o lo schema di una tabella, sono registrati automaticamente per le viste autorizzate, le viste BigLake e Tabelle BigQuery disponibili tramite l'API Storage Read. Consigliamo ai produttori di dati di fornire anche informazioni aggiuntive nella documentazione del prodotto per aiutare i consumatori di dati. Ad esempio, per aiutare gli utenti a trovare la documentazione del prodotto relativa a una voce, producer può aggiungere un URL a uno dei tag che è stato applicato alla voce. I produttori possono anche fornire quanto segue:

  • Insiemi di in cluster che dovrebbero essere utilizzate 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 di Cloud Storage delle voci di file e il relativo schema. Se un set di file di un data lake è gestito da Dataplex, viene registrato automaticamente nel Catalogo dei dati. 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 Data Catalog creando voci personalizzate.

Passaggi successivi