Prefect vs Airflow：5个真实场景对比，哪个更适合你的数据工程需求？

Prefect vs Airflow：数据工程实战中的抉择与深度解析

当数据管道从简单的脚本演变为由数百个任务交织而成的复杂网络时，选择一个合适的工作流编排工具就成了一场关键的架构决策。这不仅仅是选择一个调度器，更是为团队未来数年的开发体验、运维成本和系统可靠性奠定基础。在众多选项中，Apache Airflow 作为行业老兵，以其成熟和强大的社区生态著称；而 Prefect 作为后起之秀，以其“开发者优先”的理念和现代化的设计哲学吸引着越来越多的目光。面对“二选一”的困境，空谈特性列表往往让人更加迷茫。今天，我们不罗列参数，而是深入五个真实的数据工程场景，拆解 Prefect 和 Airflow 在其中的不同表现与设计逻辑，帮你找到那个最契合你团队基因和业务需求的伙伴。

1. 场景一：动态参数与运行时依赖的工作流

在数据工程中，并非所有工作流都能在启动前完全确定。例如，一个数据质量检查流程，需要根据上游数据表的实际分区数量，动态生成对应数量的校验任务；或者一个机器学习流水线，其后续步骤的参数依赖于前序模型训练的输出结果。

1.1 Airflow 的静态 DAG 哲学

Apache Airflow 的核心抽象是 DAG（有向无环图），它在设计上倾向于静态的、声明式的工作流定义。DAG 的结构在解析时刻（scheduler 解析 Python 文件时）就必须确定下来。

这意味着，如果你想实现上述动态任务生成，通常需要一些“技巧”：

from airflow import DAG
from airflow.operators.python import PythonOperator
from datetime import datetime

def _generate_partition_tasks(**context):
    # 假设这个函数在运行时从某个源获取分区列表
    # 但注意：这个函数本身是一个任务，它无法在DAG解析时创建新的任务节点
    partitions = context['ti'].xcom_pull(task_ids='get_partitions')
    # 实际上，你无法在这里动态创建新的Operator并加入当前DAG
    # 常见的模式是预先定义好最大可能数量的任务，然后根据条件跳过
    for p in partitions:
        # 这行代码在DAG解析时不会执行，所以无法动态创建任务
        pass

with DAG('static_dag', start_date=datetime(2023,1,1)) as dag:
    get_partitions = PythonOperator(
        task_id='get_partitions',
        python_callable=lambda: ['part_20231001', 'part_20231002'] # 模拟返回值
    )
    # 无法在此处基于get_partitions的结果动态创建后续任务

Airflow 社区为解决此类问题，引入了 Dynamic Task Mapping（自 Airflow 2.3 起）。这允许对任务进行“映射”，类似于对一组输入集合执行相同操作。

from airflow.decorators import task, dag

@dag(start_date=datetime(2023,1,1))
def dynamic_example():
    @task
    def get_partitions():
        return ['part_A', 'part_B', 'part_C']
    
    @task
    def process_partition(partition_name):
        print(f"Processing {partition_name}")
        return f"Done {partition_name}"
    
    partitions = get_partitions()
    # 使用 .expand 进行动态映射
    process_partition.expand(partition_name=partitions)

dag = dynamic_example()

虽然 Dynamic Task Mapping 是一个重要进步，但它主要解决的是“对已知列表进行并行处理”的场景，对于更复杂的、结构可能随运行时数据变化的动态工作流，其灵活性仍有边界。

1.2 Prefect 的“代码即工作流”动态性

Prefect 采用了一种根本不同的理念：工作流就是普通的 Python 代码。任务之间的依赖由函数调用关系决定，这使得动态性变得非常自然。

import prefect
from prefect import task, flow
from typing import List

@task
def get_partitions() -> List[str]:
    # 可以是从数据库、API或文件读取的真实分区列表
    return fetch_partitions_from_source()

@task
def validate_data_for_partition(partition: str) -> bool:
    # 执行针对某个分区的数据校验
    result = run_validation(partition)
    return result

@flow(name="dynamic_validation_flow")
def data_quality_flow():
    partitions = get_partitions()
    # 关键在这里：在Flow运行函数内部，基于运行时的结果创建任务
    validation_results = []
    for partition in partitions:
        # 每次循环都会创建一个新的任务实例，依赖关系自然形成
        result = validate_data_for_partition(partition)
        validation_results.append(result)
    
    # 甚至可以基于中间结果进行条件分支
    if all(validation_results):
        trigger_downstream_analysis()
    else:
        send_alert()

# 执行这个流，其内部结构会根据 get_partitions 的返回值动态变化
data_quality_flow()

核心对比：