Crea prodotti dati in un data mesh

Last reviewed 2022-10-06 UTC

Per garantire che i casi d'uso dei consumatori di dati vengano soddisfatti, è essenziale che i prodotti dati in un data mesh siano progettati e realizzati con cura. La progettazione di un prodotto dati inizia con la definizione di come i consumatori dei dati potrebbero utilizzare quel prodotto e in che modo quel prodotto viene esposto ai consumatori. I prodotti dati in un data mesh sono creati su un datastore (ad esempio un data warehouse di dominio o un data lake). Quando crei prodotti dati in un data mesh, ci sono alcuni fattori chiave che ti consigliamo di prendere in considerazione durante questo processo. Queste considerazioni sono descritte nel presente documento.

Questo documento fa parte di una serie che descrive come implementare un data mesh su Google Cloud. Presuppone che tu abbia letto e abbia familiarità con i concetti descritti in Architettura e funzioni in un data mesh e Creare un data mesh moderno e distribuito con Google Cloud.

La serie è costituita dai seguenti componenti:

Durante la creazione di prodotti dati da un data warehouse di dominio, consigliamo ai produttori di dati di progettare con attenzione le interfacce analitiche (consumo) per questi prodotti. Queste interfacce di consumo sono un insieme di garanzie relative alla qualità dei dati e ai parametri operativi, insieme a un modello di assistenza per i prodotti e alla documentazione del prodotto. Il costo della modifica delle interfacce di consumo è generalmente elevato a causa della necessità sia per il produttore che per più consumer di dati di modificare i processi e le applicazioni di consumo. Dato che è più probabile che i consumatori di dati si trovino in unità organizzative separate da quelle dei produttori di dati, coordinare le modifiche può essere difficile.

Le seguenti sezioni forniscono informazioni di base sugli aspetti da considerare durante la creazione di un warehouse di dominio, la definizione delle interfacce di consumo e l'esposizione di queste interfacce ai consumatori dei dati.

Crea un data warehouse di dominio

Non c'è alcuna differenza fondamentale tra la creazione di un data warehouse autonomo e la creazione di un data warehouse di dominio da cui il team di data producer crea prodotti 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 importati da origini dati operative vengono sottoposti al processo di arricchimento e verifica della qualità dei dati (selezione). Nei data lake gestiti da Dataplex, i dati selezionati vengono generalmente archiviati in zone curate specifiche. Una volta completata la selezione, un sottoinsieme dei dati dovrebbe essere pronto per l'utilizzo da parte dell'esterno al dominio attraverso diversi tipi di interfacce. Per definire queste interfacce di consumo, un'organizzazione deve fornire una serie di strumenti ai team di dominio che sono alle prime armi con un approccio basato sul data mesh. Questi strumenti consentono ai produttori di dati di creare nuovi prodotti dati su base self-service. Per le best practice consigliate, consulta Progettare una piattaforma dati self-service.

Inoltre, i prodotti dati devono soddisfare requisiti di governance dei dati definiti centralmente. Questi requisiti influiscono sulla qualità dei dati, sulla disponibilità dei dati e sulla gestione del ciclo di vita. Poiché questi requisiti creano la fiducia dei consumatori dei dati nei prodotti dati e incoraggiano l'utilizzo dei prodotti dati, i vantaggi dell'implementazione di questi requisiti valgono lo sforzo di supportarli.

Definisci le interfacce di consumo

Consigliamo ai produttori di dati di utilizzare più tipi di interfacce, anziché definirne solo uno 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 produttori di dati valutano l'idoneità di ciascun tipo di interfaccia, devono considerare quanto segue:

  • Capacità di eseguire l'elaborazione dei dati necessaria.
  • Scalabilità per supportare 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 nelle lingue e negli strumenti utilizzati dalla tua organizzazione.
  • Supporto per la separazione tra archiviazione e computing.

Ad esempio, se il requisito aziendale è essere in grado di eseguire query analitiche su un set di dati delle dimensioni di petabyte, l'unica interfaccia pratica è una vista BigQuery. Tuttavia, se i requisiti prevedono di fornire dati di flusso 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 esse consente inoltre di separare archiviazione e computing, una funzionalità fondamentale degli strumenti analitici di Google Cloud. I consumatori di dati esposti attraverso queste interfacce elaborano i dati utilizzando le risorse di calcolo a loro disposizione. Non è necessario che i produttori di dati eseguano il provisioning aggiuntivo dell'infrastruttura.

È disponibile un'ampia varietà di interfacce di consumo. Le seguenti interfacce sono le più comuni utilizzate in un data mesh e sono descritte nelle sezioni seguenti:

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

Viste e funzioni autorizzate

Per quanto possibile, i prodotti dati devono essere esposti attraverso viste autorizzate e funzioni autorizzate,incluse le funzioni con valori di tabella. I set di dati autorizzati consentono di autorizzare automaticamente più visualizzazioni in modo pratico. 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 di queste viste da parte dei consumatori. I consumatori di questa interfaccia usano SQL per eseguire query sui dati. Il seguente diagramma illustra l'utilizzo di set di dati autorizzati come interfaccia di consumo.

Interfacce di consumo.

Le viste e i set di dati autorizzati aiutano a semplificare il controllo delle versioni delle interfacce. Come mostrato nel diagramma seguente, i produttori di dati possono adottare due approcci principali relativi al controllo delle versioni:

Set di dati e visualizzazione del controllo delle versioni.

Gli approcci possono essere riassunti come segue:

  • Controllo delle versioni del set di dati: in questo approccio, applichi 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 viste e le funzioni a prescindere dalla versione. Ad esempio, la prima versione di un set di dati sulle vendite viene 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 sales_v2 e qualsiasi vista precedente nel set di dati mantiene i nomi precedenti, ma ha nuovi schemi. Alla seconda versione del set di dati potrebbero anche essere aggiunte nuove viste o potrebbero essere rimosse quelle precedenti.
  • Visualizza il controllo delle versioni: in questo approccio viene eseguito il controllo delle versioni all'interno del set di dati anziché del set di dati stesso. Ad esempio, il set di dati sulle vendite mantiene il nome sales indipendentemente dalla versione. Tuttavia, i nomi delle viste all'interno del set di dati cambiano in base a ogni nuova versione della vista (ad es. catalog_v1, catalog_v2, orders_v1, orders_v2 e orders_v3).

Il migliore approccio al controllo delle versioni per la tua organizzazione dipende dai criteri dell'organizzazione e dal numero di viste che vengono rese obsolete con l'aggiornamento dei dati sottostanti. Il controllo delle versioni del set di dati è ideale quando è necessario un aggiornamento importante del prodotto e la maggior parte delle viste deve cambiare. Il controllo delle versioni porta a meno viste con nomi identici in set di dati diversi, ma può generare ambiguità, ad esempio come capire se un join tra set di dati funziona correttamente. Un approccio ibrido può essere un buon compromesso. Con un approccio ibrido, le modifiche compatibili allo schema sono consentite all'interno di un singolo set di dati, mentre le modifiche incompatibili richiedono un nuovo set di dati.

Considerazioni sulla tabella BigLake

Le viste 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 tramite l'interfaccia SQL di BigQuery. Le tabelle BigLake supportano controllo dell'accesso granulare senza che i consumatori dei 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:

  • La progettazione dei formati file e il layout dei dati influiscono sulle prestazioni delle query. I formati basati su colonne, ad esempio Parquet o ORC, in genere funzionano molto meglio per le query analitiche rispetto ai formati JSON o CSV.
  • Un layout partizionato Hive ti consente di eliminare le partizioni e velocizzare le query che utilizzano colonne di partizionamento.
  • In fase di progettazione devono essere presi in considerazione anche il numero di file e le prestazioni di query preferite per le dimensioni del 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 eseguire le seguenti azioni:

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

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

API di lettura diretta

Anche se in genere sconsigliamo ai produttori di dati di concedere ai consumatori di dati l'accesso diretto in lettura alle tabelle di base, a volte potrebbe essere pratico consentire questo accesso per motivi come prestazioni e costi. In questi casi, devi prestare particolare attenzione per garantire che lo schema della tabella sia stabile.

Esistono due modi per accedere direttamente ai dati in un tipico warehouse. 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 consumer che utilizzano queste API. Uno è un caso d'uso di machine learning (ML) e l'altro un job di elaborazione dati.

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

Il controllo delle versioni di un'interfaccia di lettura diretta è un processo complesso. In genere, i produttori di dati devono creare un'altra tabella con uno schema diverso. Devono inoltre mantenere due versioni della tabella, finché tutti i consumer dei dati della versione deprecata non eseguono la migrazione alla nuova. Se i consumer possono tollerare l'interruzione della ricreazione della tabella e del 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 viene eseguito il backfill dei dati in queste colonne per tutte le righe.

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

  • 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 filtri e controllo granulare degli accessi e può essere una buona opzione per l'analisi stabili dei dati o i consumer ML.

  • API Cloud Storage: i produttori di dati potrebbero dover condividere un determinato bucket Cloud Storage direttamente con i consumatori dei dati. Ad esempio, i produttori di dati possono condividere il bucket se per qualche motivo i consumatori di dati non possono utilizzare l'interfaccia SQL 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, in quanto l'accesso diretto non consente l'applicazione di filtri e un controllo granulare degli accessi. Tuttavia, l'accesso diretto può essere una scelta valida per set di dati stabili e 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 propri progetti ed elaborarli lì. In generale, sconsigliamo di copiare i dati se può essere evitato. Più copie di dati aumentano i costi di archiviazione e si aggiungono al overhead di manutenzione e monitoraggio della derivazione.

Dati come stream

Un dominio può esporre i flussi di dati pubblicandoli in un argomento Pub/Sub. I sottoscrittori che desiderano 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 seleziona) e li salva nel datastore analitici (tabella di base BigQuery). Allo stesso tempo, la pipeline pubblica gli eventi estesi in un argomento dedicato. Questo argomento viene utilizzato da più abbonati, ognuno dei quali potrebbe potenzialmente filtrare questi eventi per ottenere solo quelli pertinenti. Inoltre, la pipeline aggrega e pubblica statistiche sugli eventi nel proprio argomento affinché vengano 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 di un particolare ordine del cliente.
  • Notifiche di aggregazione quasi in tempo reale, ad esempio le statistiche degli ordini totali per gli ultimi 15 minuti.
  • Avvisi a livello aziendale, come la generazione di un avviso se il volume degli ordini è sceso del 20% rispetto a un periodo simile del giorno precedente.
  • Notifiche di modifica dei dati (simili nel concetto alle notifiche di Change Data Capture), come le modifiche allo stato di un particolare ordine.

Il formato dei dati che i produttori utilizzano 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 di 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. Questi schemi aiutano a garantire che i consumatori ricevano messaggi ben strutturati.

Poiché la struttura di dati in modalità flusso può cambiare continuamente, il controllo delle versioni di questa interfaccia richiede il coordinamento tra i producer di dati e i consumatori di dati. I produttori di dati possono adottare diversi approcci comuni, i quali sono i seguenti:

  • Ogni volta che la struttura dei messaggi cambia, viene creato un nuovo argomento. Questo argomento ha spesso uno schema Pub/Sub esplicito. I consumatori che hanno bisogno della nuova interfaccia possono iniziare a consumare i nuovi dati. La versione del messaggio è implicita dal nome dell'argomento, ad esempio click_events_v1. I formati dei messaggi sono molto digitati. Non c'è alcuna variazione nel formato dei messaggi dello stesso argomento. Lo svantaggio di questo approccio è che potrebbero esserci consumatori di dati 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 affrontare una lacuna nel flusso dei messaggi o deduplicare i messaggi.
  • I dati vengono sempre pubblicati nello stesso argomento. Tuttavia, la struttura del messaggio può cambiare. Un attributo di 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 nuovo tipo. Inoltre, i producer di dati non possono utilizzare schemi di 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 i nuovi campi. Questo approccio può fornire un equilibrio ragionevole tra dati di tipo elevato e modifiche frequenti e complesse delle versioni.

API Data Access

I produttori 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 per esporre l'API di accesso ai dati a 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 contemporaneità, che restituiscono entrambi un risultato relativamente ridotto in una singola API e possono essere memorizzate nella cache.

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

  • Una visualizzazione combinata delle metriche dello 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).

Tutte le linee guida e la governance di cui dispone l'organizzazione per la creazione delle API delle applicazioni sono applicabili anche alle API personalizzate create dai produttori di dati. Le linee guida e la governance dell'organizzazione devono coprire problemi come hosting, monitoraggio, controllo dell'accesso e controllo delle versioni.

Lo svantaggio di un'API personalizzata è il fatto che i produttori di dati sono responsabili di qualsiasi infrastruttura aggiuntiva richiesta per ospitare questa interfaccia, nonché della codifica e manutenzione personalizzate delle API. Consigliamo ai produttori di dati di esaminare 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 contemporaneità.

Blocchi Looker

Per prodotti come Looker, molto utilizzati negli strumenti di business intelligence (BI), potrebbe essere utile mantenere un set di widget specifici per gli strumenti BI. Poiché il team di produzione dei dati conosce il modello di dati di base utilizzato nel dominio, è la persona più adatta a creare e gestire un set predefinito di visualizzazioni.

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

personalizzati

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

  • Il deployment dei modelli BigQuery ML può essere eseguito in un set di dati dedicato e condivisi con i consumatori dei dati per le previsioni batch BigQuery.
  • I modelli BigQuery ML possono essere esportati in Vertex AI per previsioni online.

Considerazioni sulla località dei dati per le interfacce di consumo

Una considerazione importante quando i produttori di dati definiscono le interfacce di consumo per i prodotti dati è la località. 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 dati in uscita tra regioni. Inoltre, questo approccio offre la latenza nel consumo di dati più bassa. Per questi motivi, i dati archiviati in località BigQuery su più regioni sono in genere i migliori candidati per l'esposizione come prodotto dati.

Tuttavia, per motivi legati alle prestazioni, i dati archiviati in Cloud Storage ed esposti tramite tabelle BigLake o API di lettura diretta devono essere archiviati in bucket a livello di regione.

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 considerare le seguenti limitazioni:

  • Le query tra regioni che utilizzano BigQuery SQL non sono supportate. Se il metodo di utilizzo principale per i dati è BigQuery SQL, tutte le tabelle nella query devono trovarsi nella stessa località.
  • 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 dati in un'altra, si applicano i prezzi on demand.
  • I consumer dei dati possono utilizzare API di lettura diretta per leggere i dati da un'altra regione. Tuttavia, vengono addebitati i costi relativi al traffico di rete in uscita tra regioni e i consumatori di dati molto probabilmente subiranno 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 quelle regioni per ridurre i costi 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 è necessario. Quando copi i dati, consigliamo ai produttori di dati di rendere disponibile solo un sottoinsieme dei dati di prodotto disponibili in più regioni. Questo approccio consente di 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 della località dei dati esplicitamente richiamata. Ad esempio, le viste autorizzate di BigQuery possono essere esposte mediante nomi come sales_eu_v1 e sales_us_v1.

Le interfacce dei flussi di dati che utilizzano argomenti Pub/Sub non richiedono alcuna logica di replica aggiuntiva per consumare messaggi in regioni diverse da quelle in cui è archiviato il messaggio. Tuttavia, in questo caso vengono applicati ulteriori costi per il traffico in uscita tra regioni.

Esporre le interfacce di consumo ai consumatori dei dati

Questa sezione illustra come rendere rilevabili le interfacce di consumo da parte dei potenziali consumer. Data Catalog è un servizio completamente gestito che le organizzazioni possono utilizzare per fornire i servizi di rilevamento dei dati e gestione dei metadati. I produttori di dati devono rendere disponibili per la ricerca le interfacce di consumo dei loro prodotti dati e annotarle con i metadati appropriati per consentire ai consumatori dei prodotti di accedervi in modo self-service. mer

Le seguenti sezioni descrivono in che modo ogni tipo di interfaccia viene definito come voce di Data Catalog.

Interfacce SQL basate su BigQuery

I metadati tecnici, ad esempio il nome completo o lo schema della tabella, 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 dati per aiutare i consumatori dei dati. Ad esempio, per aiutare gli utenti a trovare la documentazione del prodotto relativa a una voce, i produttori di dati possono aggiungere un URL a uno dei tag applicati alla voce. I produttori possono anche fornire quanto segue:

  • Insiemi di colonne in cluster, che devono essere utilizzati nei filtri delle query.
  • Valori di enumerazione per i campi che hanno un tipo di enumerazione logico, se il tipo non viene 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 dei prodotti dati.

API Cloud Storage

Data Catalog supporta la definizione delle voci dei file Cloud Storage e il 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 da Data Catalog creando voci personalizzate.

Passaggi successivi