Bagaimana Anda Menangani Event yang Terlambat dan Tidak Berurutan dalam Streaming Aggregation?

1. Pertanyaan

Sebuah stream event pesanan mengagregasi jumlah dan hitungan pesanan berdasarkan customerId dalam jendela lima menit. Jam perangkat mungkin mengalami deviasi (drift), percobaan ulang jaringan menghasilkan pengiriman yang tidak berurutan, dan beberapa partisi Kafka mungkin untuk sementara tidak memiliki pesan baru. Hasil harus muncul dengan cepat sembari memungkinkan data yang terlambat untuk mengoreksi jendela dalam jangka waktu terbatas. Rancang penanganan event-time ini.

2. Batasan dan klarifikasi

Konfirmasikan apakah jendela menggunakan event time, write time, atau processing time; masalah ini menggunakan event time.
Tetapkan batas maksimum ketidakteraturan, seperti 30 detik, dan tentukan apa yang terjadi di luar batas tersebut.
Putuskan apakah hasilnya berupa event append-only atau snapshot yang dapat diperbarui; konsumen downstream harus dapat mengidentifikasi revisi.
Diskusikan partisi idle, timestamp tidak valid, event duplikat, dan job replay sehingga input tanpa pesan tidak disalahartikan sebagai akhir dari stream.

3. Konsep inti

Event time berasal dari rekaman itu sendiri. Watermark menyatakan bahwa sistem meyakini event time telah maju ke posisi tertentu. Jendela umumnya terpicu ketika watermark melewati titik akhirnya; rekaman yang tiba setelah watermark tersebut dan timestamp-nya masih termasuk dalam jendela tersebut dianggap terlambat. Ketika input paralel digabungkan, sebuah operator umumnya menunggu watermark input minimum, sehingga partisi yang tidak aktif dapat menahan progres global. Oleh karena itu, deteksi idle atau kebijakan timeout per partisi diperlukan.

4. Alur referensi

text

onRecord(event):
  ts = extractEventTimestamp(event)
  key = canonicalKey(event.customerId)
  updateWatermarkGenerator(ts)

  window = floorToFiveMinutes(ts)
  if ts <= currentWatermark + allowedLateness:
    state[window, key] = aggregate(state[window, key], event)
    emitUpsert(window, key, state[window, key], revision + 1)
  else:
    routeToLateData(window, key, event)

onWatermark(wm):
  finalizeWindowsBefore(wm)
  expireStateAfterRetention()

Source mengekstrak timestamp event dan menghasilkan watermark bounded-out-of-orderness. Tandai partisi sebagai idle setelah periode waktu yang lama tanpa data agar tidak menahan watermark yang digabungkan. Pertahankan state jendela selama periode allowed-lateness; perbarui hasil dengan upsert atau event koreksi. Rute data yang melewati batas waktu ke side output untuk ditinjau atau dilakukan backfill offline.

5. Trade-off akurasi dan latensi

Allowed lateness yang lebih lama membuat tampilan event-time lebih lengkap tetapi meningkatkan ukuran state dan volume koreksi. Mengeluarkan satu hasil akhir meminimalkan latensi downstream tetapi tidak dapat merepresentasikan revisi yang terlambat. Event pembaruan yang membawa kunci jendela, revisi, dan alasan memerlukan penggabungan idempoten di downstream. Untuk metrik yang tidak toleran terhadap kehilangan seperti uang, pertahankan event mentah dan jadwalkan komputasi ulang offline; untuk papan peringkat real-time, mungkin dapat diterima untuk hanya menyegarkan pada batch berikutnya setelah batas waktu.

6. Verifikasi dan observabilitas

Hasilkan event yang berurutan, tidak berurutan, terlambat di bawah 30 detik, dan melampaui batas waktu; bandingkan setiap jendela dengan baseline offline.
Suntikkan partisi idle, lompatan jam, event duplikat, dan restart tugas; verifikasi bahwa watermark tidak terhenti atau bergerak mundur.
Catat watermark saat ini, jeda processing-time versus event-time, ukuran window-state, tingkat late-event, volume side-output, dan jumlah koreksi.
Sertakan kunci jendela, revisi, dan ID event input di setiap pembaruan; putar ulang log yang sama dan bandingkan snapshot akhir.

7. Kesalahan umum

Mengganti jendela event-time dengan jendela processing-time sambil mengklaim memiliki ketahanan terhadap ketidakteraturan jaringan.
Memperlakukan watermark sebagai penanda penyelesaian absolut; dalam praktiknya ini bisa berupa heuristik berdasarkan asumsi keterlambatan.
Mengabaikan partisi idle, membiarkan partisi yang tidak bersuara memblokir penutupan setiap jendela.
Membuang data yang terlambat tanpa side output, versi, atau jalur backfill offline.

8. Poin penilaian wawancara

Membedakan tiga konsep waktu

Kandidat harus mendefinisikan event time, ingestion time, dan processing time serta menjelaskan bagaimana pemilihan jendela mengubah akurasi dan latensi.

Menghasilkan dan menggabungkan watermark

Jawaban harus mencakup bounded out-of-orderness, watermark minimum di seluruh input paralel, dan penanganan idle, sembari mencatat bahwa watermark adalah estimasi progres dan bukan janji mutlak.

Merancang jalur late-data dan koreksi

Kandidat harus mendefinisikan batas waktu allowed-lateness, side output, revisi, dan penggabungan idempoten di downstream untuk data dalam batas waktu maupun setelah batas waktu.

Memverifikasi hasil dengan pemutaran ulang (replay)

Kandidat harus menguji ketidakteraturan, kondisi idle, restart, dan duplikasi terhadap baseline offline serta metrik langsung, alih-alih hanya memeriksa apakah job tetap berjalan.

Bagaimana Anda Menangani Event yang Terlambat dan Tidak Berurutan dalam Streaming Aggregation?

Pertanyaan