Udostępnij za pośrednictwem

Klonowanie tabeli w usłudze Azure Databricks

  • Artykuł

Możesz utworzyć kopię istniejącej tabeli usługi Delta Lake w usłudze Azure Databricks w określonej wersji przy użyciu clone polecenia . Klony mogą być głębokie lub płytkie.

Usługa Azure Databricks obsługuje również klonowanie tabel Parquet i Iceberg. Zobacz Incrementally clone Parquet and Iceberg tables to Delta Lake (Przyrostowe klonowanie tabel Parquet i Góry Lodowej do usługi Delta Lake).

Aby uzyskać szczegółowe informacje na temat używania klonowania z katalogiem aparatu Unity, zobacz Płytkie klonowanie tabel wykazu aparatu Unity.

Uwaga

Usługa Databricks zaleca używanie funkcji Udostępniania różnicowego w celu zapewnienia dostępu tylko do odczytu do tabel w różnych organizacjach. Zobacz Co to jest udostępnianie różnicowe?.

Typy klonowania

  • Głębokie klonowanie to klon, który kopiuje dane tabeli źródłowej do obiektu docelowego klonowania oprócz metadanych istniejącej tabeli. Ponadto metadane strumienia są również klonowane w taki sposób, że strumień, który zapisuje w tabeli delta, można zatrzymać w tabeli źródłowej i kontynuować na miejscu docelowym klonu, z którego została przerwana.
  • Płytki klon to klon, który nie kopiuje plików danych do obiektu docelowego klonowania. Metadane tabeli są równoważne źródle. Te klony są tańsze do utworzenia.

Sklonowane metadane obejmują: schemat, informacje o partycjonowaniu, niezmienność, wartość null. Tylko w przypadku klonów głębokich są klonowane metadane przesyłania strumieniowego i COPY INTO . Metadane, które nie są klonowane, to opis tabeli i metadane zatwierdzenia zdefiniowane przez użytkownika.

Jakie są semantyka operacji klonowania różnicowego?

Jeśli pracujesz z tabelą delty zarejestrowaną w magazynie metadanych Hive lub kolekcją plików, które nie zostały zarejestrowane jako tabela, klon ma następujące semantyki:

Ważne

W środowisku Databricks Runtime 13.3 LTS lub nowszym tabele zarządzane przez wykaz aparatu Unity obsługują płytkie klony. Semantyka klonowania tabel wykazu aparatu Unity różni się znacznie od semantyki klonowania usługi Delta Lake w innych środowiskach. Zobacz Płytkie klonowanie tabel wykazu aparatu Unity.

  • Wszelkie zmiany wprowadzone w klonach głębokich lub płytkich mają wpływ tylko na same klony, a nie na tabelę źródłową.
  • Płytkie klony odwołują się do plików danych w katalogu źródłowym. Jeśli uruchomisz vacuum polecenie w tabeli źródłowej, klienci nie będą mogli już odczytywać plików danych, do których się odwołujesz, i zgłaszany jest element FileNotFoundException . W takim przypadku uruchomienie klonu z zastąpieniem płytkiego klonu naprawy klonu. W takim przypadku często należy rozważyć użycie głębokiego klonu, który nie zależy od tabeli źródłowej.
  • Klony głębokie nie zależą od źródła, z którego zostały sklonowane, ale są kosztowne do utworzenia, ponieważ głębokie klonowanie kopiuje dane, a także metadane.
  • Klonowanie z elementem replace docelowym, który ma już tabelę w tej ścieżce, tworzy dziennik delty, jeśli nie istnieje w tej ścieżce. Istniejące dane można wyczyścić, uruchamiając polecenie vacuum.
  • W przypadku istniejących tabel delty tworzone jest nowe zatwierdzenie, które zawiera nowe metadane i nowe dane z tabeli źródłowej. To nowe zatwierdzenie jest przyrostowe, co oznacza, że tylko nowe zmiany od czasu ostatniego klonowania są zatwierdzane w tabeli.
  • Klonowanie tabeli nie jest takie samo jak Create Table As Select lub CTAS. Klon kopiuje metadane tabeli źródłowej oprócz danych. Klonowanie ma również prostszą składnię: nie trzeba określać partycjonowania, formatowania, niezmienności, wartości null itd., ponieważ są pobierane z tabeli źródłowej.
  • Sklonowana tabela ma niezależną historię od jej tabeli źródłowej. Zapytania dotyczące podróży w czasie w sklonowanej tabeli nie działają z tymi samymi danymi wejściowymi, które działają w tabeli źródłowej.

Przykładowa składnia klonowania

W poniższych przykładach kodu pokazano składnię tworzenia głębokich i płytkich klonów:

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

Aby uzyskać szczegółowe informacje o składni, zobacz CREATE TABLE CLONE (CREATE TABLE CLONE).

Klonowanie metryk

CLONE raportuje następujące metryki jako ramkę danych z pojedynczym wierszem po zakończeniu operacji:

  • source_table_size: rozmiar tabeli źródłowej, która jest klonowana w bajtach.
  • source_num_of_files: liczba plików w tabeli źródłowej.
  • num_removed_files: Jeśli tabela jest zastępowana, ile plików zostanie usuniętych z bieżącej tabeli.
  • num_copied_files: liczba plików skopiowanych ze źródła (0 dla płytkich klonów).
  • removed_files_size: rozmiar w bajtach plików, które są usuwane z bieżącej tabeli.
  • copied_files_size: rozmiar w bajtach plików skopiowanych do tabeli.

Przykład klonowania metryk

Uprawnienia

Musisz skonfigurować uprawnienia do kontroli dostępu do tabel usługi Azure Databricks i dostawcy usług w chmurze.

Kontrola dostępu do tabel

W przypadku klonów głębokich i płytkich wymagane są następujące uprawnienia:

  • SELECT uprawnienie do tabeli źródłowej.
  • Jeśli używasz CLONE polecenia do utworzenia nowej tabeli, CREATE uprawnienie do bazy danych, w której tworzysz tabelę.
  • Jeśli używasz CLONE funkcji w celu zastąpienia tabeli, musisz mieć MODIFY uprawnienia do tabeli.

Uprawnienia dostawcy usług w chmurze

Jeśli utworzono głębokie klonowanie, każdy użytkownik odczytujący klon bezpośredni musi mieć dostęp do odczytu do katalogu klonu. Aby wprowadzić zmiany w klonie, użytkownicy muszą mieć dostęp do zapisu w katalogu klonowania.

Jeśli utworzono płytki klon, każdy użytkownik, który odczytuje płytki klon, musi mieć uprawnienia do odczytywania plików w oryginalnej tabeli, ponieważ pliki danych pozostają w tabeli źródłowej płytkimi klonami, a także katalog klonu. Aby wprowadzić zmiany w klonie, użytkownicy będą potrzebować dostępu do zapisu w katalogu klonowania.

Używanie klonowania do archiwizowania danych

Możesz użyć głębokiego klonowania, aby zachować stan tabeli w określonym punkcie w czasie na potrzeby archiwizacji. Głębokie klony można synchronizować przyrostowo, aby zachować zaktualizowany stan tabeli źródłowej na potrzeby odzyskiwania po awarii.

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

Używanie klonowania do odtwarzania modelu uczenia maszynowego

Podczas uczenia maszynowego możesz zarchiwizować określoną wersję tabeli, na której wytrenujesz model uczenia maszynowego. Przyszłe modele można przetestować przy użyciu tego zarchiwizowanego zestawu danych.

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

Używanie klonowania w przypadku eksperymentów krótkoterminowych w tabeli produkcyjnej

Aby przetestować przepływ pracy w tabeli produkcyjnej bez uszkodzenia tabeli, można łatwo utworzyć płytki klon. Dzięki temu można uruchamiać dowolne przepływy pracy w sklonowanej tabeli zawierającej wszystkie dane produkcyjne, ale nie ma wpływu na żadne obciążenia produkcyjne.

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

Użyj polecenia clone, aby zastąpić właściwości tabeli

Przesłonięcia właściwości tabeli są szczególnie przydatne w następujących celach:

  • Dodawanie adnotacji do tabel z informacjami o właścicielach lub użytkownikach podczas udostępniania danych innym jednostkom biznesowym.
  • Wymagane jest archiwizowanie tabel delty i historii tabeli lub podróży czasowej. Okres przechowywania danych i dzienników można określić niezależnie dla tabeli archiwum. Na przykład:

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)