Pandangan termaterialisasi

Seperti tampilan standar, tampilan materialisasi adalah hasil kueri dan Anda mengaksesnya dengan cara yang sama seperti tabel. Tidak seperti tampilan standar, yang mengolah ulang hasil pada setiap kueri, tampilan materialisasi menyimpan hasil dan merefreshnya pada interval tertentu. Karena tampilan materialisasi telah dikomputasi, kueri terhadapnya dapat berjalan jauh lebih cepat daripada terhadap tampilan reguler.

Tampilan materialisasi adalah objek alur deklaratif. Ini termasuk kueri yang mendefinisikannya, alur untuk memperbaruinya, dan hasil yang di-cache untuk akses cepat. Tampilan materialisasi:

• Melacak perubahan dalam data hulu.
• Pada pemicu, secara bertahap memproses data yang diubah dan menerapkan transformasi yang diperlukan.
• Mempertahankan tabel output, sinkron dengan data sumber, berdasarkan interval refresh yang ditentukan.

Tampilan termaterialisasi adalah pilihan yang baik untuk banyak transformasi.

• Anda menerapkan penalaran atas hasil yang di-cache alih-alih baris. Sebenarnya, Anda hanya menulis kueri.
• Mereka selalu benar. Semua data yang diperlukan diproses, bahkan jika tiba terlambat atau tidak berurutan.
• Mereka sering bertahap. Databricks akan mencoba memilih strategi yang sesuai yang meminimalkan biaya pembaruan tampilan materialisasi.

Cara kerja tampilan termaterialisasi

Diagram berikut mengilustrasikan cara kerja tampilan termaterialisasi.

Diagram

Tampilan materialisasi ditentukan dan diperbarui oleh satu alur. Anda dapat secara eksplisit menentukan tampilan materialisasi dalam kode sumber alur. Tabel yang ditentukan oleh alur tidak dapat diubah atau diperbarui oleh alur lain.

Nota

Saat Anda membuat tampilan materialisasi di luar kerangka pipeline menggunakan Databricks SQL, Azure Databricks membuat pipeline yang digunakan untuk memperbarui tampilan tersebut. Anda dapat melihat alur dengan memilih Pekerjaan & Alur dari navigasi kiri di ruang kerja Anda. Anda dapat menambahkan kolom Jenis alur ke tampilan Anda. Tampilan materialisasi yang ditentukan dalam pipeline memiliki jenis ETL. Tampilan materialisasi yang dibuat di Databricks SQL memiliki jenis MV/ST.

Databricks menggunakan Unity Catalog untuk menyimpan metadata tentang tampilan, termasuk kueri dan tampilan sistem tambahan yang digunakan untuk pembaruan bertahap. Data cache diwujudkan dalam penyimpanan cloud.

Nota

Databricks membuat tabel internal untuk mendukung penyegaran inkremental tampilan yang termaterialisasi. Tabel ini muncul di system.information_schema.tables tetapi tidak terlihat di Catalog Explorer atau permukaan UI ruang kerja lainnya.

Contoh berikut menggabungkan dua tabel dan mempertahankan hasil yang terkini menggunakan tampilan materialisasi.

Phyton

from pyspark import pipelines as dp

@dp.materialized_view
def regional_sales():
  partners_df = spark.read.table("partners")
  sales_df = spark.read.table("sales")

  return (
    partners_df.join(sales_df, on="partner_id", how="inner")
  )

SQL

CREATE OR REPLACE MATERIALIZED VIEW regional_sales
  AS SELECT *
  FROM partners
    INNER JOIN sales ON
      partners.partner_id = sales.partner_id;

Pembaruan inkremental otomatis

Ketika alur yang menentukan tampilan materialisasi dipicu, tampilan secara otomatis selalu diperbarui, sering kali secara bertahap. Databricks mencoba memproses hanya data yang harus diproses untuk menjaga tampilan terwujud tetap terbarui. Tampilan materialisasi selalu menunjukkan hasil yang benar, bahkan jika memerlukan komputasi ulang sepenuhnya hasil kueri dari awal, tetapi seringkali Databricks hanya membuat pembaruan bertahap ke tampilan terwujud, yang bisa jauh lebih murah daripada komputasi ulang penuh.

Diagram di bawah ini menunjukkan tampilan materialisasi yang disebut sales_report, yang merupakan hasil dari menggabungkan dua tabel hulu yang disebut clean_customers dan clean_transactions, dan pengelompokan menurut negara. Proses upstream menyisipkan 200 baris ke dalam clean_customers di tiga negara (AS, Belanda, Inggris) dan memperbarui 5.000 baris di clean_transactions yang sesuai dengan pelanggan baru ini. Tampilan sales_report materialisasi diperbarui secara bertahap hanya untuk negara yang memiliki pelanggan baru atau transaksi yang sesuai. Dalam contoh ini, kita melihat tiga baris diperbarui alih-alih seluruh laporan penjualan.

Untuk detail selengkapnya tentang cara kerja refresh inkremental dalam tampilan materialisasi, lihat Refresh tambahan untuk tampilan materialisasi.

Batasan materialisasi tampilan

Tampilan termaterialisasi memiliki batasan berikut:

• Karena pembaruan membuat kueri yang benar, beberapa perubahan pada input akan memerlukan komputasi ulang penuh dari tampilan materialisasi, yang bisa mahal.
• Mereka tidak dirancang untuk penggunaan dengan latensi rendah. Latensi memperbarui tampilan materialisasi adalah dalam detik atau menit, bukan milidetik.
• Tidak semua komputasi dapat dihitung secara bertahap.
• Azure Databricks mencoba mendeteksi kapan UDF yang digunakan dalam tampilan materialisasi mengubah perilaku dan melakukan refresh penuh untuk menerapkan UDF yang diperbarui. Namun, UDF yang memanggil fungsi atau pustaka lain dapat mengubah perilaku dengan cara yang tidak dikenali Azure Databricks. Salah satu contohnya adalah ketika pustaka yang disebut ditingkatkan. Ketika perilaku UDF berubah, Anda bertanggung jawab untuk melakukan refresh penuh pada tampilan materialisasi apa pun yang menggunakannya.