Эксплуатационные аспекты работы с данными в режиме, близком к реальному времени

Команды, которые запускают задания dbt с очень высокой частотой, обычно сталкиваются с одним и тем же набором сложностей — как на уровне планировщика dbt, так и в самом хранилище данных.

Рассматривайте режим, близкий к реальному времени, как услугу премиум-класса

Соглашения об уровне обслуживания (SLA), предусматривающие режим, близкий к реальному времени, требуют дополнительных ресурсов и существенно увеличивают эксплуатационную нагрузку. Прежде чем брать на себя такие обязательства, тщательно проверьте, действительно ли бизнесу нужна актуальность данных с точностью до минуты.

Слишком частое расписание заданий и управление очередью

Если продолжительность выполнения задания превышает интервал между запусками по расписанию, задание оказывается запланировано слишком часто. Очередь растет быстрее, чем планировщик успевает обрабатывать запуски, и dbt platform начинает отменять запуски в очереди, чтобы избежать бесконечного накопления невыполненных запусков.

С этим легко столкнуться при работе в режиме, близком к реальному времени, если время инкрементальной сборки постепенно увеличивается (больше моделей, тестов, данных), а расписание cron остается столь же частым (например, каждые 2–5 минут).

Пример сценария:

• Задание настроено на запуск каждые 5 минут.
• Обычно выполнение задания занимает 6–7 минут.
• Новые запуски встают в очередь, пока предыдущие еще выполняются.
• dbt platform начинает отменять запуски в очереди, чтобы предотвратить бесконечное накопление невыполненных запусков.

Устранить такую ситуацию непросто. Необходимо либо переработать задание, чтобы оно выполнялось быстрее (сократить набор выбираемых моделей, настроить количество потоков, оптимизировать SQL), либо увеличить интервал между запусками и согласиться на менее строгие требования SLA к актуальности данных.

Связанные ограничения планировщика

• Слоты выполнения ограничивают количество заданий, которые могут выполняться одновременно. Частые задания для режима, близкого к реальному времени, могут лишить другие задания развертывания возможности запускаться, если использование слотов не спланировано.
• Планировщик выполняет отдельные запуски одного и того же задания последовательно. Если предыдущий запуск еще выполняется, когда наступает время следующего запуска по cron, второй запуск должен ждать (либо будет отменен, если задание запланировано слишком часто).

Стоимость и загрузка хранилища данных

По мере сокращения разницы между временем выполнения задания и интервалом между запусками хранилище фактически начинает работать непрерывно, чтобы успевать выполнять преобразования одно за другим.

Пример роста затрат:

• Ежедневное задание: хранилище работает 30 мин/день = ~2% загрузки
• Ежечасное задание: хранилище работает 30 мин × 24 = 12 часов/день = 50% загрузки
• Задание каждые 5 минут: хранилище работает почти круглосуточно = ~100% загрузки

На таких платформах, как Snowflake, способы загрузки больших потоков данных в реальном времени, например Snowpipe, могут быть очень дорогими (плата за каждую 1 000 файлов плюс вычислительные ресурсы).

Затраты на механизмы поддержания актуальности, управляемые самим хранилищем (например, динамические таблицы и материализованные представления), также бывает сложнее прогнозировать и отслеживать, особенно если исходные данные часто меняются.

Итог: следует рассматривать SLA для режима, близкого к реальному времени, как услугу премиум-класса и тщательно проверять, действительно ли бизнесу нужна актуальность с точностью до минуты для каждой рабочей нагрузки.

Сложность DAG и корректность лямбда-представлений

Если вы используете подход с лямбда-представлениями, возникают дополнительные сложности:

• Дублирование логики: нужно либо централизовать SQL в макросах (меньше повторений благодаря принципу DRY, но ниже читаемость), либо дублировать одни и те же преобразования в потоке исторических данных (HIST) и потоке данных, близком к реальному времени (NRT) (выше читаемость, но больше кода для сопровождения).
• Сложные DAG: у каждой «продуктовой» модели теперь есть как минимум три артефакта (таблица HIST, представление NRT, объединение lambda), а также вспомогательные вышестоящие слои.
• Хрупкость материализаций: этот подход зависит от конкретных материализаций (представления или инкрементальные модели). На первый взгляд безобидное изменение материализации может нарушить актуальность или корректность данных.

Кроме того, опыт сообщества выявил временные рассогласования между потоками HIST и NRT:

• Представления (NRT) часто обновляются гораздо быстрее инкрементальных таблиц. Во время выполнения задания часть NRT может начать фильтрацию по новому значению max(event_ts) до завершения загрузки инкрементальной таблицы, создавая временные пробелы в объединенном лямбда-представлении, из-за которых свежие данные ненадолго исчезают.
• Один из способов снизить риск — добавить явную зависимость NRT от инкрементальной модели (например, вручную указать зависимость в комментарии с {{ ref('fct_events') }}), но это решение довольно хрупкое и усиливает связанность.

Надежность заданий и ограничения ресурсов

При высокой частоте запусков чаще проявляются сбои на уровне заданий:

• Ограничения памяти

  • Макросы, потребляющие много памяти (например, с большими результатами run_query()), или объемные этапы генерации документации могут привести к достижению ограничений памяти на уровне учетной записи.
  • В результате запуски завершаются с ошибками "memory limit".

• Автоматическая деактивация

  • Задание, которое постоянно завершается с ошибкой, может быть автоматически деактивировано после 100 последовательных сбоев.
  • В этом случае запуски по расписанию прекращаются до ручного вмешательства.

• Меньший запас на случай ошибок

  • Нестабильная модель, тест или небольшая регрессия могут быстро привести к большому количеству неудачных запусков.
  • Это создает поток избыточных оповещений и может ускорить достижение порога автоматической деактивации.

Зависимости от архитектуры загрузки данных

Лямбда-представления и задания dbt для NRT работают поверх вашей архитектуры загрузки данных:

• В чем состоит зависимость

  • Если задержка загрузки увеличивается или пропускная способность снижается (проблемы в конвейере задач и потоков, накопление необработанных данных в хранилище, периодические задержки Snowpipe), лямбда-представление может объединять только уже поступившие данные.
  • Невозможно сделать данные актуальнее, чем позволяет слой загрузки.

• Что в итоге приходится настраивать

  • Периодичность задач и стратегии партиционирования в зоне первичной загрузки
  • Окна перекрытия lambda и периоды повторной обработки прошлых данных при инкрементальной загрузке
  • Набор источников, которые действительно должны участвовать в обработке NRT

Заключение

Именно из-за этих сложностей мы рассматриваем лямбда-представления и сверхчастые запуски dbt как подходы для особых случаев. Они эффективны, когда действительно необходимы, но требуют продуманного проектирования с учетом поведения планировщика, затрат, структуры DAG и архитектуры загрузки данных. Во многих случаях их лучше заменить динамическими таблицами, материализованными представлениями или специализированным стеком потоковой обработки.

Нашли ошибку?

Создать GitHub Issue