Kelola jendela waktu

Pertanyaan

Kapan sebuah jendela waktu boleh dianggap selesai, dan apa yang dilakukan kalau event datang setelahnya?

Setelah baca ini, kamu bisa menetapkan watermark dan batas keterlambatan, memilih perlakuan untuk event terlambat, dan menghitung ongkos replay dari event mentah.

Prasyarat dan contoh

Kamu sudah punya definisi event dan pemisahan waktu event dari waktu pemrosesan (M12.01), dan paham struktur agregat yang bisa digabung (M12.02 sampai M12.05).

Contoh: agregat "klik per menit" memakai jendela tetap per menit berdasarkan waktu event. Pukul 10:01:05 sistem ingin menyelesaikan jendela 10:00. Tapi sebuah ponsel baru menyambung ulang dan mengirim klik berstempel 10:00:42. Kalau jendela 10:00 sudah ditutup dan dikirim ke dasbor, klik itu hilang atau terhitung di tempat yang salah.

Dua jawaban ekstrem sama-sama buruk. Menutup segera membuat hasil cepat tapi tidak lengkap. Menunggu selamanya membuat hasil lengkap tapi tidak pernah keluar.

Mekanisme

Watermark. Perkiraan "waktu event sampai mana yang sudah kita lihat hampir semuanya". Definisi umum: watermark = waktu event terbesar yang pernah terlihat − keterlambatan yang ditoleransi. Jendela [10:00, 10:01) dianggap lengkap saat watermark melewati 10:01. Dengan toleransi 5 menit, jendela itu baru ditutup saat event berstempel 10:06 terlihat. Watermark adalah heuristik. Ia tidak menjamin tidak ada event yang lebih lama datang kemudian.

Perlakuan event terlambat. Setelah jendela ditutup, ada tiga pilihan:

1. Buang dan hitung jumlahnya sebagai metrik. Paling sederhana, hasil tidak pernah berubah.
2. Alihkan ke penyimpanan terpisah untuk koreksi manual atau batch malam.
3. Perbarui hasil lama. Tulis ulang baris jendela itu dengan nilai baru (upsert). Konsumen hilir harus siap menerima revisi, dan aksi seperti "kirim laporan pukul 10:06" sebaiknya tidak dijalankan ulang.

Retensi event mentah. Perbaikan apa pun bergantung pada apakah event mentah masih ada. Dengan 2 miliar event per hari dan 200 byte per event, itu 400 GB per hari. Retensi 30 hari berarti 12 TB (sebelum kompresi dan replikasi). Biaya itu dibayar supaya bisa menghitung ulang kalau definisi atau bug berubah. Tentukan retensi dari pertanyaan "berapa jauh ke belakang kita mungkin perlu mengoreksi?", bukan dari "berapa banyak disk yang ada".

Status turunan. Agregat, sketch, dan counter adalah status turunan dari log event. Anggap log sebagai sumber kebenaran dan status turunan sebagai cache yang bisa dibangun ulang. Itu membuat perbaikan menjadi operasi biasa: hapus status, putar ulang, bandingkan.

Biaya replay. Replay satu hari = 400 GB. Pada throughput baca efektif 200 MB per detik, itu 2.000 detik, atau sekitar 33 menit, sebelum biaya komputasi agregasi. Replay 30 hari secara serial membutuhkan sekitar 17 jam. Jadi rencanakan replay yang paralel per partisi dan per hari, dan pastikan agregasi idempoten supaya replay tidak menggandakan hasil.

Saat rancangan ini gagal

• Satu sumber lambat menahan semua. Watermark global ditentukan oleh partisi atau sumber paling lambat. Satu perangkat yang diam berjam-jam menahan penutupan jendela untuk semuanya. Pakai watermark per partisi dan tetapkan timeout untuk sumber yang idle.
• Toleransi terlalu kecil atau terlalu besar. Terlalu kecil, banyak event dibuang (periksa rasio event terlambat). Terlalu besar, dasbor selalu tertinggal 30 menit dan tidak ada yang memakainya sebagai "hampir real-time".
• Revisi mengejutkan konsumen. Laporan harian sudah dikirim, lalu angka kemarin berubah karena upsert. Tentukan siapa yang boleh melihat angka sementara dan angka final, lalu beri label keduanya.
• Replay menggandakan. Agregasi yang hanya n = n + 1 dan dijalankan ulang menghitung dua kali. Replay menuntut penulisan yang idempoten (timpa nilai jendela, bukan tambahkan).
• Retensi sudah habis. Bug ditemukan pada hari ke-45, event mentah hanya 30 hari. Koreksi hanya bisa memperbaiki dari agregat yang sudah salah, dan itu tidak bisa dipulihkan.

Latihan

Pipeline menghitung klik per menit. Throughput 2.000 event per detik, 200 byte per event. Kamu menemukan bug yang salah menghitung 3 hari terakhir. Retensi event mentah 14 hari. Throughput baca efektif satu worker 100 MB per detik, dan kamu punya 8 worker.

1. Berapa data yang harus diputar ulang?
2. Berapa lama replay dengan 8 worker, mengabaikan komputasi?
3. Apa syarat supaya replay aman?

Lihat pembahasan+

1. 2.000 × 200 B = 400 KB per detik. Per hari 400 KB × 86.400 = sekitar 34,6 GB. Tiga hari = sekitar 104 GB.
2. 8 worker × 100 MB/s = 800 MB/s. 104 GB / 0,8 GB/s = sekitar 130 detik, kira-kira 2 menit (dengan asumsi partisi cukup untuk memparalelkan sempurna). Waktu nyata lebih lama karena komputasi dan tulisan, jadi anggap beberapa kali lipat.
3. Penulisan hasil harus idempoten: upsert per kunci (tautan, menit) yang menimpa nilai, bukan menambah. Jalankan replay ke tabel baru atau menimpa jendela yang sama secara menyeluruh, bandingkan dengan hasil lama pada sampel, lalu alihkan konsumen. Dan pastikan event mentah untuk tiga hari itu memang masih dalam retensi 14 hari. Bug yang ditemukan di hari ke-16 tidak bisa diperbaiki dengan cara ini.

Terkait

• Sebelumnya: M12.05 Perkirakan distribusi.
• Definisi waktu event dan deduplikasi ada di M12.01 Definisikan event.
• Replay dan log berpartisi dibahas di M10, yang belum tersedia.
• Lab L12, proyek B09, dan rancangan D12 belum tersedia.

Catatan

• Asumsi: sumber event bisa diurutkan per partisi dan agregasi bisa ditulis secara idempoten.
• Yang nggak dibahas: sliding dan session window, serta jaminan exactly-once dari mesin stream tertentu.
• Angka ukuran dan throughput adalah ilustrasi. Ukur di lingkungan kamu, termasuk kompresi.
• Terakhir ditinjau: 26 Oktober 2026.