Kloning dangkal untuk tabel Unity Catalog

Penting

Fitur ini ada di Pratinjau Umum.

Penting

Dukungan untuk kloning dangkal berbeda antara tabel terkelola dan tabel eksternal di Unity Catalog. Untuk tabel terkelola gunakan Databricks Runtime 13.3 ke atas, dan untuk tabel eksternal gunakan Databricks Runtime 14.2 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.

Anda dapat menggunakan kloning dangkal untuk membuat tabel Unity Catalog baru dari tabel Unity Catalog yang ada. Dukungan kloning dangkal untuk Unity Catalog memungkinkan Anda membuat tabel dengan hak istimewa kontrol akses yang independen dari tabel induk mereka tanpa perlu menyalin file data yang mendasar.

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.

Sumber daya	Izin yang diperlukan
Skema sumber	USE SCHEMA
Katalog sumber	USE CATALOG
Skema target	USE SCHEMA, CREATE TABLE
Katalog Target	USE CATALOG

Seperti pernyataan pembuatan tabel lainnya, pengguna yang membuat shallow clone menguasai tabel target. Pemilik tabel target kloning mengontrol hak akses untuk tabel tersebut secara independen dari tabel sumber. Ini berarti bahwa 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.

Sumber daya	Izin yang 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 melakukan kueri kloning dangkal dalam mode akses standar (sebelumnya mode akses bersama), Anda harus memiliki privilege berikut pada tabel dan sumber daya yang terkait.

Sumber daya	Izin yang diperlukan
Katalog	USE CATALOG
Skema	USE SCHEMA
Meja	SELECT

Anda juga harus memiliki MODIFY izin pada target operasi kloning untuk menyelesaikan tindakan berikut.

• Sisipkan rekaman
• Hapus rekaman
• Memperbarui rekaman
• MERGE
• CREATE TABLE
• DROP TABLE

Bekerja dengan tabel kloning dangkal dalam mode akses khusus

Saat bekerja dengan klon Unity Catalog dangkal dalam mode akses yang didedikasikan (yang sebelumnya disebut mode akses pengguna tunggal), Anda harus memiliki izin pada sumber daya untuk sumber tabel kloning serta tabel target.

Ini berarti bahwa 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 akan memperbarui atau menyisipkan rekaman ke tabel target, Anda juga harus memiliki izin MODIFY pada tabel sumber.

Databricks merekomendasikan untuk bekerja dengan klon Unity Catalog pada komputasi dengan mode akses standar karena ini memungkinkan evolusi izin 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 kloning.

Biasanya, ketika VACUUM mengidentifikasi file yang valid untuk ambang retensi tertentu, hanya metadata untuk tabel saat ini yang dipertimbangkan. Namun, dukungan kloning dangkal untuk Unity Catalog 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 serta tabel sumber.

Ini berarti bahwa untuk kloning dangkal Unity Catalog VACUUM semantik, file data yang valid adalah file apa pun yang berada dalam ambang retensi yang ditentukan dalam tabel sumber atau tabel hasil kloning apa pun. Tabel terkelola dan tabel eksternal memiliki semantik yang sedikit berbeda.

Peningkatan pelacakan metadata ini mengubah cara operasi VACUUM memengaruhi file data dasar pada tabel Delta, dengan semantik berikut ini.

• Untuk tabel terkelola, VACUUM operasi terhadap 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.

Catatan

Databricks merekomendasikan untuk tidak pernah menjalankan VACUUM dengan pengaturan retensi kurang dari 7 hari untuk menghindari kerusakan pada transaksi yang sedang berjalan dan berjangka panjang. Jika Anda perlu menjalankan VACUUM dengan ambang batas retensi yang lebih rendah, pastikan Anda memahami bagaimana kloning dangkal VACUUM di Unity Catalog berbeda dengan cara VACUUM berinteraksi dengan tabel kloning lainnya di Azure Databricks. Untuk informasi selengkapnya, lihat Mengkloning tabel di Azure Databricks.

Selain itu, bahkan jika tabel kloning dangkal dihapus, Anda mungkin memerlukan SELECT akses ke tabel kloning dangkal itu untuk menjalankan VACUUM di tabel dasar. Databricks membaca log Delta dari kloning dangkal untuk memverifikasi file data tabel dasar mana yang masih dirujuk kloning sebelum membersihkannya. Databricks memelihara tautan ini selama 7 hari setelah penghapusan tabel kloning dangkal untuk mendukung operasi UNDROP. Namun, dalam mode akses standar, izin ini tidak diperlukan.

Hapus tabel dasar untuk klon dangkal

Jika tabel dasar kloning dangkal dihilangkan, kloning 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:
  • Gagal pada operasi yang memerlukan pembacaan data atau metadata (misalnya, , SELECT, INSERTUPDATE, DESCRIBE HISTORY, CLONE).
  • Masih terlihat melalui operasi tingkat metadata (misalnya, SHOW TABLES, DROP TABLE) untuk memungkinkan pembersihan.

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

Batasan

• Klon dangkal pada tabel eksternal harus berupa tabel eksternal. Kloning dangkal pada tabel yang dikelola haruslah tabel yang dikelola.
• Anda tidak dapat menggunakan REPLACE atau CREATE OR REPLACE untuk menimpa klon dangkal yang ada. Sebagai gantinya, DROP kloning dangkal dan jalankan pernyataan CREATE baru.
• Anda tidak dapat berbagi kloning dangkal menggunakan Berbagi Delta.
• 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.