Bagikan melalui

Katalog Unity: Praktik Terbaik

Dokumen ini memberikan rekomendasi untuk menggunakan Unity Catalog untuk memenuhi kebutuhan tata kelola data Anda secara paling efektif. Untuk pengenalan tata kelola data di Azure Databricks, lihat Tata kelola data dengan Azure Databricks. Untuk pengenalan Katalog Unity, lihat Apa itu Katalog Unity?.

Identitas

Prinsipal (pengguna, grup, dan perwakilan layanan) harus didefinisikan di tingkat akun Azure Databricks agar dapat ditetapkan hak istimewa pada objek yang dapat diamankan Katalog Unity. Databricks merekomendasikan agar Anda menggunakan SCIM untuk menyediakan prinsipal ke akun Azure Databricks Anda dari IdP Anda.

Praktik terbaik:

  • Hindari (dan nonaktifkan) provisi SCIM tingkat ruang kerja yang ada. Pemberian entitas secara langsung ke ruang kerja harus dicadangkan untuk ruang kerja lama yang tidak diaktifkan untuk Katalog Unity. Anda harus mengelola provisi sepenuhnya di tingkat akun.

  • Tentukan dan kelola grup di IdP Anda. Mereka harus konsisten dengan definisi grup organisasi Anda.

    Grup berperilaku berbeda dari pengguna dan prinsipal layanan. Meskipun pengguna dan perwakilan layanan yang Anda tambahkan ke ruang kerja secara otomatis disinkronkan dengan akun Azure Databricks Anda, grup tingkat ruang kerja ini tidak disinkronkan secara otomatis. Jika Anda memiliki grup ruang kerja-lokal, Anda harus memigrasikannya secara manual ke akun, sebaiknya dengan mereplikasinya di IdP Anda (jika perlu) dan memprovisikannya ke akun.

  • Siapkan grup sehingga Anda dapat menggunakannya secara efektif untuk memberikan akses ke data dan keamanan Katalog Unity lainnya. Hindari pemberian langsung kepada pengguna jika memungkinkan.

  • Gunakan grup untuk menetapkan kepemilikan ke sebagian besar objek yang dapat diamankan.

  • Hindari menambahkan pengguna secara manual, baik ke akun atau ruang kerja. Hindari memodifikasi grup di Azure Databricks: gunakan IdP Anda.

  • Gunakan prinsipal layanan untuk menjalankan tugas. Perwakilan layanan mengaktifkan otomatisasi pekerjaan. Jika Anda menggunakan akun pengguna untuk menjalankan tugas yang menulis ke lingkungan produksi, Anda berisiko menimpa data produksi secara tidak sengaja.

Untuk informasi selengkapnya, lihat Mengelola pengguna, perwakilan layanan, dan grup serta Menyinkronkan pengguna dan grup dari ID Microsoft Entra menggunakan SCIM.

Peran admin dan hak istimewa yang kuat

Menetapkan peran admin dan hak istimewa yang kuat seperti ALL PRIVILEGES dan MANAGE memerlukan kehati-hatian:

  • Pahami hak istimewa admin akun, admin ruang kerja, dan admin metastore sebelum Anda menetapkannya. Lihat hak istimewa Admin di Unity Catalog.
  • Tetapkan peran ini ke grup jika memungkinkan.
  • Admin metastore bersifat opsional. Tetapkan hanya jika Anda membutuhkannya. Untuk panduan, lihat (Opsional) Menetapkan peran admin metastore.
  • Tetapkan kepemilikan objek ke grup, terutama jika objek digunakan dalam produksi. Pembuat objek apa pun adalah pemilik pertamanya. Pembuat harus menetapkan kembali kepemilikan ke grup yang sesuai.
  • Hanya admin metastore, pemilik, dan pengguna dengan hak istimewa pada objek yang dapat memberikan hak istimewa pada objek tersebut MANAGE . Pemilik katalog dan skema induk juga memiliki kemampuan untuk memberikan hak istimewa pada semua objek dalam katalog atau skema. Jadilah hemat dalam penugasan kepemilikan dan hak akses istimewa MANAGE.
  • Hematlah dalam penugasan Anda , ALL PRIVILEGESyang mencakup semua hak istimewa kecuali MANAGE.

Penetapan hak istimewa

Objek yang dapat diamankan dalam Katalog Unity bersifat hierarkis, dan hak istimewa diwariskan ke bawah. Gunakan hierarki warisan ini untuk mengembangkan model hak istimewa yang efektif.

Praktik terbaik:

  • Pahami perbedaan antara USE CATALOG (atau USE SCHEMA) dan BROWSE:

    • USE CATALOG | SCHEMA memberikan kemampuan untuk melihat data dalam katalog atau skema. Sendiri, hak istimewa ini tidak memberikan SELECT atau READ pada objek di dalam katalog atau skema, tetapi mereka adalah prasyarat untuk memberi pengguna akses tersebut. Berikan hak istimewa ini hanya kepada pengguna yang seharusnya dapat melihat data dalam katalog atau skema.
    • USE CATALOG | SCHEMA, dengan membatasi akses ke katalog atau skema, mencegah pemilik objek (misalnya, pembuat tabel) secara tidak sengaja menetapkan akses ke objek tersebut (tabel) kepada pengguna yang seharusnya tidak memiliki akses. Biasanya untuk membuat skema per tim dan memberikan USE SCHEMA dan CREATE TABLE hanya kepada tim tersebut (bersama dengan USE CATALOG pada katalog induk).
    • BROWSE dapat diberikan secara luas di tingkat katalog untuk memungkinkan pengguna melihat metadata yang terkait dengan objek dalam katalog.

  • Pahami perbedaan antara kepemilikan objek dan MANAGE hak istimewa:

    • Pemilik objek memiliki semua hak istimewa pada objek, seperti SELECT dan MODIFY pada tabel, serta izin untuk memberikan hak istimewa pada objek yang dapat diamankan ke prinsipal lain dan untuk mentransfer kepemilikan ke prinsipal lain.
    • Pemilik dapat memberikan MANAGE hak istimewa untuk mendelegasikan kemampuan kepemilikan pada objek kepada prinsipal lain.
    • Pemilik katalog dan skema dapat mentransfer kepemilikan objek apa pun dalam katalog atau skema.
    • Yang terbaik adalah mengonfigurasi kepemilikan atau memberikan MANAGE hak istimewa pada semua objek kepada grup yang bertanggung jawab atas administrasi pemberian pada objek.

  • Batasi akses langsung MODIFY ke tabel produksi untuk prinsipal layanan.

Untuk informasi selengkapnya, lihat Mengelola hak istimewa di Katalog Unity.

Metastores

Berikut adalah aturan dan praktik terbaik untuk membuat dan mengelola metastore:

  • Anda hanya dapat memiliki satu metastore per wilayah. Semua ruang kerja di wilayah tersebut berbagi metastore yang sama. Untuk berbagi data antar wilayah, lihat Berbagi lintas wilayah dan lintas platform.

  • Metastores menyediakan isolasi regional tetapi tidak dimaksudkan sebagai unit default isolasi data. Isolasi data biasanya dimulai pada tingkat katalog. Namun, jika Anda lebih suka model tata kelola yang lebih terpusat, Anda dapat membuat penyimpanan terkelola tingkat metastore. Untuk rekomendasi, lihat Penyimpanan terkelola.

  • Peran admin metastore bersifat opsional. Untuk rekomendasi tentang apakah akan menetapkan admin metastore opsional, lihat Peran admin dan hak istimewa yang kuat.

Penting

Jangan mendaftarkan tabel yang sering diakses sebagai tabel eksternal di lebih dari satu metastore. Jika Anda melakukannya, perubahan pada skema, properti tabel, komentar, dan metadata lain yang terjadi sebagai akibat dari penulisan ke metastore A tidak akan mendaftar sama sekali dengan metastore B. Anda juga dapat menyebabkan masalah konsistensi dengan layanan penerapan Azure Databricks.

Katalog dan skema

Katalog adalah unit utama isolasi data dalam model tata kelola data Unity Catalog yang khas. Skema menambahkan lapisan organisasi tambahan.

Praktik terbaik untuk penggunaan katalog dan skema:

  • Atur data dan objek AI ke dalam katalog dan skema yang mencerminkan divisi dan proyek organisasi. Seringkali, ini berarti bahwa katalog sesuai dengan cakupan lingkungan, tim, unit bisnis, atau beberapa kombinasi dari ini. Ini memudahkan penggunaan hierarki hak istimewa untuk mengelola akses secara efektif.
  • Saat lingkungan kerja dan data keduanya memiliki persyaratan isolasi yang sama, Anda dapat mengikat katalog ke ruang kerja tertentu. Ketika diperlukan, buat katalog yang dapat dilingkup ke sekumpulan ruang kerja terbatas.
  • Selalu tetapkan kepemilikan katalog dan skema produksi ke grup, bukan pengguna individual.
  • Berikan USE CATALOG dan USE SCHEMA hanya kepada pengguna yang seharusnya dapat melihat atau mengkueri data yang ada di dalamnya.

Untuk saran selengkapnya tentang memberikan hak istimewa pada katalog dan skema, lihat Penetapan hak istimewa.

Penyimpanan terkelola

Tabel dan volume terkelola, objek yang siklus hidupnya dikelola sepenuhnya oleh Katalog Unity, disimpan di lokasi penyimpanan default, yang dikenal sebagai penyimpanan terkelola. Anda dapat menyiapkan penyimpanan terkelola di tingkat metastore, katalog, atau skema. Data disimpan di lokasi terendah yang tersedia dalam hierarki. Untuk detailnya, lihat Hierarki lokasi penyimpanan terkelola dan Tentukan lokasi penyimpanan terkelola di Katalog Unity.

Praktik terbaik untuk lokasi penyimpanan terkelola:

  • Berikan preferensi pada penyimpanan tingkat katalog sebagai unit utama isolasi data Anda.

    Penyimpanan tingkat metastore diperlukan di lingkungan Unity Catalog awal tetapi tidak lagi diperlukan.

  • Jika Anda memilih untuk membuat lokasi terkelola tingkat metastore, gunakan kontainer khusus.

  • Jangan gunakan kontainer yang dapat diakses dari luar Unity Catalog.

    Jika layanan eksternal atau prinsipal mengakses data di lokasi penyimpanan terkelola dengan melewati Unity Catalog, pengendalian akses dan kemampuan audit pada tabel dan volume terkelola disusupi.

  • Jangan gunakan kembali kontainer yang atau digunakan untuk sistem file akar DBFS Anda.

  • Jika Anda memiliki beban kerja intensif penyimpanan, jangan gunakan satu akun penyimpanan dan kontainer untuk penyimpanan terkelola dan lokasi eksternal lainnya.

    re:[ADLS] akun mendukung 20.000 permintaan per detik secara default. Hal ini dapat menyebabkan pembatasan dan perlambatan beban kerja. Menggunakan beberapa kontainer di akun penyimpanan yang sama tidak mengubah batas seluruh akun ini. Oleh karena itu, Anda harus membagi penyimpanan di beberapa akun penyimpanan.

    Striping semacam itu tidak akan terlihat oleh pengguna akhir Katalog Unity.

Tabel terkelola dan eksternal

Tabel terkelola dikelola sepenuhnya oleh Unity Catalog, yang berarti bahwa Unity Catalog mengelola tata kelola dan file data yang mendasar untuk setiap tabel terkelola. Format yang mereka gunakan selalu Delta atau Apache Iceberg.

Tabel eksternal adalah tabel yang aksesnya dari Azure Databricks dikelola oleh Unity Catalog, tetapi siklus hidup data dan tata letak filenya dikelola menggunakan penyedia cloud dan platform data lainnya. Saat Anda membuat tabel eksternal di Azure Databricks, Anda menentukan lokasinya, yang harus berada di jalur yang ditentukan di lokasi eksternal Katalog Unity.

Gunakan tabel terkelola:

  • Untuk sebagian besar kasus penggunaan. Databricks merekomendasikan tabel dan volume terkelola karena memungkinkan Anda untuk memanfaatkan sepenuhnya kemampuan tata kelola Dan pengoptimalan performa Unity Catalog, termasuk:

    • Pemadatan otomatis
    • Pengoptimalan otomatis
    • Pembacaan metadata lebih cepat (peng-cache-an metadata)
    • Pengoptimalan ukuran file cerdas

    Fungsionalitas Azure Databricks baru lebih diutamakan untuk tabel terkelola.

  • Untuk semua tabel baru.

Gunakan tabel eksternal:

  • Saat Anda sudah menggunakannya dan Anda beralih dari metastore Apache Hive ke Katalog Unity.

    • Menggunakan tabel eksternal dapat menyediakan peningkatan "satu klik" yang cepat dan lancar tanpa memindahkan data.
    • Databricks merekomendasikan agar Anda akhirnya memigrasikan tabel eksternal ke tabel terkelola.

  • Jika Anda memiliki persyaratan pemulihan bencana untuk data ini yang tidak dapat dipenuhi oleh tabel terkelola.

    Tabel terkelola tidak dapat didaftarkan di beberapa metastores di cloud yang sama.

  • Jika pembaca atau penulis eksternal perlu dapat berinteraksi dengan data dari luar Databricks.

    Biasanya, Anda harus mencegah akses eksternal bahkan ke tabel eksternal yang sudah terdaftar di Katalog Unity. Melakukannya mengabaikan kontrol akses Katalog Unity, audit, dan silsilah. Praktik yang lebih baik adalah menggunakan tabel terkelola dan berbagi data di seluruh wilayah atau penyedia cloud menggunakan Delta Sharing. Jika Anda harus mengizinkan akses eksternal ke tabel eksternal, batasi untuk membaca, dengan semua penulisan terjadi melalui Azure Databricks dan Unity Catalog.

  • Anda harus mendukung tabel non-Delta atau non-Iceberg, seperti Parquet, Avro, ORC, dan sebagainya.

Rekomendasi lainnya untuk menggunakan tabel eksternal:

  • Databricks merekomendasikan agar Anda membuat tabel eksternal menggunakan satu lokasi eksternal per skema.
  • Databricks sangat merekomendasikan untuk tidak mendaftarkan tabel sebagai tabel eksternal di lebih dari satu metastore karena risiko masalah konsistensi. Misalnya, perubahan pada skema dalam satu metastore tidak akan tercatat pada metastore kedua. Gunakan Delta Sharing untuk membagikan data antara metastores. Lihat Berbagi lintas wilayah dan lintas platform.

Lihat juga Pengantar tabel Azure Databricks.

Volume terkelola dan eksternal

Volume terkelola dikelola sepenuhnya oleh Katalog Unity, yang berarti bahwa Unity Catalog mengelola akses ke lokasi penyimpanan volume di akun penyedia cloud Anda. Volume eksternal mewakili data yang sudah ada di lokasi penyimpanan yang dikelola di luar Azure Databricks, tetapi terdaftar dalam Unity Catalog untuk mengontrol dan mengaudit akses dari dalam Azure Databricks. Saat Anda membuat volume eksternal di Azure Databricks, Anda menentukan lokasinya, yang harus berada di jalur yang ditentukan di lokasi eksternal Unity Catalog.

Gunakan volume terkelola:

  • Untuk sebagian besar kasus penggunaan, untuk memanfaatkan sepenuhnya kemampuan tata kelola Unity Catalog.
  • Jika Anda ingin membuat tabel berdasarkan file dalam suatu volume tanpa menjalankan COPY INTO atau pernyataan CTAS (CREATE TABLE AS).

Gunakan volume eksternal:

  • Untuk mendaftarkan area pendaratan untuk data mentah yang diproduksi oleh sistem eksternal untuk mendukung pemrosesannya pada tahap awal alur ETL dan aktivitas rekayasa data lainnya.
  • Untuk mendaftarkan lokasi penahapan untuk pengolahan data, misalnya, menggunakan Auto Loader, COPY INTO, atau menggunakan pernyataan CTAS.
  • Sediakan lokasi penyimpanan file bagi ilmuwan data, analis data, dan insinyur pembelajaran mesin untuk digunakan sebagai bagian dari analisis data eksploratif mereka dan tugas ilmu data lainnya, ketika volume terkelola bukanlah pilihan.
  • Untuk memberi pengguna Azure Databricks akses ke file arbitrer yang diproduksi dan disimpan di penyimpanan cloud oleh sistem lain, misalnya, kumpulan besar data yang tidak terstruktur (seperti file gambar, audio, video, dan PDF) yang diambil oleh sistem pengawasan atau perangkat IoT, atau file pustaka (JAR dan file roda Python) yang diekspor dari sistem manajemen dependensi lokal atau alur CI/CD.
  • Untuk menyimpan data operasional, misalnya, mencatat atau mengecek file, ketika volume terkelola bukanlah pilihan.

Rekomendasi lainnya untuk menggunakan volume eksternal:

  • Databricks merekomendasikan agar Anda membuat volume eksternal dari satu lokasi eksternal dalam satu skema.

Petunjuk / Saran

Untuk kasus penggunaan penyerapan di mana data disalin ke lokasi lain (misalnya, dengan menggunakan Auto Loader atau COPY INTO), gunakan volume eksternal. Gunakan tabel eksternal saat Anda ingin mengkueri data sebagai tabel, tanpa melibatkan salinan.

Lihat juga Volume terkelola vs. eksternal dan Lokasi eksternal.

Lokasi eksternal

Objek yang dapat diamankan di lokasi eksternal, dengan menggabungkan kredensial penyimpanan dan jalur penyimpanan, memberikan kontrol dan auditabilitas yang kuat terhadap akses penyimpanan. Penting untuk mencegah pengguna mengakses kontainer yang terdaftar sebagai lokasi eksternal secara langsung, melewati kontrol akses yang disediakan oleh Unity Catalog.

Untuk menggunakan lokasi eksternal secara efektif:

  • Pastikan Anda membatasi jumlah pengguna dengan akses langsung ke kontainer apa pun yang digunakan sebagai lokasi eksternal.

  • Jangan memasang akun penyimpanan ke DBFS jika akun tersebut juga digunakan sebagai lokasi eksternal. Databricks merekomendasikan agar Anda memigrasikan pemasangan di lokasi penyimpanan cloud ke lokasi eksternal di Unity Catalog menggunakan Catalog Explorer.

  • Berikan kemampuan untuk membuat lokasi eksternal hanya kepada administrator yang ditugaskan untuk menyiapkan koneksi antara Unity Catalog dan penyimpanan cloud, atau kepada teknisi data tepercaya.

    Lokasi eksternal menyediakan akses dari dalam Katalog Unity ke lokasi yang mencakup secara luas di penyimpanan cloud, misalnya, seluruh wadah atau kontainer (abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net) atau subpath yang luas (abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net/unity-catalog). Niatnya adalah bahwa administrator cloud dapat terlibat dalam menyiapkan beberapa lokasi eksternal dan kemudian mendelegasikan tanggung jawab mengelola lokasi tersebut kepada administrator Azure Databricks di organisasi Anda. Administrator Azure Databricks kemudian dapat lebih mengatur lokasi eksternal ke area dengan izin yang lebih terperinci dengan mendaftarkan volume eksternal atau tabel eksternal pada awalan tertentu di bawah lokasi eksternal.

    Karena lokasi eksternal sangat mencakup, Databricks merekomendasikan untuk memberikan CREATE EXTERNAL LOCATION izin hanya kepada administrator yang ditugaskan untuk menyiapkan koneksi antara Unity Catalog dan penyimpanan cloud, atau kepada teknisi data tepercaya. Untuk memberi pengguna lain akses yang lebih terperinci, Databricks merekomendasikan untuk mendaftarkan tabel atau volume eksternal di atas lokasi eksternal dan memberi pengguna akses ke data menggunakan volume atau tabel. Karena tabel dan volume adalah turunan dari katalog dan skema, administrator katalog atau skema memiliki kontrol utama atas izin akses.

    Anda juga dapat mengontrol akses ke lokasi eksternal dengan mengikatnya ke ruang kerja tertentu. Lihat (Opsional) Menetapkan lokasi eksternal ke ruang kerja tertentu.

  • Jangan berikan izin umum READ FILES atau WRITE FILES di lokasi eksternal kepada pengguna akhir.

    Pengguna tidak boleh menggunakan lokasi eksternal untuk apa pun kecuali membuat tabel, volume, atau lokasi terkelola. Mereka tidak boleh menggunakan lokasi eksternal untuk akses berbasis jalur untuk ilmu data atau kasus penggunaan data non-tabular lainnya.

    Untuk akses berbasis jalur ke data non-tabular, gunakan volume. Akses URI cloud ke data di bawah jalur volume diatur oleh hak istimewa yang diberikan pada volume, bukan hak istimewa yang diberikan pada lokasi eksternal tempat volume disimpan.

    Volume memungkinkan Anda bekerja dengan file menggunakan perintah SQL, dbutil, API Spark, REST API, Terraform, dan antarmuka pengguna untuk menelusuri, mengunggah, dan mengunduh file. Selain itu, volume menawarkan mount FUSE yang dapat diakses pada sistem file lokal di bawah /Volumes/<catalog_name>/<schema_name>/<volume_name>/. Pemasangan FUSE memungkinkan ilmuwan data dan insinyur ML untuk mengakses file seolah-olah mereka berada di sistem file lokal, seperti yang diperlukan oleh banyak pustaka pembelajaran mesin atau sistem operasi.

    Jika Anda harus memberikan akses langsung ke file di lokasi eksternal (untuk menjelajahi file di penyimpanan cloud sebelum pengguna membuat tabel atau volume eksternal, misalnya), Anda dapat memberikan READ FILES. Kasus penggunaan untuk pemberian WRITE FILES jarang terjadi.

  • Hindari konflik tumpang tindih jalur: jangan pernah membuat volume atau tabel eksternal pada akar lokasi eksternal.

    Jika Anda membuat volume atau tabel eksternal di akar lokasi eksternal, Anda tidak dapat membuat volume atau tabel eksternal tambahan di lokasi eksternal. Sebagai gantinya, buat volume atau tabel eksternal pada sub-direktori di dalam lokasi eksternal.

Anda harus menggunakan lokasi eksternal hanya untuk melakukan hal berikut:

  • Daftarkan tabel dan volume eksternal menggunakan CREATE EXTERNAL VOLUME perintah atau CREATE TABLE .
  • Daftarkan lokasi sebagai penyimpanan terkelola. Hak CREATE MANAGED STORAGE istimewa adalah prasyarat.
  • Jelajahi file yang ada di penyimpanan cloud sebelum Anda membuat tabel atau volume eksternal pada awalan tertentu. Hak READ FILES istimewa adalah prasyarat. Tetapkan hak istimewa ini dengan hemat. Lihat rekomendasi di daftar sebelumnya untuk detailnya.

Lokasi eksternal vs. volume eksternal

Sebelum volume dirilis, beberapa implementasi Unity Catalog menetapkan READ FILES akses langsung ke lokasi eksternal untuk eksplorasi data. Dengan ketersediaan volume yang mendaftarkan file dalam format apa pun, termasuk data terstruktur, semi terstruktur, dan tidak terstruktur, tidak ada alasan nyata untuk menggunakan lokasi eksternal untuk apa pun kecuali membuat tabel, volume, atau lokasi terkelola. Untuk informasi terperinci tentang kapan menggunakan lokasi eksternal dan kapan menggunakan volume, lihat Volume terkelola dan eksternal dan Lokasi eksternal.

Berbagi lintas wilayah dan lintas platform

Anda hanya dapat memiliki satu metastore per wilayah. Jika Anda ingin berbagi data antar ruang kerja di berbagai wilayah, gunakan Databricks-to-Databricks Delta Sharing.

Praktik terbaik:

  • Gunakan metastore wilayah tunggal Anda untuk semua cakupan siklus hidup pengembangan perangkat lunak dan unit bisnis, misalnya, pengembangan, pengujian, produksi, penjualan, dan pemasaran. Pastikan ruang kerja yang memerlukan akses data bersama yang sering berada di wilayah yang sama.
  • Gunakan Databricks-to-Databricks Delta Sharing di antara wilayah cloud atau penyedia cloud.
  • Gunakan Delta Sharing untuk tabel yang jarang diakses, karena Anda bertanggung jawab atas biaya keluar dari wilayah cloud ke wilayah cloud. Jika Anda harus berbagi data yang sering diakses antar wilayah atau antar penyedia cloud, lihat: Memantau dan mengelola biaya lalu lintas keluar Berbagi Delta (untuk penyedia).

Ketahui batasan berikut saat menggunakan fitur berbagi Databricks-to-Databricks:

  • Grafik silsilah dibuat di tingkat metastore, dan tidak lintas wilayah atau batas platform. Ini berlaku bahkan jika sebuah sumber daya dibagikan di seluruh metastores dalam akun Databricks yang sama: informasi silsilah dari sumber tidak terlihat di tujuan, dan sebaliknya.
  • Kontrol akses didefinisikan pada tingkat metastore, dan tidak lintas wilayah atau batas platform. Jika sumber daya memiliki hak istimewa yang ditetapkan untuk sumber daya tersebut dan sumber daya tersebut dibagikan ke metastore lain dalam akun yang sama, hak istimewa pada sumber daya tersebut tidak berlaku pada metastore tujuan. Anda harus memberikan hak istimewa pada share tujuan di lokasi tujuan.

Konfigurasi komputasi

Databricks merekomendasikan penggunaan kebijakan komputasi untuk membatasi kemampuan mengonfigurasi kluster berdasarkan serangkaian aturan. Kebijakan komputasi memungkinkan Anda membatasi pengguna untuk membuat kluster yang mendukung Unity Catalog, khususnya kluster yang menggunakan mode akses standar (sebelumnya mode akses bersama) atau mode akses khusus (sebelumnya pengguna tunggal atau mode akses yang ditetapkan).

Hanya kluster yang menggunakan salah satu mode akses ini yang dapat mengakses data di Unity Catalog. Semua komputasi tanpa server dan komputasi DBSQL mendukung Unity Catalog.

Databricks merekomendasikan mode akses standar untuk semua beban kerja. Gunakan mode akses khusus hanya jika fungsionalitas yang diperlukan tidak didukung oleh mode akses standar. Lihat mode akses.