Airflow讲解之BaseOperator1

由于网上这部分东西较少,我大体写写,总体上还是官网的东西,然后做一些总结。

Airflow

Operators是Airflow很重要的一个概念,他就是使用Operators来实现对所有功能的整合,然后通过DAG图调用Operators来实现流程图。

Operators允许生成某些类型的任务,这些任务在实例化时成为DAG中的节点。所有运算符都从BaseOperator派生,并以这种方式继承许多属性和方法。

BaseOperator

所有的Operators都是从BaseOperator派生的,所以通过继承获得许多功能。因为这是引擎的核心,所以花时间了解BaseOperator的参数以了解DAG中可以利用的原始特性是值得的。

所有运算符的抽象基类。由于运算符创建的对象成为DAG中的节点,BaseOperator包含许多用于DAG爬行行为的递归方法。若要派生此类,需要重写构造函数和“execute”方法。

此类是抽象的,不应实例化。实例化从这个类派生的类会导致创建一个任务对象,它最终成为DAG对象中的一个节点。任务依赖项应使用set_upstream和/或set_downstream方法进行设置。

参数列表:

  • task_id(string) - 任务的唯一,有意义的id
  • owner(string) - 使用unix用户名的任务所有者
  • retries(int) - 在失败任务之前应执行的重试次数
  • retry_delay(timedelta) - 重试之间的延迟
  • retry_exponential_backoff(bool) - 允许在重试之间使用指数退避算法在重试之间进行更长时间的等待(延迟将转换为秒)
  • max_retry_delay(timedelta) - 重试之间的最大延迟间隔
  • start_date(datetime) - start_date用于任务,确定execution_date第一个任务实例。最佳做法是将start_date四舍五入到DAG中schedule_interval。每天的工作在00:00:00有一天start_date,每小时工作的start_date在特定时间的00:00。请注意,Airflow只是查看最新的 execution_date并添加schedule_interval以确定下一个execution_date。同样非常重要的是要注意不同任务的依赖关系需要及时排列。如果任务A依赖于任务B并且它们的start_date以其execution_date不排列的方式偏移,则永远不会满足A的依赖性。如果您希望延迟任务,例如在凌晨2点运行每日任务,请查看 TimeSensor和TimeDeltaSensor。我们建议不要使用动态start_date,建议使用固定的。有关更多信息,请阅读有关start_date的FAQ条目。
  • end_date(datetime) - 如果指定,调度程序将不会超出此日期
  • depends_on_past(bool) - 当设置为true时,任务实例将依次运行,同时依赖上一个任务的计划成功。允许start_date的任务实例运行。
  • wait_for_downstream(bool) - 当设置为true时,任务X的实例将等待紧接上一个任务X实例下游的任务在运行之前成功完成。如果任务X的不同实例更改同一资产,并且任务X的下游任务使用此资产,则此操作非常有用。请注意,在使用wait_for_downstream的任何位置,depends_on_past都将强制为True。
  • queue(str) - 运行此作业时要定位的队列。并非所有执行程序都实现队列管理,CeleryExecutor确实支持定位特定队列。
  • dag(DAG) - 对任务附加的dag的引用(如果有的话)
    priority_weight(int) - 此任务相对于其他任务的优先级权重。这允许执行程序在事情得到备份时在其他任务之前触发更高优先级的任务。
  • weight_rule(str) - 用于任务的有效总优先级权重的加权方法。选项包括: default是 设置为任务的有效权重时是所有下游后代的总和。因此,上游任务将具有更高的权重,并且在使用正权重值时将更积极地安排。当您有多个dag运行实例并希望在每个dag可以继续处理下游任务之前完成所有运行的所有上游任务时,这非常有用。设置为时{ downstream | upstream | absolute }downstreamdownstreamupstream有效权重是所有上游祖先的总和。这与downtream任务具有更高权重并且在使用正权重值时将更积极地安排相反。当你有多个dag运行实例并且在开始其他dag的上游任务之前更喜欢让每个dag完成时,这很有用。设置为时 absolute,有效重量是精确priority_weight 指定的,无需额外加权。当您确切知道每个任务应具有的优先级权重时,您可能希望这样做。另外,当设置absolute为时,对于非常大的DAGS,存在显着加速任务创建过程的额外效果。可以将选项设置为字符串或使用静态类中定义的常量airflow.utils.WeightRule
  • pool(str) - 此任务应运行的插槽池,插槽池是限制某些任务的并发性的一种方法
    sla(datetime.timedelta) - 作业预期成功的时间。请注意,这表示timedelta期间结束后。例如,如果您将SLA设置为1小时,则调度程序将在凌晨1:00之后发送电子邮件,2016-01-02如果2016-01-01实例尚未成功的话。调度程序特别关注具有SLA的作业,并发送警报电子邮件以防止未命中。SLA未命中也记录在数据库中以供将来参考。共享相同SLA时间的所有任务都捆绑在一封电子邮件中,在此之后很快就会发送。每个任务实例只发送一次SLA通知。
  • execution_timeout(datetime.timedelta) - 执行此任务实例所允许的最长时间,如果超出此任务实例将会引发并失败。
  • on_failure_callback(callable) - 当此任务的任务实例失败时要调用的函数。上下文字典作为单个参数传递给此函数。Context包含对任务实例的相关对象的引用,并记录在API的宏部分下。
  • on_retry_callback(callable) - 非常类似于on_failure_callback重试发生时执行的。
  • on_success_callback(callable) - 很像on_failure_callback是在任务成功时执行它。
    trigger_rule(str) - 定义应用依赖项以触发任务的规则。选项包括: 默认为。可以将选项设置为字符串或使用静态类中定义的常量 { all_success | all_failed | all_done | one_success | one_failed | none_failed | dummy}all_successairflow.utils.TriggerRule
  • resources(dict) - 资源参数名称(Resources构造函数的参数名称)与其值的映射。
  • run_as_user(str) - 在运行任务时使用unix用户名进行模拟
  • task_concurrency(int) - 设置后,任务将能够限制execution_dates之间的并发运行
  • executor_config(dict) - 由特定执行程序解释的其他任务级配置参数。参数由executor的名称命名。
  • 1
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值