问推荐的python科学工作流管理工具，它根据参数状态而不是时间来定义依赖完整性？

EN

我进一步研究了Luigi和Airflow，据我所知，它们都不适合根据我的需要进行修改。主要的不兼容性是这些工具基本上基于预先确定的DAG/工作流。我的现有框架在实例化的和完全指定的DAG上运行，这些DAG是在运行时发现的，而不是在外部简洁地描述的--这是必要的，因为对于给定的请求，了解每个任务是否完成取决于许多参数值的组合，这些参数值定义了该任务的输出和所有上游任务的已用输出。通过实例化，我指的是各个运行的“中间”结果，每个结果都由复制(承受任何随机元素)来自该任务的相同输出所必需的完整参数状态(变量值)描述。

因此，提前在DAG上运行的“Scheduler”是没有用的。

一般来说，大多数现有的工作流框架，至少在python中，似乎更多地被设计为以一种易于扩展和健壮的方式，通过并行化来自动化许多相对简单的任务，而很少强调更复杂的分析的增量构建，以及在可能的情况下必须重用的结果，以链接复杂和昂贵的计算任务，这些任务的输出可能会被用作额外的不可预见的分析的输入。

今天早上我刚刚发现了'Prefect‘工作流程，我很想了解更多--至少它显然资金充足;-)。我最初的感觉是，它可能对预调度的依赖较少，因此更具流动性，更容易适应我的需求，但这只是一种预感。在许多方面，我的一些更复杂的“单一”任务可能非常适合包装整个Prefect流，如果它们很好地一起玩。我的需求似乎在深度复杂的DAG频谱的另一端(我不会尝试写出我的需求！)永远不会结束下游的添加。

我将更仔细地研究Prefect和Luigi，看看我可以借鉴什么来使我的框架更健壮，更少巴洛克风格。或者我可以在Prefect中添加一层完整的数据描述...

更新--与Prefect人员讨论，明确我需要从底层的Dask开始，看看它是否足够灵活--也许使用Dask delayed或futures。显然，Dask是非同寻常的。建立在Dask之上的Graphchain是在正确的方向上的一步，它促进了在由代码库和参数的散列识别的依赖‘链’上计算的‘中间’输出的永久存储。与我需要的非常接近，尽管对那些确定定义输出的参数进行了更明确的处理。