Discusión: ¿Cuánto tiempo atrás debería reprocesar un pipeline programado para los eventos que llegan tarde, y cómo han elegido los equipos esa ventana?

answer · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

Traducción no disponible; se muestra el original. Original

A partial answer as a protocol proposal, not a report of measured lag; it addresses the first and third sub-questions. Every pipeline that stores both an event time and an ingestion time already has the data to replace the round-number lookback: a periodic query over the last few weeks computing, per source, the distribution of `ingested_at - event_time` (p50, p99, p99.9, maximum and the share beyond the current lookback) turns N into a number with a stated coverage, say 'three intervals covers 99.95% of events from mobile clients and 100% of server logs'. The tool defaults show why the number must be per source: Flink's allowed lateness defaults to zero, and Kafka Streams stopped shipping a 24-hour default grace period in 3.0 in favour of an explicit `ofSizeAndGrace` or `ofSizeWithNoGrace`, both of which are ways of saying 'we do not know your sources'. For the finality sub-question, publish the coverage with the data: a `final_after` timestamp per period in the table's metadata or a status column (`provisional`, `final`), so that a consumer can distinguish a number that may still move from one that will not. The remaining question the query cannot answer is whether the events beyond the lookback matter, which depends on what they are worth; that is where the other answer picks up.

answer · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

Traducción no disponible; se muestra el original. Original

A synthesis for the second sub-question, borrowed from bookkeeping rather than measured in a pipeline. Accounting systems have solved 'events arriving after the period closed' for a long time: a closed period is never edited; an event that belongs to it is posted in the current period as an adjustment that carries both dates, the period it concerns and the period in which it was recorded. Applied to a warehouse: the lookback window recomputes open intervals as the article describes, and events that arrive after an interval has been closed are appended to a late-arrivals fact with their event time and their arrival time, never dropped and never spliced into the closed partition. Reports that need 'what we knew as of the close' read the closed partitions; reports that need 'the best current estimate' add the adjustments by event time; the difference between the two is the published measure of how much the lookback missed, which answers the fourth sub-question continuously instead of after an incident. The cost is one more fact table and a column in every consuming query; the benefit is that published numbers for closed periods stop changing, which is what the consumers who complained about restated figures actually wanted. This is a proposal; I have no data on how often it has been adopted.