python – 以DAG方式调度作业

我们有一个包含不同类型工作的系统.我们打电话给他们举个例子:

job_1
job_2
job_3

它们都需要不同的参数集(和可选参数).即我们为不同的x = A,B,C运行job_1(x)…. job_2运行一组参数,这些参数依赖于job_1(x)的结果,job_2也加载job_A(x)存储的数据.等等.

结果是依赖关系的树结构.现在,这些工作偶尔因某种原因而失败.因此,如果x = B的job_A失败,那么树的分支将完全失败并且不应该运行.所有其他分支应该运行.

所有作业都是用Python编写的,并使用并行性(基于生成SLURM作业).他们与cron一起安排.这显然不是很好,有两个主要缺点:

>调试非常困难.无论树中较高的作业是否失败,所有作业都会运行.如果不深入了解依赖关系,很难看出问题出在哪里.
>如果未完成更高的作业(例如job_A),则可能会计划job_B运行,并根据过时日期失败或运行.

为了解决这个问题,我们正在寻找用于调度或可视化的气流,因为它是用Python编写的,它似乎大致符合我们的需求.我看到了不同的挑战:

>作业的依赖关系树要么非常一般(即job_B取决于job_A)要么非常宽(即100个参数的job_B(y)取决于job_A(x = A).第一种情况下的可视化树大约有10个离开,但会使调试变得非常困难,因为作业可能只是某个参数失败.后一种情况下的可视化树将非常宽并且有大约300片叶子.它会更准确但可视化可能难以阅读.我们可以过滤失败的作业,只看他们的依赖关系吗?
>我们在工作中有并行性(我们需要它,否则工作运行超过一天,我们希望每天重新运行整个批次)这会搞砸我们的日程安排吗?
>我们希望尽可能少地改变我们的工作和数据管理.
>我们能否以易于理解的方式实施下一个产生的工作的规则系统?

气流是一个很好的选择吗?我知道还有其他一些(luigi,Azkaban等)与Hadoop堆栈有些相关(我们没有使用它,因为它不是大数据).需要多少黑客攻击?有多少黑客是明智的?

最佳答案 我真的不能说气流,但我可以代表路易吉.

路易吉的简要概述:
Luigi专为数据流和数据依赖而设计,就像气流一样,但是是在Spotify开发的.数据流中的每一步都表示为一个继承自luigi.Task的类,我们将每个步骤称为任务.每个任务由三个主要功能组成,并具有参数声明.这三个功能及其描述:

>要求:在此功能中,您可以通过返回这些任务来指定手头任务所依赖的任务.
>输出:在此函数中,您可以通过返回类Luigi.LocalTarget(或类似但对于远程)的对象来指定保存此任务结果的位置.
>运行:在此功能中,您可以指定运行任务时实际发生的情况.

注意:luigi中央调度程序通过检查文件是否存在来了解任务何时完成 – 特别是在要运行的任务的requires函数中返回的任务的输出函数中指定的文件.

Can we filter failed jobs, and just look at their dependencies?

Luigi记录传递给每个任务的所有参数以及每次运行每个任务的尝试.默认情况下,luigi不保存日志,但您可以轻松地将其设置为.去年夏天我做了一个很大的luigi管道,我把它保存了.然后使用模糊字符串比较(使用Levenshtein库)删除重复行并重新压缩日志,然后基本上搜索单词“error”,如果它出现,那么它会发送一封电子邮件给我压缩登录它.

We have parallelism within the job (and we need it otherwise the jobs run for more than a day, and we want to rerun the whole lot every day) does that screw up our scheduling?

我在其中运行具有并行性的任务没有任何问题.有些库可能会导致问题,例如gensim.

We want to change our jobs and data management as little as possible.

您通常可以将大部分计算粘贴到luigi任务的运行功能中.

Can we implement the rule system of what jobs to spawn next in a easily understandable way?

我相信是的,是的.对于每个任务,您可以在任务的requires函数中指定它所依赖的任务.

还需要考虑的是文档. Luigi的文档相当不错,但它没有尽可能多地流行起来. Luigi的社区不是很大,也不是非常活跃.据我所知,Airflow相当可比,但它更新,所以可能暂时有一个更活跃的社区.

Here是由luigi写的一篇博客文章,其中介绍了luigi和新的替代品之间的简短比较.他的结论是:他们都很糟糕.包括路易吉.

点赞