Планирование рабочих мест в DAG-манере

Question

У нас есть система с различными типами заданий. Назовем их, например:

job_1 
job_2 
job_3 

Все они требуют разных наборов параметров (и дополнительных параметров). То есть мы запускаем job_1(x) для разных x=A, B, C .... job_2 работает для набора параметров, который зависит от результатов job_1(x), а также job_2 загружает данные, хранящиеся в job_A(x). И так далее.

В результате получается древовидная структура зависимостей. Теперь эти задания иногда терпят неудачу по той или иной причине. Итак, если job_A для x=B не удается, ветка дерева полностью завершится и не должна запускаться. Все остальные ветви должны работать.

Все задания написаны на Python и используют параллелизм (на основе нереста SLURM-заданий). Они запланированы с помощью cron. Это, очевидно, не очень и имеет два основных недостатка:

• Очень сложно отлаживать. Все задания запускаются независимо от того, закончилось ли задание выше в дереве или нет. Трудно понять, где проблема без глубокого понимания зависимостей.
• Если более высокое задание (например, job_A) не завершено job_B может быть запланировано для запуска и сбой или запуск на основе устаревшей даты.

Для решения этой проблемы мы рассматривали воздушный поток для планирования или визуализации, потому что он написан на Python и, похоже, соответствует нашим потребностям. Я вижу различные проблемы, хотя:

• Дерево зависимостей рабочих мест либо очень общий характер (т.е. job_B зависит от job_A) или очень широкие (т.е. job_B(y) за 100 параметров зависит от job_A(x=A) визуализированных дерева в первом случае будет. имеют примерно 10 листов, но очень затрудняли бы отладку, потому что работа могла просто потерпеть неудачу для определенного параметра. Визуализированное дерево в последнем случае было бы очень широким и имело бы примерно 300 листьев. Это было бы более точно, но визуализация могла быть сложной читать. Можем ли мы фильтровать неудавшиеся задания и просто смотреть на их зависимости?
• У нас есть параллелизм в задании (и нам это нужно, иначе работа r un в течение более одного дня, и мы хотим, чтобы каждый день повторял всю игру), это лишает наше планирование?
• Мы хотим как можно меньше изменить наши рабочие места и управление данными.
• Можем ли мы внедрить систему правил о том, какие рабочие места должны появляться дальше в понятной форме?

Воздушный поток является хорошим выбором для этого? Я понимаю, что есть несколько других (luigi, Azkaban и т. Д.), Которые несколько связаны со стеком Hadoop (который мы не используем, потому что это не большие данные). Сколько требуется взломать? Сколько взломов разумно?

Answer 1

Я не могу говорить за воздушный поток, но я могу говорить за luigi.

Краткий обзор luigi: Luigi предназначен для потока данных и зависимости данных, как и поток воздуха, но был разработан на Spotify. Каждый шаг в потоке данных представлен как класс, который наследует от luigi.Task, и мы называем каждый шаг задачей.Каждая задача состоит из трех основных функций и содержит объявления параметров. Три функции и их описания:

1. Требуется: В этой функции вы определяете, какие задачи зависит от задачи, возвращая эти задачи.
2. Выход: в этой функции вы указываете, где будут сохраняться результаты этой задачи, возвращая объект класса Luigi.LocalTarget (или аналогичный, но для удаленного).
3. Run: В этой функции вы указываете, что на самом деле происходит при выполнении задачи.

Примечание: Центральный планировщик luigi знает, когда задача завершена, проверяя, существует ли файл - в частности, файл, указанный в функции вывода задачи, которая возвращается в требуемой функции задачи запустить.

Можем ли мы фильтровать неудачные задания и просто смотреть на их зависимости?

Luigi регистрирует все параметры, переданные каждой задаче, и каждую попытку запуска каждой задачи. По умолчанию luigi не сохраняет журналы, но вы можете легко настроить его. Прошлым летом я сделал большой трубопровод luigi, и я сохранил его. Затем он использовал сравнение нечетких строк (используя библиотеку Левенштейна) для удаления повторяющихся строк и сильно сжимал журнал, а затем в основном искал слово «ошибка», а если он появился, то он отправил мне письмо со сжатым войдите в него.

Мы параллелизм в работе (и мы должны это иначе задания выполняются в течение более суток, и мы хотим, чтобы повторно запустить весь много каждый день) делает что завинтить наше планирование?

Я запускал задачи с параллелизмом внутри них без проблем. Некоторые библиотеки могут вызывать проблемы, например, gensim.

Мы хотим как можно меньше изменить наши рабочие места и управление данными.

Вы можете просто вставить большую часть своих вычислений в функции запуска задач luigi.

Можем ли мы внедрить систему правил о том, какие рабочие места должны появляться дальше в понятной форме?

Я так считаю, да. Для каждой задачи вы определяете, какие задачи она зависит от требуемой функции задачи.

Что-то еще, о чем нужно подумать, это документация. Документация Луиджи довольно хороша, но она не попадала так сильно, как могла. Сообщество Луиджи не очень большое и не невероятно активное. Насколько мне известно, воздушный поток довольно сопоставим, но он новее, поэтому, вероятно, в настоящее время существует более активное сообщество.

Here сообщение в блоге от парня, который написал luigi с некоторыми краткими сравнениями между luigi и более новыми альтернативами. Его вывод: все они сосут. Включая Луиджи.