Klonen einer Tabelle in Azure Databricks

Mit dem Befehl clone können Sie eine Kopie einer vorhandenen Delta Lake-Tabelle in Azure Databricks mit einer bestimmten Version erstellen. Klone können entweder tief oder flach sein.

Azure Databricks unterstützt auch das Klonen von Parquet- und Iceberg-Tabellen. Siehe Inkrementelles Klonen von Parquet- und Iceberg-Tabellen zu Delta Lake.

Ausführliche Informationen zur Verwendung eines Klons mit Unity Catalog finden Sie unter Flache Klone für Unity Catalog-Tabellen.

Hinweis

Databricks empfiehlt die Verwendung von Delta Sharing, um schreibgeschützten Zugriff auf Tabellen in unterschiedlichen Organisationen bereitzustellen. Weitere Informationen unter Sicheres Freigeben von Daten und KI-Ressourcen mithilfe von Delta Sharing.

Klontypen

• Ein tiefer Klon ist ein Klon, der die Quelltabellendaten – zusätzlich zu den Metadaten der vorhandenen Tabelle – in das Klonziel kopiert. Darüber hinaus werden Stream-Metadaten auch so geklont, dass ein Stream, der in die Delta-Tabelle schreibt, für eine Quelltabelle beendet und auf dem Ziel des Klons fortgesetzt werden kann, von dem aus er unterbrochen wurde.
• Ein flacher Klon ist ein Klon, der die Datendateien nicht in das Klonziel kopiert. Die Tabellen-Metadaten entsprechen der Quelle. Diese Klone lassen sich kostengünstiger erstellen.

Zu den geklonten Metadaten gehören: Schema, Partitionierungsinformationen, Invarianten, NULL-Zulässigkeit. Nur bei tiefen Klonen werden „stream“- und COPY INTO-Metadaten ebenfalls geklont. Nicht geklonte Metadaten sind die Tabellenbeschreibung und benutzerdefinierte Commit-Metadaten.

Wie sieht die Semantik von Delta-Klonvorgängen aus?

Wenn Sie mit einer Delta-Tabelle, die im Hive-Metastore registriert ist, oder mit einer Sammlung von Dateien arbeiten, die nicht als Tabelle registriert sind, hat der Klon die folgende Semantik:

Wichtig

In Databricks Runtime 13.3 LTS und höher verfügen verwaltete Unity Catalog-Tabellen über Unterstützung für unechte Klone. Die Klonsemantik für Unity Catalog-Tabellen unterscheidet sich erheblich von der Delta Lake-Klonsemantik in anderen Umgebungen. Weitere Informationen finden Sie unter Flache Klone für verwaltete Unity Catalog-Tabellen.

• An tiefen oder flachen Klonen vorgenommene Änderungen wirken sich nur auf die Klone selbst und nicht auf die Quelltabelle aus.
• Flache Klone verweisen auf Datendateien im Quellverzeichnis. Wenn Sie vacuum für die Quelltabelle ausführen, können Clients die Datendateien, auf die verwiesen wird, nicht mehr lesen, und eine Ausnahme des Typs FileNotFoundException (Datei nicht gefunden) wird ausgelöst. In diesem Fall repariert das Ausführen des Klons mit einer Ersetzung des unechten Klons den Klon. Wenn das oft vorkommt, sollten Sie stattdessen einen tiefen Klon verwenden, der von der Quelltabelle nicht abhängig ist.
• Tiefe Klone sind nicht abhängig von der Quelle, aus der sie geklont wurden. Ihre Erstellung ist aber teuer, weil ein tiefer Klon die Daten sowie die Metadaten kopiert.
• Beim Klonen mit replace zu einem Ziel, an dem es bereits eine Tabelle unter diesem Pfad gibt, wird ein Delta-Protokoll erstellt, wenn unter diesem Pfad noch keins vorhanden ist. Sie können alle vorhandenen Daten bereinigen, indem Sie vacuum ausführen.
• Für vorhandene Delta-Tabellen wird ein neuer Commit erstellt, der die neuen Metadaten und neuen Daten aus der Quelltabelle enthält. Dieser neue Commit ist inkrementell, das heißt, es werden nur neue Änderungen seit dem letzten Klon in die Tabelle committet.
• Das Klonen einer Tabelle ist nicht identisch mit Create Table As Select oder CTAS. Ein Klon kopiert die Metadaten der Quelltabelle zusätzlich zu den Daten. Das Klonen bietet auch eine einfachere Syntax: Sie müssen keine Partitionierung, kein Format, keine Invarianten, keine NULL-Zulässigkeit usw. angeben, da diese Werte aus der Quelltabelle entnommen werden.
• Eine geklonte Tabelle hat einen unabhängigen Verlauf gegenüber ihrer Quelltabelle. Zeitreiseabfragen für eine geklonte Tabelle funktionieren nicht mit denselben Eingaben wie bei deren Quelltabelle.

Beispiel für Klonsyntax

Die folgenden Codebeispiele veranschaulichen die Syntax zum Erstellen von tiefen und flachen Klonen:

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

Details zur Syntax finden Sie unter CREATE TABLE CLONE.

Klonmetriken

CLONE meldet die folgenden Metriken als einzeiligen Datenrahmen (DataFrame), sobald der Vorgang abgeschlossen ist:

• source_table_size: Größe in Bytes der zurzeit geklonten Quelltabelle.
• source_num_of_files: Anzahl von Dateien in der Quelltabelle.
• num_removed_files: Gibt an, wie viele Dateien bei einer Ersetzung der Tabelle aus der aktuellen Tabelle entfernt werden.
• num_copied_files: Anzahl von Dateien, die aus der Quelle kopiert wurden („0“ für flache Klone).
• removed_files_size: Größe in Bytes der Dateien, die aus der aktuellen Tabelle entfernt werden.
• copied_files_size: Größe in Bytes der in die Tabelle kopierten Dateien.

Berechtigungen

Sie müssen Berechtigungen für Azure Databricks-Tabellenzugriffssteuerung und Ihren Cloudanbieter konfigurieren.

Zugriffssteuerung für Tabellen

Die folgenden Berechtigungen sind sowohl für tiefe als auch für flache Klone erforderlich:

• SELECT-Berechtigung für die Quelltabelle.
• Wenn Sie mithilfe von CLONE eine neue Tabelle erstellen, müssen Sie CREATE-Berechtigung für die Datenbank haben, in der Sie die Tabelle erstellen.
• Wenn Sie mithilfe von CLONE eine Tabelle ersetzen, müssen Sie MODIFY-Berechtigung für die Tabelle haben.

Cloudanbieterberechtigungen

Wenn Sie einen tiefen Klon erstellt haben, muss jeder Benutzer, der diesen Klon liest, Lesezugriff auf dessen Verzeichnis haben. Um Änderungen am Klon vornehmen zu können, müssen Benutzer Schreibzugriff auf dessen Verzeichnis haben.

Wenn Sie einen flachen Klon erstellt haben, benötigt jeder Benutzer, der diesen Klon liest, die Berechtigung zum Lesen der Dateien in der ursprünglichen Tabelle, da die Datendateien in der Quelltabelle mit flachen Klonen sowie im Verzeichnis des Klons verbleiben. Um Änderungen am Klon vornehmen zu können, benötigen Benutzer Schreibzugriff auf dessen Verzeichnis.

Verwenden des Klons für die Datenarchivierung

Sie können einen tiefen Klon erstellen, um den Zustand einer Tabelle zu einem bestimmten Zeitpunkt für Archivierungszwecke beizubehalten. Sie können tiefe Klone inkrementell synchronisieren, um einen aktualisierten Zustand einer Quelltabelle für die Notfallwiederherstellung beizubehalten.

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

Verwenden des Klons für die ML-Modellreplizierung

Bei der Durchführung von maschinellem Lernen möchten Sie möglicherweise eine bestimmte Version einer Tabelle archivieren, für die Sie ein ML-Modell trainiert haben. Zukünftige Modelle können mithilfe dieses archivierten Datasets getestet werden.

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

Verwenden des Klons für kurzfristige Experimente bei einer Produktionstabelle

Wenn Sie einen Workflow bei einer Produktionstabelle testen möchten, ohne die Tabelle zu beschädigen, können Sie auf einfache Weise einen flachen Klon erstellen. Dadurch können Sie beliebige Workflows bei der geklonten Tabelle ausführen, die alle Produktionsdaten enthält, sich aber nicht auf Produktionsworkloads auswirkt.

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

Verwenden des Klons zum Außerkraftsetzen von Tabelleneigenschaften

Hinweis

Verfügbar in Databricks Runtime 7.5 und höher.

Außerkraftsetzungen von Tabelleneigenschaften sind für Folgendes besonders nützlich:

• Kommentieren von Tabellen mit Besitzer- oder Benutzerinformationen bei der Freigabe von Daten für verschiedene Geschäftseinheiten.
• Die Archivierung von Delta-Tabellen und Tabellenverlauf oder Zeitreise ist erforderlich. Sie können die Daten- und Protokollaufbewahrungsdauer unabhängig für die Archivtabelle angeben. Beispiel:

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)