Topik wawancara representatif

Wawancara Data Engineering: Memantau Kesegaran Data untuk Tabel CDC BigQuery

DataSulit
Tim Redaksi Offer.ccDipublikasikan Diperbarui

Pertanyaan

Sebuah tabel CDC BigQuery memiliki `max_staleness`: dasbor terkadang membaca baseline usang yang diizinkan, sementara kueri lain menjadi lambat saat menggabungkan perubahan yang tertunda. Bagaimana Anda memantau progres penerapan dan membedakan kondisi-kondisi ini?

Pertanyaan dan konteks

Dalam batas max_staleness yang dikonfigurasi pada tabel change data capture (CDC) BigQuery, dasbor dapat membaca baseline usang yang diizinkan pada latensi normal. Begitu perubahan yang tertunda lebih lama dari jendela waktu tersebut, penggabungan saat kueri (query-time merge) dapat mengembalikan hasil terkini dengan latensi yang lebih tinggi. Tugasnya adalah membedakan kondisi-kondisi ini dan backlog penerapan di latar belakang (background apply backlog) menggunakan watermark dan metrik pekerjaan milik platform itu sendiri.

Apa yang dievaluasi oleh pewawancara

  • Mengukur progres yang diterapkan dengan upsert_stream_apply_watermark.
  • Memisahkan keusangan yang diizinkan, backlog penerapan di latar belakang, dan penggabungan runtime (runtime merge).
  • Menghubungkan kapasitas latar belakang yang tidak memadai dengan latensi kueri pengguna.
  • Memberikan peringatan berdasarkan ambang batas bisnis dan durasi alih-alih satu sampel yang bising.

Klarifikasi sebelum menjawab

Tetapkan toleransi bisnis, max_staleness tiap tabel, lonjakan penulisan (write peaks), reservasi latar belakang, dan frekuensi dasbor. Sertakan tujuan penghapusan karena penghapusan CDC baru diterapkan hanya setelah watermark melewati waktu penulisannya.

Kerangka jawaban 30 detik

Lakukan polling pada INFORMATION_SCHEMA.TABLES.upsert_stream_apply_watermark dan bandingkan now - watermark dengan konfigurasi tabel serta ambang batas bisnis. Hubungkan hal tersebut dengan P95 penerapan latar belakang, antrean dan kegagalan, ditambah jumlah runtime merge dan latensi kueri. Kirim peringatan (page) hanya jika pelanggaran watermark yang berkepanjangan disertai dengan kejenuhan sumber daya atau dampak pada pengguna.

Pembahasan mendalam langkah demi langkah

Buat metrik kardinalitas rendah per produk data: usia watermark, max_staleness, P95 penerapan latar belakang, kegagalan, dan kueri runtime merge. Di dalam jendela waktu yang dikonfigurasi, kueri dapat membaca baseline. Di luar itu, BigQuery dapat menggabungkan perubahan yang tertunda pada waktu kueri, sehingga meningkatkan latensi; penggabungan runtime tersebut tidak memajukan watermark.

Gunakan dua gerbang: dua pelanggaran ambang batas bisnis berturut-turut menghasilkan peringatan (warning); kejenuhan reservasi, batas waktu penerapan (apply timeout), atau latensi dasbor meningkatkannya menjadi page. Heartbeat sumber memisahkan kondisi ketiadaan data baru dari backlog penerapan.

Diagnosis penulisan, pekerjaan latar belakang, kapasitas, dan runtime merge secara berurutan. Kemudian tambahkan kapasitas latar belakang, ratakan input, atau tinjau kembali jendela waktunya. Jangan melemahkan tujuan bisnis hanya untuk membungkam peringatan.

Contoh jawaban yang kuat

Watermark yang diterapkan adalah sinyal utama saya; pekerjaan penerapan dan penggabungan kueri menjelaskannya. Setiap menit saya membandingkan usia watermark dengan SLO dan opsi tabel, lalu menghubungkan P95 penerapan, kapasitas, dan latensi ekor (tail latency) kueri.

Pemulihan mengharuskan watermark untuk mengejar ketertinggalan, penurunan runtime merge, dan normalisasi latensi dasbor. Pemutaran ulang beban puncak (peak-load replay) membuktikan ruang kapasitas tambahan (headroom).

Kesalahan umum

  • Hanya memantau keberhasilan penulisan atau pekerjaan pipeline yang berwarna hijau.
  • Memperlakukan waktu peristiwa sebagai watermark yang diterapkan BigQuery.
  • Mengasumsikan bahwa runtime merge memajukan watermark.
  • Meningkatkan max_staleness hanya untuk menghilangkan peringatan.
  • Tidak memiliki heartbeat sumber.

Pertanyaan lanjutan

Mengapa runtime merge dapat memperlambat kueri?

Kueri menggabungkan data baseline dengan modifikasi yang tertunda untuk mengembalikan hasil terkini, sehingga menghabiskan waktu dan komputasi tambahan.

Bagaimana jika watermark bernilai null?

Periksa konfigurasi CDC, mutasi terkini, dan pekerjaan latar belakang. Perlakukan status tidak diketahui sebagai statusnya sendiri, bukan lag nol.

Kapan penghapusan CDC diterapkan?

Hanya setelah upsert_stream_apply_watermark melewati stempel waktu saat penghapusan tersebut di-stream.

Bagaimana Anda membuktikan bahwa penskalaan berhasil?

Di bawah beban puncak yang representatif, syaratkan peningkatan bersamaan pada P95 penerapan, usia watermark, jumlah runtime merge, dan latensi ekor dasbor.

Sumber publik

Pertanyaan terkait