Creare prodotti di dati in un mesh di dati

Last reviewed 2024-09-03 UTC

Per garantire che i casi d'uso dei consumer di dati siano soddisfatti, è essenziale che i prodotti di dati in un mesh di dati siano progettati e creati con cura. La progettazione di un prodotto di dati inizia con la definizione di come i consumer di dati utilizzeranno il prodotto e di come il prodotto verrà poi esposto ai consumer. I prodotti di dati in un mesh di dati sono basati su un datastore (ad esempio un data warehouse o un data lake di dominio). Quando crei prodotti di dati in un mesh di dati, ti consigliamo di prendere in considerazione alcuni fattori chiave durante questo processo. 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 abbia familiarità con i concetti descritti in Architettura e funzioni in un mesh di dati e Crea un mesh di dati moderno e distribuito con Google Cloud.

La serie è composta dalle seguenti parti:

Quando creano prodotti di dati da un data warehouse di dominio, consigliamo ai producer di dati di progettare con attenzione le interfacce analitiche (di consumo) per questi prodotti. Queste interfacce di consumo sono un insieme di garanzie sulla qualità dei dati e sui parametri operativi, insieme a un modello di assistenza e alla documentazione del prodotto. Il costo della modifica delle interfacce di consumo è solitamente elevato a causa della necessità, sia per il producer di dati che potenzialmente per più consumer di dati, di modificare i processi e le applicazioni di consumo. Dato che i consumer di dati si trovano molto probabilmente in unità organizzative separate da quelle dei producer di dati, coordinare le modifiche può essere difficile.

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

Crea 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 producer di dati crea prodotti di dati. L'unica vera differenza 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 acquisiti dalle origini dati operative vengono sottoposti al processo di arricchimento e verifica della qualità dei dati (curation). Nei data lake gestiti da Knowledge Catalog, i dati selezionati vengono in genere archiviati in zone selezionate designate. Al termine della selezione, un sottoinsieme dei dati dovrebbe essere pronto per l'utilizzo esterno al 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 ancora adottato un approccio basato su mesh di dati. Questi strumenti consentono ai produttori di dati di creare nuovi prodotti di dati in modalità self-service. Per le pratiche consigliate, consulta Progetta 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à dei dati, sulla loro disponibilità e sulla gestione del ciclo di vita. Poiché questi requisiti creano la fiducia dei consumer di dati nei prodotti di dati e ne incoraggiano l'utilizzo, i vantaggi dell'implementazione di questi requisiti valgono lo sforzo di supportarli.

Definisci le interfacce di consumo

Consigliamo ai producer di dati di utilizzare più tipi di interfacce, anziché definirne solo una o due. Ogni tipo di interfaccia nell'analisi dei dati presenta vantaggi e svantaggi e non esiste un unico tipo di interfaccia che eccelle in tutto. Quando i producer di dati valutano l'idoneità di ogni tipo di interfaccia, devono considerare quanto segue:

  • Capacità di eseguire il trattamento dati necessario.
  • Scalabilità per supportare i casi d'uso attuali e futuri dei consumer di dati.
  • Prestazioni richieste dai consumatori di dati.
  • Costo di sviluppo e manutenzione.
  • Costo di esecuzione dell'interfaccia.
  • Supporto dei linguaggi e degli strumenti utilizzati dalla tua organizzazione.
  • Supporto per la separazione di archiviazione e calcolo.

Ad esempio, se il requisito aziendale è la possibilità di eseguire query analitiche su un set di dati di dimensioni di petabyte, l'unica interfaccia pratica è una vista BigQuery. Tuttavia, se i requisiti prevedono la fornitura di flussi di dati quasi in tempo reale, un'interfaccia basata su Pub/Sub è più appropriata.

Molte di queste interfacce non richiedono la copia o la replica dei dati esistenti. La maggior parte di questi strumenti consente anche di separare l'archiviazione e il calcolo, una funzionalità fondamentale degli strumenti di analisi diGoogle Cloud . I consumer dei dati esposti tramite queste interfacce elaborano i dati utilizzando le risorse di computing a loro disposizione. I producer di dati non devono eseguire il provisioning di un'infrastruttura aggiuntiva.

Esiste un'ampia gamma di interfacce di consumo. Le seguenti interfacce sono quelle più comunemente utilizzate in un mesh di dati e vengono descritte nelle sezioni seguenti:

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

Viste e funzioni autorizzate

Per quanto possibile, i prodotti di dati devono essere esposti tramite viste autorizzate e funzioni autorizzate, incluse le funzioni con valori di tabella. I set di dati autorizzati offrono un modo pratico per autorizzare automaticamente più viste. L'utilizzo di viste autorizzate impedisce l'accesso diretto alle tabelle di base e consente di ottimizzare le tabelle sottostanti e le query su di esse, senza influire sull'utilizzo di queste viste da parte dei consumer. I consumer 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 viste autorizzati consentono di semplificare il controllo delle versioni delle interfacce. Come mostrato nel diagramma seguente, esistono due approcci principali al controllo delle versioni che i producer di dati possono adottare:

Controllo delle versioni di set di dati e visualizzazioni.

Gli approcci possono essere riassunti come segue:

  • Controllo delle versioni del set di dati: con questo approccio, assegni una versione al nome del set di dati. Non esegui il controllo delle versioni delle viste e delle funzioni all'interno del set di dati. Mantieni gli stessi nomi per le viste e le funzioni, indipendentemente dalla versione. Ad esempio, la prima versione di un set di dati di vendita è definita in un set di dati denominato sales_v1 con due viste, catalog e orders. Per la seconda versione, il set di dati delle vendite è stato rinominato in sales_v2 e tutte le visualizzazioni precedenti nel set di dati mantengono i nomi precedenti, ma hanno nuovi schemi. La seconda versione del set di dati potrebbe anche contenere nuove visualizzazioni o rimuovere alcune di quelle precedenti.
  • Controllo delle versioni delle viste: con questo approccio, il controllo delle versioni viene applicato alle viste all'interno del set di dati anziché al set di dati stesso. Ad esempio, il set di dati delle 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 migliore per il controllo delle versioni per la tua organizzazione dipende dalle policy dell'organizzazione e dal numero di visualizzazioni che diventano obsolete con l'aggiornamento dei dati sottostanti. Il controllo delle versioni del set di dati è l'opzione migliore quando è necessario un aggiornamento importante del prodotto e la maggior parte delle visualizzazioni deve cambiare. Il controllo delle versioni delle viste genera un numero inferiore di viste con lo stesso nome in set di dati diversi, ma può causare ambiguità, ad esempio come capire se un join tra set di dati funziona correttamente. Un approccio ibrido può essere un buon compromesso. In un approccio ibrido, le modifiche allo schema compatibili sono consentite all'interno di un singolo set di dati, mentre le modifiche incompatibili richiedono un nuovo set di dati.

Considerazioni sulle tabelle BigLake

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

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

  • La progettazione dei formati file e del layout dei dati influisce sulle prestazioni delle query. I formati basati su colonne, ad esempio Parquet o ORC, in genere offrono prestazioni molto migliori per le query analitiche rispetto ai formati JSON o CSV.
  • Un layout partizionato Hive consente di eliminare le partizioni e velocizza le query che utilizzano colonne di partizionamento.
  • In fase di progettazione, è necessario tenere conto anche del numero di file e delle prestazioni delle query preferite per le dimensioni dei file.

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

  • Per i dati che devono essere esposti al consumer di dati, convertili nello spazio di archiviazione di BigQuery.
  • Ridefinisci le viste autorizzate per utilizzare le tabelle BigQuery.

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

API di lettura diretta

Sebbene in genere sconsigliamo ai producer di dati di concedere ai consumer di dati l'accesso in lettura diretto alle tabelle di base, a volte potrebbe essere pratico consentire questo accesso per motivi quali prestazioni e costi. In questi casi, è necessario prestare particolare attenzione per garantire che lo schema della tabella sia stabile.

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

Casi d'uso di ML e trattamento dati, spiegati nel testo seguente.

Il controllo delle versioni di un'interfaccia di lettura diretta è complesso. In genere, i producer di dati devono creare un'altra tabella con uno schema diverso. Inoltre, devono mantenere due versioni della tabella finché tutti i consumer di dati della versione deprecata non eseguono la migrazione alla nuova versione. Se i consumer possono tollerare l'interruzione della ricostruzione 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, è possibile evitare la migrazione della tabella di base. Ad esempio, non è necessario eseguire la migrazione della tabella di base se vengono aggiunte solo nuove colonne e i dati in queste colonne vengono inseriti retroattivamente per tutte le righe.

Di seguito è riportato un riepilogo delle differenze tra l'API Storage Read e l'API Cloud Storage. In generale, se possibile, consigliamo ai producer 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 per leggere le tabelle BigLake. Questa API supporta l'applicazione di filtri e controllo dell'accesso granulare dell'accesso e può essere una buona opzione per i consumer di analisi dei dati o ML stabili.

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

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

Consentire l'accesso Pub/Sub al bucket offre ai consumer di dati un modo semplice per copiare i dati nei loro progetti ed elaborarli lì. In generale, sconsigliamo la copia dei dati se può essere evitata. Più copie dei dati aumentano i costi di archiviazione e l'overhead di manutenzione e monitoraggio della derivazione.

Dati come stream

Un dominio può esporre i dati in streaming pubblicandoli in un argomento Pub/Sub. I sottoscrittori che vogliono utilizzare i dati creano sottoscrizioni per utilizzare i messaggi pubblicati in quell'argomento. Ogni sottoscrittore riceve e consuma 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 (cura) e salva i dati curati nel datastore analitico (tabella di base di BigQuery). Allo stesso tempo, la pipeline pubblica gli eventi arricchiti in un argomento dedicato. Questo argomento viene utilizzato da più sottoscrittori, ognuno dei quali potrebbe filtrare questi eventi per ottenere solo quelli pertinenti. La pipeline aggrega e pubblica anche le statistiche sugli eventi nel proprio argomento per l'elaborazione da parte di un altro consumer di dati.

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

  • Eventi arricchiti, ad esempio fornendo informazioni complete sul profilo del cliente insieme ai dati su un particolare ordine del cliente.
  • Notifiche di aggregazione quasi in tempo reale, ad esempio le statistiche totali sugli ordini 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 modifica dei dati (concettualmente simili alle notifiche di Change Data Capture), ad esempio quando un determinato ordine cambia stato.

Il formato dei dati utilizzato dai producer di dati per i messaggi Pub/Sub influisce sui costi e sul modo in cui questi messaggi vengono elaborati. Per i flussi ad alto volume in un'architettura mesh di dati, i formati Avro o Protobuf sono buone opzioni. Se i producer di dati utilizzano questi formati, possono assegnare schemi agli argomenti Pub/Sub. Gli schemi contribuiscono a garantire che i consumer ricevano messaggi nel formato corretto.

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

  • Ogni volta che la struttura del messaggio cambia, viene creato un nuovo argomento. Questo argomento spesso ha uno schema Pub/Sub esplicito. I consumer 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 tipizzati. Non esiste alcuna variazione nel formato dei messaggi tra i messaggi nello stesso argomento. Lo svantaggio di questo approccio è che potrebbero esserci consumer di dati che non possono passare alla nuova sottoscrizione. In questo caso, il producer di dati deve continuare a pubblicare eventi in tutti gli argomenti attivi per un certo periodo di tempo e i consumer di dati che si iscrivono all'argomento devono gestire un'interruzione 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 del 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 consumer di dati devono essere pronti a ricevere messaggi di un nuovo tipo. Inoltre, i producer di dati non possono utilizzare gli schemi degli argomenti Pub/Sub per questo approccio.
  • Un approccio ibrido. Lo schema dei messaggi può avere una sezione di dati arbitraria che può essere utilizzata per i nuovi campi. Questo approccio può fornire un equilibrio ragionevole tra dati fortemente tipizzati e modifiche di versione frequenti e complesse.

API di accesso ai dati

I producer di dati possono creare un'API personalizzata per accedere direttamente alle tabelle di base in un data warehouse. In genere, questi producer 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 si espone l'API di accesso ai dati a consumer esterni a un'organizzazione Google Cloud . I potenziali candidati per un'API di accesso ai dati sono query sensibili alla latenza e ad alta contemporaneità che restituiscono un risultato relativamente piccolo in una singola 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 primi 10 record (potenzialmente memorizzati nella cache) di una determinata tabella.
  • Un set di dati di statistiche della tabella (numero totale di righe o distribuzione dei dati all'interno delle colonne chiave).

Le linee guida e la governance dell'organizzazione relative alla creazione di API delle applicazioni sono applicabili anche alle API personalizzate create dai producer di dati. Le linee guida e la governance dell'organizzazione devono coprire aspetti quali hosting, monitoraggio, controllo dell'accesso e controllo delle versioni.

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

Looker Blocks

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

Nel caso di Looker, questa visualizzazione potrebbe essere un insieme di Looker Blocks (modelli di dati LookML predefiniti). I blocchi 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, spesso sono i team migliori per creare e gestire i modelli ML addestrati sui dati del dominio. Questi modelli ML possono essere esposti tramite diverse interfacce, tra cui:

  • I modelli BigQuery ML possono essere distribuiti in un set di dati dedicato e condivisi con i consumer di dati per le previsioni in batch di BigQuery.
  • I modelli BigQuery ML possono essere esportati nella piattaforma Gemini Enterprise Agent per essere utilizzati per le previsioni online.

Considerazioni sulla posizione dei dati per le interfacce di consumo

Un aspetto importante da considerare quando i producer di dati definiscono le interfacce di consumo per i prodotti di dati è la località 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 a evitare addebiti per il traffico in uscita tra regioni. Questo approccio ha 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 ed esposti tramite tabelle BigLake o 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 consumer di dati devono considerare le 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 della query devono trovarsi nella stessa località.

  • Gli impegni con tariffe a costo fisso 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 consumer di dati possono utilizzare le API di lettura diretta per leggere i dati da un'altra regione. Tuttavia, si applicano i costi del traffico in uscita dalla rete tra regioni e i consumer 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 i costi e la latenza delle query sostenuti dai consumer del prodotto. Ad esempio, i set di dati BigQuery possono essere copiati in altre regioni. Tuttavia, i dati devono essere copiati solo quando è necessario. Quando copi i dati, ti consigliamo di rendere disponibile solo un sottoinsieme dei dati di prodotto disponibili per più regioni. Questo approccio aiuta a ridurre al minimo la latenza e i costi di replica. Questo approccio può comportare la necessità di fornire più versioni dell'interfaccia di consumo con la regione di località 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 dei flussi di dati che utilizzano gli argomenti Pub/Sub non richiedono una logica di replica aggiuntiva per utilizzare i messaggi in regioni diverse da quella in cui sono archiviati. Tuttavia, in questo caso si applicano tariffe per il traffico in uscita tra regioni aggiuntive.

Esporre le interfacce di consumo ai consumatori di dati

Questa sezione illustra come rendere le interfacce di consumo rilevabili dai potenziali consumatori. Knowledge Catalog è un servizio completamente gestito che le organizzazioni possono utilizzare per fornire servizi di rilevamento dei dati e gestione dei metadati. I producer di dati devono rendere ricercabili le interfacce di consumo dei loro prodotti di dati e annotarle con i metadati appropriati in modo che i consumer di prodotti possano accedervi in modalità self-service.

Le sezioni seguenti descrivono come ogni tipo di interfaccia viene definito come voce di Knowledge Catalog.

Interfacce SQL basate su BigQuery

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

  • Insiemi di colonne con clustering, che devono essere utilizzate nei filtri delle query.
  • Valori di enumerazione per i campi con tipo di enumerazione logica, se il tipo non è fornito come parte della descrizione del campo.
  • Join supportati con altre tabelle.

Stream di dati

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

API Cloud Storage

Puoi utilizzare il rilevamento automatico in Knowledge Catalog per analizzare i dati nei bucket Cloud Storage ed estrarre e catalogare i metadati. Se un set di file del data lake è gestito da Knowledge Catalog, viene registrato automaticamente anche in Knowledge Catalog.

Altre interfacce

Puoi aggiungere altre interfacce che non sono supportate in modo nativo da Knowledge Catalog creando voci personalizzate.

Passaggi successivi