Menggunakan tampilan terwujud

Dokumen ini memberikan informasi tambahan tentang tampilan terwujud dan cara menggunakannya. Sebelum membaca dokumen ini, pahami Pengantar tampilan terwujud dan Membuat tampilan terwujud.

Membuat kueri tampilan terwujud

Anda dapat membuat kueri tampilan terwujud secara langsung, dengan cara yang sama seperti membuat kueri tabel reguler atau tampilan standar. Kueri terhadap tampilan terwujud selalu konsisten dengan kueri terhadap tabel dasar tampilan, meskipun tabel tersebut telah berubah sejak terakhir kali tampilan terwujud dimuat ulang. Pembuatan kueri tidak otomatis memicu refresh terwujud.

Peran yang diperlukan

Untuk mendapatkan izin yang Anda perlukan untuk membuat kueri tampilan terwujud, minta administrator untuk memberi Anda peran IAM BigQuery Data Viewer (roles/bigquery.dataViewer) di tabel dasar tampilan terwujud dan tampilan terwujud itu sendiri. Untuk mengetahui informasi selengkapnya tentang cara memberikan peran, lihat Mengelola akses ke project, folder, dan organisasi.

Peran yang telah ditentukan ini berisi izin yang diperlukan untuk membuat kueri tampilan terwujud. Untuk melihat izin yang benar-benar diperlukan, luaskan bagian Izin yang diperlukan:

Izin yang diperlukan

Izin berikut diperlukan untuk membuat kueri tampilan terwujud:

  • bigquery.tables.get
  • bigquery.tables.getData

Anda mungkin juga bisa mendapatkan izin ini dengan peran khusus atau peran bawaan lainnya.

Izin ini diperlukan untuk kueri agar dapat memanfaatkan penyesuaian cerdas.

Untuk mengetahui informasi lebih lanjut tentang peran IAM di BigQuery, lihat Pengantar IAM.

Update inkremental

Pembaruan inkremental terjadi saat BigQuery menggabungkan data tampilan yang di-cache dengan data baru untuk memberikan hasil kueri yang konsisten sambil tetap menggunakan tampilan terwujud. Untuk tampilan terwujud tabel tunggal, hal ini dapat dilakukan jika tabel dasar tidak berubah sejak pembaruan terakhir, atau jika hanya data baru yang ditambahkan. Untuk tampilan JOIN, hanya tabel di sisi kiri JOIN yang dapat memiliki data tambahan. Jika salah satu tabel di sisi kanan JOIN telah berubah, tampilan tersebut tidak dapat diperbarui secara inkremental.

Jika tabel dasar mengalami pembaruan atau penghapusan sejak pembaruan terakhir, atau jika tabel dasar tampilan terwujud di sisi kanan JOIN telah berubah, BigQuery tidak akan menggunakan pembaruan inkremental, tetapi akan otomatis kembali ke kueri asli. Untuk informasi selengkapnya tentang gabungan dan tampilan terwujud, lihat Gabungan. Berikut adalah contoh Google Cloud Console, alat command line bq, dan tindakan API yang dapat menyebabkan pembaruan atau penghapusan:

  • Pernyataan bahasa manipulasi data (DML) UPDATE, MERGE, atau DELETE
  • Pemotongan
  • Akhir masa berlaku partisi

Operasi metadata berikut juga mencegah tampilan terwujud agar tidak diperbarui secara bertahap:

  • Mengubah masa berlaku partisi
  • Memperbarui atau menghapus kolom

Jika tampilan terwujud tidak dapat diperbarui secara bertahap, data yang di-cache-nya tidak digunakan oleh kueri sampai tampilan dimuat ulang secara otomatis atau manual. Untuk mengetahui detail tentang alasan tugas tidak menggunakan data tampilan terwujud, lihat Memahami alasan tampilan terwujud ditolak. Selain itu, tampilan terwujud tidak dapat diperbarui secara bertahap jika tabel dasar telah mengumpulkan perubahan yang belum diproses selama jangka waktu yang lebih lama dari interval perjalanan waktu tabel.

Perataan partisi

Jika tampilan terwujud dipartisi, BigQuery akan memastikan bahwa partisinya sejajar dengan partisi kolom partisi tabel dasar. Diratakan berarti data dari partisi tertentu dari tabel dasar berkontribusi pada partisi yang sama dari tampilan terwujud. Misalnya, baris dari partisi 20220101 tabel dasar hanya akan berkontribusi pada partisi 20220101 tampilan terwujud.

Jika tampilan terwujud dipartisi, perilaku yang dijelaskan dalam Update inkremental akan terjadi untuk setiap partisi individual secara terpisah. Misalnya, jika data dihapus dalam satu partisi tabel dasar, BigQuery masih dapat menggunakan partisi lain dari tampilan terwujud tanpa memerlukan refresh penuh seluruh tampilan terwujud.

Tampilan terwujud dengan gabungan dalam hanya dapat disejajarkan dengan salah satu tabel dasarnya. Jika salah satu tabel dasar yang tidak disejajarkan berubah, hal ini akan memengaruhi seluruh tampilan.

Penyesuaian cerdas

BigQuery secara otomatis menulis ulang kueri untuk menggunakan tampilan terwujud jika memungkinkan. Penulisan ulang otomatis meningkatkan performa dan biaya kueri, serta tidak mengubah hasil kueri. Pembuatan kueri tidak otomatis memicu refresh terwujud. Agar kueri ditulis ulang, tampilan terwujud harus memenuhi kondisi berikut:

  • Berada dalam set data yang sama dengan salah satu tabel dasarnya.
  • Gunakan kumpulan tabel dasar yang sama dengan kueri.
  • Sertakan semua kolom yang sedang dibaca.
  • Sertakan semua baris yang sedang dibaca.

Penyesuaian cerdas tidak didukung untuk hal berikut:

Contoh penyesuaian cerdas

Perhatikan contoh kueri tampilan terwujud berikut:

SELECT
  store_id,
  CAST(sold_datetime AS DATE) AS sold_date
  SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
  CAST(sold_datetime AS DATE) >= '2021-01-01' AND
  promo_id IS NOT NULL
GROUP BY 1, 2

Contoh berikut menampilkan kueri serta alasan kueri tersebut ditulis ulang atau tidak secara otomatis menggunakan tampilan ini:

Kueri Tulis ulang? Alasan
SELECT
SUM(net_paid) AS sum_paid,
SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
CAST(sold_datetime AS DATE) >= '2021-01-01' AND
promo_id IS NOT NULL 		Tidak Tampilan harus menyertakan semua kolom yang dibaca. Tampilan tidak menyertakan 'SUM(net_paid)'.
SELECT SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
CAST(sold_datetime AS DATE) >= '2021-01-01' AND
promo_id IS NOT NULL 		Ya
SELECT SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
CAST(sold_datetime AS DATE) >= '2021-01-01' AND
promo_id IS NOT NULL AND
customer_id = 12345 		Tidak Tampilan harus menyertakan semua kolom yang dibaca. Tampilan tidak menyertakan 'customer'.
SELECT SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
sold_datetime= '2021-01-01' AND
promo_id IS NOT NULL
 Tidak Tampilan harus menyertakan semua kolom yang dibaca. 'sold_datetime' bukan sebuah output (tetapi 'CAST(sold_datetime AS DATE)' adalah output).
SELECT SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
CAST(sold_datetime AS DATE) >= '2021-01-01' AND
promo_id IS NOT NULL AND
store_id = 12345		 Ya
SELECT SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
CAST(sold_datetime AS DATE) >= '2021-01-01' AND
promo_id = 12345 		Tidak Tampilan harus mencakup semua baris yang dibaca. 'promo_id' bukan output sehingga filter yang lebih ketat tidak dapat diterapkan ke tampilan.
SELECT SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE CAST(sold_datetime AS DATE) >= '2020-01-01'
 Tidak Tampilan harus mencakup semua baris yang dibaca. Filter tampilan untuk tanggal pada tahun 2021 dan setelahnya, tetapi kueri membaca tanggal dari tahun 2020.
SELECT SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
CAST(sold_datetime AS DATE) >= '2022-01-01' AND
promo_id IS NOT NULL 		Ya

Memahami apakah kueri ditulis ulang

Untuk memahami apakah kueri ditulis ulang oleh penyesuaian cerdas untuk menggunakan tampilan terwujud, periksa paket kueri. Jika kueri ditulis ulang, paket kueri akan berisi langkah READ my_materialized_view, dengan my_materialized_view adalah nama tampilan terwujud yang digunakan. Untuk memahami alasan kueri tidak menggunakan tampilan terwujud, lihat Memahami alasan tampilan terwujud ditolak.

Memahami alasan penolakan penayangan terwujud

Jika Anda telah menonaktifkan pembaruan otomatis untuk tampilan terwujud dan tabel memiliki perubahan yang belum diproses, kueri mungkin akan lebih cepat selama beberapa hari, tetapi kemudian mulai kembali ke kueri asli sehingga kecepatan pemrosesan menjadi lebih lambat. Untuk mendapatkan manfaat dari tampilan terwujud, aktifkan pemuatan ulang otomatis atau muat ulang secara manual secara berkala, dan pantau tugas pemuatan ulang tampilan terwujud untuk mengonfirmasi bahwa tugas tersebut berhasil.

Langkah-langkah untuk memahami alasan penolakan tampilan terwujud bergantung pada jenis kueri yang Anda gunakan:

  • Kueri langsung atas tampilan terwujud
  • Kueri tidak langsung yang mana smart tuning dapat memilih untuk menggunakan tampilan terwujud

Bagian berikut memberikan langkah-langkah untuk membantu Anda memahami alasan tampilan terwujud ditolak.

Kueri langsung atas tampilan terwujud

Kueri langsung tentang tampilan terwujud mungkin tidak menggunakan data yang di-cache dalam keadaan tertentu. Langkah-langkah berikut dapat membantu Anda memahami alasan data tampilan terwujud tidak digunakan:

  1. Ikuti langkah-langkah dalam Memantau penggunaan tampilan terwujud dan temukan tampilan terwujud target di kolom materialized_view_statistics untuk kueri singkat ini.
  2. Jika chosen ada dalam statistik dan nilainya adalah TRUE, tampilan terwujud akan digunakan oleh kueri.
  3. Tinjau kolom rejected_reason untuk mengetahui langkah berikutnya. Pada umumnya, Anda dapat memuat ulang secara manual tampilan terwujud atau menunggu pembaruan otomatis berikutnya.

Kueri dengan penyesuaian cerdas

  1. Ikuti langkah-langkah dalam Memantau penggunaan tampilan terwujud dan temukan tampilan terwujud target di materialized_view_statistics untuk kueri.
  2. Tinjau rejected_reason untuk menemukan langkah berikutnya. Misalnya, jika nilai rejected_reason adalah COST, smart tuning mengidentifikasi sumber data yang lebih efisien untuk biaya dan performa.
  3. Jika tampilan terwujud tidak ada, coba kueri langsung tampilan terwujud dan ikuti langkah-langkah dalam Kueri langsung tampilan terwujud.
  4. Jika kueri langsung tidak menggunakan tampilan terwujud, bentuk tampilan terwujud tidak cocok dengan kueri. Untuk informasi selengkapnya tentang smart tuning dan cara kueri ditulis ulang menggunakan tampilan terwujud, lihat Contoh penyesuaian cerdas.

Pertanyaan umum (FAQ)

Kapan saya harus menggunakan kueri terjadwal versus tampilan terwujud?

Kueri terjadwal adalah cara yang mudah untuk menjalankan penghitungan kompleks secara arbitrer secara berkala. Setiap kali berjalan, kueri akan dijalankan sepenuhnya, tanpa manfaat dari hasil sebelumnya, dan Anda membayar biaya komputasi penuh untuk kueri tersebut. Kueri terjadwal ideal jika Anda tidak memerlukan data terbaru dan memiliki toleransi tinggi terhadap data yang tidak berlaku.

Tampilan terwujud paling cocok saat Anda perlu membuat kueri data terbaru dengan latensi dan biaya yang diminimalkan dengan menggunakan kembali hasil yang dihitung sebelumnya. Anda dapat menggunakan tampilan terwujud sebagai indeks semu, yang mempercepat kueri ke tabel dasar tanpa memperbarui alur kerja yang ada. Opsi --max_staleness memungkinkan Anda menentukan keusangan yang dapat diterima untuk tampilan terwujud, yang memberikan performa tinggi secara konsisten dengan biaya yang terkontrol saat memproses set data yang besar dan sering berubah.

Sebagai panduan umum, jika memungkinkan dan jika Anda tidak menjalankan penghitungan yang kompleks secara arbitrer, gunakan tampilan terwujud.

Beberapa kueri pada tampilan terwujud lebih lambat daripada kueri yang sama pada tabel terwujud manual. Mengapa demikian?

Secara umum, kueri atas tampilan terwujud tidak selalu berperforma tinggi dibandingkan kueri atas tabel terwujud yang setara. Alasannya adalah tampilan terwujud selalu menampilkan hasil baru, dan harus memperhitungkan perubahan pada tabel dasarnya sejak tampilan terakhir dimuat ulang.

Bayangkan skenario berikut:

CREATE MATERIALIZED VIEW my_dataset.my_mv AS
SELECT date, customer_id, region, SUM(net_paid) as total_paid
FROM my_dataset.sales
GROUP BY 1, 2, 3;

CREATE TABLE my_dataset.my_materialized_table AS
SELECT date, customer_id, region, SUM(net_paid) as total_paid
FROM my_dataset.sales
GROUP BY 1, 2, 3;

Misalnya, kueri ini: 

  SELECT * FROM my_dataset.my_mv LIMIT 10
 biasanya berjalan jauh lebih lambat daripada kueri ini: 
  SELECT * FROM my_dataset.my_materialized_table LIMIT 10
 Untuk memberikan hasil terbaru secara konsisten, BigQuery harus membuat kueri baris baru dalam tabel dasar dan menggabungkannya ke dalam tampilan terwujud sebelum menerapkan predikat 'LIMIT 10'. Akibatnya, kelambatan akan tetap ada, meskipun tampilan terwujud sepenuhnya terbaru.

Di sisi lain, agregasi pada tampilan terwujud biasanya secepat kueri terhadap tabel terwujud. Misalnya: 

  SELECT SUM(total_paid) FROM my_dataset.my_mv WHERE date > '2020-12-01'
 Harus secepat ini: 
  SELECT SUM(total_paid) FROM my_dataset.my_materialized_table WHERE date > '2020-12-01'