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
BigQuery Data Viewer (roles/bigquery.dataViewer
) Peran IAM di tabel dasar tampilan terwujud dan tampilan terwujud itu sendiri.
Untuk mengetahui informasi selengkapnya tentang cara memberikan peran, lihat Mengelola akses.
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 yang telah ditetapkan sebelumnya.
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
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 refresh terakhir, atau jika hanya data baru yang ditambahkan. Untuk tampilan JOIN
, hanya
tabel di sebelah kiri JOIN
yang dapat menambahkan data. Jika salah satu
tabel di sisi kanan JOIN
telah berubah, tampilan tidak dapat
diperbarui secara bertahap.
Jika tabel dasar mengalami pembaruan atau penghapusan sejak pembaruan terakhir, atau jika tabel dasar tampilan terwujud di sebelah kanan JOIN
telah berubah, BigQuery akan otomatis kembali ke kueri asli. Untuk
informasi selengkapnya tentang gabungan dan tampilan terwujud, lihat
Gabung. 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
, atauDELETE
- 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.
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. Misalnya, jika data dihapus dalam satu partisi tabel dasar, BigQuery masih dapat menggunakan partisi lain dari 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.
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
Kueri tidak dapat menggunakan tampilan terwujud karena berbagai alasan. 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:
- Ikuti langkah-langkah dalam Memantau penggunaan
tampilan terwujud
dan temukan tampilan terwujud target di
kolom
materialized_view_statistics
untuk kueri singkat ini. - Jika
chosen
ada dalam statistik dan nilainya adalahTRUE
, tampilan terwujud akan digunakan oleh kueri. - 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
- Ikuti langkah-langkah dalam Memantau penggunaan
tampilan terwujud
dan temukan tampilan terwujud target di
materialized_view_statistics
untuk kueri. - Tinjau
rejected_reason
untuk menemukan langkah berikutnya. Misalnya, jika nilairejected_reason
adalahCOST
, smart tuning mengidentifikasi sumber data yang lebih efisien untuk biaya dan performa. - Jika tampilan terwujud tidak ada, coba kueri langsung tampilan terwujud dan ikuti langkah-langkah dalam Kueri langsung tampilan terwujud.
- 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 kueri berjalan, kueri sedang dijalankan sepenuhnya. Hasil sebelumnya tidak digunakan, dan Anda membayar penuh untuk kueri tersebut. Kueri terjadwal sangat cocok jika Anda tidak memerlukan data terbaru dan Anda memiliki toleransi tinggi terhadap data yang tidak berlaku.
Tampilan terwujud cocok saat Anda perlu membuat kueri data terbaru sekaligus
mengurangi latensi dan biaya 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 menjamin untuk selalu menampilkan hasil baru, dan harus memperhitungkan perubahan pada tabel dasar yang ditambahkan 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 10biasanya berjalan jauh lebih lambat daripada kueri ini:
SELECT * FROM my_dataset.my_materialized_table LIMIT 10Untuk 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'