Airflow调度系统知识点整理

1. Airflow简介

1.1 简介

Airflow是一个使用python语言编写的data pipeline调度和监控工作流的平台。Airflow被Airbnb内部用来创建、监控和调整数据管道。任何工作流都可以在这个使用 Python 来编写的平台上运行。

Airflow是一种允许工作流开发人员轻松创建、维护和周期性地调度运行工作流（即有向无环图或成为 DAGs ）的工具。在 Airbnb 中，这些工作流包括了如数据存储、增长分析、Email 发送、A/B 测试等等这些跨越多部门的用例。

Airflow拥有和 Hive、Presto、MySQL、HDFS、Postgres 和 S3 交互的能力，并且提供了钩子使得系统拥有很好地扩展性。除了一个命令行界面，该工具还提供了一个基于 Web 的用户界面让您可以可视化管道的依赖关系、监控进度、触发任务等。

传统 Workflow 通常使用 TextFiles ( json,xml/etc ) 来定义 DAG ,然后 Scheduler 解析这些 DAG 文件形成具体的 TaskObjec t执行； Airflow 没这么干，它直接用 Python 写 DAGdefinition ,一下子突破了文本文件表达能力的局限，定义 DAG 变得简单。

1.2 设计原则

• 动态：Airflow配置为代码（Python），允许动态生成pipeline。 这允许编写动态实例化的pipelines代码。
• 自定义：轻松定义自己的opertators，执行程序并扩展库，使其符合适合您环境的抽象级别。
• 优雅：Airflow精益而明确。 使用强大的Jinja模板引擎将参数化脚本内置于Airflow的核心。
• 可扩展：Airflow具有模块化体系结构，并使用消息队列来协调任意数量的工作者。 Airflow已准备好扩展到无限远。

1.3 优点

• Python脚本实现DAG，非常容易扩展
• 可实现复杂的依赖规则
• 外部依赖较少，搭建容易，仅依赖DB和rabbitmq
• 工作流依赖可视化。有一套完整的UI，可视化展现所有任务的状态及历史信息
• 完全支持crontab定时任务格式，可以通过crontab格式指定任务何时进行
• 业务代码和调度系统解耦，每个业务的流程代码以独立的Python脚本描述，里面定义了流程化的节点来执行业务逻辑，支持任务的热加载

1.4 功能简介

功能	Airflow
工作流描述	Python
数据触发	Sensor
工作流节点	Operator
完整工作流	DAG
定期调度	DAG schedule_interval
任务依赖	>>,<<
内置函数、变量	template macros

2. Airflow服务构成

2.1 WebServer

Airflow 提供了一个可视化的 Web 界面。启动 WebServer 后，就可以在 Web 界面上查看定义好的 DAG 并监控及改变运行状况。也可以在 Web 界面中对一些变量进行配置。

2.1.1 DAG列表

• 1.左侧 On/Off 按钮控制 DAG 的运行状态，Off 为暂停状态，On 为运行状态。注意：所有 DAG 脚本初次部署完成时均为 Off 状态。
• 2.若 DAG 名称处于不可点击状态，可能为 DAG 被删除或未载入。若 DAG 未载入，可点击右侧刷新按钮进行刷新。注意：由于可以部署若干 WebServer，所以单次刷新可能无法刷新所有 WebServer 缓存，可以尝试多次刷新。
• 3.Recent Tasks 会显示最近一次 DAG Run（可以理解为 DAG 的执行记录）中 Task Instances（可以理解为作业的执行记录）的运行状态，如果 DAG Run 的状态为 running，此时显示最近完成的一次以及正在运行的 DAG Run 中所有 Task Instances 的状态。
• 4.Last Run 显示最近一次的 execution date。注意：execution date 并不是真实执行时间，具体细节在下文 DAG 配置中详述。将鼠标移至 execution date 右侧 info 标记上，会显示 start date，start date 为真实运行时间。start date 一般为 execution date 所对应的下次执行时间。

2.1.2 作业操作框

在 DAG 的树状图和 DAG 图中都可以点击对应的 Task Instance 以弹出 Task Instance 模态框，以进行 Task Instance 的相关操作。注意：选择的 Task Instance 为对应 DAG Run 中的 Task Instance。

• 在作业名字的右边有一个漏斗符号，点击后整个 DAG 的界面将只显示该作业及该作业的依赖作业。当该作业所处的 DAG 较大时，此功能有较大的帮助。
• Task Instance Details 显示该 Task Instance 的详情，可以从中得知该 Task Instance 的当前状态，以及处于当前状态的原因。例如，若该 Task Instance 为 no status 状态，迟迟不进入 queued 及 running 状态，此时就可通过 Task Instance Details 中的 Dependency 及 Reason 得知原因。
• Rendered 显示该 Task Instance 被渲染后的命令。
• Run 指令可以直接执行当前作业。
• Clear 指令为清除当前 Task Instance 状态，清除任意一个 Task Instance 都会使当前 DAG Run 的状态变更为 running。注意：如果被清除的 Task Instance 的状态为 running，则会尝试 kill 该 Task Instance 所执行指令，并进入 shutdown 状态，并在 kill 完成后将此次执行标记为 failed（如果 retry 次数没有用完，将标记为 up_for_retry）。Clear 有额外的5个选项，均为多选，这些选项从左到右依次为：
  • Past: 同时清除所有过去的 DAG Run 中此 Task Instance 所对应的 Task Instance。
  • Future: 同时清除所有未来的 DAG Run 中此 Task Instance 所对应的 Task Instance。注意：仅清除已生成的 DAG Run 中的 Task Instance。
  • Upstream: 同时清除该 DAG Run 中所有此 Task Instance 上游的 Task Instance。
  • Downstream: 同时清除该 DAG Run 中所有此 Task Instance 下游的 Task Instance。
  • Recursive: 当此 Task Instance 为 sub DAG 时，循环清除所有该 sub DAG 中的 Task Instance。注意：若当此 Task Instance 不是 sub DAG 则忽略此选项。
• Mark Success 指令为讲当前 Task Instance 状态标记为 success。注意：如果该 Task Instance 的状态为 running，则会尝试 kill 该 Task Instance 所执行指令，并进入 shutdown 状态，并在 kill 完成后将此次执行标记为 failed（如果 retry 次数没有用完，将标记为 up_for_retry）。

2.2 Worker

一般来说我们用 Celery Worker 来执行具体的作业。Worker 可以部署在多台机器上，并可以分别设置接收的队列。当接收的队列中有作业任务时，Worker 就会接收这个作业任务，并开始执行。Airflow 会自动在每个部署 Worker 的机器上同时部署一个 Serve Logs 服务，这样我们就可以在 Web 界面上方便的浏览分散在不同机器上的作业日志了。

2.3 Scheduler

整个 Airflow 的调度由 Scheduler 负责发起，每隔一段时间 Scheduler 就会检查所有定义完成的 DAG 和定义在其中的作业，如果有符合运行条件的作业，Scheduler 就会发起相应的作业任务以供 Worker 接收。

Scheduler 的调度逻辑：

• 遍历 dags 路径下的所有 dag 文件, 启动一定数量的进程（进程池），并且给每个进程指派一个 dag 文件。 每个 DagFileProcessor 解析分配给它的dag文件，并根据解析结果在 DB中创建 DagRuns 和 TaskInstance。
• 在 scheduler_loop 中，检查与活动 DagRun 关联的 TaskInstance 的状态，解析 TaskInstance 之间的任何依赖，标识需要被执行的 TaskInstance，然后将它们添加至 executor 队列，将新排列的 TaskInstance 状态更新为QUEUED状态。
• 每个可用的 executor 从队列中取一个 TaskInstance，然后开始执行它，将此 TaskInstance 的数据库记录更新为SCHEDULED。
• 当一个 TaskInstance 完成运行，关联的 executor 就会报告到队列并更新数据库中的 TaskInstance 的状态（例如“完成”、“失败”等）。
• 一旦所有的dag处理完毕后，就会进行下一轮循环处理。这里还有一个细节就是上一轮的某个dag的处理时间可能很长，导致到下一轮处理的时候这个dag还没有处理完成。 Airflow 的处理逻辑是在这一轮不为这个dag创建进程，这样就不会阻塞进程去处理其余dag。
  

2.4 Flower

Flower 监控worker进程的存活性，启动或关闭worker进程，查看运行的task。

3. Airflow核心概念

3.1 DAGs

DAG是一个有向无环图，它是task的集合，并且定义了这些task之间的执行顺序和依赖关系。比如，一个DAG包含A，B，C，D四个任务，A先执行，只有A运行成功后B才能执行，C只有在A，B都成功的基础上才能执行，D不受约束，随时都可以执行。DAG并不关心它的组成任务所做的事情，它的任务是确保他们所做的一切都在适当的时间，或以正确的顺序进行，或者正确处理任何意外的问题。
DAG 是在标准 Python 文件中定义的，这些文件放在 Airflow 的DAG_FOLDER中。Airflow 将执行每个文件中的代码以动态构建DAG对象。 您可以拥有任意数量的 DAG，每个 DAG 都可以描述任意数量的任务。通常，每个应该对应于单个逻辑工作流。

3.1.1 SubDag

SubDag非常适合重复模式。 在使用Airflow时，定义一个返回DAG对象的函数是一个很好的设计模式。
Airbnb在加载数据时使用stage-check-exchange模式。 数据在临时表中暂存，然后对该表执行数据质量检查。 一旦检查全部通过，分区就会移动到生产表中。
比如以下Dag:

我们可以将所有并行task-* operators组合到一个SubDag中，然后可以在主Dag文件中引用此SubDag生成的Dag类似于以下内容：

使用SubDAG时需注意以下几点：

1）按照惯例，SubDAG的dag_id应以其父级DAG名称和点为前缀。 和在parent.child中一样。
2）通过将参数传递给SubDAG operator来共享主DAG和SubDAG之间的参数（如上所示）。
3）SubDAG必须有一个计划并启用。 如果SubDAG的时间表设置为None或@once，SubDAG将成功完成而不做任何事情。
4）清除SubDagOperator也会清除其中的任务状态。
5）在SubDagOperator上标记成功不会影响其中的任务状态。
6）避免在SubDAG中的任务中使用depends_on_past=True，因为这可能会造成混淆。
7）可以为SubDAG指定执行程序。 如果要在进程中运行SubDAG并有效地将其并行性限制为1，则通常使用SequentialExecutor。 使用LocalExecutor可能会有问题，因为它可能会过度订阅你的worker，在单个插槽中运行多个任务。

3.1.2 DAG配置

default_args = {
    'owner': 'airflow', # DAG的所有者，会在Web UI上显示，主要用于方便管理
    'depends_on_past': False,  # 是否依赖于过去。如果为True，那么必须要昨天的DAG执行成功了，今天的DAG才能执行。
    'start_date': datetime(2015, 6, 1), # DAG的开始时间(必须一个datetime对象，不可以用字符串)
    'email': ['airflow@example.com'],# 出问题时，发送报警Email的地址，可以填多个，用逗号隔开。
    'email_on_failure': False, # 任务失败且重试次数用完时是否发送Email，推荐填True。
    'email_on_retry': False, # 任务重试时是否发送Email
    'retries': 1, # 任务失败后的重试次数
    'retry_delay': timedelta(minutes=5), # 重试间隔，必须是timedelta对象。
}

# 第一个参数固定为dag的名字,schedule_interval为执行时间间隔
dag = DAG('tutorial', default_args=default_args,schedule_interval=timedelta(hours=1))

整个 DAG 的配置就是一份完整的 Python 代码，在代码中实例化 DAG，实例化适合的 Operator，并通过 set_downstream 等方法配置上下游依赖关系。下面我们简单看一下在 DAG 配置中的几个重要概念。

• dag_id:给 DAG 取一个名字，方便日后维护。
• dafault_args:默认参数，当属于这个 DAG 实例的作业没有配置相应参数时，将使用 DAG 实例的 default_args 中的相应参数。
• schedule_interval:配置 DAG 的执行周期，语法和 crontab 的一致。

3.2 Task

task是Dag里最小的单元，是Dag的实例化，task之间存在依赖关系，每一个task执行都有对应的日志存在。task定义任务的类型、任务内容、任务所依赖的dag等。dag中每个task都要有不同的task_id。任务之间通过task.set_upstream/task.set_downstream来设置依赖，也可以用位运算：
t1 >> t2 << t3 表示t2依赖于t1和t3。

dag = DAG('tutorial', default_args=default_args)

# t1, t2 and t3 are examples of tasks created by instantiating operators
t1 = BashOperator(   #任务类型是bash
    task_id='echoDate', #任务id
    bash_command='echo date > /home/datefile', #任务命令
    dag=dag)

t2 = BashOperator(
    task_id='sleep',
    bash_command='sleep 5',
    retries=3,[]()
    dag=dag)

t2.set_upstream(t1) #定义任务信赖，任务2依赖于任务1

3.3 Task Instance

记录Task的一次运行，Task Instance有自己的状态，包括：running、success、failed、 skipped、up for retry等。

3.4 Sensors

Sensors是一个等待（轮询）某一时间、文件、数据库行、S3键、另一个DAG/Task等的Operator。

Airflow有3种不同的传感器运作模式:

Schedule Mode	Description	Use case
poke(default)	传感器在整个执行时间内占用了一个工作槽，并在戳的间隙进行睡眠	如果传感器的预期运行时间很短，或者需要较短的poke间隔，则使用此模式。注意，在此模式下，传感器将在传感器的运行时间内抓住一个工作槽和一个池槽
reschedule	当标准尚未满足时，传感器任务释放了工人槽，并在以后的时间重新安排	如果在满足标准之前的时间预计会相当长，请使用这种模式。poke间隔应该超过一分钟，以防止对调度器造成太大负担
smart sensor	是一个服务（由一个内置的DAG运行），它整合了传感器的分批执行。而不是为每个传感器保留一个长期运行的进程并定期进行探测，一个传感器将只在sensor_instance表中存储探测上下文，然后以 "探测 "状态退出	如果你有大量的传感器任务在你的airflow集群中运行，请使用这种模式。这可以在很大程度上降低airflow的基础设施成本，提高集群的稳定性–减少元数据库的负载

3.5 Operator

Operator即为操作器，定义任务该以哪种方式执行。airflow有多种operator,如BashOperator、DummyOperator、MySqlOperator、HiveOperator以及社区贡献的operator等，其中BaseOperator是所有operator的基础operator。

Operator 主要有三种类型:

• 执行一项操作或在远程机器上执行一项操作。
• 将数据从一个系统移动到另一个系统
• 类似传感器，是一种特定类型 Operator，它将持续运行，直到满足某种条件。例如在 HDFS 或 S3 中等待特定文件到达，在 Hive 中出现特定的分区或一天中的特定时间，继承自 BaseSensorOperator。

Operator类型	说明
BaseOperator	基础operator，设置baseoperator会影响所有的operator
BashOperator	executes a bash command
DummyOperator	空操作
PythonOperator	calls an arbitrary Python function
EmailOperator	sends an email
HTTPOperator	sends an HTTP request
SqlOperator	executes a SQL command
Sensor	waits for a certain time, file, database row, S3 key, etc…

3.5.1 BaseOperator

所有的 Operator 都是从 BaseOperator 派生而来，并通过继承获得更多功能。因此 BaseOperator的参数也是其他Operator的参数。

3.5.2 BashOperator

import airflow
from airflow import DAG
from airflow.operators.bash_operator import BashOperator
from datetime import timedelta

default_args = {
    'owner': 'airflow',
    'depends_on_past': False,
    'start_date': airflow.utils.dates.days_ago(2),
    'email': ['airflow@example.com'],
    'email_on_failure': False,
    'email_on_retry': False,
    'retries': 1,
    'retry_delay': timedelta(minutes=5),
}

dag = DAG(
    'tutorial',
    default_args=default_args,
    description='A simple tutorial DAG',
    schedule_interval=timedelta(days=1))

t1 = BashOperator(
    task_id='print_date',   #这里也可以是一个 bash 脚本文件
    bash_command='date',
    dag=dag)

t2 = BashOperator(
    task_id='sleep',
    depends_on_past=False,
    bash_command='sleep 5',
    dag=dag)

templated_command = """
{% for i in range(5) %}
    echo "{{ ds }}"
    echo "{{ macros.ds_add(ds, 7)}}"
    echo "{{ params.my_param }}"
{% endfor %}
"""

t3 = BashOperator(
    task_id='templated',
    depends_on_past=False,
    bash_command=templated_command,
    params={'my_param': 'Parameter I passed in'},
    dag=dag)

t2.set_upstream(t1)
t3.set_upstream(t1)

3.5.3 PythonOperator

from __future__ import print_function
from builtins import range
import airflow
from airflow.operators.python_operator import PythonOperator
from airflow.models import DAG

import time
from pprint import pprint

args = {
    'owner': 'airflow',
    'start_date': airflow.utils.dates.days_ago(2)
}

dag = DAG(
    dag_id='example_python_operator', default_args=args,
    schedule_interval=None)

def my_sleeping_function(random_base):
    """This is a function that will run within the DAG execution"""
    time.sleep(random_base)

def print_context(ds, **kwargs):
    pprint(kwargs)
    print(ds)
    return 'Whatever you return gets printed in the logs'

run_this = PythonOperator(
    task_id='print_the_context',
    provide_context=True,
    python_callable=print_context,
    dag=dag)

# Generate 10 sleeping tasks, sleeping from 0 to 9 seconds respectively
for i in range(10):
    task = PythonOperator(
        task_id='sleep_for_' + str(i),
        python_callable=my_sleeping_function,
        op_kwargs={'random_base': float(i) / 10},
        dag=dag)

    task.set_upstream(run_this)

3.5.4 SSHOperator

common_filter_operator = SSHOperator(
            ssh_conn_id=server,
            task_id=f"common_filter_{server_name}_{i}",
            dag=dag_subdag,
            get_pty=True,
            command=f"python common_filter.py {model_id_str} {start_date_str} {end_date_str}")

3.5.5 HiveOperator

check_first_code = HivePartitionSensor(
    task_id="check_first_code",
    dag=dag,
    partition="dt='{{ ti.xcom_pull(task_ids='push_date', key='which_date') }}'",
    schema="ai_group",  # hive 库名
    table="hive_table",  # hive 表名
    poke_interval=300,  # 每 300 秒检测一次
    execution_timeout=timedelta(hours=4),  # 超时时间
    retries=0,  # sensor 任务不重复执行
)

3.5.6 自定义Operator

如果官方的 Operator 仍不满足需求, 那么我们就自己开发一个 Operator。 开发 Operator 比较简单，继承 BaseOperator 并实现 execute方法即可。

3.6 Workflows

通过结合DAG和Operator来创建TaskInstances，建立复杂的工作流程。

3.7 附加功能

3.7.1 Hooks

Hooks是连接外部平台和数据库的接口，如Hive、S3、MySQL、Postgres、HDFS和Pig。Hooks在可能的情况下实现一个通用接口，并作为操作者的构建块。它们也使用airflow.models.connection.Connection模型来检索主机名和认证信息。Hooks将认证代码和信息从管道中分离出来，集中在元数据数据库中。
Hooks本身在Python脚本、Airflow airflow.operators.PythonOperator以及iPython或Jupyter Notebook等交互式环境中使用也非常有用。

3.7.2 Pools

当有太多的进程同时冲击时，一些系统会不堪重负。Airflow Pools可以用来限制任意任务集的执行并行性。Pools的列表是在用户界面(Menu -> Admin -> Pools)中管理的，给Pools一个名字，并给它分配一定数量的工作槽。然后，任务可以通过在创建任务（即实例化操作者）时使用池参数与现有池之一相关联。
池参数可以和priority_weight一起使用，以定义队列中的优先级，当池中有空位时，哪些任务会被首先执行。默认的priority_weight是1，也可以提升到任何数字。当对队列进行排序以评估哪个任务应该被接下来执行时，我们使用priority_weight，并与该任务下游的所有priority_weight值相加。你可以用它来提升一个特定的重要任务，而通往该任务的整个路径都会得到相应的优先级。

3.7.3 Connections

连接到外部系统所需的信息存储在Airflow元存储数据库中，可以在用户界面中管理(Menu -> Admin -> Connections)。一个conn_id被定义在那里，主机名/登录/密码/模式信息被附加到它上面。Airflow管线通过指定相关的conn_id来检索集中管理的连接信息.

3.7.4 Xcoms

XComs让任务交换信息，允许更细微的控制形式和共享状态。这个名字是 "交叉通信 "的缩写。XComs主要由一个键、值和时间戳来定义，但也跟踪一些属性，如创建XCom的task/DAG，以及它何时应该变得可见。任何可以被提取的对象都可以作为XCom值，所以用户应该确保使用适当大小的对象。
XComs可以被 “推”（发送）或 “拉”（接收）。当一个任务推送一个XCom时，它使其他任务普遍可用。任务可以在任何时候通过调用xcom_push()方法推送XComs。此外，如果一个任务返回一个值（无论是从它的操作者的execute()方法，还是从PythonOperator的python_callable函数），那么包含该值的XCom会自动被推送。
任务调用xcom_pull()来检索XComs，可以选择应用基于key、源task_ids和源dag_id等标准的过滤器。默认情况下，xcom_pull()过滤的是XComs在被推送时由执行函数返回而自动给出的键（而不是手动推送的XComs）。
如果xcom_pull传递的是单个字符串的task_ids，那么将返回该任务的最新XCom值；如果传递的是task_ids的列表，那么将返回相应的XCom值的列表。

3.7.5 Variables

变量是一种通用的方式来存储和检索任意的内容或设置，作为Airflow中一个简单的键值存储。变量可以从用户界面(Admin -> Variables),、代码或CLI中列出、创建、更新和删除。此外，json设置文件也可以通过用户界面批量上传。虽然你的管道代码定义和你的大多数常量和变量应该在代码中定义，并存储在源控制中，但让一些变量或配置项目通过用户界面访问和修改是非常有用的。

4. Airflow安装

4.1 airflow.yml文件

version: '2.2'
x-airflow-common:
  &airflow-common
  image: ${AIRFLOW_IMAGE_NAME:-apache/airflow:master-python3.8}
  environment:
    &airflow-common-env
    AIRFLOW__CORE__EXECUTOR: CeleryExecutor
    AIRFLOW__CORE__SQL_ALCHEMY_CONN: postgresql+psycopg2://aigroup:sl123456@postgres/aigroup
    AIRFLOW__CELERY__RESULT_BACKEND: db+postgresql://aigroup:sl123456@postgres/aigroup
    AIRFLOW__CELERY__BROKER_URL: redis://:@redis:6379/0
    AIRFLOW__CORE__FERNET_KEY: ''
    AIRFLOW__CORE__DAGS_ARE_PAUSED_AT_CREATION: 'true'
    AIRFLOW__CORE__LOAD_EXAMPLES: 'true'
  volumes:
    - /data/jx/airflow/dags:/opt/airflow/dags
    - /data/jx/airflow/logs:/opt/airflow/logs
    - /data/jx/airflow/plugins:/opt/airflow/plugins
  user: root
  depends_on:
    redis:
      condition: service_healthy
    postgres:
      condition: service_healthy

services:
  postgres:
    image: postgres:13
    environment:
      POSTGRES_USER: aigroup
      POSTGRES_PASSWORD: sl123456
      POSTGRES_DB: aigroup
      PGDATA: /var/lib/postgresql/data/pgdata
    volumes:
      - /etc/localtime:/etc/localtime
      - /data/pgdata:/var/lib/postgresql/data/pgdata
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "aigroup"]
      interval: 5s
      retries: 5
    restart: always

  redis:
    image: redis:6.2
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s
      timeout: 30s
      retries: 50
    restart: always

  airflow-webserver:
    <<: *airflow-common
    command: webserver
    ports:
      - 8087:8080
    healthcheck:
      test: ["CMD", "curl", "--fail", "http://localhost:8080/health"]
      interval: 10s
      timeout: 10s
      retries: 5
    restart: always

  airflow-scheduler:
    <<: *airflow-common
    command: scheduler
    restart: always

  airflow-worker:
    <<: *airflow-common
    command: celery worker
    restart: always

  airflow-init:
    <<: *airflow-common
    command: version
    environment:
      <<: *airflow-common-env
      _AIRFLOW_DB_UPGRADE: 'true'
      _AIRFLOW_WWW_USER_CREATE: 'true'
      _AIRFLOW_WWW_USER_USERNAME: ${_AIRFLOW_WWW_USER_USERNAME:-aigroup}
      _AIRFLOW_WWW_USER_PASSWORD: ${_AIRFLOW_WWW_USER_PASSWORD:-sl123456}

  flower:
    <<: *airflow-common
    command: celery flower
    ports:
      - 5555:5555
    healthcheck:
      test: ["CMD", "curl", "--fail", "http://localhost:5555/"]
      interval: 10s
      timeout: 10s
      retries: 5
    restart: always

volumes:
  postgres-db-volume:

4.2 Airflow服务启动

docker-compose -p airflow -f airflow.yaml up -d

4.3 Airflow服务web访问

在网页输入对应的ip+端口号访问airflow的webserver网页

4.4 Airflow服务关闭

docker-compose -p airflow -f airflow.yaml down

5. Airflow参考文档

• 英文文档：https://airflow.apache.org/docs/apache-airflow/stable/index.html
• 中文文档：https://airflow.apachecn.org/#/
• 代码库：https://github.com/apache/airflow