Clonare un table in Azure Databricks

È possibile creare una copia di un table Delta Lake esistente in Azure Databricks in una versione specifica usando il comando clone. I cloni possono essere profondi o superficiali.

Azure Databricks supporta anche la clonazione di Parquet e Iceberg tables. Vedere clonare in modo incrementale i tables Parquet e Iceberg in Delta Lake.

Per informazioni dettagliate sull'uso di clone con Unity Catalog, vedere clone Shallow per Unity Catalogtables.

Tipi di clonazione

• Un clone profondo è un clone che copia i dati del table di origine nel target del clone, oltre ai metadati del tableesistente. Inoltre, i metadati del flusso vengono clonati in modo che un flusso che scrive nel Delta table possa essere arrestato su un'origine table e continuato sulla destinazione di un clone da where dal punto in cui era stato interrotto.
• Un clone superficiale è un clone che non copia i file di dati nella destinazione di clonazione. I metadati table sono equivalenti all'origine. Questi cloni sono più economici da creare.

I metadati clonati includono: schema, informazioni di partizionamento, invarianti, nullabilità. Solo per i cloni profondi, vengono clonati anche i metadati di flusso e COPY INTO. I metadati non clonati sono la descrizione table e i metadati di commit definiti dall'utente ,.

Qual è la semantica delle operazioni di clonazione Delta?

Se si lavora con un table Delta registrato nel metastore di Hive o una raccolta di file non registrati come table, il clone ha la seguente semantica:

• Tutte le modifiche apportate ai cloni profondi o superficiali influiscono solo sui cloni stessi e non sull'origine table.
• I cloni superficiali fanno riferimento ai file di dati nella directory di origine. Se si esegue vacuum sul tabledi origine, i client non possono più leggere i file di dati referenziati e viene generata una FileNotFoundException. In questo caso, l'esecuzione del clone con sostituzione sul clone superficiale ripristina il clone. Se ciò si verifica spesso, considerare di utilizzare invece un clone completo non dipendente dall'origine table.
• I cloni profondi non dipendono dall'origine da cui sono stati clonati, ma sono costosi da creare perché un clone completo copia i dati e i metadati.
• La clonazione con replace a una destinazione che dispone già di un table in tale percorso crea un log Delta se non ne esiste uno in tale percorso. È possibile pulire tutti i dati esistenti eseguendo vacuum.
• Per il Delta tablesesistente, viene creato un nuovo commit che include i nuovi metadati e i nuovi dati provenienti dall'origine table. Questo nuovo commit è incrementale, ovvero solo le nuove modifiche apportate dall'ultimo clone vengono sottoposte a commit nel table.
• La clonazione di un table non è uguale a Create Table As Select o CTAS. Un clone copia i metadati di origine table oltre ai dati. La clonazione ha anche una sintassi più semplice: non è necessario specificare partizionamento, formato, invarianti, nullabilità e così via poiché vengono ricavati dall'origine table.
• Un table clonato ha una cronologia indipendente dall'origine table. Le interrogazioni di viaggio nel tempo su un table clonato non funzionano con gli stessi input come avviene sul suo originale table.

Sintassi di clonazione di esempio

Gli esempi di codice seguenti illustrano la sintassi per la creazione di cloni profondi e superficiali:

SQL

CREATE TABLE target_table CLONE source_table; -- Create a deep clone of source_table as target_table

CREATE OR REPLACE TABLE target_table CLONE source_table; -- Replace the target

CREATE TABLE IF NOT EXISTS target_table CLONE source_table; -- No-op if the target table exists

CREATE TABLE target_table SHALLOW CLONE source_table;

CREATE TABLE target_table SHALLOW CLONE source_table VERSION AS OF version;

CREATE TABLE target_table SHALLOW CLONE source_table TIMESTAMP AS OF timestamp_expression; -- timestamp can be like “2019-01-01” or like date_sub(current_date(), 1)

Python

from delta.tables import *

deltaTable = DeltaTable.forName(spark, "source_table")

deltaTable.clone(target="target_table", isShallow=True, replace=False) # clone the source at latest version

deltaTable.cloneAtVersion(version=1, target="target_table", isShallow=True, replace=False) # clone the source at a specific version

# clone the source at a specific timestamp such as timestamp="2019-01-01"
deltaTable.cloneAtTimestamp(timestamp="2019-01-01", target="target_table", isShallow=True, replace=False)

Scala

import io.delta.tables._

val deltaTable = DeltaTable.forName(spark, "source_table")

deltaTable.clone(target="target_table", isShallow=true, replace=false) // clone the source at latest version

deltaTable.cloneAtVersion(version=1, target="target_table", isShallow=true, replace=false) // clone the source at a specific version

deltaTable.cloneAtTimestamp(timestamp="2019-01-01", target="target_table", isShallow=true, replace=false) // clone the source at a specific timestamp

Per informazioni dettagliate sulla sintassi, vedere CREATE TABLE CLONE.

Metriche di clonazione

CLONE segnala le metriche seguenti come singolo dataframe di riga al termine dell'operazione:

• source_table_size: dimensioni dell'table di origine clonate in byte.
• source_num_of_files: numero di file nel tabledi origine.
• num_removed_files: Se il table viene sostituito, quanti file vengono rimossi dal tablecorrente?
• num_copied_files: numero di file copiati dall'origine (0 per cloni superficiali).
• removed_files_size: dimensioni in byte dei file che vengono rimossi dal tablecorrente.
• copied_files_size: dimensione in byte dei file copiati nel table.

Autorizzazioni

È necessario configurare le autorizzazioni per il controllo di accesso di Azure Databricks table e per il provider cloud.

Table controllo di accesso

Per i cloni profondi e superficiali sono necessarie le autorizzazioni seguenti:

• SELECT permesso sulla fonte table.
• Se utilizzi CLONE per creare una nuova table, hai bisogno dell'autorizzazione CREATE per il database in cui stai creando il table.
• Se si usa CLONE per sostituire un table, è necessario disporre dell'autorizzazione MODIFY per il table.

Autorizzazioni del provider di servizi cloud

Se è stato creato un clone completo, qualsiasi utente che legge il clone profondo deve avere accesso in lettura alla directory del clone. Per apportare modifiche al clone, gli utenti devono avere accesso in scrittura alla directory del clone.

Se hai creato un clone superficiale, qualsiasi utente che voglia leggere il clone superficiale deve ottenere l'autorizzazione per leggere i file nel tableoriginale, poiché con i cloni superficiali i file di dati rimangono nel table di origine, insieme alla directory del clone. Per apportare modifiche al clone, gli utenti dovranno accedere in scrittura alla directory del clone.

Usare il clone per l'archiviazione dei dati

È possibile usare la copia profonda per mantenere lo stato di un table in un determinato momento per scopi di archiviazione. È possibile sync cloni profondi in modo incrementale per mantenere lo stato aggiornato di un table di origine per il ripristino di emergenza.

-- Every month run
CREATE OR REPLACE TABLE archive_table CLONE my_prod_table

Usare il clone per la riproduzione del modello di Machine Learning

Quando si esegue l'apprendimento automatico, è possibile archiviare una determinata versione di un table in cui è stato eseguito il training di un modello di Machine Learning. I modelli futuri possono essere testati usando questi dati archiviati set.

-- Trained model on version 15 of Delta table
CREATE TABLE model_dataset CLONE entire_dataset VERSION AS OF 15

Utilizzare clone per esperimenti a breve termine su un sistema di produzione table.

Per testare un workflow su un table di produzione senza corrompere il table, è possibile creare facilmente un clone superficiale. In questo modo è possibile eseguire flussi di lavoro arbitrari sul table clonato che contiene tutti i dati di produzione, ma non influisce sui carichi di lavoro di produzione.

-- Perform shallow clone
CREATE OR REPLACE TABLE my_test SHALLOW CLONE my_prod_table;

UPDATE my_test WHERE user_id is null SET invalid=true;
-- Run a bunch of validations. Once happy:

-- This should leverage the update information in the clone to prune to only
-- changed files in the clone if possible
MERGE INTO my_prod_table
USING my_test
ON my_test.user_id <=> my_prod_table.user_id
WHEN MATCHED AND my_test.user_id is null THEN UPDATE *;

DROP TABLE my_test;

Usare clone per eseguire l'override delle proprietà table

Table override delle proprietà sono particolarmente utili per:

• Annotare tables con informazioni sul proprietario o sull'utente quando si condividono i dati con unità aziendali differenti.
• È necessario archiviare la cronologia o il viaggio nel tempo di Delta tables e table. È possibile specificare i periodi di conservazione dei dati e dei log in modo indipendente per l'archivio table. Ad esempio:

SQL

CREATE OR REPLACE TABLE archive_table CLONE prod.my_table
TBLPROPERTIES (
delta.logRetentionDuration = '3650 days',
delta.deletedFileRetentionDuration = '3650 days'
)

Python

dt = DeltaTable.forName(spark, "prod.my_table")
tblProps = {
"delta.logRetentionDuration": "3650 days",
"delta.deletedFileRetentionDuration": "3650 days"
}
dt.clone(target="archive_table", isShallow=False, replace=True, tblProps)

Scala

val dt = DeltaTable.forName(spark, "prod.my_table")
val tblProps = Map(
"delta.logRetentionDuration" -> "3650 days",
"delta.deletedFileRetentionDuration" -> "3650 days"
)
dt.clone(target="archive_table", isShallow = false, replace = true, properties = tblProps)