Windowing và late events: chờ bao lâu trước khi chốt một cửa sổ?

Bối cảnh Fortex là hư cấu. Biểu đồ trong bài được sinh từ report của lab cô lập và có nhãn rõ. Nó không phải dashboard production hay benchmark Kafka Streams.

Con số 30 hay 35 đều có thể “đúng”

Hà hỏi doanh thu từ giây 0 đến giây 10. Dashboard của Ben trả 30. Một phút sau, nó đổi thành 35. Báo cáo cuối ngày lại đúng, nhưng cảnh báo realtime đã bỏ lỡ ngưỡng.

Một order có event time 4 giây đến sau record ở 8 giây. Nó thuộc cửa sổ cũ, dù consumer vừa nhìn thấy nó muộn hơn. Ben muốn giữ cửa sổ mãi để không mất gì.

Tom hỏi nhẹ: “Nếu một thiết bị gửi lại dữ liệu sau ba tháng thì dashboard hôm nay còn được phép đổi không?”

Windowing luôn là quyết định giữa độ hoàn chỉnh, độ trễ và lượng state.

Tumbling window chia thời gian thế nào?

Với kích thước cửa sổ Δ, event time t thuộc cửa sổ bắt đầu tại:

$$windowStart(t)=\left\lfloor\frac{t}{\Delta}\right\rfloor\Delta$$

Cửa sổ thường có biên dưới inclusive và biên trên exclusive: [start, start + Δ). Vì vậy event đúng 10 giây thuộc [10,20), không thuộc [0,10).

Kafka Streams DSL mô tả time windows, grace period và retention. Grace là khoảng chấp nhận event đến sau khi stream time đã vượt cuối cửa sổ; retention phải đủ lớn để state còn tồn tại trong thời gian ấy.

Watermark là lời tuyên bố, không phải sự thật tuyệt đối

Trong lab nhỏ này, consumer dùng:

$$watermark=\max(eventTimeSeen)-grace$$

Record có event time nhỏ hơn watermark bị xem là quá muộn. Hệ thống thực tế có thể tính watermark theo partition, mức idle, nguồn dữ liệu và framework. Nếu lấy max toàn cục thiếu cẩn thận, một partition chạy nhanh có thể đóng cửa sổ của partition chậm.

Watermark nói: “Tôi tin rằng phần lớn dữ liệu trước mốc này đã đến, và chấp nhận chính sách cho phần còn lại.” Nó không chứng minh không còn event cũ ngoài mạng.

Lab: năm record và hai chính sách

Lab đưa năm record qua Kafka theo arrival order a, b, c, d, e:

Record	Event time	Value	Ý nghĩa
a	2s	10	đúng giờ
b	8s	20	đúng giờ
c	4s	5	đến muộn nhưng trong grace
d	16s	30	đẩy watermark tiến lên
e	6s	7	đến sau watermark

Với grace bằng 0, c và e đều muộn; tổng [0,10) là 30. Với grace 5 giây, c được nhận nên tổng thành 35; sau khi thấy event 16 giây, watermark là 11 giây và e ở 6 giây bị tách thành too-late record.

• Report JSON
• Raw log
• Docker Lab source
• Run ID: ca5ef117-03d9-4238-b780-fef8583d7364

Consumer trong lab tự cài semantics một cách xác định trên record thật đi qua Kafka. Nó không dùng Kafka Streams state store hay RocksDB, vì vậy report không được dùng để kết luận throughput hoặc memory của Kafka Streams.

Event quá muộn đi đâu?

“Drop” không nên đồng nghĩa với biến mất im lặng. Tùy nghiệp vụ, record có thể:

• đi vào side output để audit và replay;
• cập nhật bảng correction riêng;
• phát một revision cho downstream;
• chỉ ảnh hưởng báo cáo cuối ngày, không sửa dashboard realtime;
• kích hoạt reconciliation nếu giá trị lớn.

Dashboard cần nói rõ con số là preliminary hay final. Nếu downstream đã gửi invoice, việc update aggregation cũ có thể cần một compensating event thay vì sửa row âm thầm.

Chọn grace bằng gì?

Đừng chọn vì “5 phút nghe hợp lý”. Hãy đo phân phối lateness:

$$lateness=processingTime-eventTime$$

Rồi tách theo source, partition, network và loại thiết bị. Grace lớn hơn tăng completeness nhưng giữ state lâu hơn, tăng disk, changelog traffic và thời gian kết quả còn thay đổi. Grace nhỏ cho kết quả nhanh và ổn định sớm, đổi lại nhiều correction hơn.

Một production checklist:

• p50/p95/p99 lateness và tail cực đoan là bao nhiêu?
• partition idle có làm watermark đứng hoặc nhảy không?
• retention có lớn hơn window size cộng grace không?
• late record được đếm, lưu và replay ở đâu?
• downstream có chấp nhận update/retraction không?
• dashboard đánh dấu preliminary/final thế nào?

Không phải mọi bài toán đều cần event-time window

Rate limit thường quan tâm processing time tại gateway. Billing và fraud analytics thường cần event time cùng correction. Một số SLA chỉ cần ingestion time vì lời hứa bắt đầu khi hệ thống nhận request. Chọn clock theo câu hỏi nghiệp vụ, không theo framework có sẵn operator nào.

Ben giữ grace 5 giây cho dashboard realtime của bài lab và route record quá hạn sang luồng correction. Quan trọng hơn, cậu thêm nhãn “provisional” cho cửa sổ chưa đóng.

Hà nhìn con số 35 rồi hỏi: “Bao giờ nó không đổi nữa?”

Lần này Ben không trả lời bằng cảm giác. Cậu chỉ vào watermark, grace và chính sách correction. Tom không nói gì; anh biết Ben vừa đi qua một bước quan trọng: từ viết operator sang định nghĩa ý nghĩa của kết quả.