Klona en tabell i Azure Databricks

Klona en Delta Lake- eller Apache Iceberg-tabell med hjälp av CLONE kommandot för att skapa en oberoende kopia i en viss version. Djupa kloner kopierar både data och metadata. Grunda kloner kopierar endast metadata och refererar till källdatafilerna med mindre beräkning och lagring än djupa kloner.

Azure Databricks stöder också kloning av Parquet- och Apache Iceberg-tabeller. Se Klona Parquet- och Apache Iceberg-tabeller stegvis till Delta Lake och Klona en hanterad Iceberg-tabell.

För mer information om hur du använder kloningsfunktionen i Unity Catalog, se Ytklon för Unity Catalog-tabeller.

Klontyper

Följande klontyper är tillgängliga:

Klonade metadata omfattar: schema, partitioneringsinformation, invarianter, nullability och TBLPROPERTIES. Endast för djupa kloner klonas också dataström och COPY INTO-metadata. Metadata som inte klonas är tabellbeskrivningen, användardefinierade incheckningsmetadata, Delta Lake-tabellhistorik och Unity Catalog-egenskaper, till exempel taggar.

Klona metrik

CLONE rapporterar följande mått som en dataram på en rad när åtgärden är klar:

• source_table_size: Storleken på källtabellen som klonas i byte.
• source_num_of_files: Antalet filer i källtabellen.
• num_removed_files: Om tabellen ersätts, hur många filer som tas bort från den aktuella tabellen.
• num_copied_files: Antal filer som kopierades från källan (0 för grunda kloner).
• removed_files_size: Storlek i byte för de filer som tas bort från den aktuella tabellen.
• copied_files_size: Storlek i byte för de filer som kopierats till tabellen.

Permissions

Du måste konfigurera behörigheter för åtkomstkontroll för Azure Databricks-tabeller och din molnleverantör.

Åtkomstkontroll för tabeller

Följande behörigheter krävs för både djupa och grunda kloner:

• SELECT behörighet för källtabellen.
• Om du använder CLONE för att skapa en ny tabell, CREATE behörighet på databasen där du skapar tabellen.
• Om du använder CLONE för att ersätta en tabell måste du ha MODIFY behörighet för tabellen.

Behörigheter för molnleverantör

Användare som läser en djupklon behöver läsåtkomst till klonens katalog. Författare behöver skrivåtkomst till klonens katalog.

Läsare av en ytlig klon behöver läsåtkomst till både källtabellens datafiler och klonens katalog, eftersom datafilerna finns kvar i källan. Författare behöver skrivåtkomst till klonens katalog.

Examples

Skapa djupa eller grunda kloner

Följande kodexempel visar hur du skapar djupa och grunda kloner:

SQL

Skapa en djupkopiering:

CREATE TABLE target_table CLONE source_table;

Ersätt ett befintligt mål:

CREATE OR REPLACE TABLE target_table CLONE source_table;

Skapa en djup klon eller hoppa över om målet redan finns:

CREATE TABLE IF NOT EXISTS target_table CLONE source_table;

Skapa en ytlig klon vid den senaste versionen, vid en viss version eller vid en viss tidsstämpel. Tidsstämpeln kan vara en datumsträng som '2019-01-01' eller ett uttryck som date_sub(current_date(), 1).

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;

Python

PYTHON DeltaTable API:et är specifikt för Delta Lake.

Klona källan i den senaste versionen:

from delta.tables import *

deltaTable = DeltaTable.forName(spark, "source_table")
deltaTable.clone(target="target_table", isShallow=True, replace=False)

Klona källan i en viss version:

deltaTable.cloneAtVersion(version=1, target="target_table", isShallow=True, replace=False)

Klona källan vid en viss tidsstämpel:

deltaTable.cloneAtTimestamp(timestamp="2019-01-01", target="target_table", isShallow=True, replace=False)

Scala

Scala-API DeltaTable :et är specifikt för Delta Lake.

Klona källan i den senaste versionen:

import io.delta.tables._

val deltaTable = DeltaTable.forName(spark, "source_table")
deltaTable.clone(target="target_table", isShallow=true, replace=false)

Klona källan i en viss version:

deltaTable.cloneAtVersion(version=1, target="target_table", isShallow=true, replace=false)

Klona källan vid en viss tidsstämpel:

deltaTable.cloneAtTimestamp(timestamp="2019-01-01", target="target_table", isShallow=true, replace=false)

Syntaxinformation finns i CREATE TABLE CLONE.

Kontrollera metadata som kopierats under CLONE

Det här exemplet visar vilka metadata som kopieras och inte kopieras vid CLONE-åtgärder, särskilt TBLPROPERTIES, Unity Catalog-taggar och Delta Lake-historik.

Skapa en källtabell med en anpassad egenskap och en varaktighet för loggkvarhållning som inte är standard och infoga sedan data för att generera tabellhistorik:

CREATE OR REPLACE TABLE test_clone_source (id INT, val STRING)
TBLPROPERTIES ('my.custom.prop' = 'hello', 'delta.logRetentionDuration' = '12 days');

ALTER TABLE test_clone_source SET TAGS ('team' = 'data-eng', 'env' = 'prod');
INSERT INTO test_clone_source VALUES (1, 'a');
INSERT INTO test_clone_source VALUES (2, 'b');

Skapa en djup klon och en ytlig klon:

CREATE OR REPLACE TABLE test_clone_deep DEEP CLONE test_clone_source;

CREATE TABLE test_clone_shallow SHALLOW CLONE test_clone_source;

Bekräfta att TBLPROPERTIES kopieras till båda klonerna:

SHOW TBLPROPERTIES test_clone_source;
SHOW TBLPROPERTIES test_clone_deep;
SHOW TBLPROPERTIES test_clone_shallow;

Bekräfta att Unity Catalog-taggar inte kopieras till kloner:

SELECT catalog_name, schema_name, table_name, tag_name, tag_value FROM information_schema.table_tags WHERE table_name = 'test_clone_source';
SELECT catalog_name, schema_name, table_name, tag_name, tag_value FROM information_schema.table_tags WHERE table_name = 'test_clone_deep';
SELECT catalog_name, schema_name, table_name, tag_name, tag_value FROM information_schema.table_tags WHERE table_name = 'test_clone_shallow';

Bekräfta att Delta Lake-historiken inte kopieras till kloner:

DESCRIBE HISTORY test_clone_source;
DESCRIBE HISTORY test_clone_deep;
DESCRIBE HISTORY test_clone_shallow;

Rensa:

DROP TABLE IF EXISTS test_clone_shallow;
DROP TABLE IF EXISTS test_clone_source;
DROP TABLE IF EXISTS test_clone_deep;

Dataarkivering

Du kan använda djupkloning för att bevara tillståndet för en tabell vid en viss tidpunkt i arkiveringssyfte. Du kan synkronisera djupa kloner inkrementellt för att upprätthålla ett uppdaterat tillstånd för en källtabell för katastrofåterställning.

Kör följande kommando en gång i månaden för att synkronisera arkivet:

CREATE OR REPLACE TABLE archive_table CLONE my_prod_table

ML-modellreproduktion

För användningsfall för maskininlärning kanske du vill arkivera en version av en tabell som användes för att träna en ML-modell. Framtida modeller kan testas med den här arkiverade datamängden. Om du vill arkivera en datamängdsversion med CLONEgör du följande:

Om du till exempel vill arkivera versionen av en tabell som används för att träna en modell i version 15:

CREATE TABLE model_dataset CLONE entire_dataset VERSION AS OF 15

Kortsiktiga experiment i en produktionstabell

Om du vill testa ett arbetsflöde i en produktionstabell utan att skada tabellen skapar du en ytlig klon. Med grunda kloner kan du köra arbetsbelastningar i den klonade tabellen, som refererar till alla produktionsdata, men som inte påverkar några produktionsarbetsbelastningar.

Skapa en ytlig klon av produktionstabellen:

CREATE TABLE my_test SHALLOW CLONE my_prod_table;

Kör uppdateringar och valideringar på klonen:

UPDATE my_test WHERE user_id is null SET invalid=true;

När du är klar, sammanfoga ändringarna tillbaka. Sammanfogningen använder uppdateringsinformation i klonen för att rensa till endast ändrade filer där det är möjligt:

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 *;

Ta bort klonen när du är klar:

DROP TABLE my_test;

Åsidosätt tabellegenskaper

Åsidosättningar av tabellegenskaper är användbara för:

• Kommentera tabeller med ägar- eller användarinformation när du delar data med olika affärsenheter.
• Arkivera Delta Lake-tabeller när du behöver tidsresor i arkivet. Du kan ange data- och loggkvarhållningsperioder oberoende av varandra för arkivtabellen. Ett exempel:

SQL

För en Delta Lake-tabell:

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

För en Iceberg-tabell:

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

Python

Python DeltaTable-API:et är Delta Lake-specifikt.

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

Scala DeltaTable-API:et är Delta Lake-specifikt.

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)

Klonåtgärdsbeteende för äldre Hive-metaarkiv

För en Delta Lake-tabell som är registrerad i Hive-metaarkivet eller en samling filer som inte har registrerats som en tabell har klon följande beteenden:

• Ändringar i djupa eller grunda kloner påverkar inte källtabellen.
• Ytliga kloner refererar till datafiler i källkatalogen. Om du kör VACUUM i källtabellen kan klienterna inte längre läsa dessa datafiler och detta genererar en FileNotFoundException. Du kan reparera genom att köra klon med replace på den grunda klonen. Om detta händer ofta bör du överväga att använda en djup klon, som inte är beroende av källtabellen.
• Djupa kloner är inte beroende av källtabellen men är dyra att skapa eftersom de kopierar både data och metadata.
• Att klona med replace till ett mål där det redan finns en tabell på den sökvägen skapar en Delta-logg om det inte redan finns någon. Kör VACUUM för att rensa befintliga data.
• För befintliga Delta Lake-tabeller skapar kloning en ny inkrementell ändring som endast omfattar nya metadata och data från källtabellen sedan den senaste kloningen.
• Kloning av en tabell skiljer sig från Create Table As Select (CTAS). En klon kopierar källtabellens metadata utöver data. Du behöver inte ange partitionering, format, invarianter, nullability eller andra inställningar.
• En klonad tabell har en oberoende historik från källtabellen. Frågor om tidsresor i en klonad tabell fungerar inte med samma indata som i källtabellen.