Perintah dan konteks
Pesanan dan pembayaran digabungkan berdasarkan ID pengguna dan pesanan, tetapi pembayaran mungkin tiba dua jam setelah pesanan. Rancang batas interval (bounds), watermark, retensi state, jalur data terlambat, dan strategi koreksi untuk Flink Event Time Interval Join. Bedakan antara event time, processing time, dan ingestion time, serta jelaskan mengapa urutan kedatangan pesan saja tidak cukup.
Hal yang dievaluasi pewawancara
- Mendefinisikan interval waktu bisnis alih-alih menebak urutan dari processing time.
- Memahami bahwa watermark adalah sinyal progres, bukan waktu global yang pasti.
- Menjelaskan state dua stream, pembersihan, data terlambat, dan penanganan event duplikat.
- Menyeimbangkan latensi, kelengkapan data, biaya state, dan kemampuan pemutaran ulang (replayability).
Pertanyaan klarifikasi yang perlu diajukan
- Apa saja field waktu bisnis pada pesanan dan pembayaran, dan mungkinkah terjadi pergeseran jam (clock drift)?
- Seberapa terlambat pembayaran dapat diterima, dan apakah diperlukan koreksi atau rekonsiliasi manual setelah interval tersebut?
- Apakah join key bersifat unik, dan mungkinkah ada duplikat, pembatalan, atau pembayaran ganda?
- Apakah sistem downstream menerima fakta append-only, pembaruan, atau hanya tabel rekonsiliasi akhir?
Kerangka jawaban 30 detik
Definisikan interval dalam waktu bisnis, seperti pembayaran dari nol hingga dua jam setelah pesanan. Partisi kedua stream berdasarkan key, majukan watermark event-time, dan biarkan join mempertahankan rekaman kedua sisi hingga progres membuktikan bahwa rekaman tersebut tidak mungkin cocok lagi. Event terlambat dalam batas yang diizinkan dapat digabungkan; event di luar batas tersebut dikirim ke side output atau stream kompensasi. Akhiri dengan deduplikasi, checkpoint, replay, dan idempoten pada downstream.
Pembahasan mendalam langkah demi langkah
1. Memilih event time dan batas interval
Ekstrak timestamp event bisnis yang tidak dapat diubah (immutable) dari setiap rekaman dan gunakan key pengguna-dan-pesanan yang sama. Jika pembayaran harus terjadi setelah pesanan, gunakan batas bawah nol dan batas atas dua jam; izinkan batas bawah negatif hanya jika pembayaran lebih awal valid. Interval ini berasal dari SLA bisnis, bukan dari window yang panjang secara sembarangan. Processing time hanya cocok jika pengurutan historis tidak menjadi masalah.
2. Watermark dan state dua stream
Setiap input membuat watermark dari batas out-of-order miliknya sendiri. Join menunggu hingga progres di kedua sisi cukup untuk memastikan bahwa suatu rekaman tidak dapat menemukan kecocokan lain; hingga saat itu, rekaman tetap berada dalam keyed state. Ukuran state bergantung pada laju input, panjang interval, kardinalitas key, dan batas kekacauan urutan (disorder bound). Checkpoint mempertahankan state tersebut sehingga pemulihan berlanjut dari posisi yang diketahui alih-alih menebak hasil mana yang sudah dikeluarkan.
3. Event terlambat, duplikat, dan pembatalan
Event dalam rentang kekacauan urutan dan keterlambatan yang diizinkan dapat bergabung. Event di luar rentang tersebut dikirim ke side output atau topik kompensasi yang tahan lama untuk rekonsiliasi. Lakukan deduplikasi dengan ID event atau business key, dan modelkan pembatalan atau pengembalian dana pembayaran sebagai event baru atau retraksi eksplisit. Jika downstream mendukung pembaruan, keluarkan upsert atau retraksi; jika tidak, pertahankan tabel koreksi alih-alih menulis ulang riwayat secara diam-diam.
4. Latensi, biaya state, dan validasi
Batas interval dan batas ketidakteraturan yang lebih pendek mengurangi state dan latensi tetapi meningkatkan risiko hilangnya kecocokan data. Batas yang lebih lebar meningkatkan kelengkapan data sekaligus menaikkan biaya memori, checkpoint, dan pemulihan. Sebelum peluncuran, putar ulang ketidakteraturan urutan, duplikat, event lintas-window, dan kegagalan pemulihan. Periksa join hit rate, volume side output, watermark lag, ukuran state, durasi checkpoint, dan tingkat duplikasi. Idempotency key menyeluruh mencegah tagihan ganda selama restart atau replay.
Contoh jawaban model
Saya akan mengonfirmasi timestamp bisnis pesanan dan pembayaran serta SLA keterlambatan yang diizinkan, lalu mempartisi berdasarkan ID pengguna dan pesanan. Jika pembayaran hanya boleh tiba dalam waktu dua jam setelah pesanan, saya akan menetapkan interval event-time dari nol hingga dua jam daripada menggunakan window processing-time. Setiap stream mengeluarkan watermark; join menyimpan rekaman dalam keyed state dan membersihkannya saat progres membuktikan tidak ada lagi kecocokan.
Event terlambat dalam batas interval akan ikut bergabung; event di luar itu dialihkan ke side output atau stream kompensasi. Lakukan deduplikasi berdasarkan ID event, dan representasikan pengembalian dana serta pembatalan sebagai event baru. Keluarkan upsert atau retraksi jika didukung, atau pertahankan tabel koreksi. Putar ulang ketidakteraturan data, duplikat, dan pemulihan sebelum peluncuran, amati hit rate, side output, watermark lag, state, dan checkpoint, serta gunakan idempotency key untuk keamanan saat replay.
Kesalahan umum
- Mengganti waktu event bisnis dengan waktu kedatangan pesan.
- Menganggap watermark sebagai bukti mutlak bahwa semua event upstream telah tiba.
- Memilih window yang besar tanpa mendiskusikan pembersihan state, checkpoint, dan pemulihan.
- Membuang event terlambat di luar window tanpa jalur side output atau rekonsiliasi.
- Mengabaikan deduplikasi dan sifat idempoten downstream, sehingga menghasilkan data pembayaran duplikat setelah restart.
Pertanyaan lanjutan dan jawabannya
Pertanyaan lanjutan 1: Mengapa tidak menggunakan dua window independen dan join biasa?
Window independen kehilangan progres event-time dan batas pembersihan dari kedua stream, sehingga interval waktu relatif sulit untuk diekspresikan. Interval Join menggabungkan pencocokan key dengan batas bawah dan atas eksplisit untuk hubungan ini.
Pertanyaan lanjutan 2: Apa yang Anda lakukan ketika watermark terhenti (stall)?
Periksa ketidakaktifan partisi (partition idleness), timestamp sumber, backpressure, dan konfigurasi keterlambatan urutan. Konfigurasikan idleness untuk partisi yang benar-benar hening agar satu partisi kosong tidak memblokir progres, namun jangan pernah memajukan watermark secara sembarangan untuk menutupi kegagalan sumber data.
Pertanyaan lanjutan 3: Bagaimana jika bisnis menerima pembayaran yang tiba setelah dua jam?
Pisahkan proses join real-time dari rekonsiliasi. Keluarkan hasil sementara, simpan event yang terlambat ke stream kompensasi, dan biarkan proses batch atau streaming job kedua menghasilkan koreksi menggunakan upsert yang idempoten.