Аналитическая витрина объединяет данные из двух источников с разной задержкой. Как определить, что результат ещё неполон, а не содержит реальные нулевые значения?
Нужно использовать маркеры полноты: для каждого источника фиксировать подтверждённую границу обработанных данных, а витрину считать полной только до общего безопасного момента, достигнутого всеми источниками. Отсутствие записи само по себе нельзя трактовать как нулевое значение, пока не доказано, что соответствующий источник уже обработал этот диапазон.
Обычно такая граница представляется как high-water mark, временная граница или номер последовательности. Для объединённого результата используется минимальная подтверждённая граница по всем обязательным источникам.
В простых пакетных системах данные загружались целиком за период, поэтому окончание загрузки косвенно означало полноту результата. Потоковые и распределённые системы получают данные независимо: один источник может задержаться, повторить сообщение или временно стать недоступным.
Из-за этого появилось явное разделение между данными и метаданными о готовности данных. Метаданные позволяют отличать настоящий ноль от ещё не поступившего факта и безопасно публиковать промежуточные результаты.
Предположим, витрина считает продажи по заказам и оплатам. Заказы за час уже поступили, а события оплат отстают на двадцать минут. Если сразу выполнить соединение и заменить отсутствие оплаты на ноль, система покажет заниженную выручку.
Опасность состоит не только в неверном отчёте. Такой результат может попасть в кэш, агрегаты или downstream-системы, после чего исправление потребует пересчёта и специального оповещения потребителей.
Каждый источник должен публиковать не только записи, но и информацию о прогрессе обработки. Например, источник заказов может подтвердить обработку событий до времени 12:00, а источник оплат — только до 11:40. Тогда объединённая витрина безопасно считается полной лишь до 11:40.
Для этого применяют следующие элементы:
Временная граница удобна, но требует согласованной семантики времени. В потоках с опоздавшими событиями отметка 12:00 должна означать не просто отсутствие сообщений до этого момента, а гарантию, что источник больше не ожидает обычных событий для данного диапазона либо допускает их только как поздние корректировки.
Если источники используют разные временные зоны, часы или порядок событий, надёжнее применять монотонные позиции, журнальные номера или подтверждённые контрольные точки. При этом нужно отдельно обрабатывать исправления за уже опубликованный период: граница полноты не гарантирует неизменность данных.
Есть два основных варианта поведения витрины. Первый — задерживать публикацию до достижения общей границы; это повышает корректность, но увеличивает задержку. Второй — публиковать предварительные данные с признаком неполноты; это уменьшает задержку, но требует, чтобы потребители умели отличать предварительные значения от окончательных.
Нельзя вычислять полноту простым сравнением количества записей. Дубликаты, удаления, фильтрация и неравномерное распределение событий могут сделать одинаковые количества совместимыми с разным фактическим прогрессом. Нужна именно позиция или граница, для которой источник определяет гарантию обработки.
Платформа строит почасовую витрину эффективности рекламы из событий показов и подтверждённых конверсий. События показов поступают почти сразу, а конверсии могут приходить с задержкой из-за мобильных клиентов и офлайн-режима.
Рассматривались три варианта. Немедленная публикация с трактовкой отсутствующей конверсии как нуля давала минимальную задержку, но систематически занижала ранние показатели. Ожидание фиксированного времени, например часа, было проще, однако не учитывало аварии и переменную задержку источника. Полный пересчёт всей истории обеспечивал корректность, но был слишком дорогим.
Выбрали публикацию по общей границе полноты: витрина считалась окончательной только до момента, подтверждённого обоими потоками. Более свежий диапазон отображался как предварительный, а поздние конверсии запускали ограниченный пересчёт затронутых интервалов.
Такой подход сохранил раннюю видимость новых данных, не смешивая её с окончательными показателями. Дополнительно контролировали задержку каждой границы: если один источник переставал продвигаться, система поднимала предупреждение вместо молчаливого появления нулей.
1. Достаточно ли одной временной границы для определения полноты?
Нет. Временная граница полезна только при известной семантике: источник должен подтвердить, что диапазон обработан и обычные события за него не ожидаются. Если события могут приходить с неограниченной задержкой, абсолютную окончательную полноту определить невозможно; приходится задавать допустимое окно опоздания и принимать последующие корректировки.
2. Что делать, если один источник временно недоступен?
Нельзя автоматически продвигать общую границу по другим источникам. Витрина должна либо остановить публикацию окончательных данных, либо явно перейти в режим предварительных результатов. Выбор зависит от требований: для финансового отчёта обычно важнее корректность, а для оперативного мониторинга допустима ограниченная неполнота при заметном статусе свежести.
3. Почему общая граница не решает проблему дубликатов и исправлений?
Она описывает прогресс обработки, но не гарантирует уникальность событий и неизменность уже обработанных данных. Дубликаты требуют идемпотентной обработки или дедупликации, а исправления — механизма обновления, компенсационных событий либо пересчёта затронутого диапазона. Поэтому полнота, корректность доставки и стабильность результата являются разными свойствами, которые нужно контролировать отдельно.