Replica superficiale per le tabelle del Catalogo Unity

Usare clone superficiale per creare tabelle di Catalogo Unity con privilegi di controllo di accesso indipendenti dalle tabelle di origine, senza copiare i file di dati sottostanti. Il clone superficiale in Unity Catalog è supportato solo per le tabelle Delta Lake. Non è possibile creare un clone superficiale di un iceberg o di un'altra tabella non Delta.

Per informazioni sulla clonazione di una tabella, vedere Clonare una tabella in Azure Databricks.

Creare un clone superficiale gestito dal catalogo Unity

Creare un clone superficiale di una tabella gestita in Unity Catalog.

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

Per creare un clone superficiale gestito nel catalogo unity, è necessario disporre dei privilegi seguenti per le risorse di origine e di destinazione.

Come per le altre istruzioni CREATE TABLE, quando si esegue SHALLOW CLONE, si diventa proprietari della tabella di destinazione. Il proprietario di una tabella di destinazione clonata controlla i diritti di accesso per tale tabella indipendentemente dalla tabella di origine. Il proprietario di una tabella clonata potrebbe essere diverso dal proprietario di una tabella di origine.

Creare un clone esterno superficiale del Unity Catalog

Creare un clone esterno di tipo shallow del catalogo Unity specificando una posizione esterna.

CREATE TABLE <catalog-name>.<schema-name>.<target-table-name>
SHALLOW CLONE <catalog-name>.<schema-name>.<source-table-name>
LOCATION 's3://<bucket-name>/<path-name>/<target-table-name>'

Per creare un clone superficiale esterno nel catalogo unity, è necessario disporre dei privilegi seguenti per le risorse di origine e di destinazione.

Lavorare con tabelle duplicate in modo superficiale in modalità di accesso standard

Per interrogare un clone shallow in modalità di accesso standard (in precedenza modalità di accesso condiviso), sono necessari i seguenti privilegi sulla tabella e sulle risorse che la contengono:

Devi inoltre disporre delle autorizzazioni MODIFY sulla destinazione dell'operazione di clonazione per eseguire le operazioni seguenti:

• INSERT
• DELETE
• UPDATE
• MERGE
• CREATE TABLE
• DROP TABLE

Lavorare con tabelle clonate superficialmente in modalità di accesso dedicato

Quando si utilizzano cloni superficiali di Unity Catalog in modalità di accesso dedicato (in precedenza modalità di accesso utente singolo), è necessario disporre delle autorizzazioni per le risorse sia per l'origine della tabella clonata che per la tabella di destinazione.

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 tutte le query che aggiornano o inseriscono record nella tabella di destinazione, è necessario disporre anche delle autorizzazioni MODIFY sulla tabella di origine.

Databricks consiglia di usare cloni di Unity Catalog nel calcolo con modalità di accesso standard, in quanto consente modifiche indipendenti delle autorizzazioni per le destinazioni clone superficiali di Unity Catalog e le relative tabelle di origine.

Usare VACUUM con cloni superficiali del catalogo Unity

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 di VACUUM sulla sorgente di un clone superficiale non danneggia 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. Tuttavia, 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 restituire query sia per le tabelle clonate superficiali che per la tabella di origine.

Per VACUUM in un clone superficiale 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 comportamenti leggermente diversi.

Questo rilevamento avanzato dei metadati modifica il modo in cui le VACUUM operazioni influiscono sui file di dati sottostanti nelle tabelle Delta Lake, con il seguente comportamento:

• 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.

Anche se elimini una tabella clonata in modo superficiale, potresti aver bisogno di SELECT accesso a quella tabella clonata in modo superficiale per eseguire VACUUM sulla tabella di base. Databricks legge il Delta log del clone shallow per verificare quali file di dati della tabella di base vengono ancora referenziati dal clone prima di eseguirne la pulizia. Databricks mantiene questo riferimento per 7 giorni dopo aver eliminato una tabella clonata in modalità shallow per supportare l'operazione UNDROP. In modalità di accesso standard, tuttavia, questa autorizzazione non è necessaria.

Eliminare la tabella di base per un clone superficiale

Puoi eliminare la tabella di base di una tabella gestita di Unity Catalog anche quando cloni superficiali attivi fanno ancora riferimento a essa. I cloni continuano a leggere finché i file dati della tabella base non vengono eliminati, il che li rende inutilizzabili. Puoi ripristinare la tabella di base con UNDROP durante il periodo di recupero, che per impostazione predefinita è di 7 giorni e può essere configurato a livello di catalogo o di schema su 0 (per disabilitare il ripristino) oppure da 7 a 30 giorni. La configurazione del periodo di recupero avviene in Anteprima Pubblica. Se non ripristini la tabella, un processo di purga asincrona cancella i suoi file dati dopo la fine del periodo di recupero, così i cloni possono continuare a leggere per un po' dopo che la tabella base non è più recuperabile. Per recuperare una tabella base caduta, usa UNDROP.

Limitations

• Il clone superficiale è supportato solo per le tabelle Delta Lake. Non è possibile creare un clone superficiale di un iceberg o di un'altra tabella non Delta.
• Non è possibile usare CREATE OR REPLACE per sovrascrivere un clone superficiale esistente. Usare DROP TABLE seguito da CREATE TABLEo usare un nuovo nome di tabella.
• 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 condividere cloni superficiali usando OpenSharing.
• Non è possibile annidare cloni superficiali, ovvero non è possibile creare un clone superficiale da un clone superficiale.
• Per le tabelle esterne, DROP TABLE non rimuove i file dati sottostanti, quindi i cloni superficiali non sono interessati quando la tabella sorgente viene abbandonata.
• Per le tabelle gestite in Databricks Runtime 13.3 LTS e superiori, cloni superficiali di una tabella sorgente eliminata continuano a funzionare fino a quando i file di dati sorgente vengono eliminati. Vedi Rimuovere la tabella di base per un clone superficiale.