Планировщик задач в ODI: как это устроено у нас

В сфере искусственного интеллекта произошло заметное событие. RAQWKA 6 минут назад Планировщик задач в ODI: как это устроено у нас Уровень сложности Средний Время на прочтение 4 мин Охват и читатели 67 Блог компании МегаФон Oracle * Обзор В любой промышленной системе обработки данных есть пласт регулярной работы, которую нужно просто запускать раз в день или раз в час и не думать о ней: ночные ETL-загрузки, пересчёт витрин, выгрузки в смежные системы, всякая техническая обвязка вроде чистки служебных таблиц. Всё это должно где-то стартовать по расписанию, уметь учитывать зависимости между потоками и принимать во внимание тот факт, что задачи у нас разнородные. Ниже — рассказ про то, как устроен наш планировщик на Oracle Data Integrator и PL/SQL: из чего он собран, как задачи попадают в очередь, как они распределяются по серверам, и как мы закрываем сценарий с зависаниями.

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

Технические детали

Зафиксировать, чем всё закончилось, и пересчитать, когда её запускать в следующий раз. Сложность возникает из-за разнородности. В одном контуре крутятся и сценарии ODI, и процедуры PL/SQL внутри базы, и shell-скрипты на нескольких серверах приложений.

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

Чтобы они реально что-то делали, нужен отдельный исполняющий процесс, агент. Технически агент — это java-процесс на сервере приложений: он принимает запросы на выполнение, ходит в репозиторий и ведёт сценарий от старта до финиша. Агентов может быть несколько, и это важно.

Отраслевые последствия

Во-первых, так удобно разносить нагрузку — тяжёлый ETL не толкается с лёгкими задачами за ресурсы одной JVM. Во-вторых, часть задач намертво прибита к конкретному серверу: всё, что работает с локальной файловой системой, должно запускаться именно там, где эти файлы лежат. В-третьих, если один агент лёг, остальные продолжают обслуживать свои задачи.

И, как приятный бонус, разных агентов можно выделять под разные подразделения или среды, с собственными правами доступа к источникам. Под сам планировщик мы держим выделенных агентов, на которых ручных запусков не происходит в принципе. Так поведение регламента становится предсказуемым: если ночная загрузка вдруг затянулась, это точно не потому, что кто-то из аналитиков с утра запустил поверх неё тяжёлый сценарий.

Цикл опроса Сердце планировщика — пакет ODI, который дёргается раз в несколько минут и вызывает PL/SQL-процедуру выборки задач, готовых к запуску. Интервал — это компромисс: опрашивать чаще значит точнее попадать в расписание, но и чаще нагружать базу.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.