Klona en tabell i Azure Databricks

  • Artikel

Du kan skapa en kopia av en befintlig Delta Lake-tabell i Azure Databricks i en viss version med hjälp av clone kommandot . Kloner kan vara antingen djupa eller grunda.

Azure Databricks stöder också kloning av Parquet- och Iceberg-tabeller. Se Stegvis klona parquet- och isbergstabeller till Delta Lake.

Mer information om hur du använder klon med Unity Catalog finns i Shallow clone for Unity Catalog tables (Grund klon för Unity Catalog-tabeller).

Kommentar

Databricks rekommenderar att deltadelning används för att ge skrivskyddad åtkomst till tabeller i olika organisationer. Se Dela data och AI-tillgångar på ett säkert sätt med deltadelning.

Klontyper

  • En djup klon är en klon som kopierar källtabelldata till klonmålet utöver metadata för den befintliga tabellen. Dessutom klonas även dataströmmetadata så att en ström som skriver till Delta-tabellen kan stoppas i en källtabell och fortsätta på målet för en klon där den slutade.
  • En ytlig klon är en klon som inte kopierar datafilerna till klonmålet. Tabellmetadata motsvarar källan. Dessa kloner är billigare att skapa.

Metadata som klonas innehåller: schema, partitioneringsinformation, invarianter, nullabilitet. Endast för djupa kloner klonas även dataströmmen och COPY INTO-metadata . Metadata som inte klonas är tabellbeskrivningen och användardefinierade incheckningsmetadata.

Vad är semantiken för deltaklonåtgärder?

Om du har arbetat med en Delta-tabell som är registrerad i Hive-metaarkivet eller en samling filer som inte har registrerats som en tabell, har klon följande semantik:

Viktigt!

I Databricks Runtime 13.3 LTS och senare har hanterade Unity Catalog-tabeller stöd för grunda kloner. Klonsemantik för Unity Catalog-tabeller skiljer sig avsevärt från Delta Lake-klonsemantik i andra miljöer. Se Ytlig klon för Unity Catalog-tabeller.

  • Ändringar som görs i antingen djupa eller grunda kloner påverkar endast själva klonerna och inte källtabellen.
  • Grunda kloner refererar till datafiler i källkatalogen. Om du kör vacuum på källtabellen kan klienterna inte längre läsa de refererade datafilerna och en FileNotFoundException genereras. I det här fallet repareras klonen genom att köra klonen med ersätt över den grunda klonen. Om detta inträffar ofta bör du överväga att använda en djupkloning i stället som inte är beroende av källtabellen.
  • Djupa kloner beror inte på vilken källa de klonades från, men det är dyrt att skapa eftersom en djup klon kopierar data och metadata.
  • Kloning med replace till ett mål som redan har en tabell på den sökvägen skapar en Delta-logg om en inte finns på den sökvägen. Du kan rensa befintliga data genom att köra vacuum.
  • För befintliga Delta-tabeller skapas en ny incheckning som innehåller nya metadata och nya data från källtabellen. Den här nya incheckningen är inkrementell, vilket innebär att endast nya ändringar sedan den senaste klonen checkas in i tabellen.
  • Kloning av en tabell är inte samma som Create Table As Select eller CTAS. En klon kopierar metadata för källtabellen utöver data. Kloning har också enklare syntax: du behöver inte ange partitionering, format, invarianter, nullabilitet och så vidare när de hämtas från källtabellen.
  • En klonad tabell har en oberoende historik från källtabellen. Tidsresefrågor i en klonad tabell fungerar inte med samma indata som de fungerar i källtabellen.

Exempel på klonningssyntax

Följande kodexempel visar syntax för att skapa djupa och grunda kloner:

SQL

CREATE TABLE delta.`/data/target/` CLONE delta.`/data/source/` -- Create a deep clone of /data/source at /data/target

CREATE OR REPLACE TABLE db.target_table CLONE db.source_table -- Replace the target

CREATE TABLE IF NOT EXISTS delta.`/data/target/` CLONE db.source_table -- No-op if the target table exists

CREATE TABLE db.target_table SHALLOW CLONE delta.`/data/source`

CREATE TABLE db.target_table SHALLOW CLONE delta.`/data/source` VERSION AS OF version

CREATE TABLE db.target_table SHALLOW CLONE delta.`/data/source` 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.forPath(spark, "/path/to/table")  # path-based tables, or
deltaTable = DeltaTable.forName(spark, "source_table")    # Hive metastore-based tables

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.forPath(spark, "/path/to/table")
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

Syntaxinformation finns i SKAPA TABELLKLONING.

Klona mått

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.

Exempel på kloningsmått

Behörigheter

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 i 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

Om du har skapat en djup klon måste alla användare som läser den djupa klonen ha läsbehörighet till klonens katalog. Om du vill göra ändringar i klonen måste användarna ha skrivåtkomst till klonens katalog.

Om du har skapat en ytlig klon behöver alla användare som läser den grunda klonen behörighet att läsa filerna i den ursprungliga tabellen, eftersom datafilerna finns kvar i källtabellen med grunda kloner samt klonens katalog. För att göra ändringar i klonen behöver användarna skrivåtkomst till klonens katalog.

Använda klon för 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 stegvis för att upprätthålla ett uppdaterat tillstånd för en källtabell för haveriberedskap.

-- Every month run
CREATE OR REPLACE TABLE delta.`/some/archive/path` CLONE my_prod_table

Använda klon för ML-modellreproduktion

När du gör maskininlärning kanske du vill arkivera en viss version av en tabell som du har tränat en ML-modell på. Framtida modeller kan testas med den här arkiverade datauppsättningen.

-- Trained model on version 15 of Delta table
CREATE TABLE delta.`/model/dataset` CLONE entire_dataset VERSION AS OF 15

Använda klon för kortsiktiga experiment i en produktionstabell

Om du vill testa ett arbetsflöde i en produktionstabell utan att skada tabellen kan du enkelt skapa en ytlig klon. På så sätt kan du köra godtyckliga arbetsflöden i den klonade tabellen som innehåller alla produktionsdata, men som inte påverkar några produktionsarbetsbelastningar.

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

Använda klon för att åsidosätta tabellegenskaper

Kommentar

Tillgänglig i Databricks Runtime 7.5 och senare.

Åsidosättningar av tabellegenskap är särskilt användbara för:

  • Kommentera tabeller med ägar- eller användarinformation när du delar data med olika affärsenheter.
  • Arkivering av Delta-tabeller och tabellhistorik eller tidsresor krävs. Du kan ange data- och loggkvarhållningsperioder oberoende av varandra för arkivtabellen. Till exempel:

SQL

CREATE OR REPLACE TABLE archive.my_table CLONE prod.my_table
TBLPROPERTIES (
delta.logRetentionDuration = '3650 days',
delta.deletedFileRetentionDuration = '3650 days'
)
LOCATION 'xx://archive/my_table'

Python

dt = DeltaTable.forName(spark, "prod.my_table")
tblProps = {
"delta.logRetentionDuration": "3650 days",
"delta.deletedFileRetentionDuration": "3650 days"
}
dt.clone('xx://archive/my_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("xx://archive/my_table", isShallow = false, replace = true, properties = tblProps)