Watermark: khi nào hệ thống được phép chốt sổ một khoảng thời gian

Đặt vấn đề

Giả sử mình có dashboard tính doanh thu mỗi 5 phút:

10:00 - 10:05: bao nhiêu tiền?
10:05 - 10:10: bao nhiêu tiền?
10:10 - 10:15: bao nhiêu tiền?

Nghe đơn giản: đơn hàng nào xảy ra trong khoảng nào thì cộng vào khoảng đó.

Nhưng thực tế event không luôn tới đúng thứ tự. Mobile app có thể offline rồi sync lại, CDC có thể lag, broker có thể retry, producer có thể flush muộn.

Ví dụ:

Event C xảy ra lúc 10

Câu hỏi là:

Tới 10

, hệ thống có nên chốt kết quả window 10:00-10:05 chưa?

Hai khái niệm cần phân biệt trước

Trong streaming, mình cần tách hai loại thời gian:

Ví dụ đơn hàng C:

event time      = 10:02  # khách thật sự đặt hàng lúc này
ingestion time  = 10:07  # hệ thống mới nhận được lúc này

Nếu dùng processing/ingestion time, dashboard ra nhanh hơn nhưng có thể sai business meaning. Nếu dùng event time, kết quả đúng nghĩa hơn nhưng hệ thống phải đối mặt với event tới muộn.

Vì sao cách đơn giản không đủ

Cách 1: tính theo lúc hệ thống nhận event.

Event tới lúc 10:07 thì tính vào khoảng 10:05-10:10

Nhanh, dễ, nhưng sai. Vì event C thật ra xảy ra lúc 10

Cách 2: tính theo lúc event thật sự xảy ra.

Event C xảy ra lúc 10:02 nên tính vào window 10:00-10:05

Đúng hơn, nhưng phát sinh câu hỏi khó:

Nếu event có thể tới muộn, hệ thống phải đợi tới bao giờ mới dám chốt window 10:00-10:05?

Nếu đợi mãi, dashboard không bao giờ có kết quả cuối. Nếu chốt quá sớm, event muộn sẽ bị bỏ lỡ hoặc phải sửa kết quả.

Watermark là gì?

Watermark là một mốc event time mà hệ thống dùng để nói:

“Tớ nghĩ dữ liệu cũ hơn mốc này đã tới gần hết rồi, nên có thể chốt các window cũ hơn mốc này.”

Watermark không có nghĩa là chắc chắn 100% không còn event cũ nữa. Nó là một giả định có kiểm soát để đổi giữa latency và độ đầy đủ của dữ liệu.

Ví dụ hệ thống cho phép event trễ tối đa khoảng 2 phút:

event time mới nhất đã thấy = 10:08
allowed lateness            = 2 phút
watermark                   = 10:06

Nghĩa là:

Tớ đã thấy event mới tới 10:08.
Nếu thường event chỉ trễ khoảng 2 phút,
thì data có event time <= 10:06 chắc đã tới gần hết.

Window nào kết thúc trước hoặc bằng watermark thì hệ thống có thể chốt.

Watermark không hẳn là “khoảng trễ tối đa”

Một chỗ dễ nhầm:

allowed lateness = 2 phút
watermark        = 10:06

2 phút là khoảng trễ mình giả định/chấp nhận. 10:06 mới là watermark hiện tại.

Nói chính xác hơn:

Watermark là mốc event-time.
Allowed lateness / max out-of-orderness là cách thường dùng để tính watermark.

Vậy câu “watermark là khoảng thời gian tối đa giữa event time và ingestion time” là gần đúng ở mức intuition, nhưng nên sửa thành:

Watermark thường được tính từ giả định về độ trễ tối đa giữa event time và ingestion/processing time.

Ví dụ mini

Window cần tính:

10:00 - 10:05

Events:

Giả sử allowed lateness là 2 phút.

Khi D tới, hệ thống thấy event time mới nhất là 10:08:

watermark = 10:08 - 2 phút = 10:06

Window 10:00-10:05 kết thúc trước 10:06, nên hệ thống có thể chốt.

Nếu event C tới trước khi watermark vượt qua mốc kết thúc window, nó vẫn có thể được tính đúng vào window 10:00-10:05. Nếu C tới quá muộn, sau khi watermark đã đi xa, nó được xem là late event.

Late event bị xử lý thế nào?

Event đến sau watermark được xem là late event. Nhưng late event không bắt buộc lúc nào cũng bị drop. Nó phụ thuộc policy của pipeline.

Vậy nói chuẩn hơn:

Watermark xác định ranh giới để xem event là late.
Late event bị bỏ, sửa kết quả, hay xử lý bù là policy riêng.

Batch cũng có cùng bài toán

Bài toán này không chỉ có trong streaming. Batch cũng có phiên bản tương tự, chỉ khác là nó không chạy liên tục từng event.

Ví dụ batch daily:

Report ngày 2026-06-27 chạy lúc 01:00 ngày 2026-06-28

Nhưng source gửi muộn:

payment event của 2026-06-27 tới lúc 03:00
refund event tới ngày hôm sau
CDC lag 2 tiếng
mobile offline sync muộn

Batch cũng phải hỏi:

Dữ liệu của ngày D đã đủ tin cậy để close partition/report chưa?

Nói cách khác:

Streaming watermark = continuous version của data completeness cutoff.
Batch cutoff time   = discrete/manual version của watermark.

Pitfall / Trade-off

Watermark là trade-off giữa latency, completeness và state cost.

Nếu watermark tiến quá nhanh:

allowed lateness thấp
=> dashboard ra nhanh
=> state giữ ngắn hơn
=> nhưng dễ bỏ sót event tới muộn

Nếu watermark tiến quá chậm:

allowed lateness cao
=> bắt được nhiều event muộn hơn
=> dashboard chậm
=> state/window phải giữ lâu hơn
=> tốn memory/storage hơn

Nói gọn:

watermark không làm dữ liệu hết muộn
watermark chỉ định nghĩa hệ thống chấp nhận đợi muộn tới mức nào

My Summary

Watermark là mốc event-time dùng để quyết định:

“Tới đây thì đủ tự tin để chốt kết quả cho các window cũ hơn.”

Nó thường được tính từ giả định về độ trễ tối đa giữa event time và ingestion/processing time, nhưng bản thân watermark là mốc thời gian, không phải duration.

Điểm mình thấy quan trọng nhất: watermark không phải khái niệm riêng của Flink API. Nó là cách streaming diễn đạt một bài toán rộng hơn của data platform:

Khi nào mình dám nói dữ liệu của một khoảng thời gian đã đủ đầy để publish kết quả?

Batch cũng phải đối mặt với câu hỏi này qua cutoff time, close partition, late-arriving data, rerun/backfill và correction table.