Маркеры завершения партиций в Flink и Kafka

Pinterest представил механизм partition finalization, который даёт downstream-потребителям явный сигнал о том, что данные за часовой интервал полностью загружены и больше не изменятся. Решение построено на связке Kafka, Flink и Iceberg и решает проблему, которая возникает при переходе от пакетной к потоковой загрузке. Без такого сигнала аналитики либо читают неполные срезы, либо вынуждены ждать фиксированное время после окончания часа. Для команд, рассматривающих миграцию, важно понимать, что маркер завершения превращает неявную гарантию пакетного процесса в явную и проверяемую точку в потоковой архитектуре.

Проблема с определением готовности партиции

В старой пакетной схеме загрузки финализация была тривиальной. Одно задание читало всю базу и записывало данные за раз, поэтому завершение джоба автоматически означало, что партиция готова. Партиция здесь — это логический срез данных, обычно по времени, например за один час. В новом фреймворке Flink пишет события непрерывно, фиксируя множество мелких батчей в одну и ту же партицию. Flink — это распределённая система обработки потоков, которая позволяет обрабатывать события с низкой задержкой. События могут приходить с задержкой, поэтому после окончания календарного часа в партицию продолжают попадать записи. Наличие данных в таблице больше не гарантирует полноту.

В результате downstream-задания, которые должны обрабатывать часовой срез ровно один раз, не имеют точки отсчёта. Downstream-задания — это процессы, которые читают уже загруженные данные и строят витрины или отчёты. Если запустить такое задание слишком рано, оно пропустит поздние обновления. Если слишком поздно — теряется оперативность. Pinterest пришлось создавать отдельный механизм, который явно отмечает момент, когда можно считать партицию закрытой. При оценке решения стоит учитывать, что без маркера команды вынуждены либо вводить искусственные задержки, либо рисковать неполнотой данных, что напрямую влияет на SLA отчётности.

Как генерируются и хранятся маркеры

Flink-задание после коммита всех событий за час формирует специальный маркер завершения. Маркер можно записывать либо в отдельный Kafka-топик, либо как служебный файл внутри Iceberg-таблицы. Kafka — это платформа для передачи событий между системами, а Iceberg — табличный формат, позволяющий работать с большими аналитическими данными в объектных хранилищах. Первый вариант удобнее для быстрого оповещения множества потребителей, второй — когда нужно хранить сигнал вместе с данными и не заводить дополнительные топики.

Потребитель перед запуском запроса проверяет наличие маркера. Если маркера нет, партиция считается незавершённой и запрос пропускается. Такой подход позволяет избежать как чтения неполных данных, и жёстких временных задержек. Механизм унифицирован и работает одинаково для тысяч пайплайнов, независимо от источника изменений. При принятии решения о внедрении важно оценить, сколько downstream-систем будут полагаться на маркер: чем их больше, тем выше ценность централизованного сигнала по сравнению с ручными проверками или фиксированными окнами ожидания.

Ограничения и риски при внедрении

Маркер генерируется после того, как Flink зафиксировал все известные на момент обработки события. Если источник продолжает присылать изменения с большой задержкой, маркер может появиться позже, чем ожидают потребители. Кроме того, при сбоях в Kafka или Flink маркер может не записаться, и партиция останется «открытой» даже после того, как данные фактически перестали приходить.

В собственном контуре нужно предусмотреть мониторинг появления маркеров и механизм повторной генерации при сбоях. Также важно определить, как долго хранить маркеры и что делать с партициями, для которых сигнал так и не появился. Без этих правил система будет либо блокировать downstream-задания, либо пропускать неполные данные. Для решения «брать или не брать» критично наличие команды, способной поддерживать дополнительный мониторинг и правила обработки исключений; в противном случае маркеры могут добавить операционной нагрузки вместо того, чтобы её снизить.

Как это ложится на типичные российские пайплайны

В российских командах, мигрирующих с пакетных ETL на Flink и Kafka, та же проблема возникает сразу после первого запуска потоковой загрузки в Iceberg. Без явного сигнала аналитики либо ждут 2-3 часа «на всякий случай», либо рискуют получить неполные витрины. Внедрение маркеров позволяет сохранить потоковую природу загрузки и при этом дать чёткую точку готовности для batch-потребителей.

При этом важно учитывать, что в локальных установках часто отсутствует managed Kafka с гарантированной доставкой, а Iceberg-таблицы размещаются в S3-совместимых хранилищах с разной задержкой записи метаданных. Поэтому надёжнее хранить маркеры в отдельном топике и добавить проверку их возраста перед запуском потребителя. Это снижает зависимость от файловой системы и упрощает отладку при задержках. Командам стоит взвесить, готовы ли они инвестировать в отдельный топик и возрастные проверки, или текущий уровень зрелости инфраструктуры позволяет обойтись без маркеров за счёт более консервативных задержек.

Источник

Это краткий разбор материала Pinterest. Полная версия с примерами кода, схемами и деталями реализации — в оригинале: Маркеры завершения партиций в Flink и Kafka.

Курс по теме — Каталог курсов Школы Больших Данных