Как событие попадает в отчёт позже своего времени, почему пересчитывается прошлый период и о каких правилах ожидания стоит договориться.
Отчёт закрыт, а число изменилось
Вчера вечером в условном отчёте было 240 покупок. Сегодня утром он показывает 243. Это не обязательно ошибка и не обязательно повторная запись. Три покупки могли произойти вчера, но попасть в систему только утром: например, касса передала накопленные события после восстановления связи. Для отчёта важна дата самой покупки, а для обработки — момент, когда запись стала доступной.
В терминологии потоковой обработки это два разных времени. Словарь Apache Beam различает время события и время обработки и отдельно предупреждает, что события не обязаны приходить в том порядке, в каком произошли. Поэтому вчерашний показатель может быть предварительным.
Два времени на одном примере
Представим заказ, оформленный в 23:55 в пятницу. Мобильное приложение сохранило его локально и передало в центральную систему в 00:10 в субботу. По времени события заказ относится к пятнице. По времени получения система впервые увидела его в субботу. Если отчёт группирует заказы по времени события, пятничный итог вырастет после полуночи. Если группирует по времени получения, заказ окажется в субботнем итоге.
Ни один выбор не универсален. Для финансового анализа обычно важен смысл события, для мониторинга задержки передачи — момент поступления. В отчёте полезно прямо указать, какая дата используется и когда данные считаются достаточно полными.
Как обновляют прошлый период
Система может некоторое время ждать поздние записи и пересчитывать показатель за уже показанный период. В Apache Beam для этого есть понятие допустимого опоздания: руководство объясняет, как поздние элементы могут вызвать обновлённый результат. Это не магическое исправление всех задержек, а выбранное правило обработки.
Условно команда решила принимать вчерашние события ещё два дня. Пока это окно открыто, итог может меняться. После его закрытия слишком поздняя запись требует отдельного решения: отбросить её из оперативного показателя, отправить на разбор или исправить исторический отчёт особой процедурой. Последний вариант зависит от требований бизнеса и организации хранения.
Чем приходится платить за ожидание
Чем дольше система ждёт, тем больше шансов учесть задержавшееся событие. Но окончательный результат появляется позднее, а хранить сведения для возможного пересчёта приходится дольше. Слишком короткое ожидание даёт быстрый, но иногда неполный итог. Слишком длинное делает отчёт неудобным для решений, которым нужна зафиксированная цифра.
Время события не следует путать со сменой часового пояса: там одна и та же отметка времени отображается в разных локальных датах. И это не то же самое, что повторная доставка одного события. Эти причины похожи по внешнему признаку — число изменилось, — но проверяются по-разному.
Что уточнить у команды данных
Спросите, какой момент определяет принадлежность записи дню, сколько времени период остаётся предварительным, какие источники чаще задерживаются и что происходит с событием после закрытия окна ожидания. В интерфейсе отчёта полезно показывать время последнего обновления и отметку о предварительности цифр. Тогда изменение вчерашнего числа не выглядит необъяснимой поломкой.
Если дата «переехала» ровно на день при показе, сначала проверьте объяснение часовых поясов. Если число увеличилось из-за двух одинаковых записей, поможет разбор повторной доставки.
По теме
Что изучить дальше
Если хочется разобраться в том, как применять эти идеи на практике, посмотрите курс Data Engineer для начинающих. Сопоставьте программу со своими задачами: один материал объясняет принцип, но не заменяет работу с реальными данными.
