Clone superficiale per le tabelle di Unity Catalog

È 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 informazioni sulla clonazione di una tabella, vedere Clonare una tabella in Azure Databricks.

Per informazioni sulle tabelle di Unity Catalog, vedere Tabelle di Azure Databricks.

Creare un clone parziale nel Unity Catalog

È 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 superficialmente nel Unity Catalog

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:

È inoltre necessario disporre delle MODIFY autorizzazioni sulla destinazione dell'operazione di clonazione per completare le seguenti azioni:

• Inserire record
• Eliminazione di record
• Aggiorna record
• MERGE
• CREATE 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. Eseguire VACUUM sulla sorgente di una clonazione 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 dei metadati modifica il modo VACUUM in cui le operazioni influiscono sui file di dati che supportano le tabelle, con la seguente semantica:

• Per le tabelle gestite, VACUUM le operazioni eseguite sull'origine o sulla destinazione di un'operazione di clonazione 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.

Lavorare con tabelle clonate superficialmente in modalità di accesso dedicato

Quando si lavora con cloni superficiali del catalogo Unity in modalità di accesso dedicato, è necessario disporre delle autorizzazioni per le risorse per l'origine della tabella clonata e 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 anche di MODIFY autorizzazioni per la tabella di origine.

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

Eliminare la tabella di base per un clone superficiale

Se la tabella di base di un clone superficiale viene eliminata, il clone diventa inutilizzabile. Per impostazione predefinita, Databricks impedisce l'eliminazione di una tabella di base se contiene ancora cloni superficiali che lo fanno riferimento.

Per eseguire l'override di questa protezione, usare la DROP TABLE ... FORCE sintassi . Se si usa FORCE:

• La tabella di base viene eliminata immediatamente.
• Tutti i cloni superficiali referenziati diventano interrotti e:
  • Esito negativo nelle operazioni che richiedono la lettura di dati o metadati ( ad esempio , SELECT). INSERTUPDATEDESCRIBE HISTORYCLONE
  • Sono ancora visibili tramite operazioni a livello di metadati ( ad esempio SHOW TABLES, DROP TABLE) per consentire la pulizia.

Questo comportamento si applica solo alle tabelle gestite di Unity Catalog.

Vedi DROP TABLE.

Limiti

• I cloni superficiali delle tabelle esterne devono essere anch'essi tabelle esterne. I cloni superficiali delle tabelle gestite devono essere anch'essi tabelle gestite.
• Non è possibile usare REPLACE o CREATE OR REPLACE per sovrascrivere un clone superficiale esistente. Al contrario, DROP il clone superficiale ed eseguire una nuova istruzione CREATE.
• 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 supportano le tabelle esterne non vengono rimossi dalle operazioni DROP TABLE e pertanto i cloni superficiali delle tabelle esterne non sono influenzati 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 leggeri gestiti relativi a una tabella gestita eliminata continuano a funzionare durante questo periodo di 7 giorni. Se non UNDROP la tabella di origine in questa finestra, il clone superficiale smette di funzionare quando i file di dati della tabella di origine vengono raccolti come rifiuti.