Mengkloning tabel di Azure Databricks

Klon tabel Delta Lake atau Apache Iceberg menggunakan perintah CLONE untuk membuat salinan independen di versi tertentu. Klon mendalam menyalin data dan metadata. Kloning dangkal hanya menyalin metadata dan mereferensikan file data sumber, menggunakan komputasi dan penyimpanan yang lebih sedikit daripada klon mendalam.

Azure Databricks juga mendukung kloning tabel Parquet dan Apache Iceberg. Lihat Mengkloning tabel Parquet dan Apache Iceberg secara bertahap ke Delta Lake dan Mengkloning tabel Iceberg yang dikelola.

Untuk detail tentang menggunakan kloning dengan Unity Catalog, lihat Kloning dangkal untuk tabel Unity Catalog.

Note

Databricks merekomendasikan penggunaan OpenSharing untuk menyediakan akses baca-saja ke tabel di berbagai organisasi. Lihat Apa itu OpenSharing?.

Jenis klon

Jenis kloning berikut tersedia:

Type Sintaksis SQL Deskripsi
Kloning mendalam CLONE atau DEEP CLONE Menyalin data dan metadata dari tabel sumber ke target kloning, termasuk metadata aliran. Stream yang menulis ke tabel sumber dapat dihentikan dan dilanjutkan pada target klon dari titik terakhirnya.
Kloning dangkal SHALLOW CLONE Menyalin hanya metadata dari tabel sumber ke target kloning. File data tidak disalin. Kloning dangkal lebih murah untuk dibuat, karena operasi menggunakan lebih sedikit sumber daya komputasi dan ruang penyimpanan.

Metadata kloning meliputi: skema, informasi partisi, invarian, nullability, dan TBLPROPERTIES. Hanya untuk klon mendalam, stream dan metadata COPY INTO juga akan dikloning. Metadata yang tidak dikloning adalah deskripsi tabel, metadata penerapan yang ditentukan pengguna, riwayat tabel Delta Lake, dan properti Katalog Unity, seperti tag.

Note

Tabel streaming dan tampilan materialisasi tidak mendukung CLONE. Anda tidak dapat menggunakan tabel streaming atau tampilan termaterialisasi sebagai sumber atau target klon penuh atau dangkal. Lihat Batasan dan Batasan.

Metode pengukuran klon

CLONE melaporkan metrik berikut sebagai DataFrame baris tunggal setelah operasi selesai:

  • source_table_size: Ukuran tabel sumber yang sedang dikloning dalam byte.
  • source_num_of_files: Jumlah file dalam tabel sumber.
  • num_removed_files: Jika tabel sedang diganti, berapa banyak file yang dihapus dari tabel saat ini.
  • num_copied_files: Jumlah file yang disalin dari sumber (0 untuk klon dangkal).
  • removed_files_size: Ukuran dalam byte file yang sedang dihapus dari tabel saat ini.
  • copied_files_size: Ukuran file dalam byte dari file-file yang disalin ke tabel.

Contoh mengkloning metrik

Permissions

Anda harus mengonfigurasi izin untuk kontrol akses tabel Azure Databricks dan penyedia cloud Anda.

Kontrol akses tabel

Izin berikut diperlukan untuk klon dalam dan dangkal:

  • SELECT perizinan pada tabel sumber.
  • Jika Anda menggunakan CLONE untuk membuat tabel baru, izin CREATE pada database tempat Anda membuat tabel.
  • Jika Anda menggunakan CLONE untuk mengganti tabel, Anda harus memiliki izin MODIFY pada tabel.

Izin penyedia cloud

Pengguna yang membaca klon mendalam memerlukan akses baca ke direktori klon tersebut. Penulis memerlukan akses tulis ke direktori klon.

Pembaca kloning dangkal memerlukan akses baca ke file data tabel sumber dan direktori kloning, karena file data tetap berada di sumbernya. Penulis memerlukan akses tulis ke direktori klon.

Examples

Membuat klon mendalam atau dangkal

Contoh kode berikut menunjukkan cara membuat salinan mendalam dan salinan dangkal:

SQL

Buat klon mendalam:

CREATE TABLE target_table CLONE source_table;

Ganti target yang sudah ada:

CREATE OR REPLACE TABLE target_table CLONE source_table;

Buat klon mendalam, atau lewati jika target sudah ada:

CREATE TABLE IF NOT EXISTS target_table CLONE source_table;

Buat kloning dangkal pada versi terbaru, pada versi tertentu, atau pada tanda waktu tertentu. Tanda waktu dapat berupa string tanggal seperti '2019-01-01' atau ekspresi seperti 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

API Python DeltaTable khusus untuk Delta Lake.

Kloning sumber pada versi terbaru:

from delta.tables import *

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

Kloning sumber pada versi tertentu:

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

Klon sumber pada tanda waktu tertentu:

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

Scala

API Scala DeltaTable khusus untuk Delta Lake.

Kloning sumber pada versi terbaru:

import io.delta.tables._

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

Kloning sumber pada versi tertentu:

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

Klon sumber pada tanda waktu tertentu:

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

Untuk detail sintaks, lihat CREATE TABLE CLONE.

Periksa metadata yang disalin selama CLONE

Contoh ini menunjukkan metadata yang disalin dan yang tidak disalin selama operasi CLONE, khususnya TBLPROPERTIES, tag Unity Catalog, dan riwayat Delta Lake.

Buat tabel sumber dengan properti kustom dan durasi retensi log non-default, lalu sisipkan data untuk menghasilkan riwayat tabel:

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

Buat klon mendalam dan kloning dangkal:

CREATE OR REPLACE TABLE test_clone_deep DEEP CLONE test_clone_source;

CREATE TABLE test_clone_shallow SHALLOW CLONE test_clone_source;

Note

Di Unity Catalog, Anda tidak dapat menggunakan CREATE OR REPLACE untuk menimpa kloning dangkal yang sudah ada. Gunakan DROP TABLE diikuti oleh CREATE TABLE, atau gunakan nama tabel baru. Lihat Batasan.

Konfirmasikan bahwa TBLPROPERTIES disalin ke kedua klon:

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

Pastikan bahwa tag Unity Catalog tidak disalin ke klon:

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

Konfirmasikan bahwa riwayat Delta Lake tidak disalin ke kloning:

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

Bersihkan:

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

Pengarsipan data

Anda dapat menggunakan klon mendalam untuk mempertahankan status tabel pada titik waktu tertentu untuk tujuan pengarsipan. Anda dapat menyinkronkan klon secara mendetail secara bertahap untuk menjaga agar status tabel sumber tetap diperbarui untuk pemulihan bencana.

Jalankan perintah berikut sebulan sekali untuk menyinkronkan arsip:

CREATE OR REPLACE TABLE archive_table CLONE my_prod_table

Reproduksi model pembelajaran mesin

Untuk kasus penggunaan pembelajaran mesin, Anda mungkin ingin mengarsipkan versi tabel yang digunakan untuk melatih model ML. Model mendatang dapat diuji menggunakan himpunan data yang diarsipkan ini. Untuk mengarsipkan versi himpunan data dengan CLONE, lakukan hal berikut:

Misalnya, untuk mengarsipkan versi tabel yang digunakan untuk melatih model pada versi 15:

CREATE TABLE model_dataset CLONE entire_dataset VERSION AS OF 15

Eksperimen jangka pendek pada tabel produksi

Untuk menguji alur kerja pada tabel produksi tanpa merusak tabel, buat kloning dangkal. Kloning dangkal memungkinkan Anda menjalankan beban kerja pada tabel kloning, yang mereferensikan semua data produksi, tetapi tidak memengaruhi beban kerja produksi apa pun.

Buat kloning dangkal tabel produksi:

CREATE TABLE my_test SHALLOW CLONE my_prod_table;

Note

Di Unity Catalog, Anda tidak dapat menggunakan CREATE OR REPLACE untuk menimpa kloning dangkal yang sudah ada. Gunakan DROP TABLE diikuti oleh CREATE TABLE, atau gunakan nama tabel baru. Lihat Batasan.

Jalankan pembaruan dan validasi pada kloning:

UPDATE my_test WHERE user_id is null SET invalid=true;

Setelah siap, gabungkan perubahan kembali. Penggabungan menggunakan informasi pembaruan dalam kloning untuk memangkas ke hanya file yang diubah jika memungkinkan:

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

Hapus klon setelah selesai:

DROP TABLE my_test;

Mengambil alih properti tabel

Penimpaan properti tabel berguna untuk:

  • Anotasi tabel dengan pemilik atau informasi pengguna saat berbagi data dengan unit bisnis yang berbeda.
  • Mengarsipkan tabel Delta Lake saat Anda memerlukan perjalanan waktu di arsip. Anda dapat menentukan periode retensi data dan log secara independen untuk tabel arsip. Contohnya:

SQL

Untuk tabel Delta Lake:

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

Untuk tabel Iceberg:

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

Python

API Python DeltaTable ini khusus untuk Delta Lake.

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

API Scala DeltaTable secara khusus ditujukan untuk 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)

Perilaku operasi kloning untuk Hive metastore lama

Important

Dalam Databricks Runtime 13.3 LTS ke atas, tabel terkelola Unity Catalog mendukung kloning dangkal. Perilaku kloning untuk tabel Katalog Unity berbeda dari perilaku kloning di lingkungan lain. Lihat klon Shallow untuk tabel Unity Catalog.

Untuk tabel Delta Lake yang terdaftar di metastore Hive atau kumpulan file yang tidak terdaftar sebagai tabel, kloning memiliki perilaku berikut:

  • Perubahan pada klon dalam atau dangkal tidak memengaruhi tabel sumber.
  • Klon dangkal mereferensikan file data di direktori sumber. Jika Anda menjalankan VACUUM pada tabel sumber, klien tidak dapat lagi membaca file data tersebut dan ini menimbulkan FileNotFoundException. Untuk memperbaikinya, jalankan kloning dengan replace pada kloning dangkal. Jika ini sering terjadi, pertimbangkan untuk menggunakan kloning mendalam, yang tidak bergantung pada tabel sumber.
  • Klon mendalam tidak bergantung pada tabel sumber tetapi mahal untuk dibuat karena menyalin data dan metadata.
  • Mengkloning menggunakan replace ke target yang sudah memiliki tabel pada jalur tersebut akan membuat log Delta jika log tersebut belum ada. Jalankan VACUUM untuk membersihkan data yang ada.
  • Untuk tabel Delta Lake yang sudah ada, kloning membuat komit inkremental baru yang hanya menyertakan metadata dan data baru dari tabel sumber sejak klon terakhir.
  • Mengkloning tabel berbeda dari Create Table As Select (CTAS). Klon menyalin metadata tabel sumber selain datanya. Anda tidak perlu menentukan partisi, format, invarian, nullability, atau pengaturan lainnya.
  • Tabel kloning memiliki riwayat independen dari tabel sumbernya. Kueri perjalanan waktu pada tabel kloning tidak berfungsi dengan input yang sama seperti pada tabel sumber.