Рекомендуется python scientifi c инструмент управления рабочим процессом, который определяет полноту зависимости от состояния параметра, а не от времени?

Question

Мне давно пора перейти от своего собственного научного c управления рабочим процессом (python) к групповым усилиям. Вкратце, мой рабочий процесс включает в себя длительные (дни) процессы с большим количеством общих параметров. Как граф зависимостей, узлы - это задачи, которые производят вывод или выполняют какую-то другую работу. Это кажется довольно универсальным в инструментах рабочего процесса.

Однако ключом к моим потребностям является то, что каждая задача определяется требуемыми параметрами. Задачи создаются в отношении состояния этих параметров и всех параметров их зависимостей. Таким образом, если задача завершила свою работу в соответствии с заданным состоянием параметра, она завершается и не запускается повторно. Это состояние параметра НЕ является глобальным состоянием параметра, а только тем, что относится к этой части группы доступности базы данных. Эта зависимость от состояния параметра, а не от времени, по-видимому, является существенной разницей между моими потребностями и существующими инструментами (по крайней мере, тем, что я собрал из быстрого взгляда на Luigi и Airflow). Время завершения может быть одним из таких параметров, но, как правило, не время определяет повторное выполнение группы обеспечения доступности баз данных, а соответствует ли состояние параметра состоянию параметра вызывающей задачи. Существуют нетривиальные проблемы (для меня) с «взрывом параметров» и отношением к состоянию параметров и DAG, но это не мой вопрос здесь.

Мой вопрос - какой существующий инструмент python будет более легко разрешить определение «завершено» в отношении этого состояния параметра? Было высказано предположение, что Luigi совместим с моими потребностями, написав собственный полный метод, который будет сравнивать метаданные построенных данных («цели») с необходимым состоянием параметра.

Как насчет Airflow? Я не вижу упоминаний об этой проблеме, но только кратко изучил документы. Поскольку добавление этой функциональности является значительным усилием, которое отнимает у меня «научную работу c», я хотел бы начать с лучшего инструмента. У воздушного потока определенно есть импульс, но мои потребности могут быть слишком далеки от его цели. Определение полного состояния параметра необходимо по двум причинам: 1) со сложными, длительными задачами, я не могу просто перезапускать группу обеспечения доступности баз данных каждый раз, когда меняю какой-либо параметр в очень большом глобальном состоянии параметра, и 2) мне нужно знать, как были получены промежуточные и окончательные результаты для научной c и соображений целостности данных.

Answer 1

Я посмотрел дальше на Luigi и Airflow и, насколько я мог различить, ни один из них не подходит для модификации под мои нужды. Основная несовместимость заключается в том, что эти инструменты основаны на заранее определенных группах обеспечения доступности баз данных / рабочих процессах. Моя существующая структура работает с созданными и полностью определенными группами обеспечения доступности баз данных, которые обнаруживаются во время выполнения, а не кратко описываются извне - это необходимо, поскольку знание того, завершена ли каждая задача для данного запроса, зависит от многих комбинаций значений параметров, которые определяют выходные данные. этой задачи и используемого вывода всех вышестоящих задач. Под экземпляром я подразумеваю «промежуточные» результаты отдельных прогонов, каждый из которых описывается полным состоянием параметра (значениями переменных), необходимыми для воспроизведения (выдерживающего любой элемент стохастики c) идентичного результата этой задачи.

«Планировщик», который работает с DAG раньше времени, бесполезен.

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

Я только что открыл рабочий процесс «Префект» этим утром, и заинтригован, чтобы узнать больше - по крайней мере, он явно хорошо финансируется ;-). Мой первоначальный смысл заключается в том, что он может быть менее зависимым от предварительного планирования и, следовательно, более гибким и более легко адаптируемым к моим потребностям, но это всего лишь догадка. Во многих отношениях некоторые из моих более сложных «одиночных» задач могут хорошо подходить, чтобы обернуть весь поток префектов, если они хорошо сыграли вместе. Кажется, мои потребности находятся в дальнем конце спектра глубоко сложных DAG (я не буду пытаться выписать свои!), Не заканчивая последующие добавления.

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

ОБНОВЛЕНИЕ - обсуждая с людьми Префекта, ясно, что мне нужно начать с базового Dask и посмотреть, достаточно ли он гибок - возможно, используя Dask с задержкой или фьючерсами. Ясно, что Даск необычен. Graphchain, построенный поверх Dask, является движением в правильном направлении, облегчая постоянное хранение «промежуточного» вывода, вычисленного по «цепочке» зависимостей, идентифицируемой ha sh базы кода и параметров. Довольно близко к тому, что мне нужно, хотя и с более явной обработкой тех параметров, которые детерминистически определяют выходные данные.