Klon dangkal untuk tabel Unity Catalog

Important

Fitur ini ada di Pratinjau Umum.

Important

Dukungan untuk kloning dangkal berbeda antara tabel terkelola dan tabel eksternal di Unity Catalog. Untuk tabel terkelola, gunakan Databricks Runtime 13.3 LTS ke atas, dan untuk tabel eksternal gunakan Databricks Runtime 14.3 LTS ke atas.

Anda hanya dapat mengkloning tabel terkelola Unity Catalog ke tabel terkelola Unity Catalog dan tabel eksternal Unity Catalog ke tabel eksternal Unity Catalog. VACUUM perilaku berbeda antara tabel yang dikelola dan tabel eksternal. Lihat Menggunakan VACUUM dengan klon dangkal pada Unity Catalog.

Gunakan kloning dangkal untuk membuat tabel Unity Catalog dengan hak istimewa kontrol akses yang independen dari tabel sumbernya, tanpa menyalin file data yang mendasar. Kloning dangkal di Unity Catalog hanya didukung untuk tabel Delta Lake. Anda tidak dapat membuat klon dangkal dari tabel Iceberg atau tabel lain yang bukan Delta.

Untuk informasi tentang mengkloning tabel, lihat Mengkloning tabel di Azure Databricks.

Membuat Kloning Dangkal yang Dikelola Unity Catalog

Buat kloning dangkal tabel terkelola di Unity Catalog.

CREATE TABLE <catalog-name>.<schema-name>.<target-table-name>
SHALLOW CLONE <catalog-name>.<schema-name>.<source-table-name>

Untuk membuat kloning dangkal terkelola di Unity Catalog, Anda harus memiliki hak istimewa berikut pada sumber daya sumber dan target.

Resource	Izin diperlukan
Skema sumber	USE SCHEMA
Katalog sumber	USE CATALOG
Skema target	USE SCHEMA, CREATE TABLE
Katalog Target	USE CATALOG

Seperti pernyataan buat tabel lainnya, saat Anda menjalankan SHALLOW CLONE, Anda memiliki tabel target. Pemilik tabel target kloning mengontrol hak akses untuk tabel tersebut secara independen dari tabel sumber. Pemilik tabel kloning mungkin berbeda dari pemilik tabel sumber.

Membuat klon eksternal ringan dari Katalog Unity

Buat klon dangkal eksternal Katalog Unity dengan menentukan lokasi eksternal.

CREATE TABLE <catalog-name>.<schema-name>.<target-table-name>
SHALLOW CLONE <catalog-name>.<schema-name>.<source-table-name>
LOCATION 's3://<bucket-name>/<path-name>/<target-table-name>'

Untuk membuat kloning dangkal eksternal di Unity Catalog, Anda harus memiliki hak istimewa berikut pada sumber daya sumber dan target.

Resource	Izin diperlukan
Skema sumber	USE SCHEMA
Katalog sumber	USE CATALOG
Skema target	USE SCHEMA, CREATE TABLE
Katalog Target	USE CATALOG
Lokasi eksternal yang ditargetkan	CREATE EXTERNAL TABLE

Bekerja dengan tabel kloning dangkal dalam mode akses standar

Untuk mengkueri kloning dangkal dalam mode akses standar (sebelumnya mode akses bersama), Anda harus memiliki hak istimewa berikut pada tabel dan berisi sumber daya:

Resource	Izin diperlukan
Catalog	USE CATALOG
Schema	USE SCHEMA
Tabel	SELECT

Anda juga harus memiliki MODIFY izin pada target operasi kloning untuk menjalankan operasi berikut:

• INSERT
• DELETE
• UPDATE
• MERGE
• CREATE TABLE
• DROP TABLE

Bekerja dengan tabel kloning dangkal dalam mode akses khusus

Saat bekerja dengan shallow clone Unity Catalog pada mode akses khusus (sebelumnya mode akses pengguna tunggal), Anda harus memiliki izin atas sumber daya untuk tabel sumber yang dikloning dan tabel target.

Untuk kueri sederhana, selain izin yang diperlukan pada tabel target, Anda harus memiliki USE izin pada katalog sumber dan skema dan SELECT izin pada tabel sumber. Untuk kueri apa pun yang memperbarui atau menyisipkan rekaman ke tabel target, Anda juga harus memiliki MODIFY izin pada tabel sumber.

Databricks merekomendasikan penggunaan klon Unity Catalog pada komputasi dengan mode akses standar, karena hal ini memungkinkan perubahan izin secara independen untuk target klon dangkal Unity Catalog dan tabel sumbernya.

Gunakan VACUUM dengan klon unity Catalog dangkal

Saat Anda menggunakan tabel Unity Catalog untuk sumber dan target operasi kloning dangkal, Unity Catalog mengelola file data yang mendasar untuk meningkatkan keandalan untuk sumber dan target operasi kloning. Menjalankan VACUUM pada sumber klon dangkal tidak merusak tabel hasil klon.

Biasanya, ketika VACUUM mengidentifikasi file yang valid untuk ambang retensi tertentu, hanya metadata untuk tabel saat ini yang dipertimbangkan. Namun, dukungan kloning dangkal untuk Katalog Unity melacak hubungan antara semua tabel kloning dan file data sumber, sehingga file yang valid diperluas untuk menyertakan file data yang diperlukan untuk mengembalikan kueri untuk tabel kloning dangkal dan tabel sumber.

Untuk VACUUM pada shallow clone Unity Catalog, file data yang valid adalah file apa pun yang berada dalam batas retensi yang ditentukan untuk tabel sumber atau tabel hasil kloning apa pun. Tabel terkelola dan tabel eksternal memiliki perilaku yang sedikit berbeda.

Pelacakan metadata yang ditingkatkan ini mengubah cara operasi VACUUM memengaruhi file data dasar pada tabel Delta Lake, dengan perilaku berikut:

• Untuk tabel terkelola, VACUUM operasi pada sumber atau target operasi kloning dangkal dapat menghapus file data dari tabel sumber.
• Untuk tabel eksternal, operasi VACUUM hanya menghapus file data dari tabel sumber saat dijalankan terhadap tabel sumber.
• Hanya file data yang tidak dianggap valid untuk tabel sumber atau kloning dangkal terhadap sumber yang dihapus.
• Jika beberapa kloning dangkal didefinisikan terhadap satu tabel sumber, menjalankan VACUUM pada salah satu tabel kloning tidak menghapus file data yang valid untuk tabel kloning lainnya.

Nota

Databricks merekomendasikan agar Anda tidak pernah menjalankan VACUUM dengan pengaturan retensi kurang dari 7 hari untuk menghindari kerusakan transaksi jangka panjang yang sedang berlangsung. Jika Anda memerlukan ambang retensi yang lebih rendah, pertimbangkan bagaimana VACUUM pada clone dangkal di Unity Catalog berbeda dari cara VACUUM memengaruhi tabel hasil clone lainnya di Azure Databricks. Untuk informasi selengkapnya, lihat Mengkloning tabel di Azure Databricks.

Bahkan jika Anda menghapus tabel yang dikloning secara dangkal, Anda mungkin memerlukan akses SELECT ke tabel yang dikloning secara dangkal tersebut untuk menjalankan VACUUM pada tabel dasar. Databricks membaca log Delta dari kloning dangkal untuk memverifikasi file data tabel dasar mana yang masih dirujuk kloning sebelum membersihkannya. Databricks mempertahankan tautan ini selama 7 hari setelah menghapus tabel yang dikloning secara dangkal untuk mendukung operasi UNDROP. Namun, dalam mode akses standar, izin ini tidak diperlukan.

Hapus tabel dasar untuk klon dangkal

Jika Anda menghapus tabel dasar dari klon dangkal, klon tersebut menjadi tidak dapat digunakan. Secara bawaan, Databricks menghalangi Anda untuk menghapus tabel dasar jika masih memiliki klon dangkal yang merujuknya.

Untuk mengambil alih perlindungan ini, gunakan DROP TABLE ... FORCE sintaks. Jika Anda menggunakan FORCE:

• Tabel dasar segera dihapus.
• Semua referensi kloning dangkal menjadi rusak dan:
  • Kloning dangkal gagal pada operasi yang memerlukan membaca data atau metadata (misalnya, , SELECT, INSERTUPDATE, DESCRIBE HISTORYCLONE).
  • Untuk memungkinkan pembersihan, kloning dangkal masih terlihat melalui operasi tingkat metadata (misalnya, SHOW TABLES, DROP TABLE).

Perilaku ini hanya berlaku untuk tabel terkelola Katalog Unity. Untuk informasi selengkapnya, lihat DROP TABLE .

Keterbatasan

• Klon dangkal hanya didukung untuk tabel Delta Lake. Anda tidak dapat membuat klon dangkal dari tabel Iceberg atau tabel lain yang bukan Delta.
• Anda tidak dapat menggunakan CREATE OR REPLACE untuk menimpa clone dangkal yang sudah ada. Gunakan DROP TABLE diikuti oleh CREATE TABLE, atau gunakan nama tabel baru.
• Klon dangkal pada tabel eksternal harus berupa tabel eksternal. Kloning dangkal pada tabel yang dikelola haruslah tabel yang dikelola.
• Anda tidak dapat berbagi kloning dangkal menggunakan OpenSharing.
• Anda tidak dapat melakukan penumpukan kloning dangkal, artinya Anda tidak bisa membuat kloning dangkal dari kloning dangkal.
• Untuk tabel terkelola, menghilangkan tabel sumber merusak tabel target untuk kloning dangkal. File data dasar untuk tabel eksternal tidak dihapus oleh operasi DROP TABLE, sehingga klon dangkal dari tabel eksternal tidak terpengaruh oleh penghapusan sumbernya.
• Katalog Unity memungkinkan pengguna untuk UNDROP tabel terkelola selama sekitar 7 hari setelah perintah DROP TABLE. Dalam Databricks Runtime 13.3 LTS dan versi setelahnya, klon dangkal yang dikelola dari tabel sumber yang dihapus tetap berfungsi selama periode 7 hari selama Unity Catalog mendukung UNDROP. Jika tabel sumber tidak dipulihkan dalam jendela itu, kloning dangkal berhenti berfungsi ketika file data sumber dihapus selama pengumpulan sampah.