Pemutakhiran bertahap untuk tampilan materialisasi

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.

Alur tanpa server diperlukan untuk refresh bertahap

Refresh bertahap untuk tampilan materialisasi memerlukan alur tanpa server.

Operasi pembaruan untuk tampilan materialisasi yang ditentukan dalam Databricks SQL selalu berjalan menggunakan pipeline tanpa server.

Untuk tampilan materialisasi yang ditentukan menggunakan alur Delta Live Tables, Anda harus mengonfigurasi alur untuk menggunakan tanpa server. Lihat Mengonfigurasi alur Delta Live Tables 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.

Catatan

Beberapa hasil cache produk Azure Databricks secara otomatis dalam atau di seluruh sesi jika sumber data tidak 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 transation_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:

Penting

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.

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.
  • Menyerap operasi, seperti kueri yang menggunakan Auto Loader untuk menyerap 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 terintegrasi dengan Delta Lake.
  • Tampilan termaterialisasi.
  • Tabel streaming, termasuk target operasi APPLY CHANGES 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 materialisasi, tabel streaming, dan tabel terkelola Unity Catalog. Lihat Menggunakan pelacakan baris untuk tabel Delta.

Mengoptimalkan tampilan materialisasi

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

• Vektor penghapusan
  • Pelacakan baris
  • Mengubah umpan data

Jenis refresh untuk tampilan materialisasi

Penyegaran untuk tampilan materialisasi dapat bersifat penuh atau inkremental. Untuk semua operasi, hasil refresh bertahap dan refresh penuh sama. Azure Databricks menjalankan analisis biaya untuk mengidentifikasi apakah perubahan pada sumber data memerlukan refresh penuh.

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

Refresh penuh

Refresh penuh menimpa hasil dalam tampilan materialisasi dengan memproses ulang semua data yang tersedia di sumbernya. Semua tampilan terwujud mungkin disegarkan sepenuhnya setiap kali ada pembaruan, tergantung pada perubahan yang terjadi pada sumber data.

Anda dapat secara opsional memaksa refresh penuh. Untuk tampilan materialisasi yang ditentukan menggunakan Databricks SQL, gunakan sintaks berikut:

REFRESH MATERIALIZED VIEW mv_name FULL

Untuk tampilan materialisasi yang ditentukan dalam alur Tabel Langsung Delta, Anda dapat memilih untuk menjalankan refresh penuh pada himpunan data yang dipilih atau pada semua himpunan data dalam alur. Lihat Semantik pembaharuan pipeline.

Penting

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.

Catatan

Anda dapat secara opsional menonaktifkan refresh penuh pada tabel dengan mengatur properti tabel pipelines.reset.allowed ke false.

Penyegaran 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.

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

Saat tampilan materialized dibuat menggunakan gudang SQL atau pipeline Delta Live Tables tanpa server, tampilan tersebut secara otomatis terperbarui secara bertahap jika kuerinya didukung. Jika kueri menyertakan ekspresi yang tidak didukung untuk refresh inkremental, refresh penuh dilakukan, berpotensi menghasilkan biaya tambahan.

Dukungan untuk tampilan materialisasi penyegaran inkremental

Tabel berikut ini mencantumkan dukungan untuk refresh bertahap menurut kata kunci atau klausa SQL.

Penting

Beberapa kata kunci dan klausa mengharuskan pelacakan baris diaktifkan pada sumber data yang dikueri. Lihat Menggunakan pelacakan baris untuk tabel Delta.

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

Kata kunci atau klausa SQL	Dukungan untuk penyegaran inkremental
SELECT Ekspresi*	Ya, ekspresi termasuk fungsi bawaan deterministik dan fungsi yang ditentukan pengguna (UDF) yang tidak dapat diubah didukung.
GROUP BY	Ya
WITH	Ya, ekspresi tabel umum didukung.
UNION ALL*	Ya
FROM	Tabel dasar yang didukung mencakup tabel Delta, tampilan materialisasi, dan tabel streaming.
WHERE, HAVING*	Klausa filter seperti WHERE dan HAVING didukung.
INNER JOIN*	Ya
LEFT OUTER JOIN*	Ya
FULL OUTER JOIN*	Ya
RIGHT OUTER JOIN*	Ya
OVER	Ya. PARTITION_BY kolom harus ditentukan untuk penginkrementasian pada fungsi jendela.
QUALIFY	Ya
EXPECTATIONS	Tidak. Tampilan materialisasi yang menggunakan pengharapan selalu diperbarui sepenuhnya.

Catatan

Fungsi non-deterministik, misalnya, CURRENT_TIMESTAMP, tidak didukung.

Menentukan jenis refresh pembaruan

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

Teknik	Penyegaran bertahap?	Deskripsi
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.
ROW_BASED atau PARTITION_OVERWRITE	Ya	Tampilan materialisasi disegarkan secara bertahap menggunakan teknik yang ditentukan.

Untuk menentukan teknik yang digunakan, periksa log peristiwa Tabel Langsung Delta 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.

Lihat Apa itu log peristiwa Delta Live Tables?.