Menggunakan tabel streaming di Databricks SQL

Databricks merekomendasikan penggunaan tabel streaming untuk menyerap data menggunakan Databricks SQL. Sebuah tabel streaming adalah tabel yang terdaftar di Unity Catalog dengan dukungan tambahan untuk pemrosesan data secara streaming atau inkremental. Alur secara otomatis dibuat untuk setiap tabel streaming. Anda dapat menggunakan tabel streaming untuk pemuatan data bertahap dari Kafka dan penyimpanan objek cloud.

Nota

Untuk mempelajari cara menggunakan tabel Delta Lake sebagai sumber dan tujuan streaming, lihat Pembacaan dan penulisan streaming tabel Delta.

Persyaratan

Untuk menggunakan tabel streaming, Anda harus memenuhi persyaratan berikut.

Persyaratan ruang kerja:

Tabel streaming yang dibuat di Databricks SQL didukung oleh alur tanpa server. Ruang kerja Anda harus mendukung alur tanpa server untuk menggunakan fungsionalitas ini.

Akun Azure Databricks dengan fitur serverless diaktifkan. Untuk informasi selengkapnya, lihat Menyiapkan gudang SQL tanpa server.
Ruang kerja dengan Katalog Unity yang sudah diaktifkan. Untuk informasi selengkapnya, lihat Mulai menggunakan Katalog Unity.

Persyaratan komputasi:

Anda harus menggunakan salah satu hal berikut:

Gudang SQL yang menggunakan saluran Current.
Komputasi dengan mode akses standar (sebelumnya mode akses bersama) pada Databricks Runtime 13.3 LTS atau lebih tinggi.

Komputasi dengan mode akses khusus (sebelumnya mode akses pengguna tunggal) pada Databricks Runtime 15.4 LTS atau lebih tinggi.

Pada Databricks Runtime 15.3 ke bawah, Anda tidak dapat menggunakan komputasi khusus untuk mengkueri tabel streaming yang dimiliki oleh pengguna lain. Anda dapat menggunakan komputasi khusus pada Databricks Runtime 15.3 ke bawah hanya jika Anda memiliki tabel streaming. Pembuat tabel adalah si pemiliknya.

Databricks Runtime 15.4 LTS ke atas mendukung kueri tabel yang dihasilkan alur pada komputasi khusus, bahkan jika Anda bukan pemilik tabel. Anda mungkin dikenakan biaya untuk sumber daya komputasi tanpa server saat menggunakan komputasi khusus untuk menjalankan operasi pemfilteran data. Lihat Kontrol akses halus pada komputasi khusus.

Persyaratan izin:

USE CATALOG dan USE SCHEMA hak akses pada katalog dan skema tempat Anda membuat tabel streaming.
Hak istimewa CREATE TABLE dalam skema tempat Anda membuat tabel streaming.
Hak istimewa untuk mengakses tabel atau lokasi yang menyediakan data sumber untuk tabel streaming Anda.

Membuat tabel streaming

Tabel streaming ditentukan oleh kueri SQL di Databricks SQL. Saat Anda membuat tabel streaming, data yang saat ini ada di tabel sumber digunakan untuk membangun tabel streaming. Setelah itu, Anda me-refresh tabel, biasanya sesuai jadwal, untuk menarik data apa pun yang ditambahkan dalam tabel sumber untuk ditambahkan ke tabel streaming.

Saat membuat tabel streaming, Anda dianggap sebagai pemilik tabel.

Untuk membuat tabel streaming dari tabel yang sudah ada, gunakan CREATE STREAMING TABLE pernyataan , seperti dalam contoh berikut:

CREATE OR REFRESH STREAMING TABLE sales
  SCHEDULE EVERY 1 hour
  AS SELECT product, price FROM STREAM raw_data;

Dalam hal ini, tabel streaming sales dibuat dari kolom tertentu pada tabel raw_data, dengan jadwal untuk diperbarui setiap jam. Kueri yang digunakan harus berupa kueri streaming . Gunakan kata kunci STREAM untuk memanfaatkan semantik streaming dalam membaca dari sumber.

Komputasi yang digunakan untuk refresh

Saat Anda membuat tabel streaming menggunakan CREATE OR REFRESH STREAMING TABLE pernyataan , refresh data awal dan populasi segera dimulai. Operasi ini tidak menggunakan komputasi gudang Databricks SQL. Sebagai gantinya, tabel streaming mengandalkan alur tanpa server untuk pembuatan dan refresh. Alur tanpa server khusus secara otomatis dibuat dan dikelola oleh sistem untuk setiap tabel streaming.

Memuat file dengan Auto Loader

Untuk membuat tabel streaming dari file dalam volume, Anda menggunakan Auto Loader. Gunakan Auto Loader untuk sebagian besar tugas penyerapan data dari penyimpanan objek cloud. Auto Loader dan pipeline dirancang untuk memuat data yang terus bertambah secara inkremental dan idempoten saat tiba di penyimpanan cloud.

Untuk menggunakan Auto Loader di Databricks SQL, gunakan fungsi .read_files Contoh berikut menunjukkan penggunaan Auto Loader untuk membaca volume file JSON ke dalam tabel streaming:

CREATE OR REFRESH STREAMING TABLE sales
  SCHEDULE EVERY 1 hour
  AS SELECT * FROM STREAM read_files(
    "/Volumes/my_catalog/my_schema/my_volume/path/to/data",
    format => "json"
  );

Untuk membaca data dari penyimpanan cloud, Anda juga dapat menggunakan Auto Loader:

CREATE OR REFRESH STREAMING TABLE sales
  SCHEDULE EVERY 1 hour
  AS SELECT *
  FROM STREAM read_files(
    'abfss://myContainer@myStorageAccount.dfs.core.windows.net/analysis/*/*/*.json',
    format => "json"
  );

Untuk mempelajari tentang Auto Loader, lihat Apa itu Auto Loader?. Untuk mempelajari selengkapnya tentang menggunakan Auto Loader di SQL, dengan contoh, lihat Memuat data dari penyimpanan objek.

Penyerapan streaming dari sumber lain

Misalnya pengambilan data dari sumber lain, termasuk Kafka, dapat dilihat pada Memuat data melalui pipa pemrosesan.

Menerapkan penangkapan data perubahan (CDC) dengan alur CDC Otomatis

Penting

Fitur ini ada di Beta. Tersedia di Databricks SQL menggunakan Current kanal.

Gunakan klausul FLOW AUTO CDC untuk memproses rekaman *change data capture* (CDC) dari sumber ke dalam tabel streaming. Sebelumnya, pernyataan ini MERGE INTO umumnya digunakan untuk memproses rekaman CDC di Azure Databricks. Namun, MERGE INTO dapat menghasilkan hasil yang salah karena rekaman yang tidak berurutan atau memerlukan logika kompleks untuk mengurutkan ulang rekaman. Lihat Mengubah pengambilan data dan rekam jepret.

AUTO CDC menyederhanakan CDC dengan menangani rekaman yang tidak berurutan secara otomatis. Anda menentukan kunci untuk mengidentifikasi rekaman, kolom urutan untuk pemesanan, dan apakah akan menyimpan hasil sebagai SCD tipe 1 (pembaruan langsung) atau SCD tipe 2 (pelacakan riwayat).

Contoh berikut membuat tabel streaming yang menerapkan perubahan CDC menggunakan SCD tipe 1:

CREATE OR REFRESH STREAMING TABLE target
  FLOW AUTO CDC
  FROM stream(cdc_data.users)
  KEYS (userId)
  SEQUENCE BY sequenceNum
  STORED AS SCD TYPE 1;

Contoh berikut menggunakan SCD tipe 2 untuk mempertahankan riwayat perubahan:

CREATE OR REFRESH STREAMING TABLE target
  FLOW AUTO CDC
  FROM stream(cdc_data.users)
  KEYS (userId)
  APPLY AS DELETE WHEN operation = "DELETE"
  SEQUENCE BY sequenceNum
  COLUMNS * EXCEPT (operation, sequenceNum)
  STORED AS SCD TYPE 2;

Untuk detail selengkapnya tentang opsi dan perilaku CDC Otomatis, lihat API CDC OTOMATIS: Menyederhanakan perubahan pengambilan data dengan alur. Untuk referensi sintaks lengkap, lihat CREATE STREAMING TABLE.

Menyerap data baru saja

Secara default, read_files fungsi membaca semua data yang ada di folder sumber selama pembuatan tabel, lalu memproses rekaman yang baru tiba dengan setiap refresh.

Untuk menghindari penyerapan data yang sudah ada di folder sumber pada saat pembuatan tabel, atur includeExistingFiles opsi ke false. Ini berarti bahwa hanya data yang tiba di folder setelah pembuatan tabel diproses. Contohnya:

CREATE OR REFRESH STREAMING TABLE sales
  SCHEDULE EVERY 1 hour
  AS SELECT *
  FROM STREAM read_files(
    '/path/to/files',
    includeExistingFiles => false
  );

Mengatur saluran runtime

Tabel streaming yang dibuat menggunakan gudang SQL secara otomatis disegarkan menggunakan pipelin. Pipeline menggunakan runtime pada saluran current secara default. Lihat Catatan rilis Lakeflow Spark Declarative Pipelines dan proses peningkatan rilis untuk mempelajari tentang proses rilis.

Databricks merekomendasikan penggunaan current saluran untuk beban kerja produksi. Fitur baru pertama kali dirilis ke saluran preview. Anda dapat mengatur alur ke saluran pratinjau untuk menguji fitur baru dengan menentukan preview sebagai properti tabel menggunakan CREATE OR REFRESH STREAMING TABLE pernyataan. Untuk memperbarui saluran untuk tabel streaming yang ada, Anda harus menjalankan CREATE OR REFRESH STREAMING TABLE dengan yang diperbarui TBLPROPERTIES.

Contoh kode berikut menunjukkan cara mengatur saluran ke pratinjau:

CREATE OR REFRESH STREAMING TABLE sales
  TBLPROPERTIES ('pipelines.channel' = 'preview')
  SCHEDULE EVERY 1 hour
  AS SELECT *
  FROM STREAM raw_data;

Menyembunyikan data sensitif

Anda dapat menggunakan tabel streaming untuk menyembunyikan data sensitif dari pengguna yang mengakses tabel. Salah satu pendekatannya adalah menentukan kueri sehingga mengecualikan kolom atau baris sensitif sepenuhnya. Atau, Anda bisa menerapkan masker kolom atau filter baris berdasarkan izin pengguna kueri. Misalnya, Anda mungkin menyembunyikan tax_id kolom untuk pengguna yang tidak berada dalam grup HumanResourcesDept. Untuk melakukan ini, gunakan sintaks ROW FILTER dan MASK selama pembuatan tabel streaming. Untuk informasi selengkapnya, lihat Filter baris dan masker kolom.

Memperbarui tabel streaming

Tabel streaming secara otomatis membuat dan menggunakan alur tanpa server untuk memproses operasi refresh. Refresh dikelola oleh pipeline dan pembaruan dipantau oleh gudang SQL Databricks yang digunakan untuk membuat tabel streaming. Tabel streaming dapat diperbarui menggunakan alur yang berjalan sesuai jadwal.

Bahkan jika Anda memiliki refresh terjadwal, Anda dapat memanggil refresh manual kapan saja. Refresh ditangani oleh alur yang sama yang secara otomatis dibuat bersama dengan tabel streaming.

Untuk me-refresh tabel streaming:

REFRESH STREAMING TABLE sales;

Anda dapat memeriksa status refresh terbaru dengan DESCRIBE TABLE EXTENDED.

Nota

Anda mungkin perlu me-refresh tabel streaming sebelum menggunakan kueri perjalanan waktu .

Untuk mempelajari cara menjadwalkan refresh, lihat Menjadwalkan refresh di Databricks SQL. Penyegaran terjadwal dapat memiliki pemberitahuan pembaruan, dan Anda dapat mengatur mode kinerja untuk penyegaran.

Cara kerja refresh

Refresh tabel streaming hanya memeriksa baris baru yang telah tiba setelah pembaruan terakhir, dan hanya menambahkan data baru.

Setiap refresh menggunakan definisi tabel streaming saat ini untuk memproses data baru ini. Memodifikasi definisi tabel streaming tidak secara otomatis menghitung ulang data yang ada. Jika modifikasi tidak kompatibel dengan data yang ada (misalnya, mengubah jenis data), refresh berikutnya gagal dengan kesalahan.

Contoh berikut menjelaskan bagaimana perubahan pada definisi tabel streaming memengaruhi perilaku refresh:

Menghapus filter tidak memproses ulang baris yang difilter sebelumnya.
Mengubah proyeksi kolom tidak akan memengaruhi cara data yang ada diproses.
Penggabungan dengan rekam jepret statis menggunakan status rekam jepret pada waktu pemrosesan pertama kali. Data yang terlambat tiba yang akan cocok dengan rekam jepret yang diperbarui diabaikan. Hal ini dapat menyebabkan fakta dihilangkan jika dimensi terlambat.
Modifikasi pada fungsi CAST dari kolom yang sudah ada dapat menyebabkan kesalahan.

Jika data Anda berubah dengan cara yang tidak dapat didukung dalam tabel streaming yang ada, Anda dapat melakukan refresh penuh.

Memperbarui sepenuhnya tabel streaming

Refresh penuh memproses ulang semua data yang tersedia di sumber dengan definisi terbaru. Tidak disarankan untuk memanggil refresh penuh pada sumber yang tidak menyimpan seluruh riwayat data atau memiliki periode retensi singkat, seperti Kafka, karena refresh penuh memotong data yang ada. Anda mungkin tidak dapat memulihkan data lama jika data tidak lagi tersedia di sumbernya.

Contohnya:

REFRESH STREAMING TABLE sales FULL;

Mengubah jadwal untuk tabel streaming

Anda dapat mengonfigurasi tabel streaming Databricks SQL untuk di-refresh secara otomatis berdasarkan jadwal yang ditentukan, atau untuk memicu saat data upstram diubah. Tabel berikut ini memperlihatkan opsi berbeda untuk menjadwalkan refresh.

Metode	Deskripsi	Contoh kasus penggunaan
Manual	Refresh sesuai permintaan menggunakan pernyataan SQL `REFRESH` , atau melalui UI ruang kerja.	Pengembangan, pengujian, pembaruan ad-hoc.
`TRIGGER ON UPDATE`	Tentukan tabel streaming agar diperbarui secara otomatis saat data upstream berubah.	Beban kerja produksi dengan SLA kesegaran data atau periode refresh yang tidak dapat diprediksi.
`SCHEDULE`	Tentukan tabel streaming untuk di-refresh pada interval waktu yang ditentukan.	Persyaratan refresh berbasis waktu yang dapat diprediksi.
Tugas SQL dalam pekerjaan	Refresh diorkestrasi melalui Pekerjaan Lakeflow.	Alur kompleks dengan dependensi lintas sistem.

Pembaruan manual

Untuk me-refresh tabel streaming secara manual, Anda dapat memanggil refresh dari Databricks SQL, atau menggunakan UI ruang kerja.

REFRESH pernyataan

Untuk me-refresh alur menggunakan Databricks SQL:

Di Editor SQL, jalankan pernyataan berikut:
```
REFRESH MATERIALIZED VIEW <table-name>;
```

Untuk informasi selengkapnya, lihat REFRESH (MATERIALIZED VIEW atau STREAMING TABLE).

Antarmuka Pengguna Ruang Kerja

Untuk memperbarui pipeline di antarmuka pengguna ruang kerja:

Di ruang kerja Azure Databricks, klik ikon Alur Kerja.Pekerjaan & Pipeline.
Pilih alur yang ingin Anda refresh dari daftar.
Klik tombol Mulai .

Saat alur di-refresh, Anda akan melihat pembaruan di UI.

Pemicu pada pembaruan

Klausa TRIGGER ON UPDATE secara otomatis memperbarui tabel streaming saat data sumber upstream berubah. Ini menghilangkan kebutuhan untuk mengoordinasikan jadwal di seluruh alur. Tabel streaming tetap terbaru tanpa mengharuskan pengguna untuk mengetahui kapan pekerjaan upstream yang selesai atau memelihara logika penjadwalan yang kompleks.

Ini adalah pendekatan yang direkomendasikan untuk beban kerja produksi, terutama ketika dependensi upstream tidak berjalan pada jadwal yang dapat diprediksi. Setelah dikonfigurasi, tabel streaming memantau tabel sumbernya dan me-refresh secara otomatis saat perubahan di salah satu sumber hulu terdeteksi.

Limitations

Batas dependensi upstream: Tabel streaming dapat memantau batas maksimum 10 tabel upstream dan 30 tampilan upstream. Untuk dependensi lainnya, pisahkan logika di beberapa tabel streaming.
Batas ruang kerja: Maksimal 1.000 tabel streaming dengan TRIGGER ON UPDATE dapat ada per ruang kerja. Silakan hubungi dukungan Databricks jika diperlukan lebih dari 1.000 tabel streaming.
Interval minimum: Interval pemicu minimum adalah 1 menit.

Contoh berikut menunjukkan cara mengatur pemicu pada pembaruan saat menentukan tabel streaming.

Membuat tabel streaming dengan pemicu pada pembaruan

Untuk membuat tabel streaming yang di-refresh secara otomatis saat data sumber berubah, sertakan TRIGGER ON UPDATE klausa dalam CREATE STREAMING TABLE pernyataan.

Contoh berikut membuat tabel streaming yang membaca pesanan pelanggan dan me-refresh setiap kali tabel sumber orders diperbarui:

CREATE OR REFRESH STREAMING TABLE catalog.schema.customer_orders
  TRIGGER ON UPDATE
AS SELECT
    o.customer_id,
    o.name,
    o.order_id
FROM STREAM catalog.schema.orders o;

Pembatasan frekuensi refresh

Jika data upstream sering di-refresh, gunakan AT MOST EVERY untuk membatasi seberapa sering tampilan di-refresh dan membatasi biaya komputasi. Ini berguna ketika tabel sumber sering diperbarui tetapi konsumen hilir tidak memerlukan data real time. Kata kunci INTERVAL harus ada sebelum nilai waktu.

Contoh berikut membatasi tabel streaming untuk di-refresh paling lama setiap 5 menit, bahkan jika data sumber lebih sering berubah:

CREATE OR REFRESH STREAMING TABLE catalog.schema.customer_orders
  TRIGGER ON UPDATE AT MOST EVERY INTERVAL 5 MINUTES
AS SELECT
    o.customer_id,
    o.name,
    o.order_id
FROM STREAM catalog.schema.orders o;

Refresh terjadwal

Jadwal refresh dapat ditentukan langsung dalam definisi tabel streaming untuk menyegarkan tampilan pada interval waktu tetap. Pendekatan ini berguna ketika irama pembaruan data diketahui dan waktu refresh yang dapat diprediksi diinginkan.

Ketika ada jadwal refresh, Anda masih dapat menjalankan refresh manual kapan saja jika Anda memerlukan data yang diperbarui.

Databricks mendukung dua sintaks penjadwalan: SCHEDULE EVERY untuk interval sederhana dan SCHEDULE CRON untuk penjadwalan yang tepat. Kata kunci SCHEDULE dan SCHEDULE REFRESH setara secara semantik.

Untuk detail tentang sintaksis dan penggunaan SCHEDULE klausa, lihat CREATE STREAMING TABLE klausa SCHEDULE.

Saat jadwal dibuat, pekerjaan baru di Databricks secara otomatis ditetapkan untuk memproses pembaruan.

Untuk melihat jadwal, lakukan salah satu hal berikut ini:

Jalankan DESCRIBE EXTENDED pernyataan dari editor SQL di antarmuka pengguna Azure Databricks. Lihat DESCRIBE TABLE.
Gunakan Catalog Explorer untuk melihat tabel streaming. Jadwal tercantum di tab Gambaran Umum, di bawah Refresh status. Lihat Apa itu Catalog Explorer?.

Contoh berikut menunjukkan cara membuat tabel streaming dengan jadwal:

Jadwalkan setiap interval waktu

Contoh ini menjadwalkan refresh setiap 5 menit sekali:

CREATE OR REFRESH STREAMING TABLE catalog.schema.hourly_metrics
  SCHEDULE EVERY 5 MINUTES
AS SELECT
    event_id,
    event_time,
    event_type
FROM catalog.schema.raw_events;

Jadwalkan menggunakan cron

Contoh ini menjadwalkan refresh setiap 15 menit, pada seperempat jam zona waktu UTC:

CREATE OR REFRESH STREAMING TABLE catalog.schema.hourly_metrics
  SCHEDULE CRON '0 */15 * * * ?' AT TIME ZONE 'UTC'
AS SELECT
    event_id,
    event_time,
    event_type
FROM catalog.schema.raw_events;

Tugas SQL dalam pekerjaan

Refresh tabel streaming dapat diorkestrasi melalui Jobs Databricks dengan membuat tugas SQL yang mencakup perintah REFRESH STREAMING TABLE. Pendekatan ini mengintegrasikan pembaruan tabel streaming ke dalam alur kerja orkestrasi pekerjaan yang sudah ada.

Ada dua cara untuk membuat pekerjaan guna memperbarui tabel streaming.

Dari Editor SQL: Tulis REFRESH STREAMING TABLE perintah dan klik tombol Jadwalkan untuk membuat pekerjaan langsung dari kueri.
Dari antarmuka pengguna Pekerjaan: Buat pekerjaan baru, tambahkan jenis tugas SQL, dan lampirkan Kueri SQL atau Notebook dengan REFRESH STREAMING TABLE perintah .

Contoh berikut menunjukkan pernyataan SQL dalam tugas SQL yang me-refresh tabel streaming:

REFRESH STREAMING TABLE catalog.schema.sales;

Pendekatan ini sesuai ketika:

Alur multi-langkah yang kompleks memiliki dependensi di seluruh sistem.
Integrasi dengan orkestrasi pekerjaan yang ada diperlukan.
Pemberitahuan dan pemantauan tingkat pekerjaan diperlukan.

Tugas SQL memanfaatkan gudang SQL yang terkait dengan pekerjaan dan komputasi tanpa server yang melaksanakan penyegaran. Jika menggunakan penjadwalan berbasis definisi tabel streaming memenuhi persyaratan, beralih ke TRIGGER ON UPDATE atau SCHEDULE dapat menyederhanakan alur kerja.

Menambahkan jadwal ke tabel streaming yang sudah ada

Untuk mengatur jadwal setelah pembuatan, gunakan ALTER STREAMING TABLE pernyataan:

-- Alters the schedule to refresh the streaming table when its upstream
-- data gets updated.
ALTER STREAMING TABLE sales
  ADD TRIGGER ON UPDATE;

Mengubah jadwal atau pemicu yang ada

Jika tabel streaming sudah memiliki jadwal atau pemicu yang terkait, gunakan ALTER SCHEDULE atau ALTER TRIGGER ON UPDATE untuk mengubah konfigurasi refresh. Ini berlaku baik ketika mengubah dari satu jadwal ke jadwal lainnya, dari satu pemicu ke pemicu lainnya, atau ketika beralih antara jadwal dan pemicu.

Contoh berikut mengubah jadwal yang ada untuk di-refresh setiap 5 menit:

ALTER STREAMING TABLE catalog.schema.my_table
  ALTER SCHEDULE EVERY 5 MINUTES;

Menghilangkan jadwal atau pemicu

Untuk menghapus jadwal, gunakan ALTER ... DROP:

ALTER STREAMING TABLE catalog.schema.my_table
  DROP SCHEDULE;

Pantau status pembaruan

Anda dapat melihat status pembaruan tabel streaming dengan melihat jalur pipa yang mengelola tabel streaming di UI Pipelines atau dengan melihat Informasi Refresh yang dikembalikan oleh perintah DESCRIBE EXTENDED untuk tabel streaming.

DESCRIBE TABLE EXTENDED <table-name>;

Secara bergantian, Anda dapat melihat tabel streaming di Catalog Explorer dan melihat status refresh di sana:

Klik Katalog di bilah samping.
Di pohon Catalog Explorer di sebelah kiri, buka katalog dan pilih skema tempat tabel streaming Anda berada.
Buka item Tabel di bawah skema yang Anda pilih, dan klik tabel streaming.

Dari sini, Anda dapat menggunakan tab di bawah nama tabel streaming untuk melihat dan mengedit informasi tentang tabel streaming, termasuk:

Memperbarui status dan riwayat
Skema tabel
Data sampel (membutuhkan komputasi yang aktif)
Permissions
Silsilah data, termasuk tabel dan alur yang bergantung pada tabel streaming ini
Wawasan tentang penggunaan
Monitor yang telah Anda buat untuk tabel streaming ini

Tenggang waktu untuk pembaharuan

Refresh tabel streaming dijalankan dengan batas waktu yang membatasi berapa lama mereka dapat berjalan. Untuk tabel streaming yang dibuat atau diperbarui pada atau setelah 14 Agustus 2025, batas waktu diambil saat Anda memperbarui dengan menjalankan CREATE OR REFRESH:

Jika STATEMENT_TIMEOUT diatur, nilai tersebut digunakan. Lihat STATEMENT_TIMEOUT.
Jika tidak, batas waktu dari gudang SQL yang digunakan untuk menjalankan perintah digunakan.
Jika gudang tidak memiliki batas waktu yang dikonfigurasi, default 2 hari akan berlaku.

Batas waktu digunakan pada pembuatan awal, namun juga pada pembaruan terjadwal berikutnya.

Untuk tabel streaming yang terakhir diperbarui sebelum 14 Agustus 2025, batas waktu diatur ke 2 hari.

Contoh: Mengatur batas waktu untuk refresh tabel streaming Anda dapat secara eksplisit mengontrol berapa lama refresh tabel streaming diizinkan untuk dijalankan dengan mengatur batas waktu tingkat pernyataan saat membuat atau memperbarui tabel:

SET STATEMENT_TIMEOUT = '6h';

CREATE OR REFRESH STREAMING TABLE my_catalog.my_schema.my_st
  SCHEDULE EVERY 12 HOURS
AS SELECT * FROM large_source_table;

Ini mengatur agar tabel streaming di-refresh setiap 12 jam, dan jika proses refresh memakan waktu lebih dari 6 jam, batas waktu tercapai dan menunggu hingga refresh terjadwal berikutnya.

Cara refresh terjadwal menangani batas waktu

Batas waktu hanya disinkronkan saat Anda secara eksplisit menjalankan CREATE OR REFRESH.

Refresh terjadwal tetap menggunakan batas waktu yang dicatat selama CREATE OR REFRESH.
Mengubah batas waktu gudang saja tidak memengaruhi penyegaran terjadwal yang sudah ada.

Penting

Setelah mengubah batas waktu gudang, jalankan CREATE OR REFRESH lagi untuk menerapkan batas waktu baru ke refresh terjadwal di masa mendatang.

Mengontrol akses ke tabel streaming

Tabel streaming mendukung kontrol akses yang kaya untuk mendukung berbagi data sambil menghindari mengekspos data yang berpotensi privat. Pemilik tabel streaming atau pengguna dengan MANAGE hak istimewa dapat memberikan SELECT hak istimewa kepada pengguna lain. Pengguna dengan akses SELECT ke tabel streaming tidak memerlukan akses SELECT ke tabel yang dirujuk oleh tabel streaming. Kontrol akses ini memungkinkan berbagi data sambil mengontrol akses ke data yang mendasar.

Anda juga dapat memodifikasi pemilik tabel streaming.

Memberikan otoritas pada tabel streaming

Untuk memberikan akses ke tabel streaming, gunakan GRANT pernyataan :

GRANT <privilege_type> ON <st_name> TO <principal>;

Dapat privilege_type berupa:

SELECT - pengguna dapat SELECT tabel streaming.
REFRESH - pengguna dapat REFRESH tabel streaming. Refresh dijalankan menggunakan izin pemilik.

Contoh berikut membuat tabel streaming dan memberikan hak istimewa pilih dan refresh kepada pengguna:

CREATE OR REFRESH STREAMING TABLE st_name AS SELECT * FROM source_table;

-- Grant read-only access:
GRANT SELECT ON st_name TO read_only_user;

-- Grant read and refresh access:
GRANT SELECT ON st_name TO refresh_user;
GRANT REFRESH ON st_name TO refresh_user;

Untuk informasi selengkapnya tentang memberikan hak istimewa pada objek yang dapat diamankan Katalog Unity, lihat Referensi hak istimewa Katalog Unity.

Mencabut izin dari tabel streaming

Untuk mencabut akses dari tabel streaming, gunakan REVOKE pernyataan :

REVOKE privilege_type ON <st_name> FROM principal;

Ketika SELECT hak istimewa pada tabel sumber dicabut dari pemilik tabel streaming atau pengguna lain yang telah diberikan MANAGE atau SELECT hak istimewa pada tabel streaming, atau tabel sumber dihilangkan, pemilik tabel streaming atau akses yang diberikan pengguna masih dapat mengkueri tabel streaming. Namun, perilaku berikut terjadi:

Pemilik tabel streaming atau orang lain yang kehilangan akses ke tabel streaming tidak dapat lagi REFRESH tabel streaming tersebut, dan tabel streaming menjadi basi dari waktu ke waktu.
Jika diotomatisasi dengan jadwal, jadwal berikutnya REFRESH gagal atau tidak dijalankan.

Contoh berikut mencabut SELECT hak istimewa dari read_only_user:

REVOKE SELECT ON st_name FROM read_only_user;

Mengubah pemilik tabel streaming

Pengguna dengan MANAGE izin pada tabel streaming yang ditentukan di Databricks SQL dapat menyetel pemilik baru melalui Catalog Explorer. Pemilik baru dapat menjadi diri mereka sendiri atau perwakilan layanan tempat mereka memiliki peran Pengguna Perwakilan Layanan .

Dari ruang kerja Azure Databricks Anda, klik Katalog untuk membuka Catalog Explorer.
Pilih tabel streaming yang ingin Anda perbarui.
Di bilah sisi kanan, di bawah Tentang tabel streaming ini, temukan Pemilik, dan klik edit.

Nota

Jika Anda mendapatkan pesan yang memberi tahu Anda untuk memperbarui pemilik dengan mengubah Jalankan sebagai pengguna di pengaturan alur, maka tabel streaming ditentukan dalam Alur Deklaratif Lakeflow Spark, bukan Databricks SQL. Pesan menyertakan tautan ke pengaturan alur, tempat Anda dapat mengubah Jalankan sebagai pengguna.
Pilih pemilik baru untuk tabel streaming.

Pemilik secara otomatis memiliki hak istimewa MANAGE dan SELECT pada tabel streaming yang mereka miliki. Jika Anda mengatur perwakilan layanan sebagai pemilik untuk tabel streaming yang Anda miliki, dan Anda tidak secara eksplisit memiliki SELECT atau MANAGE hak istimewa pada tabel streaming, maka perubahan ini akan menyebabkan Anda kehilangan semua akses ke tabel streaming. Dalam hal ini, Anda diminta untuk secara eksplisit memberikan hak istimewa tersebut.

Pilih Grant MANAGE dan Berikan SELECT hak istimewa agar hak istimewa tersebut tersedia di Simpan.
Klik Simpan untuk mengubah pemilik.

Tabel streaming kini memiliki pemilik baru. Semua pembaruan di masa mendatang dijalankan menggunakan identitas pemilik baru.

Ketika pemilik kehilangan hak istimewa untuk tabel sumber

Jika Anda mengubah pemilik, dan pemilik baru tidak mempunyai akses ke tabel sumber (atau izin akses dicabut pada tabel sumber yang mendasar), pengguna masih dapat melakukan kueri pada tabel streaming. Namun:

Mereka tidak dapat REFRESH melakukan streaming tabel.
Refresh terjadwal berikutnya dari tabel streaming gagal.

Kehilangan akses ke data sumber mencegah adanya pembaruan, tetapi tidak segera menghentikan pembacaan tabel streaming yang ada.

Menghapus rekaman secara permanen dari tabel streaming

Penting

Dukungan untuk pernyataan REORG dengan tabel streaming ada di Pratinjau Umum .

Nota

Menggunakan pernyataan REORG dengan tabel streaming memerlukan Databricks Runtime 15.4 ke atas.
Meskipun Anda dapat menggunakan REORG pernyataan dengan tabel streaming apa pun, itu hanya diperlukan saat menghapus rekaman dari tabel streaming dengan vektor penghapusan diaktifkan. Perintah tidak berpengaruh saat digunakan dengan tabel streaming tanpa vektor penghapusan diaktifkan.

Untuk menghapus catatan secara fisik dari penyimpanan yang digunakan untuk tabel streaming dengan fitur vektor penghapusan yang diaktifkan, seperti untuk kepatuhan GDPR, diperlukan langkah tambahan untuk memastikan bahwa operasi VACUUM dilakukan pada data tabel streaming.

Untuk menghapus rekaman secara fisik dari penyimpanan yang mendasar:

Memperbarui rekaman atau menghapus rekaman dari tabel streaming.
Jalankan pernyataan REORG terhadap tabel streaming, menentukan parameter APPLY (PURGE). Contoh: REORG TABLE <streaming-table-name> APPLY (PURGE);.
Tunggu hingga periode retensi data tabel streaming berlalu. Periode retensi data default adalah tujuh hari, tetapi dapat dikonfigurasi dengan properti tabel delta.deletedFileRetentionDuration. Lihat Mengonfigurasi retensi data untuk kueri perjalanan lintas waktu.
REFRESH tabel streaming. Lihat Penyegaran tabel streaming. Dalam waktu 24 jam setelah operasi REFRESH, tugas pemeliharaan pipa saluran, termasuk operasi VACUUM yang dibutuhkan untuk memastikan catatan dihapus secara permanen, dieksekusi secara otomatis.

Memantau eksekusi menggunakan riwayat kueri

Anda bisa menggunakan halaman riwayat kueri untuk mengakses detail kueri dan profil kueri yang dapat membantu Anda mengidentifikasi kueri yang kinerjanya buruk dan kendala dalam alur yang digunakan untuk melakukan pembaruan tabel streaming Anda. Untuk gambaran umum jenis informasi yang tersedia dalam riwayat kueri dan profil kueri, lihat Riwayat kueri dan Profil kueri.

Penting

Fitur ini ada di Pratinjau Umum. Admin ruang kerja dapat mengontrol akses ke fitur ini dari halaman Pratinjau . Lihat Kelola Pratinjau Azure Databricks.

Semua pernyataan yang terkait dengan tabel streaming muncul dalam riwayat kueri. Anda dapat menggunakan filter drop-down Pernyataan untuk memilih perintah apa pun dan memeriksa kueri terkait. Semua CREATE pernyataan diikuti oleh REFRESH pernyataan yang dijalankan secara asinkron di dalam jalur pemrosesan. Pernyataan REFRESH biasanya mencakup rencana kueri terperinci yang memberikan wawasan tentang mengoptimalkan performa.

Untuk mengakses REFRESH pernyataan di antarmuka pengguna riwayat kueri, gunakan langkah-langkah berikut:

Klik di bilah sisi kiri untuk membuka UI Riwayat Kueri .
Pilih kotak centang REFRESH dari filter dropdown Pernyataan.
Klik nama pernyataan kueri untuk menampilkan detail ringkasan seperti durasi kueri dan metrik agregat.
Klik Lihat profil kueri untuk membuka profil kueri. Lihat Profil kueri untuk detail tentang menavigasi profil kueri.
Secara opsional, Anda bisa menggunakan tautan di bagian Sumber Kueri untuk membuka kueri atau alur terkait.

Anda juga dapat mengakses detail kueri menggunakan tautan di editor SQL atau dari buku catatan yang dilampirkan ke gudang SQL.

Mengakses tabel streaming dari klien eksternal

Untuk mengakses tabel streaming dari klien Delta Lake atau Iceberg eksternal yang tidak mendukung API terbuka, Anda dapat menggunakan Mode Kompatibilitas. Mode Kompatibilitas membuat versi baca-saja dari tabel streaming Anda yang dapat diakses oleh klien Delta Lake atau Iceberg apa pun.

Sumber daya tambahan

Saran dan Komentar

Apakah halaman ini membantu?

Last updated on 2026-04-25

Menggunakan tabel streaming di Databricks SQL

Persyaratan

Membuat tabel streaming

Komputasi yang digunakan untuk refresh

Memuat file dengan Auto Loader

Penyerapan streaming dari sumber lain

Menerapkan penangkapan data perubahan (CDC) dengan alur CDC Otomatis

Menyerap data baru saja

Mengatur saluran runtime

Menyembunyikan data sensitif

Memperbarui tabel streaming

Cara kerja refresh

Memperbarui sepenuhnya tabel streaming

Mengubah jadwal untuk tabel streaming

Pembaruan manual

REFRESH pernyataan

Antarmuka Pengguna Ruang Kerja

Pemicu pada pembaruan

Refresh terjadwal

Tugas SQL dalam pekerjaan

Menambahkan jadwal ke tabel streaming yang sudah ada

Mengubah jadwal atau pemicu yang ada

Menghilangkan jadwal atau pemicu

Pantau status pembaruan

Tenggang waktu untuk pembaharuan

Cara refresh terjadwal menangani batas waktu

Mengontrol akses ke tabel streaming

Memberikan otoritas pada tabel streaming

Mencabut izin dari tabel streaming

Mengubah pemilik tabel streaming

Ketika pemilik kehilangan hak istimewa untuk tabel sumber

Menghapus rekaman secara permanen dari tabel streaming

Memantau eksekusi menggunakan riwayat kueri

Mengakses tabel streaming dari klien eksternal

Sumber daya tambahan

Saran dan Komentar

Sumber Daya Tambahan: