Gesaan dan konteks
Dalam max_staleness yang dikonfigurasikan bagi jadual penangkapan data perubahan (CDC) BigQuery, papan pemuka boleh membaca garis dasar usang yang dibenarkan pada kependaman normal. Sebaik sahaja perubahan yang belum selesai lebih lama daripada tetingkap tersebut, penggabungan pada masa pertanyaan (query-time merge) boleh mengembalikan hasil semasa pada kependaman yang lebih tinggi. Tugasnya adalah untuk membezakan keadaan ini dan tunggakan penggunaan latar belakang (background apply backlog) dengan tanda air dan metrik kerja platform itu sendiri.
Perkara yang dinilai oleh penemu duga
- Mengukur kemajuan yang digunakan dengan
upsert_stream_apply_watermark. - Memisahkan keusangan yang dibenarkan, tunggakan penggunaan latar belakang, dan penggabungan masa jalanan (runtime merge).
- Menghubungkan kapasiti latar belakang yang tidak mencukupi dengan kependaman pertanyaan pengguna.
- Memberi amaran berdasarkan ambang perniagaan dan tempoh dan bukannya satu sampel yang bising.
Penjelasan sebelum menjawab
Tetapkan toleransi perniagaan, max_staleness setiap jadual, puncak penulisan, tempahan latar belakang, dan kekerapan papan pemuka. Sertakan objektif pemadaman kerana pemadaman CDC hanya digunakan selepas tanda air melepasi masa penulisannya.
Rangka kerja jawapan 30 saat
Tinjau INFORMATION_SCHEMA.TABLES.upsert_stream_apply_watermark dan bandingkan now - watermark dengan konfigurasi jadual dan ambang perniagaan. Hubungkaitkannya dengan P95 penggunaan latar belakang, pembentukan giliran dan kegagalan, serta kiraan runtime merge dan kependaman pertanyaan. Hantar amaran (page) hanya apabila pelanggaran tanda air yang berterusan bergabung dengan ketepuan sumber atau kesan kepada pengguna.
Perbincangan mendalam langkah demi langkah
Cipta metrik kekardinalan rendah bagi setiap produk data: umur tanda air, max_staleness, P95 penggunaan latar belakang, kegagalan, dan pertanyaan runtime merge. Dalam tetingkap yang dikonfigurasikan, sesuatu pertanyaan boleh membaca garis dasar. Di luarnya, BigQuery mungkin menggabungkan perubahan yang belum selesai pada masa pertanyaan, sekali gus meningkatkan kependaman; runtime merge tersebut tidak memajukan tanda air.
Gunakan dua pintu: dua pelanggaran ambang perniagaan berturut-turut menghasilkan amaran (warning); ketepuan tempahan, masa tamat penggunaan (apply timeout), atau kependaman papan pemuka menaikkannya kepada page. Denyutan nadi (heartbeat) sumber memisahkan ketiadaan data baharu daripada tunggakan penggunaan.
Diagnosis penulisan, kerja latar belakang, kapasiti, dan runtime merge mengikut urutan tersebut. Kemudian tambah kapasiti latar belakang, lancarkan input, atau semak semula tetingkap. Jangan melemahkan objektif perniagaan semata-mata untuk mendiamkan amaran.
Contoh jawapan yang mantap
Tanda air yang digunakan ialah isyarat utama saya; kerja penggunaan dan penggabungan pertanyaan menjelaskannya. Setiap minit saya membandingkan umur tanda air dengan SLO dan pilihan jadual, kemudian mengaitkan P95 penggunaan, kapasiti, dan kependaman ekor (tail latency) pertanyaan.
Pemulihan memerlukan tanda air untuk mengejar semula, runtime merge berkurangan, dan kependaman papan pemuka kembali normal. Main semula beban puncak (peak-load replay) membuktikan ruang kelegaan tambahan (headroom).
Kesilapan biasa
- Hanya memantau penulisan yang berjaya atau kerja saluran paip yang berwarna hijau.
- Menganggap masa peristiwa sebagai tanda air BigQuery yang digunakan.
- Menganggap bahawa runtime merge memajukan tanda air.
- Meningkatkan
max_stalenesssemata-mata untuk membuang amaran. - Ketiadaan denyutan nadi (heartbeat) sumber.
Soalan susulan
Mengapakah runtime merge boleh memperlahankan pertanyaan?
Pertanyaan menggabungkan data garis dasar dengan pengubahsuaian yang belum selesai untuk mengembalikan hasil semasa, menggunakan masa dan pengiraan tambahan.
Bagaimana jika tanda air adalah null?
Semak konfigurasi CDC, mutasi terkini, dan kerja latar belakang. Anggap tidak diketahui sebagai keadaannya yang tersendiri, bukan sifar lag.
Bilakah pemadaman CDC digunakan?
Hanya selepas upsert_stream_apply_watermark melepasi cap masa di mana pemadaman itu distrim.
Bagaimanakah anda membuktikan penskalaan telah berjaya?
Di bawah beban puncak yang mewakili, syaratkan peningkatan serentak bagi P95 penggunaan, umur tanda air, kiraan runtime merge, dan kependaman ekor papan pemuka.