Bagikan melalui

Kloning dangkal untuk tabel Unity Catalog

  • Artikel

Penting

Dukungan kloning dangkal untuk tabel yang dikelola Unity Catalog ada di Public Preview di Databricks Runtime 13.3 dan versi ke atas. Dukungan kloning dangkal untuk tabel eksternal Unity Catalog dalam Pratinjau Umum tersedia di Databricks Runtime 14.2 dan versi di atasnya.

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 yang dikelola dan tabel eksternal. Lihat klon dangkal Vacuum dan Unity Catalog.

Untuk informasi selengkapnya tentang klon 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 CREATE TABLE lainnya, pengguna yang membuat klon 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 memodifikasi tabel kloning dangkal pada Unity Catalog

Penting

Instruksi di bagian ini menjelaskan hak istimewa yang diperlukan untuk komputasi yang dikonfigurasi dengan mode akses standar (sebelumnya mode akses bersama). Untuk mode akses khusus (sebelumnya mode akses pengguna tunggal), lihat Bekerja dengan tabel yang dikloning secara dangkal dalam mode akses khusus.

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

Klon dangkal Vacuum dan Unity Catalog

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

Pelacakan metadata yang disempurnakan ini mengubah bagaimana operasi VACUUM 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, 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 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 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. Lihat Menggandakan tabel di Azure Databricks.

Bekerja dengan tabel kloning dangkal dalam mode akses khusus

Saat bekerja dengan Unity Catalog kloning dangkal dalam mode akses khusus, Anda harus memiliki izin atas sumber daya untuk tabel sumber kloning serta tabel target.

Ini berarti bahwa untuk kueri sederhana selain izin yang diperlukan pada tabel target, Anda harus memiliki izin USE pada katalog sumber dan skema dan izin SELECT 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.

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 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 operasi DROP TABLE, sehingga klon tabel eksternal yang dangkal tidak terpengaruh dengan menghilangkan sumbernya.
  • Katalog Unity memungkinkan pengguna untuk UNDROP tabel terkelola selama sekitar 7 hari setelah perintah DROP TABLE. 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 tidak UNDROP tabel sumber di jendela ini, salinan dangkal akan berhenti berfungsi setelah file data tabel sumber dikumpulkan sebagai sampah.