Een tabel klonen in Azure Databricks

U kunt met behulp van de clone opdracht een kopie van een bestaande Delta Lake-tabel in Azure Databricks maken op een specifieke versie. Klonen kunnen diep of ondiep zijn.

Azure Databricks biedt ook ondersteuning voor het klonen van Parquet- en Iceberg-tabellen. Zie Incrementeel Parquet- en Iceberg-tabellen klonen naar Delta Lake.

Zie Ondiepe kloon voor Unity Catalog-tabellen voor meer informatie over het gebruik van kloon met Unity Catalog.

Notitie

Databricks raadt aan Delta Sharing te gebruiken om alleen-lezentoegang te bieden tot tabellen in verschillende organisaties. Zie Wat is Delta Sharing?

Kloontypen

• Een diepe kloon is een kloon waarmee de brontabelgegevens worden gekopieerd naar het kloondoel, naast de metagegevens van de bestaande tabel. Daarnaast worden streammetagegevens ook gekloond, zodat een stroom die naar de Delta-tabel schrijft, kan worden gestopt op een brontabel en verder kan worden voortgezet op het doel van een kloon van waaruit deze was gebleven.
• Een ondiepe kloon is een kloon die de gegevensbestanden niet naar het kloondoel kopieert. De metagegevens van de tabel zijn gelijk aan de bron. Deze kloons zijn goedkoper om te maken.

De metagegevens die worden gekloond, omvatten: schema, partitioneringsgegevens, invarianten, nullability. Alleen voor diepe klonen worden stream- en COPY INTO-metagegevens ook gekloond. Metagegevens die niet zijn gekloond, zijn de tabelbeschrijving en door de gebruiker gedefinieerde doorvoermetagegevens.

Wat zijn de semantiek van Delta-kloonbewerkingen?

Als u werkt met een Delta-tabel die is geregistreerd bij de Hive-metastore of als een verzameling bestanden die niet zijn geregistreerd als een tabel, heeft de kloon de volgende semantiek:

Belangrijk

In Databricks Runtime 13.3 LTS en hoger bieden beheerde tabellen van Unity Catalog ondersteuning voor ondiepe klonen. Kloonsemantiek voor Unity Catalog-tabellen verschilt aanzienlijk van delta lake-kloonsemantiek in andere omgevingen. Zie Ondiepe kloon voor Unity Catalog-tabellen.

• Wijzigingen die zijn aangebracht in diepe of ondiepe klonen, hebben alleen invloed op de klonen zelf en niet op de brontabel.
• Ondiepe kloonklonen verwijzen naar gegevensbestanden in de bronmap. Als u op de brontabel uitvoert vacuum , kunnen clients de gegevensbestanden waarnaar wordt verwezen niet meer lezen en wordt er een FileNotFoundException gegenereerd. In dit geval herstelt het uitvoeren van een kloon met vervanging door de ondiepe kloon de kloon. Als dit vaak gebeurt, kunt u overwegen een diepe kloon te gebruiken die niet afhankelijk is van de brontabel.
• Diepe klonen zijn niet afhankelijk van de bron waaruit ze zijn gekloond, maar zijn duur om te maken omdat een diepe kloon de gegevens en de metagegevens kopieert.
• Als u kloont met replace een doel dat al een tabel in dat pad heeft, wordt er een Delta-logboek gemaakt als er geen deltalogboek bestaat op dat pad. U kunt alle bestaande gegevens opschonen door deze uit te voeren vacuum.
• Voor bestaande Delta-tabellen wordt een nieuwe doorvoering gemaakt die de nieuwe metagegevens en nieuwe gegevens uit de brontabel bevat. Deze nieuwe doorvoering is incrementeel, wat betekent dat alleen nieuwe wijzigingen sinds de laatste kloon worden doorgevoerd in de tabel.
• Het klonen van een tabel is niet hetzelfde als Create Table As Select of CTAS. Een kloon kopieert de metagegevens van de brontabel naast de gegevens. Klonen heeft ook een eenvoudigere syntaxis: u hoeft geen partitionering, indeling, invarianten, null-waarde enzovoort op te geven, omdat ze uit de brontabel worden gehaald.
• Een gekloonde tabel heeft een onafhankelijke geschiedenis van de brontabel. Query's voor tijdreizen in een gekloonde tabel werken niet met dezelfde invoer als voor de brontabel.

Voorbeeld van kloonsyntaxis

In de volgende codevoorbeelden ziet u de syntaxis voor het maken van diepe en ondiepe klonen:

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

Zie CREATE TABLE CLONE voor syntaxisdetails.

Metrische gegevens klonen

CLONE rapporteert de volgende metrische gegevens als één rij DataFrame zodra de bewerking is voltooid:

• source_table_size: Grootte van de brontabel die wordt gekloond in bytes.
• source_num_of_files: het aantal bestanden in de brontabel.
• num_removed_files: Als de tabel wordt vervangen, hoeveel bestanden uit de huidige tabel worden verwijderd.
• num_copied_files: Aantal bestanden dat is gekopieerd uit de bron (0 voor ondiepe klonen).
• removed_files_size: Grootte in bytes van de bestanden die uit de huidige tabel worden verwijderd.
• copied_files_size: Grootte in bytes van de bestanden die naar de tabel zijn gekopieerd.

Machtigingen

U moet machtigingen configureren voor toegangsbeheer voor Azure Databricks-tabellen en uw cloudprovider.

Toegangsbeheer voor tabellen

De volgende machtigingen zijn vereist voor zowel diepe als ondiepe klonen:

• SELECT machtiging voor de brontabel.
• Als u CLONE een nieuwe tabel maakt, CREATE moet u toestemming geven voor de database waarin u de tabel maakt.
• Als u CLONE een tabel vervangt, moet u gemachtigd zijn MODIFY voor de tabel.

Machtigingen voor cloudproviders

Als u een diepe kloon hebt gemaakt, moet elke gebruiker die de diepe kloon leest leestoegang hebben tot de map van de kloon. Als u wijzigingen wilt aanbrengen in de kloon, moeten gebruikers schrijftoegang hebben tot de map van de kloon.

Als u een ondiepe kloon hebt gemaakt, moet elke gebruiker die de ondiepe kloon leest, toestemming nodig om de bestanden in de oorspronkelijke tabel te lezen, omdat de gegevensbestanden in de brontabel met ondiepe klonen blijven staan, evenals de map van de kloon. Als u wijzigingen wilt aanbrengen in de kloon, moeten gebruikers schrijftoegang hebben tot de map van de kloon.

Kloon gebruiken voor gegevensarchivering

U kunt diepe kloon gebruiken om de status van een tabel op een bepaald moment te behouden voor archiveringsdoeleinden. U kunt diepe kloons incrementeel synchroniseren om een bijgewerkte status van een brontabel te behouden voor herstel na noodgevallen.

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

Kloon gebruiken voor reproductie van ML-modellen

Wanneer u machine learning uitvoert, wilt u mogelijk een bepaalde versie van een tabel archiveren waarop u een ML-model hebt getraind. Toekomstige modellen kunnen worden getest met behulp van deze gearchiveerde gegevensset.

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

Kloon gebruiken voor kortetermijnexperimenten in een productietabel

Als u een werkstroom op een productietabel wilt testen zonder de tabel te beschadigen, kunt u eenvoudig een ondiepe kloon maken. Hiermee kunt u willekeurige werkstromen uitvoeren in de gekloonde tabel die alle productiegegevens bevat, maar die geen invloed heeft op productieworkloads.

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

Kloon gebruiken om tabeleigenschappen te overschrijven

Onderdrukkingen van tabeleigenschappen zijn met name handig voor:

• Aantekeningen toevoegen aan tabellen met eigenaar- of gebruikersgegevens bij het delen van gegevens met verschillende bedrijfseenheden.
• Het archiveren van Delta-tabellen en tabelgeschiedenis of tijdreizen is vereist. U kunt de gegevens- en logboekretentieperioden onafhankelijk voor de archieftabel opgeven. Voorbeeld:

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)