21 道最常见的 Airflow 面试题及其作答思路

Airflow 面试基础与核心概念

在技术面试中，面试官通常会从较简单的问题入手，先关注 Airflow 框架与核心概念的基础，再逐步过渡到更复杂、技术性更强的问题。

作答这些问题时，请务必不仅讨论技术细节，还要说明其如何与数据工程和/或企业级数据流程相衔接。

1. 什么是 Apache Airflow？它最常见的使用方式是什么？

回答：Apache Airflow 是一款开源的数据编排工具，数据从业者可以借助 Python 以编程方式定义数据管道。Airflow 最常被数据工程团队用于整合其数据生态，并完成数据的抽取、转换与加载。

更多说明：Airflow 以 Apache 软件许可维护（因此名称前缀带有“Apache”）。

数据编排工具提供的功能能够把多个来源与服务整合到单一的管道中。

Airflow 之所以在数据编排工具中脱颖而出，是因为其使用 Python 定义数据管道，带来了其他编排工具难以提供的可扩展性与可控性。Airflow 拥有丰富的内建与社区提供的集成工具，可融入任何团队的数据栈，同时也支持自行设计。

若想了解如何上手 Airflow，请查看这篇 DataCamp 教程：Getting Started with Apache Airflow。如果您想更深入探索 Airflow 的数据编排世界，这门Introduction to Airflow 课程是绝佳起点。

2. 什么是 DAG？

回答：DAG（有向无环图）是一组任务及其任务间关系的集合。DAG 具有明确的起点与终点，且任务之间不存在任何“环”。在 Airflow 中经常使用“DAG”一词，通常可以把它理解为一条数据管道。

更多说明：这是个有些刁钻的问题。面试官提出该问题时，既要回答 DAG 的正式“数学化”定义，也要说明它在 Airflow 中的用法。理解 DAG 时，看一张示意图很有帮助。下图一就是 DAG：它有清晰的起止点，任务之间不存在环。

下面第二个过程并不是 DAG。尽管存在明确的起始任务，但在抽取与校验任务之间形成了一个循环，使得加载任务何时被触发变得不明确。

3. 定义一个 DAG 需要哪三个参数？

回答：要定义一个 DAG，必须提供ID、开始日期和调度间隔。

更多说明：ID 用于唯一标识 DAG，通常是一个简短字符串，如 "sample_da."。开始日期指的是 DAG 首次被触发的时间区间的日期与时间。

这是一条时间戳，意味着需精确指定年、月、日、时与分。调度间隔表示 DAG 的执行频率，可以是每周、每天、每小时，或更自定义的频率。

在此示例中，DAG 使用 dag_id 为 "sample_dag"。来自 datetime 库的 datetime 函数用于将 start_date 设为 2024 年 1 月 1 日上午 9 点。该 DAG 将按 @daily 调度间隔每天（上午 9 点）运行。也可通过 cron 表达式或 datetime 库的 timedelta 函数设置更自定义的调度间隔。

with DAG(
   	 dag_id="sample_dag",
	start_date=datetime(year=2024, month=1, day=1, hour=9, minute=0),
	schedule="@daily",
) as dag:
    …
技术支持

4. 什么是 Airflow 任务？请给出三个 Airflow 任务的示例。

回答：Airflow 任务是 Airflow 框架中最小的执行单元。一个任务通常封装了数据管道（DAG）中的单一操作。任务是构建 DAG 的基石，DAG 中任务之间的关系决定了其执行顺序。三个任务示例：

• 从源系统（如 API 或平面文件）抽取数据
• 将数据转换为目标模型或格式
• 将数据加载到数据存储工具（如数据库或数据仓库）

在一条 ETL 管道中，关系通常如下：

• “transform”（转换）任务位于“extract”（抽取）任务的下游，即先执行“抽取”逻辑
• “load”（加载）任务位于“transform”（转换）任务的下游，同理将于“转换”任务之后执行

更多说明：任务既可以十分通用，也可以高度定制。Airflow 提供两种定义任务的方式：传统 Operator 与 TaskFlow API（后文详述）。

开源的一个好处是来自更广泛社区的贡献，不仅包括个人贡献者，也包括 AWS、Databricks、Snowflake 等诸多厂商。

很可能您需要的 Airflow Operator 已经存在；即便没有，也可以很容易地自定义创建。比如 SFTPToS3Operator、S3ToSnowflakeOperator 与 DatabricksRunNowOperator 等。

5. Airflow 架构的核心组件有哪些？

回答：Airflow 架构有四个核心组件：调度器（scheduler）、执行器（executor）、元数据数据库（metadata database）与 Web 服务器（webserver）。

更多说明：调度器每分钟检查 DAG 目录，并监控 DAG 与任务，以识别可被触发的任务。执行器用于运行任务。任务可以在本地（调度器内）执行，也可以在远程（调度器外）执行。

执行器承担每个任务所需的计算“工作”。元数据数据库包含与您所运行的 Airflow 项目相关的所有 DAG 与任务信息，包括历史执行详情、连接、变量以及其他大量信息。

Web 服务器用于渲染并交互 Airflow UI，便于在开发、操作与维护 DAG 时使用。

以上只是 Airflow 核心架构组件的快速概览。

Airflow DAG 面试题

如果您已经清楚表明自己掌握了 Airflow 框架与架构的基础，接下来就要考察您在 DAG 编写方面的功底了。

6. 什么是 PythonOperator？使用该 Operator 的要求是什么？在哪些场景下会用到 PythonOperator？

回答：PythonOperator 允许将一个 Python 函数作为 Airflow 任务执行。要使用该 Operator，必须向 python_callable 参数传入一个 Python 函数。一个使用场景是访问 API 抽取数据。

更多说明：PythonOperator 是 Airflow 提供的最强大的 Operator 之一。它不仅能在 DAG 中执行自定义代码，还能将结果写入 XCom，供下游任务使用。

通过向 op_kwargs 传入一个字典，可将关键字参数传给 Python callable，从而在运行时实现更灵活的定制。除了 op_kwargs 之外，还有许多参数可扩展 PythonOperator 的功能。

下面是一次 PythonOperator 的示例调用。通常，传给 python_callable 的 Python 函数定义在 DAG 定义文件之外。但此处为便于说明直接写在一起。

def some_callable(name):
print("Hello ", name)

...

some_task = PythonOperator(
task_id="some_task",
	python_callable=some_callable,
	op_kwargs={"name": "Charles"}
)
技术支持

7. 若有三个任务，希望按顺序依次执行，您会如何设置它们之间的依赖？会使用何种语法？

回答：方法有不少。最常见的是使用 >> 位移运算符。也可以使用 .set_downstream() 方法把一个任务设置为另一个任务的下游。chain 函数也是设置顺序依赖的实用工具。如下三种示例：

# task_1, task_2, task_3 已在上方实例化

# 使用位移运算符
task_1 >> task_2 >> task_3

# 使用 .set_downstream()
task_1.set_downstream(task_2)
task_2.set_downstream(task_3)

# 使用 chain
chain(task_1, task_2, task_3)
技术支持

更多说明：设置依赖有时很简单，有时会相当复杂！对于顺序执行，常用位移运算符以增强可读性。使用 TaskFlow API 时，任务之间的依赖设置看起来会有所不同。

如果两个任务存在依赖关系，可以通过把一个函数调用传入另一个函数来表示，而无需使用上述技巧。您可以在另一篇文章中进一步了解 Airflow 的任务依赖。

8. 什么是 Task Group？它们在 DAG 中如何使用？

回答：Task Group 用于在一个 DAG 中把任务进行分组，便于在 Airflow UI 中把相似任务归类展示。当在同一个 DAG 中抽取、转换、加载属于不同团队的数据时，使用 Task Group 会很有帮助。

在训练多个机器学习模型，或在单一 DAG 中与多个（但相似的）源系统交互时，也常会使用 Task Group。

在 Airflow 中使用 Task Group 后，图形视图可能类似这样：

更多说明：在传统 Airflow 语法中，使用 TaskGroup 来创建 Task Group。Task Group 可以显式或动态生成，但必须拥有唯一的 ID（类似 DAG）。

不过，同一 DAG 中的不同 Task Group 可以包含相同的 task_id。此时任务将通过 Task Group ID 与 Task ID 的组合实现唯一标识。使用 TaskFlow API 时，也可用 @task_group 装饰器创建 Task Group。

9. 如何动态生成多个 DAG，而无需复制粘贴相同代码？需要注意哪些事项？

回答：动态生成 DAG 是一种很实用的技巧，可用一段代码创建多个 DAG。比如要从多个地点拉取数据，动态创建 DAG 就很有用。如果需要以相同逻辑对三个机场执行抽取、转换、加载，动态生成 DAG 能让流程更顺畅。

实现方式有很多。其中一种最简单的方法是使用一个可迭代的元数据列表并进行循环。然后在循环中实例化 DAG。务必记住，每个 DAG 都应拥有唯一的 DAG ID。示例代码如下：

airport_codes = ["atl", "lax", "jfk"]

for code in airport_codes:
with DAG(
dag_id=f"{code}_daily_etl"
		start_date=datetime(2024, 1, 1, 9, 0),
		schedule="@daily"
) as dag:
# Rest of the DAG definition
...
技术支持

该代码会生成三个 DAG，其 ID 分别为 atl_daily_etl、lax_daily_etl 与 jfk_daily_etl。在下游，可以使用相同的机场代码对任务进行参数化，确保每个 DAG 按预期执行。

更多说明：动态生成 DAG 在企业场景中很常见。在选择是在单个 DAG 中以编程方式创建 Task Group，还是动态生成多个 DAG 时，需要考虑各操作之间的关系。

在上述示例中，如果某一个机场导致抛出异常，使用 Task Group 会导致整个 DAG 失败；而若改为动态生成 DAG，则单点故障不会殃及另外两个 DAG。

循环遍历 Python 可迭代对象并非动态生成 DAG 的唯一方法——定义 create_dag 函数、使用变量/连接生成 DAG，或借助 JSON 配置文件也很常见。第三方工具如 gusty 与 dag-factory 还提供了更多基于配置的动态生成方案。

高级 Airflow 面试题

理解并清晰表达 Airflow 与 DAG 开发的基础，往往足以满足初级岗位的要求。但要真正掌握 Airflow，不仅要会编写和运行 DAG。

下面的问题与答案将帮助您向面试官展示对 Airflow 更复杂功能的深刻理解——这通常是高级岗位所需的能力。

10. 给定 data_interval_start 与 data_interval_end, DAG 何时执行？

回答：顾名思义，data_interval_start 与 data_interval_end 是一次 DAG 运行对应的数据时间边界。如果在回填（backfill）时，当前执行时间晚于 data_interval_end，则该 DAG 会立即进入队列运行。

但在“正常”执行下，在执行时间晚于 **data_interval_end** 之前，DAG 不会运行。

更多说明：这个概念不太直观，尤其是结合 DAG 运行的标注方式来理解时。可以这样看：您想从某 API 拉取 2024 年 3 月 17 日的全部数据。

如果调度间隔为每日，那么该次运行的 data_interval_start 为 2024-03-17 00:00:00 UTC，data_interval_end 为 2024-03-18 00:00:00 UTC。若在 2024-03-17 00:00:00 UTC 运行此 DAG 并不合理，因为 3 月 17 日的数据尚未完整产生。相反，DAG 会在 data_interval_end 也就是 2024-03-18 00:00:00 UTC 执行。

11. 什么是 catchup 参数？它如何影响 Airflow DAG 的执行？

回答：catchup 参数在实例化 DAG 时定义，取值为 True 或 False，默认 True。若为 True，则从开始日期到该 DAG 首次被设为激活之间的所有 DAG 运行都会被补齐执行。

假设某 DAG 的开始日期为 2024 年 1 月 1 日，调度为每日，且 catchup=True。如果在 2024 年 4 月 15 日首次将该 DAG 设为激活，那么会从 data_interval_start 为 2024 年 1 月 1 日的运行开始执行，随后是 1 月 2 日（依此类推）。

这将持续到该 DAG“追平”为止，然后恢复正常执行。这称为“回填”。回填过程可能很快：如果一次 DAG 运行只需几分钟，那么数月的历史运行可能在数小时内完成。

若为 False，则不会执行任何历史运行，首次运行将在 DAG 状态被设为运行的那个时间区间结束时开始。

更多说明：无需对代码进行重大修改或大量人工操作即可回填，是 Airflow 最强大的特性之一。比如您要集成某 API 并拉取过去一年的所有交易记录。

当您构建好 DAG 后，只需设置合适的开始日期并设定 catchup=True，就能便捷地获取这段历史数据。

如果您在首次激活 DAG 时并不想回填，也别担心！还有多种系统化的方式可触发回填。可以使用 Airflow API 与 Airflow（以及 Astro CLI）。

12. 什么是 XCom？它通常如何使用？

回答：XCom（cross-communications 的缩写）是 Airflow 的一项更为细致的功能，允许在任务之间存储与检索消息。

XCom 以键值对形式存储，可通过多种方式读写。使用 PythonOperator 时，可在 callable 内使用 .xcom_push() 与 .xcom_pull() 方法向 XCom “推送”与“拉取”数据。XCom 用于存储小量数据，如文件名或布尔标记。

更多说明：除 .xcom_push() 与 .xcom_pull() 外，还有多种读写 XCom 的方式。使用 PythonOperator 时，将 do_xcom_push 设为 True 会把 callable 返回值写入 XCom。

这不仅限于 PythonOperator；任何返回值的 Operator 都可在将 do_xcom_push 设为 True 时把该返回值写入 XCom。底层上，TaskFlow API 在任务间传递数据时也使用 XCom（下文会提到）。

13. 请介绍 TaskFlow API，并说明它与传统 Operator 的区别。

回答：TaskFlow API 提供了一种更直观、更“Pythonic”的 DAG 编写方式。与传统 Operator 不同，它使用 @task 装饰器装饰 Python 函数，并可在无需显式定义的情况下推断任务之间的依赖。

使用 TaskFlow API 编写的任务可能如下所示：

import random

...

@task
def get_temperature():
# Pull a temperature, return the value
	temperature = random.randint(0, 100)
	return temperature
…
技术支持

借助 TaskFlow API，可以更容易地在任务之间共享数据。无需直接使用 XCom，就能将一个任务（函数）的返回值直接作为参数传入另一个任务。在此过程中，底层仍使用 XCom，因此即便使用 TaskFlow API，也无法在任务间传递大体量数据。

更多说明：TaskFlow API 旨在让 DAG 编写更为轻松，使框架更能吸引更广泛的数据科学家和分析师用户。尽管对于需要集成云数据生态的数据工程团队而言，TaskFlow API 可能并不能完全满足需求，但它对基础 ETL 任务来说尤其好用、直观。

TaskFlow API 与传统 Operator 可以在同一 DAG 中混用，既保留传统 Operator 的集成能力，又具备 TaskFlow API 的易用性。更多关于 TaskFlow API 的信息，请参阅文档。

14. 什么是幂等性（idempotency）？在构建 Airflow DAG 时为何重要？

回答：幂等性指某个过程/操作可以被多次执行而不改变初始结果。更直白地说，无论您运行 DAG 一次还是十次，结果都应完全一致。

一个常见的反例是向结构化（SQL）数据库插入数据。如果没有强制主键约束而多次运行 DAG，就可能在目标表中产生重复数据。采用删写（delete-insert）或“upsert”等模式，有助于在数据管道中实现幂等性。

更多说明：这并非 Airflow 专属概念，但在设计与构建数据管道时至关重要。幸运的是，Airflow 提供了多种工具，让实现幂等性更容易。然而，大部分相关逻辑仍需要由使用 Airflow 的从业者进行设计、开发与测试。

生产级 Airflow 工作流的管理与监控面试题

对于更技术性的岗位，面试官可能会问及如何管理与监控生产级 Airflow 部署，类似他们团队在实际运行的环境。这类问题更棘手，面试前需要更多准备。

15. 编写好 DAG 后，如何对其进行测试？请从头到尾讲述流程。

回答：编写完 DAG 后有多种测试方式。最常见的是执行一次 DAG，确保其能成功运行。这可以通过启动本地 Airflow 环境，并在 Airflow UI 中触发该 DAG 来完成。

DAG 触发后，可以监控其表现（包括 DAG 与各个任务的成功/失败，以及运行所需的时间与资源）。

除了通过执行进行手动测试外，还可以对 DAG 进行单元测试。Airflow 通过 CLI 提供了执行测试的工具，也可使用标准测试运行器。这些单元测试既可以针对 DAG 的配置与执行，也可以针对 Airflow 项目的其他组件（如 callable 与插件）。

更多说明：测试 Airflow DAG 是数据工程师最重要的工作之一。若未经过测试，DAG 就还没准备好支持生产工作负载。

测试数据管道尤其棘手；常会出现在其他开发场景中不常见的边缘与角落情况。在更技术性的面试（尤其是负责人/高级工程师）中，请务必强调端到端测试与单元测试并行推进的重要性，并记录各项测试结果。

16. 如何处理 DAG 失败？如何进行分诊并修复问题？

回答：没人喜欢 DAG 失败，但优雅地处理它能让您在数据工程师中脱颖而出。幸好，Airflow 提供了大量工具来捕获、告警并修复 DAG 失败。首先，DAG 的失败会在 Airflow UI 中被捕获。DAG 的状态会变为“failed”，在网格视图中该次运行会显示红色方块/矩形。接着，可在 UI 中手动查看该任务的日志。

通常，日志会提供导致失败的异常，并为数据工程师提供进一步分诊的信息。

定位问题后，可更新 DAG 的底层代码/配置，然后重新运行。这可以通过清除 DAG 状态并将其设置为“active”来完成。

如果某 DAG 经常失败但重试后能成功，建议使用 Airflow 的 retries 与 retry_delay 功能。这两个参数可用于在失败后等待一定时间并重试指定次数。在尝试从可能延迟落地的 SFTP 站点拉取文件等场景下会很有用。

更多说明：要使一个 DAG 失败，必然是某个具体任务失败。重要的是先分诊该任务，而非整个 DAG。除了 UI 内置功能外，还有大量工具可用于监控与管理 DAG 性能。

回调（callback）为数据工程师在处理 DAG 成功与失败时提供了几乎无限的自定义能力。通过在 Operator 上使用 on_success_callback 与 on_failure_callback 参数，可在 DAG 成功或失败时执行任意函数。该函数可以向 PagerDuty 等工具发送消息，或把结果写入数据库以便后续告警。这有助于提升可见性，并在失败发生时迅速启动分诊过程。

17. 为管理连接到数据库、API、SFTP 等工具所需的凭据，Airflow 提供了哪些功能？

回答：Airflow 最好用的工具之一是“连接”（connections）。连接允许 DAG 作者存储与访问连接信息（如主机、用户名、密码等），而无需在代码中硬编码这些值。

存储连接的方法有多种；最常见的是使用 Airflow 的 UI。连接创建后，可在代码中直接通过“hook”访问。不过，多数需要与源系统交互的传统 Operator 都提供了 conn_id（或类似名称）的字段，用于接收字符串并与目标源建立连接。

Airflow 连接既有助于保障敏感信息安全，也让存储与检索这些信息变得轻而易举。

更多说明：除了使用 Airflow UI，也可通过 CLI 存储与检索连接。在企业环境中，更常见的是使用自定义“机密后端”（secrets backend）管理连接信息。Airflow 提供了多种受支持的机密后端来管理连接。例如，使用 AWS 的公司可以轻松将 Secrets Manager 与 Airflow 集成，用于存储与检索连接和敏感信息。如有需要，也可在项目的环境变量中定义连接。

18. 您会如何将一个 Airflow 项目部署到生产级环境中运行？

回答：将 Airflow 部署到生产级环境并不容易。Azure 与 AWS 等云工具提供了受管服务来部署与管理 Airflow，但这些服务需要云账号且可能费用不菲。

一个常见替代方案是使用 Kubernetes 部署并运行生产级 Airflow 环境。这能让您完全控制底层资源，但也意味着需要承担管理基础设施的额外责任。

撇开云原生与自建 Kubernetes 部署不谈，Astronomer 是该领域最受欢迎的 Airflow 托管服务提供商。

它们除了提供开源工具（CLI、SDK、海量文档）外，还有“Astro”PaaS 产品，旨在尽可能平滑 Airflow 的开发与部署。在 Astro 中，资源分配、平台访问控制与就地 Airflow 升级都得到原生支持，让团队能将重心放回到管道开发上。

情景类 Airflow 面试题

情景题并不算特别技术化，但却是 Airflow 面试中最重要的题型之一。提供详尽而周全的回答，不仅能体现您对 Airflow 的熟练掌握，也展现您对数据架构与设计原则的深刻理解。

19. 团队目前在维护一条使用自研工具的遗留数据管道。您被指派将这条管道迁移到 Airflow。您会如何开展？

回答：这是个很有意思的问题！面对这类问题，发挥空间很大。最重要的是——在讲述过程时，请选择您熟悉的遗留数据管道中的工具与流程。这样能展现您的专业性，也让答案更有依据。

这同样是展示项目管理与领导力的绝佳机会。说明您会如何规划项目、与干系人和其他工程师协作、以及如何记录/沟通流程。这体现了您对价值交付与提升团队效率的重视。

如果公司栈里有某个特定工具（比如 Google BigQuery），不妨谈谈如何将流程从 Postgres 等迁移到 BigQuery。这不仅展现您对 Airflow 的了解，也体现您对公司其他基础设施组件的认知。

20. 设计一条 DAG：从 API 拉取数据，将响应保存为平面文件，然后加载到云数据仓库再进行转换。需要注意哪些要点？

回答：要设计这条 DAG，首先需访问 API 抽取数据。可以使用 PythonOperator 配合自定义 callable 实现。在该 callable 中，还需将数据持久化到云存储位置，例如 AWS S3。

数据持久化后，可使用现成的 Operator（如 S3ToSnowflakeOperator）将 S3 中的数据加载到 Snowflake 数据仓库。最后，使用 DbtCloudRunJobOperator 执行一个 DBT 任务对数据进行转换。

您需要按期望的频率调度该 DAG，并配置为在失败时能优雅处理（同时具备可观测性）。请看下图！

需要牢记，Airflow 同时与云存储文件系统和数据仓库交互。要使该 DAG 成功执行，这些资源需要事先存在，并应正确定义与使用连接。上述架构图中每个任务下方的图标即表示这些连接。

更多说明：这些是最常见的 Airflow 面试问题之一，更侧重于 DAG 的高层设计与实现，而非细枝末节的技术细节。面对这类问题，务必牢记以下几点：

• 确保将 DAG 拆分为清晰、独立的任务。在本例中，面试官期望看到包含三个任务的 DAG。
• 可提及用于构建该 DAG 的具体工具，但无需展开过多细节。例如，若想使用 DbtCloudRunJobOperator，可点到为止（除非被追问）。
• 别忘了提及潜在的风险点或注意事项。这能体现您在构建数据管道时，具备处理边缘与角落情况的意识与经验。

21. 除了传统的数据工程工作流外，数据团队还会以哪些方式使用 Apache Airflow？

回答：Airflow 的可扩展性与在数据社区中的日益流行，使其不再只是数据工程师的首选工具。数据科学家与机器学习工程师使用 Airflow 训练（与再训练）模型，并执行完整的 MLOps 流程。AI 工程师也开始使用 Airflow 管理与扩展其生成式 AI 模型，且不断涌现与 OpenAI、OpenSearch、Pinecone 等工具的全新集成。

更多说明：在传统数据工程管道之外大展拳脚，或许并非 Airflow 初创者当初的设想。然而，凭借 Python 与开源理念，Airflow 已成长为能满足快速演进的数据/AI 领域需求的工具。当需要对编程化任务进行调度与执行时，Airflow 很可能就是那把最趁手的利器！

结语

干得漂亮！您已经通关。以上问题虽具挑战，但覆盖了以 Airflow 为中心的技术面试中常被问及的重点。

除了温习以上问题，准备 Airflow 面试的最佳方式之一，就是亲手用 Airflow 构建数据管道。

找一个您感兴趣的数据集，从零开始构建 ETL（或 ELT）管道。练习使用 TaskFlow API 与传统 Operator。使用 Airflow 连接存储敏感信息。尝试用回调上报失败，并用单元测试与端到端测试验证 DAG。最重要的是，记录并分享您的工作成果。

这样的项目不仅能体现您对 Airflow 的熟练掌握，也能展示您学习与成长的热情与动力。若仍需回顾基础原则，可查看我们的 Introduction to Airflow in Python 课程、Airflow 与 Prefect 对比以及Getting Started with Apache Airflow 教程。

祝您好运，编码愉快！