Clone superficiale per le tabelle del catalogo Unity

È possibile usare clone superficiale per creare nuove tabelle del catalogo Unity da tabelle del catalogo Unity esistenti. Il supporto dei cloni superficiali per Unity Catalog consente di creare tabelle con privilegi di controllo di accesso indipendenti dalle tabelle padre senza dover copiare i file di dati sottostanti.

Per altre informazioni sul clone Delta, vedere Clonare una tabella in Azure Databricks.

Per altre informazioni sulle tabelle del catalogo Unity, vedere Informazioni su tabelle e viste.

Creare un clone superficiale nel catalogo unity

È possibile creare un clone superficiale nel catalogo unity usando la stessa sintassi disponibile per cloni superficiali in tutto il prodotto, come illustrato nell'esempio di sintassi seguente:

CREATE TABLE <catalog-name>.<schema-name>.<target-table-name> SHALLOW CLONE <catalog-name>.<schema-name>.<source-table-name>

Per creare un clone superficiale nel catalogo unity, è necessario disporre di privilegi sufficienti per le risorse di origine e di destinazione, come descritto nella tabella seguente:

Analogamente ad altre istruzioni create table, l'utente che crea un clone superficiale è il proprietario della tabella di destinazione. Il proprietario di una tabella clonata di destinazione può controllare i diritti di accesso per tale tabella indipendentemente dalla tabella di origine.

Eseguire query o modificare una tabella clonata superficiale nel catalogo unity

Per eseguire query su un clone superficiale nel catalogo unity, è necessario disporre di privilegi sufficienti per la tabella e le risorse contenenti, come descritto nella tabella seguente:

Per completare le azioni seguenti, è necessario disporre MODIFY anche delle autorizzazioni per la destinazione dell'operazione di clonazione:

• Inserire record
• Eliminazione di record
• Aggiornamento di record
• MERGE
• CREATE OR REPLACE TABLE
• DROP TABLE

Cloni superficiali di Vacuum e Unity Catalog

Quando si usano le tabelle di Catalogo Unity per l'origine e la destinazione di un'operazione clone superficiale, Unity Catalog gestisce i file di dati sottostanti per migliorare l'affidabilità per l'origine e la destinazione dell'operazione di clonazione. L'esecuzione VACUUM nell'origine di un clone superficiale non interrompe la tabella clonata.

In genere, quando VACUUM identifica i file validi per una determinata soglia di conservazione, vengono considerati solo i metadati per la tabella corrente. Il supporto dei cloni superficiali per Unity Catalog tiene traccia delle relazioni tra tutte le tabelle clonate e i file di dati di origine, quindi i file validi vengono espansi per includere i file di dati necessari per la restituzione di query per qualsiasi tabella clonata superficiale e la tabella di origine.

Ciò significa che per la semantica dei cloni VACUUM superficiali di Unity Catalog, un file di dati valido è qualsiasi file entro la soglia di conservazione specificata per la tabella di origine o qualsiasi tabella clonata. Le tabelle gestite e le tabelle esterne hanno una semantica leggermente diversa.

Questo rilevamento avanzato delle modifiche ai metadati influisce VACUUM sul modo in cui le operazioni influisce sui file di dati che eseguino il backup delle tabelle Delta, con la semantica seguente:

• Per le tabelle gestite, VACUUM le operazioni sull'origine o sulla destinazione di un'operazione clone superficiale potrebbero eliminare i file di dati dalla tabella di origine.
• Per le tabelle esterne, VACUUM le operazioni rimuovono solo i file di dati dalla tabella di origine quando vengono eseguiti sulla tabella di origine.
• Vengono rimossi solo i file di dati non considerati validi per la tabella di origine o qualsiasi clone superficiale sull'origine.
• Se più cloni superficiali vengono definiti su una singola tabella di origine, l'esecuzione VACUUM in una delle tabelle clonate non rimuove i file di dati validi per altre tabelle clonate.

Usare tabelle clonate superficiali in modalità accesso utente singolo

Quando si lavora con cloni superficiali del catalogo Unity in modalità accesso utente singolo, è necessario disporre delle autorizzazioni per le risorse per l'origine della tabella clonata e per la tabella di destinazione.

Ciò significa che per le query semplici oltre alle autorizzazioni necessarie per la tabella di destinazione, è necessario disporre USE delle autorizzazioni per il catalogo di origine e lo schema e SELECT le autorizzazioni per la tabella di origine. Per le query che aggiornano o inseriscono record nella tabella di destinazione, è necessario disporre MODIFY anche delle autorizzazioni per la tabella di origine.

Databricks consiglia di usare cloni di Unity Catalog nel calcolo con modalità di accesso condiviso, in quanto consente l'evoluzione indipendente delle autorizzazioni per le destinazioni clone superficiali di Unity Catalog e le relative tabelle di origine.

Limiti

• I cloni superficiali nelle tabelle esterne devono essere tabelle esterne. I cloni superficiali nelle tabelle gestite devono essere tabelle gestite.
• Non è possibile condividere cloni superficiali usando la condivisione delta.
• Non è possibile annidare cloni superficiali, ovvero non è possibile creare un clone superficiale da un clone superficiale.
• Per le tabelle gestite, l'eliminazione della tabella di origine interrompe la tabella di destinazione per cloni superficiali. I file di dati che eseguono il backup di tabelle esterne non vengono rimossi dalle DROP TABLE operazioni e pertanto i cloni superficiali delle tabelle esterne non sono interessati dall'eliminazione dell'origine.
• Unity Catalog consente agli UNDROP utenti di gestire le tabelle per circa 7 giorni dopo un DROP TABLE comando. In Databricks Runtime 13.3 LTS e versioni successive, i cloni superficiali gestiti gestiti basati su una tabella gestita eliminata continuano a funzionare durante questo periodo di 7 giorni. Se non UNDROP si usa la tabella di origine in questa finestra, il clone superficiale smette di funzionare dopo il Garbage Collection dei file di dati della tabella di origine.