Spark
Средний уровеньКак выбрать правильный интервал триггера и размер микропакета в Structured Streaming?
Structured Streaming по умолчанию не непрерывен — это микропакеты по таймеру. Выбранный интервал обменивает задержку на фиксированные накладные расходы на пакет, и этот обмен может пойти не в ту сторону.
Кажется, что более короткий интервал триггера всегда означает меньшую задержку. После определённой точки это значит лишь больше пакетов, потраченных на учёт, а не на данные.
Что на самом деле контролирует интервал триггера
Trigger.ProcessingTime группирует все новые данные, пришедшие в это окно, в один микропакет, а затем планирует, выполняет, коммитит и чекпойнтит его как единое целое. Более короткий интервал означает меньшую сквозную задержку на запись, но у каждого из этих шагов — планирования, коммита, чекпойнта — примерно фиксированная стоимость независимо от того, сколько данных реально в пакете.
Почему уменьшение интервала может ухудшить пропускную способность
Если этот фиксированный оверхед на пакет близок к самому интервалу, задача тратит больше реального времени на учёт пакетов, чем на фактическую обработку. Это выглядит как пакеты, которые «завершаются» почти мгновенно в Spark UI, пока за ними растёт очередь входных данных — пайплайн выглядит здоровым по каждому пакету отдельно, но в целом отстаёт.
Trigger.AvailableNow для ограниченных бэкфиллов
Разовый бэкфилл или догоняющий запуск — это не постоянная стриминговая задача, и для него вообще не стоит использовать обычный триггер по интервалу — Trigger.AvailableNow обрабатывает именно то, что сейчас доступно, пакетами, а затем сам останавливается. Использование не того типа триггера здесь — частая причина, по которой «бэкфилл» на самом деле никогда не завершается.
Посмотрите, как это выглядит на вашем собственном пайплайне.
Загрузите реальный event log Spark, run_results.json от dbt или экспорт метрик Flink — и получите конкретные рекомендации, которые нужно одобрить, а не ещё одно эмпирическое правило.