Gesaan dan skop
Pihak perniagaan mahu data yang ditulis ke BigQuery mencetuskan amaran dengan cepat dan menghantar hasil ke jadual, Pub/Sub, Bigtable atau Spanner. Terangkan sama ada perlu menggunakan continuous query BigQuery dan cara anda mengendalikan semantik input, pengesahan (authorization), masa jalanan (runtime), rantau, kos dan pemulihan. Jangan hadkan jawapan kepada sintaks SQL sahaja.
Perkara yang diuji oleh penemu duga
- Sama ada anda memahami continuous query sebagai SQL yang berjalan secara berterusan, bukan pengundian selang masa tetap.
- Sama ada anda boleh meletakkannya secara relatif kepada Dataflow, Pub/Sub dan pertanyaan biasa berdasarkan pendaman (latency) dan semantik data.
- Sama ada anda mengesahkan edisi Enterprise, tempahan
CONTINUOUS, akaun perkhidmatan dan kekangan wilayah. - Sama ada anda menangani output pendua, tekanan belakang (backpressure), pemantauan, tingkah laku mula semula (restart) dan kos.
Soalan penjelasan
- Adakah input jenis tambah sahaja (append-only), atau adakah baris sedia ada boleh dikemas kini dan dipadamkan? Adakah data pendua boleh diterima?
- Adakah destinasi tersebut BigQuery, Pub/Sub, Bigtable atau Spanner, dan bolehkah pengguna mencuba semula (retry) dengan selamat?
- Apakah jaminan pendaman, masa jalanan dan wilayah data yang diperlukan? Adakah projek diperuntukkan untuknya?
- Selepas kegagalan, di manakah pemprosesan disambung semula, dan bagaimanakah kelambatan (lag), ralat dan volum output dipantau?
Jawapan 30 saat
Saya terlebih dahulu akan mengesahkan bahawa keperluan tersebut benar-benar pemprosesan berterusan. Continuous query menganalisis data BigQuery yang masuk dan menulis atau mengeksport hasil, tetapi ia mempunyai kekangan edisi, kapasiti, pengesahan dan wilayah. Tentukan kunci keidempotennan (idempotency), pilih destinasi, dan sediakan akaun perkhidmatan, tempahan CONTINUOUS serta pemantauan. Sahkan pendaman, pendua, kos, penghentian dan pemulihan dengan trafik terkawal; jangan anggap ciri ini sebagai pengganti Cron percuma yang tanpa had.
Reka bentuk langkah demi langkah
1. Tentukan semantik data terlebih dahulu
Continuous query terus memproses data yang ditulis ke jadual BigQuery. Penambahan, peristiwa lewat, kemas kini dan pemadaman mempunyai makna yang berbeza. Jika perniagaan memerlukan keadaan (state) yang kompleks, tetingkap masa peristiwa (event-time windows) atau susunan yang ketat, sahkan gelagat SQL yang disokong dan bandingkan dengan pemproses penstriman seperti Dataflow.
2. Pilih laluan output
Dokumentasi menyokong memasukkan hasil ke dalam jadual BigQuery atau menggunakan EXPORT DATA ke Pub/Sub, Bigtable atau Spanner. Pilih berdasarkan daya pemprosesan hiliran, susunan, keidempotennan dan wilayah. Pub/Sub berguna untuk peringkat pemprosesan peristiwa yang lain; penulisan jadual secara langsung memerlukan penyahduplikasian dan kunci pengekalan.
3. Sahkan kekangan masa jalanan dan pengesahan
Anda boleh membuat dan menjalankan continuous query dengan akaun pengguna atau akaun perkhidmatan; mengeksport ke Pub/Sub memerlukan akaun perkhidmatan. Tugas akaun pengguna boleh berjalan sehingga dua hari, manakala tugas akaun perkhidmatan boleh berjalan sehingga 150 hari. Continuous query memerlukan edisi Enterprise atau Enterprise Plus dan peruntukan tempahan jenis CONTINUOUS.
4. Belanjawan, pantau dan pulihkan
Continuous query menggunakan harga pengiraan kapasiti BigQuery, manakala perkhidmatan penerima dikenakan kos secara berasingan. Pantau metrik khusus pertanyaan, pendaman input-ke-output, ralat, pemulaan semula dan volum output; tentukan prosedur henti, bina semula dan amaran. Pulihkan daripada kunci keidempotennan atau tanda air (watermark) dan mainkan semula julat yang boleh diterima sahaja, supaya pemulaan semula tidak menduplikasi kesan sampingan.
Model jawapan berkualiti tinggi
Saya akan menilai continuous query sebagai kekangan operasi produk data. Ia boleh menganalisis data yang ditulis ke BigQuery secara berterusan dan menulis atau mengeksport hasil ke BigQuery, Pub/Sub, Bigtable atau Spanner, tetapi semantik tambah-lawan-ubah serta toleransi pendua menentukan sama ada ia sesuai. Saya akan mengesahkan edisi Enterprise, tempahan CONTINUOUS, akaun perkhidmatan, masa jalanan maksimum dan sempadan wilayah. Kontrak output akan menentukan keidempotennan, percubaan semula dan pengendalian dead-letter; telemetri akan merangkumi kelambatan, tunggakan (backlog), ralat dan kos. Sebelum pelancaran, trafik terkawal akan menguji pendaman dan tingkah laku mula semula, dengan prosedur jeda, sambung semula dan isian semula (backfill) yang jelas. Jika beban kerja memerlukan keadaan masa peristiwa yang kaya, susunan yang ketat atau topologi yang tahan lebih lama, saya akan membandingkan pemproses penstriman khusus daripada memaksa setiap keperluan masa nyata ke dalam BigQuery.
Kesilapan biasa
- Menganggap continuous query sebagai pertanyaan yang berjalan sekali setiap minit.
- Mengabaikan keperluan Enterprise atau Enterprise Plus, tempahan
CONTINUOUSatau akaun perkhidmatan. - Menganggap setiap destinasi mempunyai semantik susunan dan pendua yang serupa.
- Meniadakan tanda air atau kunci keidempotennan untuk pemulaan semula, pendua dan data lewat.
- Mengukur pendaman SQL tanpa mengambil kira harga kapasiti BigQuery dan perkhidmatan hiliran.
- Menganggap had masa operasi dua hari atau 150 hari sebagai janji pelaksanaan kekal.
Soalan susulan dan jawapan
Bilakah anda akan memilih Dataflow?
Bandingkan Dataflow atau pemproses penstriman lain apabila beban kerja memerlukan tetingkap masa peristiwa yang kompleks, pengurusan keadaan, susunan yang ketat, penyambung yang kaya atau topologi jangka hayat panjang. Sempadannya adalah dari segi semantik dan operasi, bukannya bilangan baris SQL.
Bagaimanakah anda mengelakkan amaran pendua selepas pemulaan semula?
Letakkan kunci keidempotennan peristiwa atau perniagaan dalam setiap output, lakukan penyahduplikasian atau urus niaga di peringkat hiliran, dan rekod tanda air serta kelompok pemprosesan. Sambung semula dari sempadan main semula yang selamat dan dokumentasikan sebarang tingkah laku pendua yang tidak dapat dielakkan kepada pengguna.
Bagaimanakah anda memutuskan sama ada kos itu boleh diterima?
Anggarkan slot kapasiti, penyerapan (ingestion) dan storan, serta caj Pub/Sub, Bigtable atau Spanner secara berasingan. Uji beban bagi keadaan stabil, tempoh melahu dan waktu puncak, kemudian tentukur belanjawan dengan pendaman dan penggunaan slot yang diperhatikan.