Планировщик заданий
Планировщик заданий — это основа выполнения jobs в dbt, которая обеспечивает мощный и при этом простой подход к построению дата‑пайплайнов как в контексте непрерывной интеграции, так и в продакшене. Планировщик освобождает команды от необходимости разрабатывать и поддерживать собственную инфраструктуру и гарантирует своевременность и надёжность выполнения трансформаций данных.
Планировщик позволяет выполнять команды dbt в пользовательской платформе данных как на основе cron, так и по событиям. В частности, он обрабатывает:
- Запуск заданий dbt по расписанию (cron), выполняющихся с заранее заданной периодичностью
- Событийный запуск заданий dbt, выполняющихся по факту завершения другого задания (trigger on job completion)
- Событийный запуск CI‑заданий dbt, инициируемый при слиянии pull request в ветку (merge jobs)
- Событийный запуск заданий dbt, инициируемый через API
- Событийный запуск заданий dbt, вручную инициируемый пользователем с помощью Run now
Планировщик выполняет различные задачи, включая:
- постановку заданий в очередь
- создание временных окружений для выполнения dbt‑команд, необходимых для этих заданий
- предоставление логов для отладки и устранения проблем
- хранение dbt‑артефактов для прямого использования или загрузки через Discovery API
Планировщик также:
- Использует кэширование Git‑репозиториев dbt для защиты от сбоев сторонних сервисов и повышения надёжности выполнения заданий. EnterpriseEnterprise +
- Обеспечивает запуск dbt в staging‑ и production‑окружениях, упрощая и повышая надёжность CI/CD‑процессов, а также обеспечивая наблюдаемость и управление при масштабном развёртывании dbt.
- Использует Hybrid projects для загрузки артефактов dbt Core в dbt с целью централизованной видимости, межпроектных ссылок и более удобной совместной работы. BetaEnterprise +
- Использует state-aware orchestration, чтобы определять, что необходимо перестроить, на основе свежести источников, устаревания моделей и изменений кода. BetaEnterpriseEnterprise +
Термины планировщика
Ознакомьтесь с этими полезными терминами, чтобы лучше понять, как работает планировщик заданий.
| Loading table... |
Очередь планировщика
Планировщик ставит в очередь задание на развертывание для обработки, когда оно запускается по расписанию, по завершению задания, вызовом API или вручную.
Перед началом выполнения задания планировщик проверяет следующие условия, чтобы определить, может ли запуск начаться:
-
Есть ли доступный слот запуска в учетной записи? — Если все слоты запуска заняты, запланированный запуск будет ожидать. Время ожидания отображается в dbt Cloud. Если время ожидания длительное, переход на корпоративный план может предоставить больше слотов запуска и позволить более высокую параллельность заданий.
-
Есть ли на аккаунте свободный слот для запуска? — Если все слоты запуска заняты, поставленный в очередь запуск будет ожидать. Время ожидания отображается в dbt. Если время ожидания слишком большое, переход на план уровня Enterprise может предоставить больше слотов для запусков и позволить более высокую параллельность выполнения заданий.
-
Выполняется ли уже запуск этого же задания? — Планировщик выполняет отдельные запуски одного и того же задания dbt последовательно, чтобы избежать конфликтов при сборке моделей. Если задание уже выполняется, поставленный в очередь запуск будет ждать, а время ожидания будет отображаться в dbt.
Если доступен слот для запуска и нет активно выполняющегося экземпляра задания, планировщик подготовит задание к выполнению в вашей облачной платформе данных. Эта подготовка включает создание Kubernetes-пода с установленной нужной версией dbt, настройку переменных окружения, загрузку учетных данных платформы данных и авторизацию провайдера Git, а также другие задачи по подготовке окружения. Время, необходимое для подготовки задания, отображается в интерфейсе как Prep time.
Обработка CI-заданий
По сравнению с заданиями развертывания, планировщик ведет себя иначе при работе с заданиями непрерывной интеграции (CI). CI-задание ставится в очередь для обработки в момент, когда оно запускается pull request’ом в Git, и условия, которые планировщик проверяет для определения возможности начала выполнения запуска, также отличаются:
Обработка merge заданий
Когда задание запускается слиянием pull-запроса Git, планировщик ставит в очередь merge задание для обработки.
Обработка merge jobs
Когда процесс запускается объединённым pull request в Git, планировщик ставит в очередь merge job для последующей обработки.
Память задания
В dbt Cloud настройка для выделения памяти, доступной для задания, определяется на уровне учетной записи и применяется к каждому заданию, выполняемому в учетной записи; лимит памяти не может быть настроен для каждого задания отдельно. Если выполняющееся задание достигает своего лимита памяти, запуск завершается с сообщением об ошибке "memory limit error".
В dbt настройка объёма памяти, доступной для выполнения задания, задаётся на уровне аккаунта и применяется ко всем заданиям, выполняемым в этом аккаунте; настроить лимит памяти отдельно для каждого задания невозможно. Если выполняющееся задание достигает установленного лимита памяти, выполнение прерывается с сообщением об ошибке «memory limit error».
Обратитесь к архитектуре dbt Cloud для диаграммы архитектуры и чтобы узнать, как данные перемещаются.
См. архитектуру dbt, чтобы посмотреть архитектурную схему и узнать, как происходит поток данных.
Планировщик не будет отменять перепланированные задания, вызванные через API.
Планировщик dbt предотвращает переполнение очереди из‑за слишком большого количества запусков заданий, отменяя ненужные. Если выполнение задания занимает больше времени, чем заданная частота его запуска, очередь будет расти быстрее, чем планировщик успевает обрабатывать запуски. В результате формируется постоянно увеличивающаяся очередь с запусками, которые не требуется выполнять (так называемые over-scheduled jobs).
Планировщик предотвращает засорение очереди, отменяя запуски, которые не нужны, обеспечивая, чтобы в очереди было только одно выполнение задания в любой момент времени. Если в очередь поставлен новый запуск, планировщик отменяет любой ранее поставленный в очередь запуск для этого задания и отображает сообщение об ошибке.
Чтобы предотвратить перепланирование, пользователи должны предпринять действия, либо рефакторизовав задание, чтобы оно выполнялось быстрее, либо изменив его расписание.
Деактивация заданий Beta
Чтобы снизить избыточное потребление ресурсов и уменьшить конкуренцию за слоты выполнения в вашем аккаунте, dbt деактивирует deploy job или CI job, если она достигает 100 последовательных неуспешных запусков.
При деактивации задания отображается баннер со следующим сообщением:
«Задание было деактивировано из‑за повторяющихся сбоев выполнения. Чтобы повторно активировать, убедитесь, что задание настроено правильно, и запустите его вручную или повторно включите любой триггер».
После этого запланированные задания и задания, запускаемые по триггеру, больше не будут помещаться в очередь на выполнение.
Чтобы реактивировать деактивированное задание, вы можете:
- Обновить настройки задания, чтобы исправить проблему, и сохранить задание (рекомендуется)
- Выполнить ручной запуск, нажав Run now на странице задания

