Bagikan melalui

Kloning dangkal untuk tabel Unity Catalog

  • Artikel

Penting

Dukungan kloning dangkal untuk tabel terkelola Unity Catalog ada di Pratinjau Umum di Databricks Runtime 13.3 ke atas. Dukungan kloning dangkal untuk tabel eksternal Unity Catalog ada di Pratinjau Umum di Databricks Runtime 14.2 ke atas.

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.

Penting

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 terkelola dan eksternal. Lihat Klon Vakum dan Unity Catalog dangkal.

Untuk informasi selengkapnya tentang kloning Delta, lihat Mengkloning tabel di Azure Databricks.

Untuk informasi selengkapnya tentang tabel Unity Catalog, lihat Apa itu tabel dan tampilan?.

Membuat kloning dangkal pada Unity Catalog

Anda dapat membuat kloning dangkal di Unity Catalog menggunakan sintaks yang sama yang tersedia untuk kloning dangkal di seluruh produk, seperti yang ditunjukkan dalam contoh sintaks berikut:

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

Untuk membuat kloning dangkal pada Unity Catalog, Anda harus memiliki hak istimewa yang memadai pada sumber daya sumber dan target, seperti yang dirinci dalam tabel berikut:

Sumber daya Izin yang diperlukan
Tabel sumber SELECT
Skema sumber USE SCHEMA
Katalog sumber USE CATALOG
Skema target USE SCHEMA, CREATE TABLE
Katalog target USE CATALOG
Lokasi eksternal target (hanya tabel eksternal) CREATE EXTERNAL TABLE

Seperti pernyataan buat tabel lainnya, pengguna yang membuat kloning dangkal adalah pemilik tabel target. Pemilik tabel kloning target dapat mengontrol hak akses untuk tabel tersebut secara independen dari tabel sumber.

Catatan

Pemilik tabel kloning mungkin berbeda dari pemilik tabel sumber.

Mengkueri atau mengubah tabel kloning dangkal di Unity Catalog

Penting

Instruksi di bagian ini menjelaskan hak istimewa yang diperlukan untuk komputasi yang dikonfigurasi dengan mode akses bersama. Untuk mode akses Pengguna Tunggal, lihat Bekerja dengan tabel kloning dangkal dalam mode akses Pengguna Tunggal.

Untuk mengkueri kloning dangkal pada Unity Catalog, Anda harus memiliki hak istimewa yang memadai pada tabel dan berisi sumber daya, seperti yang dirinci dalam tabel berikut:

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

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

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

Klon vakum dan Unity Catalog dangkal

Penting

Perilaku ini ada di Pratinjau Umum di Databricks Runtime 13.3 LTS ke atas untuk tabel terkelola dan Databricks Runtime 14.2 ke atas untuk tabel eksternal.

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. Berjalan VACUUM pada sumber kloning dangkal tidak merusak tabel kloning.

Biasanya, ketika VACUUM mengidentifikasi file yang valid untuk ambang retensi tertentu, hanya metadata untuk tabel saat ini yang dipertimbangkan. 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 semantik kloning VACUUM dangkal Katalog Unity, file data yang valid adalah file apa pun dalam ambang retensi yang ditentukan untuk tabel sumber atau tabel kloning apa pun. Tabel terkelola dan tabel eksternal memiliki semantik yang sedikit berbeda.

Pelacakan metadata yang ditingkatkan ini mengubah bagaimana VACUUM operasi memengaruhi file data yang mendukung tabel Delta, dengan semantik berikut:

  • Untuk tabel terkelola, VACUUM operasi terhadap sumber atau target operasi kloning dangkal dapat menghapus file data dari tabel sumber.
  • Untuk tabel eksternal, VACUUM operasi 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 tabel sumber tunggal, berjalan VACUUM pada salah satu tabel kloning tidak menghapus file data yang valid untuk tabel kloning lainnya.

Catatan

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

Bekerja dengan tabel kloning dangkal dalam mode akses Pengguna Tunggal

Saat bekerja dengan kloning Unity Catalog dangkal dalam 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 MODIFY izin pada tabel sumber.

Databricks merekomendasikan untuk bekerja dengan klon Katalog Unity pada komputasi dengan mode akses bersama karena ini memungkinkan evolusi izin independen untuk target kloning unity Catalog dangkal dan tabel sumbernya.

Batasan

  • Kloning dangkal pada tabel eksternal harus tabel eksternal. Kloning dangkal pada tabel terkelola harus dikelola tabel.
  • Anda tidak dapat berbagi kloning dangkal menggunakan Berbagi Delta.
  • Anda tidak dapat menumpuk kloning dangkal, yang berarti Anda tidak dapat membuat kloning dangkal dari kloning dangkal.
  • Untuk tabel terkelola, menghilangkan tabel sumber merusak tabel target untuk kloning dangkal. File data yang mendukung tabel eksternal tidak dihapus oleh DROP TABLE operasi, sehingga klon tabel eksternal yang dangkal tidak terpengaruh dengan menghilangkan sumbernya.
  • Katalog Unity memungkinkan pengguna untuk UNDROP mengelola tabel selama sekitar 7 hari setelah DROP TABLE perintah. Dalam Databricks Runtime 13.3 LTS ke atas, klon dangkal yang dikelola berdasarkan tabel terkelola yang dihilangkan terus berfungsi selama periode 7 hari ini. Jika Anda bukan UNDROP tabel sumber di jendela ini, kloning dangkal berhenti berfungsi setelah file data tabel sumber dikumpulkan sampah.