Sdílet prostřednictvím


Klonování tabulky v Azure Databricks

Pomocí příkazu můžete vytvořit kopii existující tabulky Delta Lake v Azure Databricks v konkrétní verzi clone . Klony můžou být hluboké nebo mělké.

Azure Databricks podporuje také klonování tabulek Parquet a Iceberg. Podívejte se na přírůstkové klonování tabulek Parquet a Iceberg do Delta Lake.

Podrobnosti o použití klonování s katalogem Unity naleznete v tématu Mělké klonování pro tabulky katalogu Unity.

Poznámka:

Databricks doporučuje používat funkci Delta Sharing k poskytování přístupu k tabulkám jen pro čtení v různých organizacích. Informace o bezpečném sdílení dat a prostředků umělé inteligence pomocí rozdílového sdílení

Klonování typů

  • Přímý klon je klon, který kromě metadat existující tabulky kopíruje data zdrojové tabulky do cíle klonování. Metadata datových proudů jsou také klonována tak, aby datový proud, který zapisuje do tabulky Delta, mohl být zastaven ve zdrojové tabulce a pokračoval v cíli klonu, odkud skončil.
  • Mělký klon je klon, který nekopíruje datové soubory do cíle klonu. Metadata tabulky jsou ekvivalentní zdroji. Tyto klony jsou levnější k vytvoření.

Metadata klonovaná zahrnují: schéma, informace o dělení, invarianty a nulovost. Pouze pro hluboké klony se naklonují také metadata STREAM a COPY INTO . Metadata, která nejsou naklonována, jsou popis tabulky a uživatelsky definovaná metadata potvrzení.

Jaké jsou sémantika operací klonování Delta?

Pokud pracujete s tabulkou Delta zaregistrovanou v metastoru Hive nebo kolekcí souborů, které nejsou zaregistrované jako tabulka, klon má následující sémantiku:

Důležité

Ve službě Databricks Runtime 13.3 LTS a novějších spravovaných tabulkách Katalogu Unity podporují pro mělké klony. Sémantika klonování pro tabulky katalogu Unity se výrazně liší od sémantiky klonování Delta Lake v jiných prostředích. Viz "Mělké klonování" pro tabulky katalogu Unity.

  • Jakékoli změny provedené v hlubokých nebo mělkých klonech ovlivní pouze samotné klony, nikoli zdrojovou tabulku.
  • Mělké klony odkazují na datové soubory ve zdrojovém adresáři. Pokud spustíte vacuum zdrojovou tabulku, klienti už nebudou moct číst odkazované datové soubory a FileNotFoundException vyvolá se. V tomto případě spuštění klonu s nahrazením nad mělkým klonem opraví klon. Pokud k tomu dochází často, zvažte použití hloubkového klonu, který nezávisí na zdrojové tabulce.
  • Hloubkové klony nezávisí na zdroji, ze kterého byly klonovány, ale jejich vytvoření je nákladné, protože přímý klon kopíruje data i metadata.
  • Klonování s replace cílem, který již obsahuje tabulku na této cestě, vytvoří protokol Delta, pokud na této cestě neexistuje. Spuštěním příkazu vacuummůžete vyčistit všechna existující data.
  • Pro existující tabulky Delta se vytvoří nové potvrzení, které obsahuje nová metadata a nová data ze zdrojové tabulky. Toto nové potvrzení je přírůstkové, což znamená, že do tabulky jsou potvrzeny pouze nové změny od posledního klonování.
  • Klonování tabulky není stejné jako Create Table As Select nebo CTAS. Klon zkopíruje metadata zdrojové tabulky kromě dat. Klonování má také jednodušší syntaxi: nemusíte zadávat dělení, formát, invarianty, nulovost atd., protože jsou převzaty ze zdrojové tabulky.
  • Klonovaná tabulka má nezávislou historii ze zdrojové tabulky. Dotazy na časovou cestu na klonované tabulce nefungují se stejnými vstupy jako u zdrojové tabulky.

Příklad syntaxe klonování

Následující příklady kódu ukazují syntaxi pro vytváření hlubokých a mělkých klonů:

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

Podrobnosti o syntaxi najdete v tématu VYTVOŘENÍ KLONOVÁNÍ TABULKY.

Klonování metrik

CLONE Po dokončení operace sestaví následující metriky jako datový rámec s jedním řádkem:

  • source_table_size: Velikost zdrojové tabulky, která se klonuje v bajtech.
  • source_num_of_files: Počet souborů ve zdrojové tabulce.
  • num_removed_files: Pokud se tabulka nahrazuje, kolik souborů se z aktuální tabulky odebere.
  • num_copied_files: Počet souborů, které byly zkopírovány ze zdroje (0 pro mělké klony).
  • removed_files_size: Velikost v bajtech souborů, které jsou odebrány z aktuální tabulky.
  • copied_files_size: Velikost v bajtech souborů zkopírovaných do tabulky.

Příklad klonování metrik

Oprávnění

Musíte nakonfigurovat oprávnění pro řízení přístupu k tabulce Azure Databricks a poskytovatele cloudu.

Řízení přístupu k tabulkám

Pro hluboké i mělké klony jsou vyžadována následující oprávnění:

  • SELECT oprávnění ke zdrojové tabulce.
  • Pokud k vytvoření nové tabulky používáte CLONE , oprávnění k databázi, CREATE ve které vytváříte tabulku.
  • Pokud k nahrazení tabulky používáte CLONE , musíte mít MODIFY oprávnění k tabulce.

Oprávnění poskytovatele cloudu

Pokud jste vytvořili přímý klon, musí mít každý uživatel, který čte hluboké klony, přístup pro čtení k adresáři klonu. Aby uživatelé mohli provádět změny klonu, musí mít přístup k zápisu do adresáře klonu.

Pokud jste vytvořili mělký klon, musí každý uživatel, který přečte mělký klon, oprávnění ke čtení souborů v původní tabulce, protože datové soubory zůstávají ve zdrojové tabulce s mělkými klony a adresářem klonu. Aby uživatelé mohli provádět změny klonu, budou potřebovat přístup k zápisu do adresáře klonu.

Použití klonování pro archivaci dat

Pomocí hloubkového klonování můžete zachovat stav tabulky v určitém časovém okamžiku pro účely archivace. Hloubkové klony můžete synchronizovat přírůstkově, aby se zachoval aktualizovaný stav zdrojové tabulky pro zotavení po havárii.

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

Použití klonování pro reprodukci modelu ML

Při strojovém učení můžete chtít archivovat určitou verzi tabulky, na které jste vytrénovali model ML. Budoucí modely je možné testovat pomocí této archivované datové sady.

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

Použití klonování pro krátkodobé experimenty v produkční tabulce

Pokud chcete otestovat pracovní postup v produkční tabulce bez poškození tabulky, můžete snadno vytvořit mělký klon. To umožňuje spouštět libovolné pracovní postupy v klonované tabulce, která obsahuje všechna produkční data, ale nemá vliv na žádné produkční úlohy.

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

Přepsání vlastností tabulky pomocí klonování

Poznámka:

K dispozici ve službě Databricks Runtime 7.5 a novějších.

Přepsání vlastností tabulky je zvlášť užitečné pro:

  • Přidávání poznámek k tabulkám s informacemi vlastníka nebo uživatele při sdílení dat s různými organizačními jednotkami
  • Archivace tabulek Delta a historie tabulek nebo časových cest je vyžadována. Data a doby uchovávání protokolů můžete zadat nezávisle na archivační tabulce. Příklad:

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)