Bagikan melalui

Pemutakhiran bertahap untuk tampilan materiil

Artikel ini menguraikan semantik dan persyaratan untuk refresh inkremental pada tampilan materialisasi, dan mengidentifikasi operasi, kata kunci, dan klausa SQL yang mendukung refresh bertahap. Ini termasuk diskusi tentang perbedaan antara refresh bertahap dan penuh, dan mencakup rekomendasi untuk memilih antara tampilan materialisasi dan tabel streaming.

Saat menjalankan pembaruan pada tampilan materialisasi menggunakan alur tanpa server, banyak kueri dapat disegarkan secara bertahap. Refresh bertahap menghemat biaya komputasi dengan mendeteksi perubahan dalam sumber data yang digunakan untuk menentukan tampilan materialisasi dan menghitung hasil secara bertahap.

Refresh berjalan pada komputasi tanpa server

Operasi refresh dijalankan pada alur tanpa server, terlepas dari apakah operasi ditentukan di Databricks SQL atau dengan Alur Deklaratif Lakeflow Spark.

Untuk tampilan materialisasi yang ditentukan menggunakan Databricks SQL, ruang kerja Anda tidak perlu diaktifkan untuk Alur Deklaratif Lakeflow Spark tanpa server. Refresh akan menggunakan alur tanpa server secara otomatis.

Untuk tampilan materialisasi yang ditentukan menggunakan Alur Deklaratif Lakeflow Spark, Anda harus mengonfigurasi alur untuk menggunakan tanpa server. Lihat Mengonfigurasi alur tanpa server.

Apa saja semantik refresh untuk tampilan materialisasi?

Tampilan materialisasi menjamin hasil yang setara dengan kueri batch. Misalnya, pertimbangkan kueri agregat berikut:

SELECT account_id,
  COUNT(txn_id) txn_count,
  SUM(txn_amount) account_revenue
FROM transactions_table
GROUP BY account_id

Saat Anda menjalankan kueri ini menggunakan produk Azure Databricks apa pun, hasilnya dihitung menggunakan semantik batch untuk menggabungkan semua rekaman dalam sumber transactions_table, yang berarti bahwa semua data sumber dipindai dan dikumpulkan dalam satu operasi.

Note

Beberapa produk Azure Databricks secara otomatis menyimpan cache hasil dalam atau di seluruh sesi jika sumber data belum berubah setelah kueri terakhir dijalankan. Perilaku pengelolaan cache otomatis berbeda dari tampilan yang terwujud.

Contoh berikut mengubah kueri batch ini menjadi tampilan materialisasi:

CREATE OR REPLACE MATERIALIZED VIEW transaction_summary AS
SELECT account_id,
  COUNT(txn_id) txn_count,
  SUM(txn_amount) account_revenue
FROM transactions_table
GROUP BY account_id

Saat Anda me-refresh tampilan materialisasi, hasil komputasi identik dengan semantik kueri batch. Kueri ini adalah contoh tampilan materialisasi yang dapat disegarkan secara bertahap, yang berarti bahwa operasi pembaharuan berusaha sebaik mungkin untuk hanya memproses data baru atau yang diubah pada sumber transactions_table guna menghitung hasilnya.

Pertimbangan sumber data untuk tampilan berwujud

Meskipun Anda dapat menentukan tampilan materialisasi terhadap sumber data apa pun, tidak semua sumber data sangat cocok untuk tampilan materialisasi. Pertimbangkan peringatan dan rekomendasi berikut:

Important

Tampilan termaterialisasi membuat upaya sebaik mungkin untuk memperbarui hasil secara bertahap dan berkelanjutan untuk operasi yang didukung. Beberapa perubahan dalam sumber data memerlukan refresh penuh. Anda dapat menentukan kebijakan refresh yang gagal daripada menjalankan refresh penuh.

Semua sumber data untuk tampilan materialisasi harus tahan terhadap semantik pembaruan penuh, bahkan jika kueri yang menentukan tampilan materialisasi mendukung pembaruan inkremental.

  • Untuk kueri di mana refresh penuh akan terlalu mahal, gunakan tabel streaming untuk menjamin pemrosesan satu kali dengan tepat. Contohnya termasuk tabel yang sangat besar.
  • Jangan tentukan tampilan materialisasi terhadap sumber data jika rekaman hanya boleh diproses sekali. Sebagai gantinya, gunakan tabel streaming. Contohnya termasuk yang berikut ini:
    • Sumber data yang tidak menyimpan riwayat data, seperti Kafka.
    • Operasi ingest, seperti kueri yang menggunakan Auto Loader untuk mengambil data dari penyimpanan objek cloud.
    • Sumber data apa pun tempat Anda berencana untuk menghapus atau mengarsipkan data setelah diproses tetapi perlu menyimpan informasi dalam tabel hilir. Misalnya, tabel yang dipartisi tanggal di mana Anda berencana untuk menghapus rekaman yang lebih lama dari ambang batas tertentu.
  • Tidak semua sumber data mendukung refresh inkremental. Sumber data berikut mendukung refresh inkremental:
    • Tabel Delta, termasuk tabel yang dikelola Katalog Unity serta tabel eksternal yang ditopang oleh Delta Lake.
    • Materialisasi pandangan.
    • Tabel streaming, termasuk sasaran operasi AUTO CDC ... INTO.
  • Beberapa operasi refresh bertahap mengharuskan pelacakan baris diaktifkan pada sumber data yang dikueri. Pelacakan baris adalah fitur Delta Lake yang hanya didukung oleh tabel Delta, yang mencakup tampilan terwujud, tabel streaming, dan tabel yang dikelola oleh Unity Catalog. Lihat Pelacakan baris di Databricks.
  • Sumber data dengan filter baris atau masker kolom yang ditentukan tidak mendukung refresh inkremental. Lihat Filter baris dan masker kolom

Mengoptimalkan tampilan materialisasi

Untuk mendapatkan performa terbaik, Databricks merekomendasikan untuk mengaktifkan fitur berikut pada semua tabel sumber tampilan materialisasi:

Anda dapat mengatur fitur-fitur ini selama pembuatan, atau nanti dengan pernyataan ALTER TABLE. Contohnya:

ALTER TABLE <table-name> SET TBLPROPERTIES (
  delta.enableDeletionVectors = true,
  delta.enableRowTracking = true,
  delta.enableChangeDataFeed = true);

Jenis refresh untuk tampilan termaterialisasi

Saat tampilan materialisasi diperbarui, Anda dapat menentukan refresh atau refresh penuh.

  • Refresh mencoba melakukan refresh inkremental, tetapi akan melakukan komputasi ulang penuh data jika diperlukan. Refresh inkremental hanya tersedia ketika komputasi yang Anda sambungkan tanpa server.
  • Refresh penuh selalu menghitung ulang semua input ke tampilan materialisasi, dan mengatur ulang semua titik pemeriksaan.

Untuk menentukan jenis refresh mana yang digunakan pembaruan, lihat Menentukan jenis refresh pembaruan.

Refresh default

Refresh default untuk tampilan materialisasi pada upaya tanpa server untuk melakukan refresh bertahap. Refresh inkremental memproses perubahan dalam data yang mendasar setelah refresh terakhir lalu menambahkan data tersebut ke tabel. Bergantung pada tabel dasar dan operasi yang disertakan, hanya jenis tampilan materialisasi tertentu yang dapat disegarkan secara bertahap. Jika refresh bertahap tidak dimungkinkan atau komputasi yang terhubung klasik alih-alih tanpa server, rekomputasi penuh dilakukan.

Note

Azure Databricks menerapkan refresh penuh atau bertahap. Keputusan didasarkan pada opsi mana yang lebih hemat biaya, dan apakah kueri mendukung refresh inkremental. Untuk mengubah perilaku ini, lihat Kebijakan refresh.

Output refresh inkremental dan komputasi ulang penuh sama. Azure Databricks menjalankan analisis biaya untuk memilih opsi yang lebih murah antara refresh bertahap dan komputasi ulang penuh.

Hanya tampilan materialisasi yang diperbarui menggunakan alur tanpa server yang dapat menggunakan refresh bertahap. Tampilan materialisasi yang tidak menggunakan alur tanpa server selalu dikomputasi ulang sepenuhnya.

Saat Anda membuat tampilan materialisasi dengan gudang data SQL atau Pipeline Deklaratif Lakeflow Spark tanpa server, Azure Databricks secara bertahap menyegarkan tampilan tersebut jika kueri tersebut didukung. Jika kueri menggunakan ekspresi yang tidak didukung, Azure Databricks menjalankan recompute penuh sebagai gantinya, yang dapat meningkatkan biaya.

Untuk menentukan jenis refresh mana yang digunakan pembaruan, lihat Menentukan jenis refresh pembaruan.

Pembaruan penuh

Refresh penuh menimpa hasil dalam tampilan materialisasi dengan menghapus tabel dan titik pemeriksaan, dan memproses ulang semua data yang tersedia di sumbernya.

Untuk melakukan refresh penuh pada tampilan materialisasi yang ditentukan menggunakan Databricks SQL, gunakan sintaks berikut:

REFRESH MATERIALIZED VIEW mv_name FULL

Untuk tampilan materialisasi yang ditentukan dalam Alur Deklaratif Lakeflow Spark, Anda dapat memilih untuk menjalankan refresh penuh pada himpunan data yang dipilih atau pada semua himpunan data dalam alur. Lihat Semantik pembaharuan jalur.

Important

Saat refresh penuh berjalan terhadap sumber data di mana rekaman telah dihapus karena ambang retensi data atau penghapusan manual, rekaman yang dihapus tidak tercermin dalam hasil komputasi. Anda mungkin tidak dapat memulihkan data lama jika data tidak lagi tersedia di sumbernya. Ini mungkin juga mengubah skema untuk kolom yang tidak lagi ada di data sumber.

Dukungan untuk penyegaran inkremental tampilan materialisasi

Tabel berikut ini mencantumkan dukungan untuk refresh bertahap menurut kata kunci atau klausa SQL. Untuk menguji inkrementabilitas suatu kueri tertentu, Anda bisa menggunakan EXPLAIN CREATE MATERIALIZED VIEW.

Important

Beberapa kata kunci dan klausa mengharuskan pelacakan baris diaktifkan pada sumber data yang dikueri. Lihat Pelacakan baris di Databricks.

Kata kunci dan klausa ini ditandai dengan bintang (*) dalam tabel berikut.

Kata kunci atau klausa SQL Dukungan untuk penyegaran inkremental
SELECT Ekspresi* Ya, ungkapan yang mencakup fungsi bawaan deterministik dan fungsi yang ditentukan pengguna (UDF) yang tidak dapat diubah termasuk dalam dukungan.
GROUP BY Yes
WITH Ya, ekspresi tabel umum didukung.
UNION ALL* Yes
FROM Tabel dasar yang didukung mencakup tabel Delta, tampilan materialisasi, dan tabel streaming.
WHERE, HAVING* Klausa filter seperti WHERE dan HAVING didukung.
INNER JOIN* Yes
LEFT OUTER JOIN* Yes
FULL OUTER JOIN* Yes
RIGHT OUTER JOIN* Yes
OVER Yes. PARTITION_BY kolom harus ditentukan untuk penginkrementasian pada fungsi jendela.
QUALIFY Yes
EXPECTATIONS Ya, tampilan materialisasi yang mencakup harapan dapat disegarkan secara bertahap. Namun, refresh inkremental tidak didukung untuk kasus-kasus berikut:
  • Saat tampilan materialisasi dibaca dari tampilan yang berisi ekspektasi.
  • Ketika tampilan materialisasi memiliki DROP harapan dan menyertakan NOT NULL kolom dalam skemanya.
Fungsi non-deterministik Fungsi waktu non-deterministik didukung dalam WHERE klausul. Ini termasuk fungsi seperti current_date(), , current_timestamp()dan now(). Fungsi non-deterministik lainnya tidak didukung.
Sumber non-Delta Sumber seperti volume, lokasi eksternal, dan katalog asing tidak didukung.

Menentukan jenis refresh pembaruan

Untuk mengoptimalkan kinerja refresh tampilan materialisasi, Azure Databricks menggunakan model biaya untuk memilih teknik yang digunakan untuk melakukan refresh. Tabel berikut ini menjelaskan teknik-teknik ini:

Technique Penyegaran inkremental? Description
FULL_RECOMPUTE No Tampilan materialisasi sepenuhnya dikomputasi ulang
NO_OP Tidak berlaku Tampilan materialisasi tidak diperbarui karena tidak ada perubahan pada tabel dasar yang terdeteksi.
Salah satu dari:
  • ROW_BASED
  • PARTITION_OVERWRITE
  • WINDOW_FUNCTION
  • APPEND_ONLY
  • GROUP_AGGREGATE
  • GENERIC_AGGREGATE
 Yes Tampilan terwujud diperbarui secara bertahap menggunakan teknik yang telah ditentukan.

Lihat juga Kebijakan refresh.

Untuk menentukan teknik yang digunakan, kueri log peristiwa Lakeflow Spark Declarative Pipelines di mana event_type adalah planning_information:

SELECT
  timestamp,
  message
FROM
  event_log(TABLE(<fully-qualified-table-name>))
WHERE
  event_type = 'planning_information'
ORDER BY
  timestamp desc;

Ganti <fully-qualified-table-name> dengan nama tampilan terwujud yang lengkap, termasuk katalog dan skema.

Contoh output untuk perintah ini:

    • stempel waktu
    • message
    • 2025-03-21T22:23:16.497+00:00
    • Flow 'sales' has been planned in :re[LDP] to be executed as ROW_BASED.

Lihat Log peristiwa alur.

Kebijakan refresh

Secara default, Azure Databricks secara otomatis memilih strategi refresh yang paling hemat biaya—bertambah atau penuh—berdasarkan struktur kueri, volume perubahan data, dan pemodelan biaya sistem. Perilaku default ini mengoptimalkan performa refresh tanpa memerlukan konfigurasi manual.

Namun, beberapa beban kerja memerlukan perilaku refresh yang lebih dapat diprediksi atau dikontrol secara eksplisit. Untuk mendukung skenario ini, Anda dapat menentukan REFRESH POLICY dalam definisi tampilan materialisasi. Kebijakan refresh mengontrol apakah Azure Databricks melakukan refresh inkremental, kapan dapat kembali ke refresh penuh, dan apakah refresh harus gagal daripada melakukan perhitungan ulang penuh.

Menggunakan REFRESH POLICY, Anda dapat mengonfigurasi sistem untuk:

  • AUTO (default) - Gunakan pilihan otomatis berbasis biaya. Databricks memilih refresh bertahap atau penuh berdasarkan efisiensi dan kemampuan kueri. Direkomendasikan untuk sebagian besar pengguna.
  • INCREMENTAL - Lebih suka refresh inkremental. Databricks melakukan refresh bertahap jika memungkinkan. Sistem akan kembali ke pembaruan penuh jika rencana kueri tidak lagi mendukung pembaruan bertahap.
  • INCREMENTAL STRICT - Membutuhkan penyegaran inkremental yang ketat. Penyegaran bertahap diperlukan selama operasi normal. Jika inkrementalisasi tidak dimungkinkan, operasi refresh atau buat gagal.
  • FULL - Selalu lakukan refresh penuh. Databricks tidak pernah melakukan penyegaran bertahap, bahkan ketika kueri dapat diinkrementalkan.
-- Create a materialized view with an incremental refresh policy
CREATE MATERIALIZED VIEW IF NOT EXISTS my_mv
REFRESH POLICY INCREMENTAL
AS SELECT a, sum(b) FROM my_catalog.example.my_table GROUP BY a;

Kebijakan refresh optimal tergantung pada karakteristik beban kerja Anda:

  • AUTO sesuai untuk sebagian besar beban kerja. Ini menyeimbangkan biaya dan performa dan beradaptasi secara otomatis saat perilaku kueri berubah.
  • INCREMENTAL berguna ketika refresh inkremental memberikan manfaat, tetapi dapat diterima oleh Azure Databricks untuk melakukan refresh penuh ketika inkrementalisasi menjadi tidak tersedia sementara (seperti ketika pelacakan baris pada tabel sumber dimatikan).
  • INCREMENTAL STRICT harus digunakan ketika refresh inkremental diperlukan untuk memenuhi batasan biaya, performa, atau SLA, dan refresh penuh yang tidak terduga tidak dapat diterima. Kebijakan ini direkomendasikan ketika pengguna lebih suka pembaruan gagal, memungkinkan mereka untuk men-debug masalah daripada melanjutkan dengan refresh penuh.
  • FULL cocok ketika refresh inkremental memberikan sedikit manfaat, himpunan data kecil, atau struktur kueri sering berubah dengan cara yang mencegah inkrementalisasi.
  • Last updated on