Objek data di databricks lakehouse

  • Artikel

Databricks lakehouse mengatur data yang disimpan dengan Delta Lake di penyimpanan objek cloud dengan hubungan yang familier seperti database, tabel, dan tampilan. Model ini menggabungkan banyak manfaat gudang data perusahaan dengan skalabilitas dan fleksibilitas data lake. Pelajari selengkapnya tentang cara kerja model ini, dan hubungan antara data objek dan metadata sehingga Anda dapat menerapkan praktik terbaik saat merancang dan menerapkan Databricks lakehouse untuk organisasi Anda.

Objek data apa yang ada di data lakehouse Databricks?

Arsitektur databricks lakehouse menggabungkan data yang disimpan dengan protokol Delta Lake dalam penyimpanan objek cloud dengan metadata yang terdaftar ke metastore. Ada lima objek utama di databricks lakehouse:

  • Katalog: pengelompokan database.
  • Database atau skema: pengelompokan objek dalam katalog. Database berisi tabel, tampilan, dan fungsi.
  • Tabel: kumpulan baris dan kolom yang disimpan sebagai file data dalam penyimpanan objek.
  • Tampilan: kueri tersimpan biasanya terhadap satu atau beberapa tabel atau sumber data.
  • Fungsi: logika tersimpan yang mengembalikan nilai skalar atau sekumpulan baris.

Unity Catalog object model diagram

Untuk informasi tentang mengamankan objek dengan Unity Catalog, lihat model objek yang dapat diamankan.

Apa itu metastore?

Metastore berisi semua metadata yang menentukan objek data di lakehouse. Azure Databricks menyediakan opsi metastore berikut:

  • Metastore Unity Catalog: Unity Catalog menyediakan kontrol akses terpusat, audit, silsilah data, dan kemampuan penemuan data. Anda membuat metastore Unity Catalog di tingkat akun Azure Databricks, dan satu metastore dapat digunakan di beberapa ruang kerja.

    Setiap metastore Unity Catalog dikonfigurasi dengan lokasi penyimpanan akar dalam kontainer Azure Data Lake Storage Gen2 di akun Azure Anda. Lokasi penyimpanan ini digunakan secara default untuk menyimpan data untuk tabel terkelola.

    Di Katalog Unity, data aman secara default. Awalnya, pengguna tidak memiliki akses ke data di metastore. Akses dapat diberikan oleh admin metastore atau pemilik objek. Objek yang dapat diamankan dalam Katalog Unity bersifat hierarkis dan hak istimewa diwariskan ke bawah. Unity Catalog menawarkan satu tempat untuk mengelola kebijakan akses data. Pengguna dapat mengakses data di Unity Catalog dari ruang kerja apa pun yang dilampirkan metastore. Untuk informasi selengkapnya, lihat Mengelola hak istimewa di Katalog Unity.

  • Metastore Apache Hive bawaan (warisan): Setiap ruang kerja Azure Databricks menyertakan metastore Apache Hive bawaan sebagai layanan terkelola. Instans metastore disebarkan ke setiap kluster dan mengakses metadata dengan aman dari repositori pusat untuk setiap ruang kerja pelanggan.

    Metastore Apache Hive menyediakan model tata kelola data yang kurang terpusat daripada Katalog Unity. Secara default, kluster memungkinkan semua pengguna mengakses semua data yang dikelola oleh metastore Apache Hive bawaan ruang kerja kecuali kontrol akses tabel diaktifkan untuk kluster tersebut. Untuk informasi selengkapnya, lihat Kontrol akses tabel metastore Apache Hive (warisan).

    Kontrol akses tabel tidak disimpan di tingkat akun, dan oleh karena itu harus dikonfigurasi secara terpisah untuk setiap ruang kerja. Untuk memanfaatkan model tata kelola data terpusat dan disederhanakan yang disediakan oleh Unity Catalog, Databricks menyarankan agar Anda meningkatkan tabel yang dikelola oleh metastore Apache Hive ruang kerja Anda ke metastore Unity Catalog.

  • Metastore Apache Hive Eksternal (warisan): Anda juga dapat membawa metastore Anda sendiri ke Azure Databricks. Kluster Azure Databricks dapat tersambung ke metastore Apache Hive eksternal yang ada. Anda bisa menggunakan kontrol akses tabel untuk mengelola izin di metastore eksternal. Kontrol akses tabel tidak disimpan di metastore eksternal, dan oleh karena itu harus dikonfigurasi secara terpisah untuk setiap ruang kerja. Databricks merekomendasikan agar Anda menggunakan Unity Catalog sebagai gantinya untuk model tata kelolanya yang sederhana dan berpusat pada akun.

Terlepas dari metastore yang Anda gunakan, Azure Databricks menyimpan semua data tabel dalam penyimpanan objek di akun cloud Anda.

Apa itu katalog?

Katalog adalah abstraksi tertinggi (atau biji-bijian terkoar) dalam model relasional Databricks lakehouse. Setiap database akan dikaitkan dengan katalog. Katalog ada sebagai objek dalam metastore.

Sebelum pengenalan Unity Catalog, Azure Databricks menggunakan namespace dua tingkat. Katalog adalah tingkat ketiga dalam model namespacing Katalog Unity:

catalog_name.database_name.table_name

Metastore Apache Hive bawaan hanya mendukung satu katalog, hive_metastore.

Apa itu database?

Database adalah kumpulan objek data, seperti tabel atau tampilan (juga disebut "relasi"), dan fungsi. Di Azure Databricks, istilah "skema" dan "database" digunakan secara bergantian (sedangkan dalam banyak sistem relasional, database adalah kumpulan skema).

Database akan selalu dikaitkan dengan lokasi pada penyimpanan objek cloud. Anda dapat secara opsional menentukan LOCATION saat mendaftarkan database, mengingat bahwa:

  • Yang LOCATION terkait dengan database selalu dianggap sebagai lokasi terkelola.
  • Membuat database tidak membuat file apa pun di lokasi target.
  • Database LOCATION akan menentukan lokasi default untuk data semua tabel yang terdaftar ke database tersebut.
  • Berhasil menghilangkan database akan secara rekursif menghilangkan semua data dan file yang disimpan di lokasi terkelola.

Interaksi antara lokasi yang dikelola oleh database dan file data ini sangat penting. Untuk menghindari penghapusan data secara tidak sengaja:

  • Jangan bagikan lokasi database di beberapa definisi database.
  • Jangan mendaftarkan database ke lokasi yang sudah berisi data.
  • Untuk mengelola siklus hidup data secara independen dari database, simpan data ke lokasi yang tidak disarangkan di bawah lokasi database apa pun.

Apa itu meja?

Tabel Azure Databricks adalah kumpulan data terstruktur. Tabel Delta menyimpan data sebagai direktori file pada penyimpanan objek cloud dan mendaftarkan metadata tabel ke metastore dalam katalog dan skema. Karena Delta Lake adalah penyedia penyimpanan default untuk tabel yang dibuat di Azure Databricks, semua tabel yang dibuat di Databricks adalah tabel Delta, secara default. Karena tabel Delta menyimpan data di penyimpanan objek cloud dan memberikan referensi ke data melalui metastore, pengguna di seluruh organisasi dapat mengakses data menggunakan API pilihan mereka; pada Databricks, ini termasuk SQL, Python, PySpark, Scala, dan R.

Perhatikan bahwa dimungkinkan untuk membuat tabel pada Databricks yang bukan tabel Delta. Tabel ini tidak didukung oleh Delta Lake, dan tidak akan memberikan transaksi ACID dan performa tabel Delta yang dioptimalkan. Tabel yang termasuk dalam kategori ini mencakup tabel yang terdaftar terhadap data dalam sistem eksternal dan tabel yang terdaftar terhadap format file lain di data lake. Lihat Koneksi ke sumber data.

Ada dua jenis tabel di Databricks, tabel terkelola dan tidak dikelola (atau eksternal).

Catatan

Perbedaan Tabel Langsung Delta antara tabel langsung dan tabel langsung streaming tidak diberlakukan dari perspektif tabel.

Apa itu tabel terkelola?

Azure Databricks mengelola metadata dan data untuk tabel terkelola; saat Anda menghapus tabel, Anda juga menghapus data yang mendasar. Analis data dan pengguna lain yang sebagian besar bekerja di SQL mungkin lebih suka perilaku ini. Tabel terkelola adalah default saat membuat tabel. Data untuk tabel terkelola berada di LOCATION database tempat tabel tersebut didaftarkan. Hubungan terkelola antara lokasi data dan database ini berarti bahwa untuk memindahkan tabel terkelola ke database baru, Anda harus menulis ulang semua data ke lokasi baru.

Ada sejumlah cara untuk membuat tabel terkelola, termasuk:

CREATE TABLE table_name AS SELECT * FROM another_table

CREATE TABLE table_name (field_name1 INT, field_name2 STRING)

df.write.saveAsTable("table_name")

Apa itu tabel yang tidak dikelola?

Azure Databricks hanya mengelola metadata untuk tabel yang tidak dikelola (eksternal) ; saat Anda menghapus tabel, Anda tidak memengaruhi data yang mendasar. Tabel yang tidak dikelola akan selalu menentukan LOCATION selama pembuatan tabel; Anda dapat mendaftarkan direktori file data yang ada sebagai tabel atau menyediakan jalur saat tabel pertama kali ditentukan. Karena data dan metadata dikelola secara independen, Anda dapat mengganti nama tabel atau mendaftarkannya ke database baru tanpa perlu memindahkan data apa pun. Teknisi data sering lebih suka tabel yang tidak dikelola dan fleksibilitas yang mereka berikan untuk data produksi.

Ada sejumlah cara untuk membuat tabel yang tidak dikelola, termasuk:

CREATE TABLE table_name
USING DELTA
LOCATION '/path/to/existing/data'

CREATE TABLE table_name
(field_name1 INT, field_name2 STRING)
LOCATION '/path/to/empty/directory'

df.write.option("path", "/path/to/empty/directory").saveAsTable("table_name")

Apa itu tampilan?

Tampilan menyimpan teks untuk kueri biasanya terhadap satu atau beberapa sumber data atau tabel di metastore. Di Databricks, tampilan setara dengan Spark DataFrame yang bertahan sebagai objek dalam database. Tidak seperti DataFrames, Anda dapat mengkueri tampilan dari bagian mana pun dari produk Databricks, dengan asumsi Anda memiliki izin untuk melakukannya. Membuat tampilan tidak memproses atau menulis data apa pun; hanya teks kueri yang didaftarkan ke metastore dalam database terkait.

Apa itu tampilan sementara?

Tampilan sementara memiliki cakupan dan persistensi terbatas dan tidak terdaftar ke skema atau katalog. Masa pakai tampilan sementara berbeda berdasarkan lingkungan yang Anda gunakan:

  • Di buku catatan dan pekerjaan, tampilan sementara dilingkupkan ke tingkat buku catatan atau skrip. Mereka tidak dapat direferensikan di luar buku catatan tempat buku catatan dideklarasikan, dan tidak akan ada lagi ketika buku catatan terlepas dari kluster.
  • Di Databricks SQL, tampilan sementara dilingkup ke tingkat kueri. Beberapa pernyataan dalam kueri yang sama dapat menggunakan tampilan sementara, tetapi tidak dapat direferensikan dalam kueri lain, bahkan dalam dasbor yang sama.
  • Tampilan sementara global dilingkup ke tingkat kluster dan dapat dibagikan antara notebook atau pekerjaan yang berbagi sumber daya komputasi. Databricks merekomendasikan penggunaan tampilan dengan ACL tabel yang sesuai alih-alih tampilan sementara global.

Apa itu fungsi?

Fungsi memungkinkan Anda mengaitkan logika yang ditentukan pengguna dengan database. Fungsi dapat mengembalikan nilai skalar atau sekumpulan baris. Fungsi digunakan untuk mengagregasi data. Azure Databricks memungkinkan Anda menyimpan fungsi dalam berbagai bahasa tergantung pada konteks eksekusi Anda, dengan SQL didukung secara luas. Anda dapat menggunakan fungsi untuk menyediakan akses terkelola ke logika kustom di berbagai konteks pada produk Databricks.

Bagaimana cara kerja objek relasional di Tabel Langsung Delta?

Tabel Langsung Delta menggunakan sintaksis deklaratif untuk menentukan dan mengelola penyebaran DDL, DML, dan infrastruktur. Tabel Langsung Delta menggunakan konsep "skema virtual" selama perencanaan dan eksekusi logika. Tabel Langsung Delta dapat berinteraksi dengan database lain di lingkungan Databricks Anda, dan Tabel Langsung Delta dapat menerbitkan dan mempertahankan tabel untuk kueri di tempat lain dengan menentukan database target dalam pengaturan konfigurasi alur.

Semua tabel yang dibuat dalam Tabel Langsung Delta adalah tabel Delta. Saat menggunakan Unity Catalog dengan Tabel Langsung Delta, semua tabel adalah tabel terkelola Unity Catalog. Jika Katalog Unity tidak aktif, tabel dapat dinyatakan sebagai tabel terkelola atau tidak terkelola.

Meskipun tampilan dapat dideklarasikan dalam Tabel Langsung Delta, tampilan ini harus dianggap sebagai tampilan sementara yang dilingkup ke alur. Tabel sementara dalam Tabel Langsung Delta adalah konsep unik: tabel ini menyimpan data ke penyimpanan tetapi tidak menerbitkan data ke database target.

Beberapa operasi, seperti APPLY CHANGES INTO, akan mendaftarkan tabel dan tampilan ke database; nama tabel akan dimulai dengan garis bawah (_) dan tampilan akan memiliki nama tabel yang dinyatakan sebagai target APPLY CHANGES INTO operasi. Tampilan meminta tabel tersembunyi yang sesuai untuk mewujudkan hasilnya.