Pertanyaan dan konteks
Anda menghitung metrik jumlah pesanan dan nilai pesanan berdurasi lima menit. Klien offline, percobaan ulang (retries), dan pengiriman multi-wilayah menyebabkan event tiba terlambat, dan pesanan yang sama dapat dikirim lebih dari sekali. Bisnis menginginkan nilai awal dalam waktu satu menit dan koreksi tersedia untuk laporan dalam waktu 24 jam.
Bedakan waktu kejadian (event time) dari waktu pemrosesan (processing time), tentukan kapan sebuah window memancarkan hasil (emit), dan tunjukkan ke mana event yang terlambat diarahkan serta bagaimana konsumen mengidentifikasi koreksi.
Hal yang diuji oleh pewawancara
Semantik waktu
Jawaban yang kuat mendefinisikan stempel waktu event (timestamp), waktu pemrosesan, batas window, dan zona waktu sebelum menjelaskan bahwa watermark adalah perkiraan bahwa sebagian besar data untuk suatu window telah tiba.
Siklus hidup hasil
Pisahkan hasil awal, hasil tepat waktu (on-time), koreksi yang terlambat, dan data yang melewati batas waktu (cutoff). Satu kali emisi tidak secara otomatis menjadi kebenaran permanen.
State dan biaya
Diskusikan retensi state, kelonggaran keterlambatan (allowed lateness), cakupan komputasi ulang, hot keys, dan checkpoint. Menunggu tanpa batas membuat state dan biaya menjadi tidak terbatas.
Observabilitas
Lacak lag watermark, distribusi keterlambatan, rasio koreksi, event yang di-drop, rasio duplikat, dan kesegaran hasil (freshness).
Pertanyaan klarifikasi yang perlu diajukan
- Apakah metrik dikelompokkan berdasarkan event time atau waktu kedatangan (arrival time)?
- Berapa banyak kesalahan yang dapat diterima untuk hasil pertama, dan kapan batas waktu akhir (cutoff)?
- Haruskah event yang terlambat mengoreksi laporan yang sudah dipublikasikan?
- Apakah setiap event membawa event_id yang stabil untuk deduplikasi?
- Berapa laju puncak (peak rate) per kunci dan anggaran state maksimum?
- Haruskah event yang melewati batas waktu di-drop, dikarantina, atau dikomputasi ulang secara offline?
Kerangka jawaban 30 detik
“Saya akan menggunakan window event-time dan mewajibkan event_id beserta timestamp event. Pemroses stream menggunakan watermark untuk memancarkan hasil awal dan periode allowed-lateness yang terikat untuk koreksi; koreksi menggunakan kunci window yang sama dengan nomor revisi. Event yang melewati batas waktu diarahkan ke karantina dan komputasi ulang batch alih-alih menulis ulang riwayat secara diam-diam. Saya akan memantau lag watermark, persentil keterlambatan, tingkat koreksi, drop, dan ukuran state.”
Pembahasan mendalam langkah demi langkah
Langkah 1: Tentukan window dan waktu
Gunakan event time UTC dan window tetap seperti [10:00, 10:05). Waktu pemrosesan digunakan untuk peringatan operasional dan pemicu awal, bukan pengelompokan bisnis. Sertakan tenant, produk, atau wilayah dalam kunci.
Langkah 2: Memajukan watermark
Setiap partisi maju berdasarkan timestamp event yang diamati, sementara kebijakan global mengambil batas bawah yang aman. Deteksi partisi yang menganggur (idle); partisi yang hening tidak boleh menyandera seluruh pipeline.
Langkah 3: Memicu dan mengakumulasi
Pancarkan perkiraan dengan pemicu waktu pemrosesan, lalu pancarkan hasil tepat waktu ketika watermark melewati akhir window. Pilih accumulating atau discarding panes dan sertakan window_end, revision, dan is_final di setiap output.
Langkah 4: Tangani event yang terlambat dan terduplikasi
Dalam batas allowed lateness, lakukan deduplikasi berdasarkan event_id, perbarui state, dan pancarkan revisi baru. Pemutaran ulang (replay) tidak boleh menambahkan nominal dua kali. Pertahankan state hingga batas waktu bisnis, lalu bersihkan.
Langkah 5: Tentukan fallback untuk data yang terlambat
Tulis event yang melewati batas allowed lateness ke karantina beserta alasan dan payload aslinya. Pekerjaan batch menghitung ulang data 24 jam terakhir dan menerapkan upsert yang idempoten atau revisi yang lebih tinggi ke repositori koreksi.
Langkah 6: Uji dan publikasikan
Gunakan timestamp yang terkontrol untuk menguji pengurutan ulang, duplikat, partisi idle, pemulihan restart, dan keterlambatan batas. Konsumen mendeduplikasi (metric, window_end, revision) dan menggunakan revisi final atau yang disetujui batas waktu untuk laporan.
Contoh jawaban berkualitas tinggi
“Pertama, saya menjadikan event time, window, dan batas waktu (cutoff) sebagai kontrak yang eksplisit. Setiap event membawa eventid yang stabil, eventtime, dan schema_version. Pemroses membagi window berdasarkan tenant dan metrik selama lima menit. Watermark partisi memperhitungkan partisi idle, dan watermark global merupakan perkiraan konservatif dari penyelesaian window.
Sistem segera memancarkan revisi awal, memancarkan revisi tepat waktu setelah watermark melewati akhir window, dan menerima event terlambat selama 30 menit. Setiap output mencakup batas window, revisi, dan flag final, sehingga penulisan di downstream bersifat idempoten. Event yang terlambat lebih dari 30 menit masuk ke karantina; pekerjaan komputasi ulang 24 jam menghasilkan revisi yang lebih tinggi. Setelah batas waktu laporan, kami mengaudit event tersebut tetapi tidak menulis ulang buku besar bisnis secara diam-diam.
Saya memantau lag watermark, keterlambatan p50/p95/p99, tingkat koreksi dan drop, duplikat, byte state, backlog komputasi ulang, dan keterlambatan hasil akhir. Kapasitas adalah window aktif dikalikan state per window, yang dibatasi oleh checkpoint dan TTL state.”
Kesalahan umum
- Mengganti event time dengan processing time → event offline masuk ke window yang salah → pertahankan event_time dan cadangkan processing time untuk operasional.
- Memperlakukan watermark sebagai kebenaran mutlak → event yang terlambat hilang secara diam-diam → dokumentasikan sebagai perkiraan dan konfigurasikan allowed lateness serta karantina.
- Memancarkan satu hasil yang tidak dapat diubah (immutable) → koreksi tidak dapat disebarkan → gunakan revisi dan flag final untuk pembaruan yang idempoten.
- Menunggu tanpa batas → state dan biaya menjadi tidak terikat → tetapkan batas waktu bisnis dan lakukan komputasi ulang offline setelahnya.
- Melakukan deduplikasi hanya berdasarkan payload → urutan retry mengubah perhitungan ganda → gunakan event_id yang stabil dan state deduplikasi yang tahan lama (durable).
- Mengabaikan partisi idle → watermark terhenti dan peringatan memberikan data palsu → deteksi partisi idle dan kecualikan sementara dari batas bawah.
- Hanya menguji input yang berurutan → kegagalan batas muncul di produksi → lakukan pengujian dengan menyuntikkan data tidak berurutan, duplikat, data terlambat, restart, dan pemulihan.
Pertanyaan lanjutan dan tanggapan
Pertanyaan lanjutan 1: Mengapa watermark bisa terhenti (stall)?
Partisi mungkin hening, terputus, atau memperkirakan progres secara terlalu konservatif. Gabungkan batas waktu idle (idle timeouts), heartbeat partisi, dan peringatan lag watermark untuk membedakan antara keheningan dan kegagalan.
Pertanyaan lanjutan 2: Bagaimana cara memilih kelonggaran keterlambatan (allowed lateness)?
Gunakan riwayat keterlambatan, batas waktu bisnis, dan anggaran state. Mulailah dengan estimasi keterlambatan p99 dan validasi melalui replay. Waktu yang lebih lama tidak secara otomatis lebih benar; ini meningkatkan state dan biaya koreksi.
Pertanyaan lanjutan 3: Bagaimana cara mencegah badai koreksi (correction storm)?
Gunakan micro-batch untuk event yang terlambat, batasi koreksi per window, dan pertahankan hanya revisi terbaru di downstream. Selama lonjakan trafik, turunkan metrik non-kritis ke koreksi batch.
Pertanyaan lanjutan 4: Bisakah event yang melewati batas waktu di-drop?
Jangan pernah men-drop event secara diam-diam. Catat data karantina dan audit serta ukur dampaknya terhadap bisnis. Persyaratan akuntansi atau kepatuhan mungkin memerlukan komputasi ulang atau penanganan manual.
Pertanyaan lanjutan 5: Bagaimana cara mencegah hasil bergerak mundur setelah restart?
Buat checkpoint untuk state window, state deduplikasi, dan watermark. Gunakan revisi monotonik, tolak revisi yang lebih lama di downstream, putar ulang log, dan jalankan pemeriksaan konsistensi setelah pemulihan.
Sumber 1: Apache Beam Programming Guide
Beam mendefinisikan watermark, pemicu (triggers), allowed lateness, dan mode akumulasi, termasuk bagaimana data yang terlambat dapat menghasilkan pane baru.
Sumber 2: Apache Kafka Streams Core Concepts
Kafka Streams mendokumentasikan periode tenggang (grace period) untuk record yang tidak berurutan dan semantik pembuangan (discard) setelah akhir window ditambah grace.
Sumber 3: Pertanyaan wawancara streaming Dataford
Pertanyaan wawancara publik ini memperlakukan watermark, perutean event terlambat, komputasi ulang, dan pemantauan sebagai poin investigasi mendalam untuk skenario ini.