Skema Langsung (Legacy)
Artikel ini memberikan gambaran umum tentang sintaksis dan perilaku warisan untuk skema virtual LIVE.
Skema virtual LIVE adalah fitur warisan dari alur DLT dan dianggap tidak digunakan lagi. Anda masih dapat menggunakan mode penerbitan warisan dan skema virtual LIVE untuk alur yang dibuat dengan mode ini.
Dukungan untuk skema virtual warisan LIVE dan mode penerbitan warisan akan dihapus dalam versi Azure Databricks di masa mendatang.
Nota
Alur mode penerbitan warisan ditunjukkan di bidang Ringkasan dari antarmuka pengguna pengaturan alur DLT. Anda juga dapat mengonfirmasi apakah pipeline menggunakan modus penerbitan lama jika bidang target ditetapkan dalam spesifikasi JSON untuk pipeline.
Anda tidak dapat menggunakan UI konfigurasi alur untuk membuat alur baru dengan mode penerbitan warisan. Jika Anda perlu menyebarkan alur baru menggunakan sintaks LIVE warisan, hubungi perwakilan akun Databricks Anda.
Apa itu skema virtual LIVE?
Nota
Skema virtual LIVE tidak lagi diperlukan untuk menganalisis dependensi himpunan data dalam mode penerbitan default untuk DLT.
Skema LIVE adalah konsep pemrograman di DLT yang menentukan batas virtual untuk semua himpunan data yang dibuat atau diperbarui dalam alur. Secara desain, skema LIVE tidak terkait langsung dengan himpunan data dalam skema yang diterbitkan. Sebagai gantinya, skema LIVE memungkinkan logika dalam alur direncanakan dan dijalankan meskipun pengguna tidak ingin menerbitkan himpunan data ke skema.
Dalam alur mode penerbitan klasik, Anda dapat menggunakan kata kunci LIVE untuk mereferensikan dataset lain dalam alur saat ini untuk dibaca, misalnya, SELECT * FROM LIVE.bronze_table. Dalam mode penerbitan default untuk alur DLT baru, sintaks ini diabaikan secara diam-diam, yang berarti bahwa pengidentifikasi yang tidak memenuhi syarat menggunakan skema saat ini. Lihat Tetapkan katalog dan skema target.
Mode penerbitan lama untuk pipeline
Skema virtual LIVE digunakan dengan mode penerbitan lama untuk alur DLT. Semua tabel yang dibuat sebelum 5 Februari 2025, menggunakan mode penerbitan warisan secara default.
Tabel berikut ini menjelaskan perilaku untuk semua tampilan materialisasi dan tabel streaming yang dibuat atau diperbarui dalam alur dalam mode penerbitan warisan:
| Opsi penyimpanan | Lokasi atau katalog penyimpanan | Skema target | Perilaku |
|---|---|---|---|
| Metastore Hive | Tidak ada yang ditentukan | Tidak ada yang ditentukan | Metadata dan data himpunan data disimpan ke akar DBFS. Tidak ada objek database yang terdaftar ke metastore Apache Hive. |
| Penyimpanan Metadata Hive | URI atau jalur file ke penyimpanan objek cloud. | Tidak ada yang ditentukan | Metadata dan data himpunan data disimpan ke lokasi penyimpanan yang ditentukan. Tidak ada objek database yang terdaftar ke metastore Apache Hive. |
| Metastore Hive | Tidak ada yang ditentukan | Skema yang sudah ada atau baru di metastore Apache Hive. | Metadata dan data himpunan data disimpan ke akar DBFS. Semua tampilan termaterialisasi dan tabel streaming dalam pipeline diterbitkan ke skema yang ditentukan dalam metastore Apache Hive. |
| Metastore Hive | URI atau jalur file ke penyimpanan objek cloud. | Skema yang ada atau baru di metastore Hive. | Metadata dan data himpunan data disimpan ke lokasi penyimpanan yang ditentukan. Semua tampilan materialisasi dan tabel streaming dalam pipeline diterbitkan ke skema yang ditentukan dalam metastore Hive. |
| Katalog Unity | Katalog Unity Catalog yang sudah ada. | Tidak ada yang ditentukan | Metadata dan data himpunan data disimpan di lokasi penyimpanan default yang terkait dengan katalog target. Tidak ada objek database yang terdaftar ke Katalog Unity. |
| Katalog Unity | Katalog Unity Catalog yang sudah ada. | Skema yang sudah ada atau baru di Katalog Unity. | Metadata dan data himpunan data disimpan di lokasi penyimpanan default yang terkait dengan skema atau katalog target. Semua tampilan materialisasi dan tabel streaming dalam alur diterbitkan ke skema yang ditentukan di Katalog Unity. |
Memperbarui kode sumber dari skema LIVE
Alur yang dikonfigurasi untuk dijalankan dengan mode penerbitan default baru akan mengabaikan sintaks skema LIVE tanpa pemberitahuan. Secara default, semua pembacaan tabel menggunakan katalog dan skema yang ditentukan dalam konfigurasi alur.
Untuk sebagian besar jalur pemrosesan yang sudah ada, perubahan perilaku ini tidak berdampak, karena perilaku skema virtual LIVE lawas juga mengarahkan pengambilan data ke katalog dan skema yang ditentukan dalam konfigurasi jalur pemrosesan.
Penting
Kode warisan dengan pembacaan yang memanfaatkan katalog dan skema default ruang kerja memerlukan pembaruan kode. Pertimbangkan definisi tampilan materialisasi berikut:
CREATE MATERIALIZED VIEW silver_table
AS SELECT * FROM raw_data
Dalam mode penerbitan lama, pembacaan tanpa kualifikasi dari tabel raw_data menggunakan katalog dan skema default area kerja, misalnya, main.default.raw_data. Dalam mode alur default baru, katalog dan skema yang digunakan secara default adalah yang dikonfigurasi dalam konfigurasi alur. Untuk memastikan bahwa kode ini terus berfungsi seperti yang diharapkan, perbarui referensi untuk menggunakan pengidentifikasi yang sepenuhnya memenuhi syarat untuk tabel, seperti dalam contoh berikut:
CREATE MATERIALIZED VIEW silver_table
AS SELECT * FROM main.default.raw_data
Bekerja dengan log peristiwa untuk alur mode penerbitan warisan Katalog Unity
Penting
TVF event_log tersedia untuk jalur mode penerbitan lama yang menerbitkan tabel ke Unity Catalog. Perilaku bawaan untuk pipeline baru menerbitkan log peristiwa ke katalog target dan skema yang dikonfigurasi untuk pipeline tersebut. Lihat Mengkueri log peristiwa.
Tabel yang dikonfigurasi dengan metastore Hive juga memiliki dukungan log peristiwa dan perilaku yang berbeda. Lihat Bekerja dengan log peristiwa untuk alur metastore Apache Hive.
Jika alur Anda menerbitkan tabel ke Unity Catalog dengan mode penerbitan lama, Anda harus menggunakan fungsi bernilai tabel (TVF) event_log untuk mengambil log peristiwa untuk alur tersebut. Anda mengambil catatan kejadian untuk jalur pipa dengan meneruskan ID jalur pipa atau nama tabel ke TVF. Misalnya, untuk mengambil rekaman log peristiwa untuk alur dengan ID 04c78631-3dd7-4856-b2a6-7d84e9b2638b:
SELECT * FROM event_log("04c78631-3dd7-4856-b2a6-7d84e9b2638b")
Untuk mengambil rekaman log peristiwa dari pipeline yang membuat atau memiliki tabel my_catalog.my_schema.table1:
SELECT * FROM event_log(TABLE(my_catalog.my_schema.table1))
Untuk memanggil TVF, Anda harus menggunakan kluster bersama atau gudang SQL. Misalnya, Anda dapat menggunakan notebook yang dilampirkan ke kluster bersama atau menggunakan editor SQL tersambung ke gudang SQL.
Untuk menyederhanakan kueri peristiwa untuk pipeline, pemilik pipeline dapat membuat tampilan di atas event_log TVF. Contoh berikut membuat tampilan di atas log peristiwa untuk alur. Tampilan ini digunakan dalam contoh kueri log peristiwa yang disertakan dalam artikel ini.
Nota
- TVF
event_loghanya dapat dipanggil oleh pemilik jalur. - Anda tidak dapat menggunakan fungsi bernilai tabel
event_logdalam pipeline atau kueri untuk mengakses log peristiwa dari lebih dari satu pipeline. - Anda tidak dapat berbagi tampilan yang dibuat melalui fungsi bernilai tabel
event_logdengan pengguna lain.
CREATE VIEW event_log_raw AS SELECT * FROM event_log("<pipeline-ID>");
Ganti <pipeline-ID> dengan pengidentifikasi unik untuk alur DLT. Anda dapat menemukan ID di panel detail Alur di Antarmuka DLT.
Setiap contoh dari eksekusi alur disebut pembaruan . Anda sering ingin mengekstrak informasi untuk pembaruan terbaru. Jalankan kueri berikut untuk menemukan pengidentifikasi untuk pembaruan terbaru dan simpan dalam tampilan sementara latest_update_id. Tampilan ini digunakan dalam contoh kueri log peristiwa yang disertakan dalam artikel ini:
CREATE OR REPLACE TEMP VIEW latest_update AS SELECT origin.update_id AS id FROM event_log_raw WHERE event_type = 'create_update' ORDER BY timestamp DESC LIMIT 1;