Memantau tampilan terwujud
Anda dapat memantau tampilan terwujud menggunakan alat yang mencakup skema informasi dan pemantauan log.
Untuk membuat daftar tampilan terwujud, lihat Mencantumkan tampilan terwujud.
Tampilan skema informasi tampilan terwujud
Untuk menemukan tampilan terwujud, buat kueri tampilan INFORMATION_SCHEMA.TABLES. Untuk mengambil properti tampilan terwujud, buat kueri tabel virtual INFORMATION_SCHEMA.TABLE_OPTIONS.
Tampilan terwujud tidak tercantum dalam tabel tabel virtualINFORMATION_SCHEMA.VIEWS.
Memantau pemuatan ulang otomatis
Bagian ini menjelaskan cara melihat detail pemuatan ulang untuk tampilan terwujud.
Melihat status pemuatan ulang terakhir
Untuk mengambil status tampilan terwujud saat ini, panggil metode tables.get, atau buat kueri tabel virtual INFORMATION_SCHEMA.MATERIALIZED_VIEWS.
Contoh:
SELECT table_name, last_refresh_time, refresh_watermark, last_refresh_status FROM `DATASET`.INFORMATION_SCHEMA.MATERIALIZED_VIEWS;
Jika nilai untuk last_refresh_status bukan NULL, tugas pemuatan ulang otomatis terakhir akan gagal. Permintaan pemuatan ulang manual tidak ditampilkan di sini. Perubahan pada tabel dasar dapat membatalkan definisi tampilan terwujud, sehingga mengakibatkan error selama pemuatan ulang otomatis. Untuk mengetahui informasi selengkapnya, lihat Update inkremental. Misalnya, jika kolom yang direferensikan oleh tampilan terwujud dihapus dari tabel dasar, kolom last_refresh_status akan menampilkan error invalidQuery. Untuk mengetahui informasi selengkapnya, lihat Pesan error.
Mencantumkan tugas pemuatan ulang otomatis
Untuk mencantumkan tugas pemuatan ulang otomatis tampilan terwujud, panggil metode jobs.list. Untuk mengambil detail tentang tugas, panggil metode jobs.get. Anda juga dapat membuat kueri
tampilan INFORMATION_SCHEMA.JOBS_BY_* untuk
mengambil detail tugas. Tugas pemuatan ulang otomatis berisi awalan materialized_view_refresh dalam ID tugas dan dimulai oleh akun administrator BigQuery.
Contoh:
SELECT job_id, total_slot_ms, total_bytes_processed, materialized_view_statistics.materialized_view[SAFE_OFFSET(0)].rejected_reason AS full_refresh_reason FROM `region-us.INFORMATION_SCHEMA.JOBS_BY_PROJECT` WHERE job_id LIKE '%materialized_view_refresh_%' LIMIT 10;
Untuk memantau biaya tugas pemuatan ulang dan menyesuaikan interval pemuatan ulang otomatis jika diperlukan, lihat kolom total_bytes_processed dan total_slot_ms.
Misalnya, jika kecepatan penyerapan dalam tabel dasar relatif kecil, sebaiknya muat ulang tabel virtual lebih jarang. Jika data dasar berubah dengan cepat, sebaiknya muat ulang lebih sering.
Jika tabel dasar menyerap data pada waktu tertentu, seperti menggunakan pipeline ekstrak, transformasi, dan pemuatan per malam (ETL), pertimbangkan untuk mengontrol jadwal pemeliharaan tampilan terwujud sebagai berikut:
Lakukan pemuatan ulang manual, sebagai bagian dari pipeline ETL, atau dengan mengonfigurasi kueri terjadwal pada waktu tertentu.
Pemotongan tabel, pemotongan partisi, masa berlaku partisi, serta pernyataan bahasa pengolahan data (DML) UPDATE, DELETE, dan MERGE pada tabel dasar semuanya dapat membatalkan tampilan terwujudnya. Jika tampilan terwujud dipartisi, partisi yang dimodifikasi akan dibatalkan. Jika tidak dipartisi, seluruh tampilan terwujud menjadi tidak valid. Oleh karena itu, sebaiknya Anda mengelompokkan pernyataan DML dan melakukan pemuatan ulang manual di akhir kueri.
Untuk mengetahui informasi selengkapnya tentang harga tampilan terwujud, lihat harga tampilan terwujud.
Memantau kegagalan pemuatan ulang tampilan terwujud
Anda dapat membuat otomatisasi untuk memantau pemuatan ulang tampilan terwujud yang gagal dan mengirim pemberitahuan menggunakan log audit BigQuery di Cloud Logging. BigQuery membuat entri log untuk tugas pemuatan ulang tampilan terwujud, termasuk kegagalan. Logs Explorer di konsol Google Cloud membantu Anda mengambil, melihat, dan menganalisis entri log. Entri ini disimpan di bucket log, yang merupakan container yang digunakan Cloud Logging untuk menyimpan data log Anda.
Untuk membuat metrik dan pemberitahuan, ikuti langkah-langkah berikut:
Konsol
Ikuti langkah-langkah berikut untuk membuat metrik berbasis log yang mengirimkan pemberitahuan jika lebih dari tiga refresh tampilan terwujud gagal dalam interval 10 menit.
Membuat metrik berbasis log
- Untuk menyiapkan Logs Explorer, ikuti petunjuk di Melihat dan menganalisis log.
Di Logs Explorer, pastikan setelan Show query diaktifkan.
Saat Anda menggunakan konsol Google Cloud , cakupan project adalah satu project yang dipilih di pemilih project konsol Google Cloud . Untuk mempelajari cara menambahkan project tambahan, lihat Menambahkan project ke cakupan metrik.
Di panel Query, tempel kueri berikut untuk merekam semua tugas pemuatan ulang tampilan terwujud otomatis yang gagal dalam cakupan logging project saat ini:
severity: "ERROR" protoPayload.metadata.jobChange.after: "DONE" protoPayload.metadata.jobChange.job.jobConfig.queryConfig.query =~ "CALL BQ.REFRESH_MATERIALIZED_VIEW\('.*'\)" protoPayload.resourceName =~ ".*materialized_view_refresh_[\w]"
Klik Run query.
Klik Tindakan, lalu pilih Buat metrik.
Untuk membuat pemberitahuan berdasarkan jumlah error, pilih Counter untuk jenis metrik, lalu masukkan Nama metrik berbasis log dan Deskripsi untuk metrik Anda. Kolom Unit dapat dikosongkan.
Untuk menentukan filter metrik di bagian Filter selection, terapkan setelan berikut:
Gunakan menu Pilih project atau bucket log untuk memilih apakah metrik menghitung entri log di project Anda Google Cloud atau hanya entri log tersebut di bucket log tertentu.
Buat filter yang hanya mengumpulkan entri log yang ingin Anda hitung dalam metrik menggunakan bahasa kueri logging. Anda juga dapat menggunakan ekspresi reguler untuk membuat filter metrik.
Untuk melihat entri log mana yang cocok dengan filter Anda, klik Pratinjau log.
Klik Tambahkan label.
Masukkan Nama label dan Deskripsi unik untuk membantu Anda mengidentifikasi metrik. Biarkan Jenis label sebagai String, setelan default.
Untuk Nama kolom, masukkan string berikut:
protoPayload.metadata.jobChange.job.jobConfig.queryConfig.query
Untuk Regular expression, masukkan string berikut:
CALL BQ.REFRESH_MATERIALIZED_VIEW\('(.*)'\)
Klik Selesai, lalu klik Buat metrik.
Untuk mengetahui informasi selengkapnya tentang metrik penghitung, lihat Mengonfigurasi metrik penghitung.
Membuat pemberitahuan
Selesaikan langkah-langkah berikut untuk membuat kebijakan pemberitahuan yang menentukan kondisi dan mengirim email saat tiga tugas refresh tampilan terwujud gagal dalam jangka waktu sepuluh menit. Opsi ini memberikan fleksibilitas tambahan saat mengonfigurasi kebijakan pemberitahuan. Jika Anda membuat metrik berbasis log secara langsung, pemberitahuan akan dikirim setiap kali error refresh tampilan terwujud yang gagal ada dalam log.
Di konsol Google Cloud , buka halaman Log-based Metrics.
Di samping metrik berbasis log buatan pengguna untuk refresh tampilan terwujud, klik Tindakan lainnya > Buat pemberitahuan dari metrik.
Di Select a metric, pilih nama metrik yang Anda tentukan sebelumnya untuk Log-based metric name.
Di Tambahkan filter, tambahkan filter tambahan ke pemberitahuan berdasarkan konvensi penamaan tampilan terwujud yang ditentukan di kolom Ekspresi reguler.
Langkah ini berguna jika Anda perlu menentukan channel notifikasi terpisah untuk beberapa tim yang menggunakan project yang sama, tetapi dibagi secara logis berdasarkan konvensi penamaan tampilan yang diwujudkan. Untuk informasi selengkapnya tentang kriteria pemberitahuan, lihat Memfilter data dalam diagram di "Memilih metrik saat menggunakan Metrics Explorer".
Di setelan Rolling window pada bagian Transform data, tentukan nilai yang lebih besar dari 10 menit untuk memastikan beberapa entri log yang cocok dengan filter Anda dihitung, lalu klik Next.
Tentukan Threshold value, misalnya
3, dan jika perlu, konfigurasi kolom Alert trigger dan Threshold position. Klik Berikutnya.Pilih saluran notifikasi untuk pemberitahuan.
Klik Create policy.
Jika jumlah refresh tampilan terwujud yang gagal melebihi nilai minimum, channel notifikasi Anda akan diberi tahu.
Terraform
Anda dapat membuat metrik kustom, kebijakan pemberitahuan, saluran notifikasi, dan cakupan logging menggunakan Terraform. Contoh Terraform berikut menggunakan kueri untuk memantau dan mencatat setiap tugas refresh tampilan terwujud yang gagal.
resource "google_logging_metric" "failed_mv_refresh_metric" { project = var.project_id name = var.logging_metric_name filter = trimspace(<<EOT severity="ERROR" AND protoPayload.metadata.jobChange.after="DONE" AND protoPayload.metadata.jobChange.job.jobConfig.queryConfig.query=~"CALL BQ.REFRESH_MATERIALIZED_VIEW\('.*'\)" AND protoPayload.resourceName=~".*materialized_view_refresh_[\\w]" EOT ) metric_descriptor { metric_kind = "DELTA" value_type = "INT64" unit = "1" display_name = "Failed Materialized View Refresh Count" labels { key = "materialized_view_name" value_type = "STRING" description = "The name of the materialized view that failed to refresh." } } label_extractors = { "materialized_view_name" = "REGEXP_EXTRACT(protoPayload.metadata.jobChange.job.jobConfig.queryConfig.query, \"CALL BQ\\.REFRESH_MATERIALIZED_VIEW\\('(.*)'\\)\")" } }
Contoh berikut membuat pemberitahuan yang dapat digunakan untuk mengirim email saat jumlah tugas refresh tampilan terwujud yang gagal melebihi nilai minimum.
resource "google_monitoring_alert_policy" "failed_mv_refresh_alert" { project = var.project_id display_name = var.alert_policy_display_name combiner = "OR" conditions { display_name = "Condition: Materialized View Refresh Failure Count Exceeds Threshold" condition_threshold { filter = "metric.type=\"logging.googleapis.com/user/${google_logging_metric.failed_mv_refresh_metric.name}\" AND resource.type=\"bigquery_project\"" duration = "${var.alert_duration_seconds}s" comparison = "COMPARISON_GT" threshold_value = var.alert_threshold_count aggregations { alignment_period = "${var.alert_rolling_window_seconds}s" per_series_aligner = "ALIGN_DELTA" cross_series_reducer = "REDUCE_SUM" group_by_fields = [] } trigger { count = 1 } } } notification_channels = [ google_monitoring_notification_channel.email_channel.id, ] }
Untuk contoh tambahan, lihat berikut ini:
Untuk mengetahui informasi selengkapnya tentang metrik penghitung, lihat Ringkasan metrik berbasis log.
Memantau penggunaan tampilan terwujud
Untuk melihat penggunaan tampilan terwujud untuk tugas kueri, Anda dapat memanggil
metode jobs.get atau membuat kueri
tabel virtual INFORMATION_SCHEMA.JOBS_BY_*,
dan melihat kolom materialized_view_statistics, yang memberikan detail tentang
penggunaan tampilan terwujud oleh kueri, termasuk detail berikut:
- Apakah tampilan terwujud digunakan.
- Jika tampilan terwujud tidak digunakan, alasan penolakannya.
Contoh:
SELECT job_id, materialized_view_statistics FROM region-US.INFORMATION_SCHEMA.JOBS_BY_PROJECT WHERE job_id = '<my-query-job-id>';
Untuk melihat penggunaan tampilan terwujud dari waktu ke waktu, buat kueri tabel virtual INFORMATION_SCHEMA.JOBS_BY_*.
Misalnya, kueri berikut menampilkan ringkasan tugas kueri terbaru yang menggunakan tampilan terwujud target:
SELECT mv.table_reference.dataset_id, mv.table_reference.table_id, MAX(job.creation_time) latest_job_time, COUNT(job_id) job_count FROM region-US.INFORMATION_SCHEMA.JOBS_BY_PROJECT job, UNNEST(materialized_view_statistics.materialized_view) mv WHERE job.creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP, INTERVAL 7 DAY) AND mv.table_reference.dataset_id = 'MY_DATASET' AND mv.table_reference.table_id = 'MY_MATERIALIZED_VIEW' AND mv.chosen = TRUE GROUP BY 1, 2;
Memecahkan masalah kueri lambat dengan tampilan terwujud
Jika kueri Anda menggunakan tampilan terwujud dan berjalan lebih lambat dari yang diharapkan, lakukan hal berikut:
- Verifikasi bahwa tampilan terwujud yang dimaksud benar-benar digunakan oleh kueri. Untuk petunjuk mendetail, lihat Memantau penggunaan tampilan terwujud.
- Periksa keaktualan tampilan terwujud Anda.
- Tinjau definisi tampilan terwujud dan data yang dirujuknya, lalu pertimbangkan teknik untuk mengoptimalkan penggunaan tampilan terwujud.