Un informe de pedidos se actualiza al terminar el día. A la mañana siguiente llega una operación que ocurrió antes del cierre, pero que el sistema de origen no había enviado. Si la asignas al día de recepción, cambias el significado de la métrica; si la ignoras, el informe queda incompleto.
Los datos tardíos requieren una política de cierre y corrección. El pipeline necesita saber a qué periodo pertenece el hecho y el consumidor necesita saber qué versión del resultado está consultando.
Conserva las fechas que explican la llegada
Distingue al menos la fecha del evento de negocio y la de recepción. Cuando sea relevante, conserva también la de modificación del origen y la de procesamiento. Ninguna sustituye automáticamente a las otras.
Documenta la zona horaria y el límite del periodo. Un evento almacenado en UTC puede pertenecer a un día comercial diferente después de convertirlo a la zona acordada. Evita repartir esa conversión entre varias consultas con reglas distintas.
La llegada tardía tampoco equivale siempre a una corrección. Puede tratarse de un evento nuevo que no había llegado, una versión modificada de un evento conocido o una repetición de transporte. Cada caso debe conservar su identidad.
Un cierre con una operación pendiente
Considera este ejemplo ficticio. El informe mide el importe de pedidos aceptados por fecha de aceptación, en una unidad monetaria común.
| Operación | Fecha del hecho | Fecha de recepción | Importe |
|---|---|---|---|
| P-01 | 10 de marzo | 10 de marzo | 120 |
| P-02 | 10 de marzo | 10 de marzo | 80 |
| P-03 | 10 de marzo | 11 de marzo | 50 |
Al cerrar la primera carga, el total conocido del 10 de marzo es 200. Tras recibir P-03, el total de ese mismo día es 250. El incremento de 50 corresponde a una nueva operación recibida tarde; no representa actividad comercial del 11 de marzo.
Si P-03 vuelve a llegar con la misma identidad y versión, el total debe seguir siendo 250. Si una corrección válida cambia su importe de 50 a 40, la nueva versión del total será 240. Sumar las cuatro entregas como hechos independientes perdería el significado del informe.
Acuerda qué significa provisional y qué significa cerrado
Una publicación provisional indica que el periodo puede recibir datos adicionales. El usuario necesita ver el corte de información y la regla de revisión, no solo una etiqueta genérica de ‘actualizado’.
Un cierre operativo puede limitar las modificaciones ordinarias y enviar los casos posteriores a un procedimiento de corrección. Eso no hace desaparecer el dato. Define quién decide reabrir, publicar un ajuste o mantener una versión congelada para un uso concreto.
Cuando coexistan una vista actual y otra de cierre, deben poder distinguirse. La misma etiqueta de fecha con cifras diferentes, sin versión ni propósito, genera una discrepancia que parece un error técnico.
Una watermark no sustituye el acuerdo de negocio
En procesamiento por eventos, una watermark representa el avance temporal que el sistema utiliza para estimar qué datos deberían haber llegado. No es una prueba universal de que no exista ninguna operación pendiente en todos los sistemas externos.
La guía de Apache Beam sobre watermarks y datos tardíos explica su relación con ventanas y la admisión de elementos tardíos. La política técnica de una ventana debe alinearse con el tratamiento que necesita el consumidor.
Configurar más tolerancia puede permitir nuevas actualizaciones, pero también prolonga el estado que mantiene el sistema. Configurar menos exige una vía explícita para los datos que quedan fuera. No elijas el límite solo para que el gráfico deje de cambiar.
Publica correcciones con una identidad estable
Conserva la clave del evento y la versión que gana según el contrato del origen. La idempotencia del pipeline evita que un reintento convierta una llegada tardía en un duplicado.
La actualización del agregado debe reflejar el cambio del hecho. Según el sistema, puede recalcularse la partición afectada o aplicarse una diferencia controlada. En ambos casos, prueba la recuperación si el proceso falla entre escribir el detalle y publicar el total.
Si necesitas rehacer un periodo amplio, utiliza un backfill con validación y conserva las versiones que expliquen el antes y el después. Recalcular el histórico sin registrar qué regla cambió dificulta reconciliarlo con informes ya distribuidos.
Prueba la política con entregas desordenadas
Reproduce las operaciones del ejemplo en orden normal, con retraso, repetidas y con una corrección posterior. Comprueba el detalle, el total por periodo y la versión visible. Añade una operación fuera del plazo de admisión y verifica que queda localizable en el flujo acordado.
Para diseñar esta política en una plataforma de ingeniería de datos, lleva a Nexeus Big Data ejemplos de retrasos reales y los informes que necesitan cerrar. El punto de partida es acordar qué debe ocurrir con cada llegada; después se configura el pipeline para cumplirlo.