Een tabel klonen in Azure Databricks

Kloon een Delta Lake- of Apache Iceberg-tabel met behulp van de CLONE opdracht om een onafhankelijke kopie te maken op een specifieke versie. Diepe klonen kopiëren zowel gegevens als metagegevens. Ondiepe klonen kopiëren alleen metagegevens en verwijzen naar de brongegevensbestanden, met minder rekenkracht en opslag dan diepe klonen.

Azure Databricks biedt ook ondersteuning voor het klonen van Parquet- en Apache Iceberg-tabellen. Zie Parquet- en Apache Iceberg-tabellen incrementeel klonen naar Delta Lake en een beheerde Iceberg-tabel klonen.

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

Kloontypen

De volgende kloontypen zijn beschikbaar:

Gekloonde metagegevens omvatten: schema, partitioneringsgegevens, invarianten, null-ability en TBLPROPERTIES. Alleen voor diepe klonen worden zowel de stream als de COPY INTO-metagegevens gekloond. Metagegevens die niet zijn gekloond, zijn de tabelbeschrijving, door de gebruiker gedefinieerde doorvoermetagegevens, delta lake-tabelgeschiedenis en Unity Catalog-eigenschappen, zoals tags.

Meetgegevens 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.

Permissions

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 toestemming voor de brontabel.
• Als u CLONE gebruikt om een nieuwe tabel te maken, heeft u CREATE toestemming nodig voor de database waarin u de tabel maakt.
• Als u CLONE gebruikt om een tabel te vervangen, moet u MODIFY-machtiging hebben op de tabel.

Machtigingen voor cloudproviders

Lezers van een diepe kloon hebben leestoegang nodig tot de map van de kloon. Schrijvers hebben schrijftoegang nodig tot de map van de kloon.

Lezers van een ondiepe kloon moeten leestoegang hebben tot zowel de gegevensbestanden van de brontabel als de map van de kloon, omdat de gegevensbestanden in de bron blijven staan. Schrijvers hebben schrijftoegang nodig tot de map van de kloon.

Examples

Diepe of ondiepe kloons maken

In de volgende codevoorbeelden ziet u hoe u diepe en ondiepe klonen maakt:

SQL

Maak een diepe kloon:

CREATE TABLE target_table CLONE source_table;

Een bestaand doel vervangen:

CREATE OR REPLACE TABLE target_table CLONE source_table;

Maak een diepe kloon of sla over als het doel al bestaat:

CREATE TABLE IF NOT EXISTS target_table CLONE source_table;

Maak een ondiepe kloon bij de laatste versie, bij een specifieke versie of op een specifieke tijdstempel. De tijdstempel kan een datumtekenreeks zijn zoals '2019-01-01' of een expressie zoals 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

De Python-API DeltaTable is specifiek voor Delta Lake.

Kloon de bron in de nieuwste versie:

from delta.tables import *

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

Kloon de broncode bij een specifieke versie:

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

Kloon de bron op een specifieke tijdstempel:

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

Scala

De Scala-API DeltaTable is specifiek voor Delta Lake.

Kloon de bron in de nieuwste versie:

import io.delta.tables._

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

Kloon de broncode bij een specifieke versie:

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

Kloon de bron op een specifieke tijdstempel:

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

Zie CREATE TABLE CLONEvoor syntaxisdetails.

Controleer de metagegevens die zijn gekopieerd tijdens CLONE

In dit voorbeeld ziet u de metagegevens die wel en niet worden gekopieerd tijdens CLONE bewerkingen, met name TBLPROPERTIESUnity Catalog-tags en Delta Lake-geschiedenis.

Maak een brontabel met een aangepaste eigenschap en een niet-standaardperiode voor het bewaren van logboeken en voeg vervolgens gegevens in om tabelgeschiedenis te genereren:

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

Maak een diepe kloon en een ondiepe kloon:

CREATE OR REPLACE TABLE test_clone_deep DEEP CLONE test_clone_source;

CREATE TABLE test_clone_shallow SHALLOW CLONE test_clone_source;

Controleer of TBLPROPERTIES naar beide klonen zijn gekopieerd:

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

Controleer of Unity Catalog-tags niet naar klonen worden gekopieerd:

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

Controleer of de Delta Lake-geschiedenis niet naar klonen is gekopieerd:

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

Opschonen:

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

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.

Voer de volgende opdracht eenmaal per maand uit om het archief te synchroniseren:

CREATE OR REPLACE TABLE archive_table CLONE my_prod_table

ML-modelreproductie

Voor machine learning-gebruiksscenario's wilt u mogelijk een versie van een tabel archiveren die is gebruikt om een ML-model te trainen. Toekomstige modellen kunnen worden getest met behulp van deze gearchiveerde gegevensset. Doe het volgende om een datasetversie te archiveren met CLONE:

Als u bijvoorbeeld de versie van een tabel wilt archiveren die wordt gebruikt voor het trainen van een model op versie 15:

CREATE TABLE model_dataset CLONE entire_dataset VERSION AS OF 15

Korte-termijnexperimenten op een productietabel

Als u een werkstroom in een productietabel wilt testen zonder de tabel te beschadigen, maakt u een ondiepe kloon. Met ondiepe klonen kunt u workloads uitvoeren in de gekloonde tabel, die verwijst naar alle productiegegevens, maar geen invloed heeft op productieworkloads.

Maak een ondiepe kloon van de productietabel:

CREATE TABLE my_test SHALLOW CLONE my_prod_table;

Updates en validaties uitvoeren op de kloon:

UPDATE my_test WHERE user_id is null SET invalid=true;

Wanneer u klaar bent, voegt u wijzigingen weer samen. De samenvoegbewerking maakt gebruik van updategegevens in de kloon om alleen gewijzigde bestanden te verwijderen, indien mogelijk:

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

Verwijder de kloon wanneer u klaar bent:

DROP TABLE my_test;

Tabeleigenschappen overschrijven

Onderdrukkingen van tabeleigenschappen zijn handig voor:

• Aantekeningen toevoegen aan tabellen met eigenaar- of gebruikersgegevens bij het delen van gegevens met verschillende bedrijfseenheden.
• Delta Lake-tabellen archiveren wanneer u tijd nodig hebt voor het archief. U kunt gegevens- en logboekretentieperioden onafhankelijk voor de archieftabel opgeven. Voorbeeld:

SQL

Voor een Delta Lake-tabel:

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

Voor een Iceberg-tabel:

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

Python

De Python DeltaTable-API is Delta Lake-specifiek.

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

De Scala DeltaTable API is specifiek voor Delta Lake.

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)

Gedrag van kloonbewerkingen voor verouderde Hive-metastore

Voor een Delta Lake-tabel die is geregistreerd bij de Hive-metastore of een verzameling bestanden die niet zijn geregistreerd als een tabel, heeft de kloon het volgende gedrag:

• Wijzigingen aan diepe of ondiepe klonen hebben geen invloed op de brontabel.
• Ondiepe klonen verwijzen naar gegevensbestanden in de bronmap. Als u op de brontabel uitvoert VACUUM , kunnen clients deze gegevensbestanden niet meer lezen en dit leidt tot een FileNotFoundException. Voer clone met replace uit op de ondiepe kloon om dit te herstellen. 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 brontabel, maar zijn duur om te maken omdat ze zowel de gegevens als de metagegevens kopiëren.
• Klonen met replace naar een doellocatie die al een tabel op dat pad heeft, maakt een Delta-log aan als die nog niet bestaat. Voer uit VACUUM om bestaande gegevens op te schonen.
• Voor bestaande Delta Lake-tabellen zorgt klonen voor een nieuwe incrementele commit die alleen nieuwe metagegevens en gegevens uit de brontabel bevat sinds de laatste kloon.
• Het klonen van een tabel verschilt van Create Table As Select (CTAS). Een kloon kopieert de metagegevens van de brontabel naast de gegevens. U hoeft geen partitionering, indeling, invarianten, null-ability of andere instellingen op te geven.
• Een gekloonde tabel heeft een onafhankelijke geschiedenis van de brontabel. Query's voor tijdreizen in een gekloonde tabel werken niet met dezelfde invoer als in de brontabel.