Replica superficiale per le tabelle del Catalogo Unity

Importante

Questa funzionalità è in Anteprima Pubblica.

Importante

Il supporto dei cloni superficiali è diverso per le tabelle gestite ed esterne di Unity Catalog. Per le tabelle gestite usare Databricks Runtime 13.3 LTS e versioni successive e per le tabelle esterne usare Databricks Runtime 14.3 LTS e versioni successive.

È possibile clonare le tabelle gestite del Unity Catalog solo in altre tabelle gestite del Unity Catalog e le tabelle esterne del Unity Catalog solo in altre tabelle esterne del Unity Catalog. VACUUM il comportamento è diverso tra tabelle gestite ed esterne. Vedi Usa VACUUM con i cloni superficiali di Unity Catalog.

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.

Risorsa Autorizzazioni necessarie
Schema di origine USE SCHEMA
Catalogo di origine USE CATALOG
Schema di destinazione USE SCHEMA, CREATE TABLE
Catalogo obiettivo USE CATALOG

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.

Risorsa Autorizzazioni necessarie
Schema di origine USE SCHEMA
Catalogo di origine USE CATALOG
Schema di destinazione USE SCHEMA, CREATE TABLE
Catalogo obiettivo USE CATALOG
Posizione esterna di destinazione CREATE EXTERNAL TABLE

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:

Risorsa Autorizzazioni necessarie
Catalog USE CATALOG
Schema USE SCHEMA
Table SELECT

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.

Nota

Databricks consiglia di non eseguire VACUUM mai con un'impostazione di conservazione inferiore a 7 giorni per evitare di danneggiare le transazioni a esecuzione prolungata in corso. Se è richiesta una soglia di conservazione inferiore, considera in che modo VACUUM per i cloni superficiali in Unity Catalog differisca da come VACUUM incida sulle altre tabelle clonate in Azure Databricks. Per altre informazioni, vedere Clonare una tabella in Azure Databricks.

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

Se si elimina la tabella di base di un clone superficiale, 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:
    • I cloni superficiali hanno esito negativo sulle operazioni che richiedono la lettura di dati o metadati (ad esempio, SELECT, INSERTUPDATE, DESCRIBE HISTORYCLONE).
    • Per consentire la pulizia, i cloni superficiali sono ancora visibili tramite operazioni a livello di metadati , ad esempio SHOW TABLES, DROP TABLE.

Questo comportamento si applica solo alle tabelle gestite di Unity Catalog. Per altre informazioni, vedere DROP TABLE.

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.
  • 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 gestite, l'eliminazione della tabella di origine interrompe la tabella di destinazione per cloni superficiali. I file di dati sottostanti per le 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 di una tabella di origine eliminata continuano a funzionare per il periodo di 7 giorni durante il quale Unity Catalog supporta UNDROP. Se la tabella di origine non viene ripristinata all'interno di tale finestra, il clone superficiale smette di funzionare quando i file di dati di origine vengono eliminati durante la Garbage Collection.