В любой промышленной системе обработки данных есть пласт регулярной работы, которую нужно просто запускать раз в день или раз в час и не думать о ней: ночные ETL-загрузки, пересчёт витрин, выгрузки в смежные системы, всякая техническая обвязка вроде чистки служебных таблиц. Всё это должно где-то стартовать по расписанию, уметь учитывать зависимости между потоками и принимать во внимание тот факт, что задачи у нас разнородные. Ниже — рассказ про то, как устроен наш планировщик на Oracle Data Integrator и PL/SQL: из чего он собран, как задачи попадают в очередь, как они распределяются по серверам, и как мы закрываем сценарий с зависаниями.

Что от планировщика требуется

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

Агенты ODI — пара слов, без которых дальше не разобраться

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

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

Цикл опроса

Сердце планировщика — пакет ODI, который дёргается раз в несколько минут и вызывает PL/SQL-процедуру выборки задач, готовых к запуску. Интервал — это компромисс: опрашивать чаще значит точнее попадать в расписание, но и чаще нагружать базу. Чтобы задача попала в очередь на запуск, должны сойтись несколько условий: • отработали все её родители по графу зависимостей; • текущее системное время доросло до планового времени следующего запуска; • не исчерпан лимит повторных запусков. Последний пункт как раз про то, чтобы не долбиться в закрытую дверь. Если есть реальная проблема — кривые данные, баг в коде, что-то не перенеслось с теста — задача после нескольких попыток остановится и будет ждать, пока с ней разберутся руками. А если причина разовая (условно, умер агент, на котором она запускалась, или отвалился сетевой маунт), перезапуск отработает штатно, и регламент поедет дальше сам, без звонка дежурному в три часа ночи. На выходе этого шага у нас есть список task_id — задач, которые действительно можно запускать прямо сейчас.

Диспетчеризация и пакеты запуска

Список уезжает в следующий PL/SQL-пакет — диспетчер. Для каждого task_id он разбирается, что это за задача (сценарий ODI, пакет PL/SQL или shell-скрипт), с какими параметрами её запускать — даты, идентификаторы объектов, пути к файлам — и, главное, на каком агенте. Целевой агент закреплен за задачей в её настройках ещё на этапе регистрации в планировщике. Сам запуск идёт не напрямую из диспетчера, а через пакеты-обёртки — по одной под каждый тип задач. Обёртка знает, как дёрнуть нужного агента, параллельно пишет в журнал выполнения, обновляет статусы в служебных таблицах и пересчитывает следующую дату запуска. Главное, ради чего эти обёртки вообще появились — возможность явно указать, на каком агенте задача пойдёт.

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

Killer — про зависшие задачи

Рано или поздно на проде случается ситуация, когда задача формально «выполняется», но фактически стоит: блокировка в базе, недоступный источник, сетевой сбой, пропавший ответ от внешнего сервиса. Статус висит в running, сессия вроде бы живая, а прогресса нет. Мы это называем «зависом».

На такой случай есть отдельный пакет — killer. Он ходит по собственному расписанию, смотрит активные задачи и сверяет их длительность с порогом. Если задача превысила допустимое время, он прерывает сессию в ODI, выставляет статус неуспешного завершения и пишет событие в журнал, чтобы утром было понятно, что произошло.

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

Что получилось в итоге

Механизм многоуровневый, но логика каждого слоя простая и живёт отдельно. Пакет-будильник запускает цикл опроса. Процедура выборки отбирает кандидатов. Диспетчер решает, кем и как выполнять. Обёртки отправляют задачу на конкретного агента и ведут учёт. Killer подчищает хвосты, которые по каким-то причинам не доехали сами.

Главное достоинство такой схемы как раз в этой разнесённости. Каждый пакет можно дорабатывать и чинить самостоятельно, не боясь задеть соседей, а привязка задач к конкретным агентам позволяет распоряжаться вычислительными ресурсами так, как это удобно под конкретный контур, а не так, как решил за тебя один общий scheduler.