Petunjuk dan ruang lingkup
Bisnis ingin data yang ditulis ke BigQuery memicu peringatan dengan cepat dan mengirimkan hasilnya ke tabel, Pub/Sub, Bigtable, atau Spanner. Jelaskan apakah akan menggunakan continuous query BigQuery dan bagaimana Anda akan menangani semantik input, otorisasi, waktu proses (runtime), wilayah (region), biaya, dan pemulihan. Jangan membatasi jawaban hanya pada sintaksis SQL.
Apa yang sedang diuji oleh pewawancara
- Apakah Anda memahami continuous query sebagai SQL yang berjalan terus-menerus, bukan polling dengan interval tetap.
- Apakah Anda dapat memposisikannya secara relatif terhadap Dataflow, Pub/Sub, dan kueri biasa berdasarkan latensi dan semantik data.
- Apakah Anda memverifikasi edisi Enterprise, reservasi
CONTINUOUS, akun layanan (service account), dan batasan regional. - Apakah Anda menangani output duplikat, backpressure, pemantauan, perilaku restart, dan biaya.
Pertanyaan klarifikasi
- Apakah input bersifat append-only, atau apakah baris yang ada dapat diperbarui dan dihapus? Apakah data duplikat dapat diterima?
- Apakah tujuannya adalah BigQuery, Pub/Sub, Bigtable, atau Spanner, dan bisakah konsumen melakukan percobaan ulang (retry) dengan aman?
- Jaminan latensi, runtime, dan wilayah data apa yang diperlukan? Apakah proyek telah diprovisikan untuk hal tersebut?
- Setelah kegagalan, dari mana pemrosesan dilanjutkan, dan bagaimana lag, kesalahan, serta volume output dipantau?
Jawaban 30 detik
Pertama-tama saya akan memverifikasi bahwa persyaratannya benar-benar pemrosesan berkelanjutan. Continuous query menganalisis data BigQuery yang masuk dan menulis atau mengekspor hasil, tetapi mereka memiliki batasan edisi, kapasitas, otorisasi, dan regional. Tentukan kunci idempotensi, pilih tujuan, dan siapkan akun layanan, reservasi CONTINUOUS, serta pemantauan. Validasi latensi, duplikat, biaya, penghentian, dan pemulihan dengan lalu lintas terkontrol; jangan perlakukan fitur ini sebagai pengganti Cron yang tak terbatas dan gratis.
Desain langkah demi langkah
1. Tentukan semantik data terlebih dahulu
Continuous query terus memproses data yang ditulis ke tabel BigQuery. Penambahan (append), peristiwa yang terlambat, pembaruan, dan penghapusan memiliki arti yang berbeda. Jika bisnis memerlukan status (state) yang kompleks, jendela waktu peristiwa (event-time windows), atau pengurutan yang ketat, konfirmasikan perilaku SQL yang didukung dan bandingkan dengan pemroses stream seperti Dataflow.
2. Pilih jalur output
Dokumentasi mendukung penyisipan hasil ke dalam tabel BigQuery atau menggunakan EXPORT DATA ke Pub/Sub, Bigtable, atau Spanner. Pilih berdasarkan throughput downstream, pengurutan, idempotensi, dan wilayah. Pub/Sub berguna untuk tahap pemrosesan peristiwa lainnya; penulisan tabel langsung membutuhkan deduplikasi dan kunci retensi.
3. Verifikasi batasan runtime dan otorisasi
Anda dapat membuat dan menjalankan continuous query dengan akun pengguna atau akun layanan; mengekspor ke Pub/Sub memerlukan akun layanan. Tugas akun pengguna dapat berjalan hingga dua hari, sedangkan tugas akun layanan dapat berjalan hingga 150 hari. Continuous query memerlukan edisi Enterprise atau Enterprise Plus dan penetapan reservasi dengan tipe CONTINUOUS.
4. Anggaran, pantau, dan pulihkan
Continuous query menggunakan harga komputasi kapasitas BigQuery, sedangkan layanan penerima dikenakan biaya terpisah. Pantau metrik khusus kueri, latensi input-ke-output, kesalahan, restart, dan volume output; tentukan prosedur penghentian, pembangunan ulang, dan peringatan. Pulihkan dari kunci idempotensi atau watermark dan putar ulang hanya rentang yang dapat diterima, sehingga restart tidak menduplikasi efek samping.
Contoh jawaban berkualitas tinggi
Saya akan mengevaluasi continuous query sebagai batasan operasional produk data. Fitur ini dapat menganalisis data yang ditulis ke BigQuery secara terus-menerus dan menulis atau mengekspor hasil ke BigQuery, Pub/Sub, Bigtable, atau Spanner, tetapi semantik penambahan versus perubahan serta toleransi duplikat menentukan apakah fitur ini cocok. Saya akan memverifikasi edisi Enterprise, reservasi CONTINUOUS, akun layanan, runtime maksimum, dan batas wilayah. Kontrak output akan menentukan idempotensi, percobaan ulang, dan penanganan dead-letter; telemetri akan mencakup lag, backlog, kesalahan, dan biaya. Sebelum peluncuran, lalu lintas terkontrol akan menguji latensi dan perilaku restart, dengan prosedur jeda, lanjutkan, dan backfill yang eksplisit. Jika beban kerja membutuhkan status waktu peristiwa yang kaya, pengurutan ketat, atau topologi yang bertahan lebih lama, saya akan membandingkannya dengan pemroses stream khusus daripada memaksakan setiap kebutuhan real-time ke dalam BigQuery.
Kesalahan umum
- Memperlakukan continuous query sebagai kueri yang berjalan sekali per menit.
- Mengabaikan persyaratan Enterprise atau Enterprise Plus, reservasi
CONTINUOUS, atau akun layanan. - Mengasumsikan setiap tujuan memiliki semantik pengurutan dan duplikat yang identik.
- Menghilangkan watermark atau kunci idempotensi untuk restart, duplikat, dan data yang terlambat.
- Mengukur latensi SQL tanpa memperhitungkan harga kapasitas BigQuery dan layanan downstream.
- Memperlakukan batas runtime dua hari atau 150 hari sebagai janji eksekusi permanen.
Pertanyaan lanjutan dan tanggapan
Kapan Anda akan memilih Dataflow?
Bandingkan Dataflow atau pemroses stream lainnya ketika beban kerja membutuhkan jendela waktu peristiwa yang kompleks, manajemen status, pengurutan ketat, konektor yang kaya, atau topologi yang berumur panjang. Batasannya bersifat semantik dan operasional, bukan jumlah baris SQL.
Bagaimana Anda menghindari peringatan duplikat setelah restart?
Sertakan kunci idempotensi peristiwa atau bisnis di setiap output, lakukan deduplikasi atau transaksi di downstream, dan catat watermark serta batch pemrosesan. Lanjutkan dari batas pemutaran ulang yang aman dan dokumentasikan perilaku duplikat yang tidak dapat dihindari kepada konsumen.
Bagaimana Anda memutuskan apakah biayanya dapat diterima?
Perkirakan slot kapasitas, penyerapan (ingestion) dan penyimpanan, ditambah biaya Pub/Sub, Bigtable, atau Spanner secara terpisah. Lakukan uji beban pada kondisi stabil, periode tidak aktif, dan saat beban puncak, lalu kalibrasikan anggaran dengan latensi dan konsumsi slot yang diamati.