Che cos'è Unity Catalog?

Questo articolo presenta Unity Catalog, una soluzione di governance unificata per gli asset di dati e intelligenza artificiale in Azure Databricks.

Nota

Unity Catalog è disponibile anche come implementazione open source. Vedere il blog dell'annuncio e il repository GitHub del catalogo Di Unity pubblico.

Panoramica del catalogo unity

Unity Catalog offre funzionalità centralizzate di controllo di accesso, controllo, derivazione e individuazione dei dati nelle aree di lavoro di Azure Databricks.

Le funzionalità principali di Unity Catalog includono:

• Definire una sola volta, proteggere ovunque: Unity Catalog offre un'unica posizione per amministrare i criteri di accesso ai dati che si applicano in tutte le aree di lavoro.
• Modello di sicurezza conforme agli standard: il modello di sicurezza del catalogo Unity si basa su SQL ANSI standard e consente agli amministratori di concedere autorizzazioni nel data lake esistente usando una sintassi familiare, a livello di cataloghi, schemi (detti anche database), tabelle e viste.
• Controllo e derivazione predefiniti: Unity Catalog acquisisce automaticamente i log di controllo a livello di utente che registrano l'accesso ai dati. Unity Catalog acquisisce anche dati di derivazione che tengono traccia del modo in cui vengono creati e usati gli asset di dati in tutti i linguaggi.
• Individuazione dei dati: Unity Catalog consente di contrassegnare e documentare gli asset di dati e fornisce un'interfaccia di ricerca per aiutare i consumer di dati a trovare i dati.
• Tabelle di sistema (anteprima pubblica): Il catalogo unity consente di accedere e eseguire facilmente query sui dati operativi dell'account, inclusi i log di controllo, l'utilizzo fatturabile e la derivazione.

Modello a oggetti del catalogo Unity

In Unity Catalog tutti i metadati vengono registrati in un metastore. La gerarchia degli oggetti di database in qualsiasi metastore del catalogo Unity è suddivisa in tre livelli, rappresentati come uno spazio dei nomi a tre livelli (catalog.schema.table-etc) quando si fa riferimento a tabelle, viste, volumi, modelli e funzioni.

Metastore

Il metastore è il contenitore di primo livello per i metadati in Unity Catalog. Registra i metadati relativi ai dati e agli asset di intelligenza artificiale e alle autorizzazioni che ne regolano l'accesso. Affinché un'area di lavoro usi il catalogo Unity, deve avere un metastore del catalogo Unity collegato.

È necessario disporre di un metastore per ogni area in cui sono presenti aree di lavoro. In che modo un'area di lavoro viene collegata a un metastore? Vedere Ricerca per categorie configurare Unity Catalog per l'organizzazione?

Gerarchia di oggetti nel metastore

In un metastore del catalogo Unity la gerarchia di oggetti di database a tre livelli è costituita da cataloghi che contengono schemi, che a loro volta contengono dati e oggetti di intelligenza artificiale, ad esempio tabelle e modelli.

Livello 1:

• I cataloghi vengono usati per organizzare gli asset di dati e vengono in genere usati come livello principale nello schema di isolamento dei dati. I cataloghi spesso rispecchiano le unità organizzative o gli ambiti del ciclo di vita dello sviluppo software. Vedere Che cosa sono i cataloghi in Azure Databricks?.
• oggetti non proteggibili relativi ai dati, ad esempio le credenziali di archiviazione e le posizioni esterne, sono utilizzati per gestire il modello di governance dei dati in Unity Catalog. Questi si trovano anche direttamente nel metastore. Sono descritti in modo più dettagliato in Altri oggetti a protezione diretta.

Livello due:

• Gli schemi (noti anche come database) contengono tabelle, viste, volumi, modelli di intelligenza artificiale e funzioni. Gli schemi organizzano i dati e gli asset di intelligenza artificiale in categorie logiche più granulari rispetto ai cataloghi. In genere uno schema rappresenta un singolo caso d'uso, un progetto o una sandbox del team. Vedere Che cosa sono gli schemi in Azure Databricks?.

Livello tre:

• I volumi sono volumi logici di dati non strutturati e non tabulari nell'archiviazione di oggetti cloud. I volumi possono essere gestiti, con Unity Catalog che gestisce il ciclo di vita completo e il layout dei dati in archiviazione o esterni, con Unity Catalog che gestisce l'accesso ai dati da Azure Databricks, ma non gestisce l'accesso ai dati nell'archiviazione cloud da altri client. Vedere Che cosa sono i volumi di Catalogo Unity? e Gestiti rispetto a tabelle e volumi esterni.
• Le tabelle sono raccolte di dati organizzati in base a righe e colonne. Le tabelle possono essere gestite, con Unity Catalog che gestisce il ciclo di vita completo della tabella o esterna, con Unity Catalog che gestisce l'accesso ai dati da Azure Databricks, ma non gestisce l'accesso ai dati nell'archiviazione cloud da altri client. Vedere Che cosa sono tabelle e viste? e Gestite rispetto a tabelle e volumi esterni.
• Le viste vengono salvate su una o più tabelle. Vedere Che cos'è una visualizzazione?.
• Le funzioni sono unità di logica salvata che restituiscono un valore scalare o un set di righe. Si veda Funzioni definite dall'utente (UDF) nel catalogo Unity.
• I modelli sono modelli di intelligenza artificiale in pacchetto con MLflow e registrati in Unity Catalog come funzioni. Vedere Gestire il ciclo di vita del modello nel catalogo Unity.

Utilizzo di oggetti di database nel catalogo unity

L'uso di oggetti di database in Unity Catalog è molto simile all'uso di oggetti di database registrati in un metastore Hive, ad eccezione del fatto che un metastore Hive non include cataloghi nello spazio dei nomi dell'oggetto. È possibile usare una sintassi ANSI familiare per creare oggetti di database, gestire oggetti di database, gestire le autorizzazioni e usare i dati in Unity Catalog. È anche possibile creare oggetti di database, gestire oggetti di database e gestire le autorizzazioni per gli oggetti di database usando l'interfaccia utente di Esplora cataloghi.

Per altre informazioni, vedere Oggetti di database in Azure Databricks e Usare il catalogo Unity e il metastore Hive legacy.

Altri oggetti a protezione diretta

Oltre agli oggetti di database e agli asset di intelligenza artificiale contenuti negli schemi, Unity Catalog controlla anche l'accesso ai dati usando gli oggetti a protezione diretta seguenti:

• Credenziali del servizio, che incapsulano una credenziale cloud a lungo termine che fornisce l'accesso a un servizio esterno. Vedere Gestire l'accesso ai servizi cloud esterni usando le credenziali del servizio.

• Credenziali di archiviazione, che incapsulano una credenziale cloud a lungo termine che fornisce l'accesso all'archiviazione cloud. Vedere Creare credenziali di archiviazione per la connessione ad Azure Data Lake Storage Gen2.

• Percorsi esterni, che contengono un riferimento a una credenziale di archiviazione e a un percorso di archiviazione cloud. I percorsi esterni possono essere usati per creare tabelle esterne o per assegnare un percorso di archiviazione gestito per tabelle e volumi gestiti. Vedere Creare una posizione esterna per connettere l'archiviazione cloud ad Azure Databricks, Isolamento dei dati usando l'archiviazione gestita e Specificare un percorso di archiviazione gestito nel catalogo unity.

• Connessioni, che rappresentano credenziali che consentono l'accesso in sola lettura a un database esterno in un sistema di database come MySQL tramite Lakehouse Federation. Vedere Lakehouse Federation e Unity Catalog e Che cos'è Lakehouse Federation?.

• Clean rooms, che rappresentano un ambiente gestito da Databricks in cui più partecipanti possono collaborare a progetti senza condividere i dati sottostanti tra loro. Si veda Che cos'è Azure Databricks Clean Rooms?.

• Condivisioni, ovvero oggetti Delta Sharing che rappresentano una raccolta di dati e asset di intelligenza artificiale di sola lettura condivisi da un provider di dati con uno o più destinatari.

• Destinatari, ovvero oggetti Delta Sharing che rappresentano un'entità che riceve condivisioni da un provider di dati.

• Provider, ovvero oggetti Delta Sharing che rappresentano un'entità che condivide i dati con un destinatario.

Per altre informazioni sugli oggetti a protezione diretta di condivisione differenziale, vedere Informazioni sulla condivisione differenziale.

Concessione e revoca dell'accesso agli oggetti di database e ad altri oggetti a protezione diretta in Unity Catalog

È possibile concedere e revocare l'accesso a oggetti a protezione diretta a qualsiasi livello della gerarchia, incluso il metastore stesso. L'accesso a un oggetto concede in modo implicito lo stesso accesso a tutti gli elementi figlio di tale oggetto, a meno che l'accesso non venga revocato.

È possibile usare i comandi SQL ANSI tipici per concedere e revocare l'accesso agli oggetti nel catalogo unity. Ad esempio:

GRANT CREATE TABLE ON SCHEMA mycatalog.myschema TO `finance-team`;

È anche possibile usare Esplora cataloghi, l'interfaccia della riga di comando di Databricks e le API REST per gestire le autorizzazioni degli oggetti.

Per informazioni su come gestire i privilegi nel catalogo unity, vedere Gestire i privilegi nel catalogo unity.

Accesso predefinito agli oggetti di database nel catalogo unity

Il catalogo unity opera sul principio dei privilegi minimi, in cui gli utenti hanno l'accesso minimo necessario per eseguire le attività necessarie. Quando viene creata un'area di lavoro, gli utenti non amministratori hanno accesso solo al catalogo delle aree di lavoro con provisioning automatico, in modo da consentire agli utenti di provare il processo di creazione e accesso a oggetti di database in Unity Catalog. Vedere Privilegi del catalogo dell'area di lavoro.

Ruoli amministratore

Gli amministratori dell'area di lavoro e gli amministratori degli account hanno privilegi aggiuntivi per impostazione predefinita. L'amministratore metastore è un ruolo facoltativo, obbligatorio se si vuole gestire l'archiviazione di tabelle e volumi a livello di metastore e conveniente se si vogliono gestire i dati centralmente in più aree di lavoro in un'area. Per altre informazioni, vedere Privilegi di amministratore in Unity Catalog e (facoltativo) Assegnare il ruolo di amministratore del metastore.

Tabelle e volumi gestiti e esterni

Le tabelle e i volumi possono essere gestiti o esterni.

• Le tabelle gestite sono completamente gestite da Unity Catalog, il che significa che Unity Catalog gestisce sia la governance che i file di dati sottostanti per ogni tabella gestita. Le tabelle gestite vengono archiviate in una posizione gestita dal catalogo unity nell'archiviazione cloud. Le tabelle gestite usano sempre il formato Delta Lake. È possibile archiviare tabelle gestite a livello di metastore, catalogo o schema.
• Le tabelle esterne sono tabelle il cui accesso da Azure Databricks è gestito da Unity Catalog, ma il cui ciclo di vita dei dati e il layout dei file vengono gestiti usando il provider di servizi cloud e altre piattaforme dati. In genere si usano tabelle esterne per registrare grandi quantità di dati esistenti in Azure Databricks o se è necessario anche l'accesso in scrittura ai dati usando strumenti esterni ad Azure Databricks. Le tabelle esterne sono supportate in più formati di dati. Dopo aver registrato una tabella esterna in un metastore di Unity Catalog, è possibile gestire e controllare l'accesso ad Azure Databricks e usarlo come per le tabelle gestite.
• I volumi gestiti sono completamente gestiti da Unity Catalog, il che significa che Unity Catalog gestisce l'accesso alla posizione di archiviazione del volume nell'account del provider di servizi cloud. Quando si crea un volume gestito, questo viene archiviato automaticamente nel percorso di archiviazione gestito assegnato allo schema contenitore.
• I volumi esterni rappresentano i dati esistenti nei percorsi di archiviazione gestiti all'esterno di Azure Databricks, ma registrati in Unity Catalog per controllare e controllare l'accesso da Azure Databricks. Quando si crea un volume esterno in Azure Databricks, è necessario specificarne la posizione, che deve trovarsi in un percorso definito in una posizione esterna del catalogo Unity.

Databricks consiglia tabelle e volumi gestiti per sfruttare appieno le funzionalità di governance e le ottimizzazioni delle prestazioni di Unity Catalog.

Vedere Usare tabelle gestite, Usare tabelle esterne e Volumi gestiti o esterni.

Isolamento dei dati tramite l'archiviazione gestita

L'organizzazione potrebbe richiedere che determinati tipi di dati vengano archiviati all'interno di account o bucket specifici nel tenant cloud.

Il catalogo Unity consente di configurare i percorsi di archiviazione a livello di metastore, catalogo o schema per soddisfare tali requisiti. Il sistema valuta la gerarchia dei percorsi di archiviazione dallo schema al catalogo al metastore.

Si supponga, ad esempio, che l'organizzazione disponga di un criterio di conformità aziendale che richiede che i dati di produzione relativi alle risorse umane risiedano nel contenitore abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net. In Unity Catalog è possibile ottenere questo requisito impostando una posizione a livello di catalogo, creando un catalogo denominato, ad esempio hr_prod, e assegnando il percorso abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net/unity-catalog. Ciò significa che le tabelle gestite o i volumi creati nel hr_prod catalogo (ad esempio, usando CREATE TABLE hr_prod.default.table …) archiviano i dati in abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net/unity-catalog. Facoltativamente, è possibile scegliere di fornire percorsi a livello di schema per organizzare i dati all'interno di hr_prod catalog a un livello più granulare.

Se l'isolamento dell'archiviazione non è necessario per alcuni cataloghi, è possibile impostare facoltativamente una posizione di archiviazione a livello di metastore. Questo percorso funge da percorso predefinito per tabelle gestite e volumi in cataloghi e schemi che non hanno assegnato spazio di archiviazione. In genere, Tuttavia, Databricks consiglia di assegnare posizioni di archiviazione gestite separate per ogni catalogo.

Per altre informazioni, vedere Specificare un percorso di archiviazione gestito in Unity Catalog e i dati sono separati fisicamente nell'archiviazione.

Associazione del catalogo dell'area di lavoro

Per impostazione predefinita, i proprietari del catalogo (e gli amministratori del metastore, se definiti per l'account) possono rendere un catalogo accessibile agli utenti in più aree di lavoro collegate allo stesso metastore del catalogo Unity. Se si usano aree di lavoro per isolare l'accesso ai dati utente, tuttavia, è possibile limitare l'accesso al catalogo a aree di lavoro specifiche nell'account, per assicurarsi che determinati tipi di dati vengano elaborati solo in tali aree di lavoro. È possibile che si vogliano separare le aree di lavoro di produzione e sviluppo, ad esempio o un'area di lavoro separata per l'elaborazione dei dati personali. Questa operazione è nota come associazione del catalogo dell'area di lavoro. Vedere Limitare l'accesso al catalogo ad aree di lavoro specifiche.

Nota

Per aumentare l'isolamento dei dati, è anche possibile associare l'accesso alle risorse di archiviazione cloud e all'accesso al servizio cloud a aree di lavoro specifiche. Vedere (Facoltativo) Assegnare credenziali di archiviazione a aree di lavoro specifiche, (Facoltativo) Assegnare una posizione esterna a aree di lavoro specifiche e (Facoltativo) Assegnare credenziali del servizio a aree di lavoro specifiche.

Controllo dell'accesso ai dati

Il catalogo unity acquisisce un log di controllo delle azioni eseguite sul metastore, consentendo agli amministratori di accedere ai dettagli con granularità fine sugli utenti che hanno eseguito l'accesso a un determinato set di dati e sulle azioni eseguite.

È possibile accedere ai log di controllo dell'account usando le tabelle di sistema gestite da Unity Catalog.

Vedere Controllare gli eventi di Unity Catalog, gli eventi di Unity Catalog e Monitorare l'attività dell'account con le tabelle di sistema.

Derivazione dei dati di rilevamento

È possibile usare Unity Catalog per acquisire la derivazione dei dati di runtime tra query in qualsiasi linguaggio eseguito in un cluster Di Azure Databricks o in SQL Warehouse. La derivazione viene acquisita fino al livello di colonna e include notebook, processi e dashboard correlati alla query. Per altre informazioni, vedere Acquisire e visualizzare la derivazione dei dati con Unity Catalog.

Federazione di Lakehouse e Catalogo Unity

Lakehouse Federation è la piattaforma di federazione delle query per Azure Databricks. Il termine federazione di query descrive una raccolta di funzionalità che consentono a utenti e sistemi di eseguire query su più origini dati silo senza dover eseguire la migrazione di tutti i dati a un sistema unificato.

Azure Databricks usa Unity Catalog per gestire la federazione delle query. Usare Unity Catalog per configurare le connessioni di sola lettura ai sistemi di database esterni più diffusi e creare cataloghi stranieri che rispecchiano i database esterni. Gli strumenti di governance dei dati e derivazione dei dati di Unity Catalog assicurano che l'accesso ai dati sia gestito e controllato per tutte le query federate eseguite dagli utenti nelle aree di lavoro di Azure Databricks.

Vedere Che cos'è Lakehouse Federation?.

Condivisione differenziale, Databricks Marketplace e Catalogo Unity

Delta Sharing è una piattaforma di condivisione dei dati sicura che consente di condividere i dati e le risorse di intelligenza artificiale con utenti esterni all'organizzazione, indipendentemente dal fatto che gli utenti usino Databricks. Anche se Delta Sharing è disponibile come implementazione open source, in Databricks richiede Unity Catalog per sfruttare appieno le funzionalità estese. Si veda Che cos'è Delta Sharing?.

Databricks Marketplace, un forum aperto per lo scambio di prodotti dati, si basa sulla condivisione delta e, di conseguenza, è necessario disporre di un'area di lavoro abilitata per Unity Catalog per essere un provider del Marketplace. Vedere Che cos'è Databricks Marketplace?.

Ricerca per categorie configurare Unity Catalog per l'organizzazione?

Per usare Unity Catalog, l'area di lavoro di Azure Databricks deve essere abilitata per Unity Catalog, il che significa che l'area di lavoro è collegata a un metastore del catalogo Unity.

In che modo un'area di lavoro viene collegata a un metastore? Dipende dall'account e dall'area di lavoro:

• In genere, quando si crea un'area di lavoro di Azure Databricks in un'area per la prima volta, il metastore viene creato automaticamente e collegato all'area di lavoro.
• Per alcuni account meno recenti, un amministratore dell'account deve creare il metastore e assegnare le aree di lavoro in tale area al metastore. Per istruzioni, vedere Creare un metastore Unity Catalog.
• Se un account ha già un metastore assegnato per un'area, un amministratore dell'account può decidere se collegare automaticamente il metastore a tutte le nuove aree di lavoro in tale area. Vedere Abilitare un metastore per l'assegnazione automatica alle nuove aree di lavoro.

Indipendentemente dal fatto che l'area di lavoro sia stata abilitata automaticamente per Il catalogo unity, per iniziare a usare il catalogo Unity sono necessari anche i passaggi seguenti:

• Creare cataloghi e schemi per contenere oggetti di database come tabelle e volumi.
• Creare percorsi di archiviazione gestiti per archiviare tabelle e volumi gestiti in questi cataloghi e schemi.
• Concedere all'utente l'accesso a cataloghi, schemi e oggetti di database.

Le aree di lavoro abilitate automaticamente per Unity Catalog eseguono il provisioning di un catalogo di aree di lavoro con privilegi generali concessi a tutti gli utenti dell'area di lavoro. Questo catalogo è un punto di partenza pratico per provare Unity Catalog.

Per istruzioni dettagliate sulla configurazione, vedere Configurare e gestire il catalogo Unity.

Migrazione di un'area di lavoro esistente al catalogo Unity

Se si dispone di un'area di lavoro precedente abilitata di recente per Unity Catalog, è probabile che i dati siano gestiti dal metastore Hive legacy. È possibile usare questi dati insieme ai dati registrati in Unity Catalog, ma il metastore Hive legacy è deprecato ed è necessario eseguire la migrazione dei dati nel metastore Hive al catalogo Unity il prima possibile per sfruttare le funzionalità di governance e le prestazioni superiori di Unity Catalog.

La migrazione prevede quanto segue:

1. Conversione di tutti i gruppi locali dell'area di lavoro in gruppi a livello di account. Unity Catalog centralizza la gestione delle identità a livello di account.
2. Migrazione di tabelle e viste gestite nel metastore Hive nel catalogo unity.
3. Aggiornare query e processi per fare riferimento alle nuove tabelle del catalogo Unity anziché alle tabelle del metastore Hive precedenti.

Di seguito è possibile gestire una migrazione:

• UCX, un progetto databricks Labs, fornisce strumenti che consentono di aggiornare l'area di lavoro non Unity-Catalog a Unity Catalog. UCX è una buona scelta per le migrazioni su larga scala. Vedere Usare le utilità UCX per aggiornare l'area di lavoro a Unity Catalog.

• Se si dispone di un numero inferiore di tabelle di cui eseguire la migrazione, Azure Databricks fornisce una procedura guidata dell'interfaccia utente e comandi SQL che è possibile usare. Vedere Aggiornare tabelle e viste Hive a Unity Catalog.

• Per informazioni su come usare le tabelle nel metastore Hive insieme agli oggetti di database nel catalogo unity nella stessa area di lavoro, vedere Usare il catalogo unity e il metastore Hive legacy.

Requisiti e restrizioni del catalogo Unity

Il catalogo unity richiede tipi specifici di formati di calcolo e di file, descritti di seguito. Di seguito sono elencate anche alcune funzionalità di Azure Databricks non completamente supportate in Unity Catalog in tutte le versioni di Databricks Runtime.

Supporto per l'area

Tutte le aree supportano il catalogo Unity. Per informazioni dettagliate, vedere Aree di Azure Databricks.

Requisiti di calcolo

Il catalogo unity è supportato nei cluster che eseguono Databricks Runtime 11.3 LTS o versione successiva. Il catalogo Unity è supportato per impostazione predefinita in tutte le versioni di calcolo di SQL Warehouse.

I cluster in esecuzione nelle versioni precedenti di Databricks Runtime non forniscono supporto per tutte le caratteristiche e le funzionalità disponibili a livello generale per Unity Catalog.

Per accedere ai dati in Unity Catalog, i cluster devono essere configurati con la modalità di accesso corretta. Il catalogo unity è sicuro per impostazione predefinita. Se un cluster non è configurato con la modalità di accesso condiviso o utente singolo, il cluster non può accedere ai dati in Unity Catalog. Vedere Modalità di accesso usata.

Per informazioni dettagliate sulle modifiche alle funzionalità di Unity Catalog in ogni versione di Databricks Runtime, vedere le note sulla versione.

Le limitazioni per Unity Catalog variano in base alla modalità di accesso e alla versione di Databricks Runtime. Vedere Limitazioni della modalità di accesso condiviso per il catalogo Unity.

Supporto del formato di file

Il catalogo unity supporta i formati di tabella seguenti:

• Le tabelle gestite devono usare il delta formato di tabella.
• Le tabelle esterne possono usare delta, CSV, JSONavro, parquet, , ORCo text.

Limiti

Unity Catalog presenta le limitazioni seguenti. Alcune di queste sono specifiche delle versioni precedenti di Databricks Runtime e delle modalità di accesso alle risorse di calcolo.

I carichi di lavoro Structured Streaming presentano limitazioni aggiuntive, a seconda del runtime di Databricks e della modalità di accesso. Vedere Limitazioni della modalità di accesso condiviso per il catalogo Unity.

Databricks rilascia regolarmente nuove funzionalità che riducono l'elenco.

• I gruppi creati in precedenza in un'area di lavoro (ovvero i gruppi a livello di area di lavoro) non possono essere usati nelle istruzioni del catalogo GRANT Unity. Ciò consente di garantire una visualizzazione coerente dei gruppi che possono estendersi tra aree di lavoro. Per usare i gruppi nelle GRANistruzioni T, creare i gruppi a livello di account e aggiornare qualsiasi automazione per la gestione dell'entità o del gruppo ,ad esempio i connettori SCIM, Okta e Microsoft Entra ID e Terraform, per fare riferimento agli endpoint dell'account anziché agli endpoint dell'area di lavoro. Consulta Tipi di gruppi in Azure Databricks.

• I carichi di lavoro in R non supportano l'uso di viste dinamiche per la sicurezza a livello di riga o a livello di colonna nel calcolo che esegue Databricks Runtime 15.3 e versioni successive.

  Usare una singola risorsa di calcolo utente che esegue Databricks Runtime 15.4 LTS o versione successiva per i carichi di lavoro in R che eseguono query sulle viste dinamiche. Tali carichi di lavoro richiedono anche un'area di lavoro abilitata per il calcolo serverless. Per informazioni dettagliate, vedere Controllo di accesso con granularità fine sul calcolo di un singolo utente.

• I cloni superficiali non sono supportati in Unity Catalog nell'ambiente di calcolo che esegue Databricks Runtime 12.2 LTS e versioni successive. È possibile usare cloni superficiali per creare tabelle gestite in Databricks Runtime 13.3 LTS e versioni successive. Non è possibile usarle per creare tabelle esterne, indipendentemente dalla versione di Databricks Runtime. Vedere Clone superficiale per le tabelle del catalogo Unity.

• Il bucketing non è supportato per le tabelle di Unity Catalog. Se si eseguono comandi che tentano di creare una tabella in bucket nello Unity Catalog, si genererà un'eccezione.

• La scrittura nello stesso percorso o nella tabella Delta Lake dalle aree di lavoro in più aree può causare prestazioni inaffidabili se alcuni cluster accedono a Unity Catalog e altri no.

• La modifica delle partizioni per le tabelle esterne tramite comandi come ALTER TABLE ADD PARTITION richiede l'abilitazione della registrazione dei metadati della partizione. Consultare Individuazione delle partizioni per tabelle esterne.

• Quando si usa la modalità di sovrascrittura per le tabelle non in formato Delta, l'utente deve avere il privilegio CREATE TABLE per lo schema padre e deve essere il proprietario dell'oggetto esistente OPPURE avere il privilegio MODIFY per l'oggetto .

• Le funzioni definite dall'utente Python non sono supportate in Databricks Runtime 12.2 LTS e versioni successive. Sono incluse le funzioni definite dall'utente, le funzioni definite dall'utente e Pandas in Spark (applyInPandas e mapInPandas). Le funzioni definite dall'utente scalari Python sono supportate in Databricks Runtime 13.3 LTS e versioni successive.

• Le funzioni definite dall'utente scala non sono supportate in Databricks Runtime 14.1 e versioni successive nei cluster condivisi. Le funzioni definite dall'utente scalari scalari sono supportate in Databricks Runtime 14.2 e versioni successive nei cluster condivisi.

• I pool di thread Scala standard non sono supportati. Usare invece i pool di thread speciali in org.apache.spark.util.ThreadUtils, ad esempio org.apache.spark.util.ThreadUtils.newDaemonFixedThreadPool. Tuttavia, i pool di thread seguenti in ThreadUtils non sono supportati: ThreadUtils.newForkJoinPool e qualsiasi ScheduledExecutorService pool di thread.

• La registrazione di controllo è supportata solo per gli eventi di Unity Catalog a livello di area di lavoro. Gli eventi che si verificano a livello di account senza riferimento a un'area di lavoro, ad esempio la creazione di un metastore, non vengono registrati.

I modelli registrati in Unity Catalog presentano limitazioni aggiuntive. Vedere Limitazioni.

Quote di risorse

Unity Catalog applica le quote di risorse a tutti gli oggetti a protezione diretta. Queste quote sono elencate in Limiti delle risorse. Se si prevede di superare questi limiti di risorse, contattare il team dell'account Azure Databricks.

È possibile monitorare l'utilizzo delle quote usando le API delle quote delle risorse del catalogo Unity. Vedere Monitorare l'utilizzo delle quote delle risorse del catalogo Unity.