Airflow 工作流管理平台：数据管道调度与 DAG 编排实践

Meta Description： 本文介绍 Airflow 工作流管理平台如何帮助数据团队创建、调度、监控和维护数据管道，解决 DAG 编排、任务依赖、批处理作业调度和数据流程可视化等问题。

某海外住宿平台是一家快速发展、数据驱动型公司。随着数据团队和数据规模迅速增长，我们面临的问题也变得越来越复杂。为了让不断壮大的数据工程师、数据科学家和分析师团队能够更高效地创建、调度、监控和改造数据管道，我们开发了 Airflow 这一工作流管理平台，帮助团队在快速推进工作的同时，保持数据流程的稳定和可控。

今天，我们很高兴地宣布：我们将开源并分享工作流管理平台 Airflow。

为什么数据团队需要工作流管理平台

当数据从业者开始自动化处理流程时，几乎不可避免地会编写批处理作业。这些作业需要按计划运行，通常依赖其他已有数据集，同时也会被其他作业依赖。

即便只是少数数据从业者一起工作一段时间，也很快会形成一个日益复杂的批处理计算网络。现在，想象一下：一个节奏很快的中型数据团队，在持续演进的数据基础设施上工作数年之后，会面对怎样复杂的计算作业网络。这样的复杂性可能会给数据团队带来沉重的管理负担，甚至让人难以理解整个系统到底是如何运转的。

这类作业网络通常是有向无环图，也就是 DAG。它们通常具有以下特征：

• 定时运行：每个任务都应按照预定时间间隔执行。
• 任务关键：如果部分作业未能运行，业务或数据链路就可能受到影响。
• 持续演进：随着公司和数据团队不断成熟，数据处理流程也会持续变化。
• 异构系统并存：现代分析技术栈变化很快，大多数公司都会同时运行多个需要集成的系统。

每家公司都有一个，甚至不止一个

工作流管理已经成为一种普遍需求。大多数公司都会通过多种方式在内部创建和调度作业。

最初，大家通常会使用传统的 cron 调度器。许多软件工具也会自带调度能力。再进一步，团队可能会让脚本调用其他脚本；这种方式在短期内或许可行。最终，一些简单框架会逐渐出现，用来解决作业状态存储、依赖关系管理等问题。

通常，这些解决方案都是在作业调度需求不断增长后，被动演化出来的。它们往往是因为当前系统无法轻松扩展，才被迫进入下一阶段。此外，还需要注意的是，编写数据管道的人通常并不是软件工程师。他们的主要任务和能力集中在数据处理与分析上，而不是构建工作流管理系统。

因此，如果内部开发的工作流管理系统总是至少落后于公司需求一代，那么围绕作业编写、调度和故障排查产生的摩擦，就会造成巨大的效率损耗和挫败感，让数据从业者偏离真正有价值的工作。

Airflow 如何管理数据管道与 DAG

在评估开源解决方案，并结合团队成员过去使用过的系统经验之后，我们得出结论：当时市场上没有任何一个产品能够同时满足我们当前和未来的需求。因此，我们决定构建一个现代化系统，从根本上解决这一问题。

随着项目不断推进，我们意识到，这是一个回馈开源社区的绝佳机会。我们高度依赖开源生态，也希望把自己的成果贡献回去。因此，我们决定以开源许可证发布 Airflow。

下面是公司内部一些由 Airflow 驱动的流程：

• 数据仓库：清洗、整理、校验数据质量，并将数据发布到不断增长的数据仓库中。
• 增长分析：计算围绕用户互动和增长核算的各类指标。
• 实验分析：计算 A/B 测试实验框架所需的逻辑和聚合结果。
• 邮件定向：基于规则进行邮件营销活动的用户触达与运营。
• 会话化处理：计算点击流、停留时间等数据集。
• 搜索分析：计算与搜索排序相关的指标。
• 数据基础设施维护：执行数据库抓取、目录清理、数据保留策略等任务。

Airflow 架构：DAG、调度器与元数据存储

如果说英语是商业世界的通用语言，那么 Python 已经稳固地成为数据领域的通用语言。Airflow 从一开始就使用 Python 构建，并以符合 Python 习惯的方式设计。它的代码库可扩展、文档完善、风格一致，经过代码检查，并拥有较高的单元测试覆盖率。

数据管道本身也使用 Python 编写。这意味着，我们可以很自然地从配置文件或其他任何元数据源生成动态管道。“配置即代码”是我们坚持的重要原则。

当然，使用 YAML 或 JSON 这类作业配置，也可以让用户通过任何语言生成 Airflow 管道。但我们认为，这种转换过程会损失一部分灵活性。能够直接内省代码，例如使用交互式 Python 环境或 IDE；能够进行子类化、元编程，并利用导入库辅助编写管道，这些能力都带来了很大价值。

需要说明的是，只要你编写的 Python 代码能够解释这些配置，你仍然可以使用任何语言或标记语言来描述作业。

虽然只需要几个命令就能开始使用 Airflow，但完整架构通常包含以下组件：

• 存放在源代码管理系统中的作业定义；
• 功能丰富的命令行界面，用于测试、运行、回填、描述和清理 DAG 的不同部分；
• 一个用于探索 DAG 定义、依赖关系、进度、元数据和日志的 Web 应用；
• 元数据存储，通常是关系型数据库，Airflow 用它来跟踪任务实例状态和其他持久化信息；
• 一组工作进程，用于以分布式方式运行作业任务实例；
• 一个调度器进程，用于启动已经准备好运行的任务实例。

可扩展性：Hook、Operator 与 Executor

Airflow 提供了与常用数据系统交互的完整能力，也允许用户触发任意脚本。同时，它的基础模块设计也使系统非常容易扩展。

Hook 被定义为外部系统的抽象，并共享统一接口。Hook 使用集中式连接仓库，对主机、端口、登录名、密码等信息进行抽象，并暴露与这些系统交互的方法。

Operator 利用 Hook 生成特定类型的任务。这些任务在实例化后，会成为工作流中的节点。所有 Operator 都派生自 BaseOperator，并继承一系列丰富的属性和方法。Operator 主要分为三类：

• 执行某个操作，或指示另一个系统执行操作的 Operator；
• 将数据从一个系统传输到另一个系统的传输型 Operator；
• Sensor，也就是一种特殊的 Operator，会持续运行，直到某个特定条件满足为止。

Executor 实现了一套接口，使 Airflow 的各个组件，例如 CLI、调度器和 Web 服务器，能够远程运行作业。Airflow 当前提供了用于测试的 SequentialExecutor、基于线程的 LocalExecutor，以及基于分布式任务队列的 Executor。我们也计划在不久后提供更多执行方式。

Airflow Web UI：可视化监控工作流

虽然 Airflow 提供了丰富的命令行界面，但监控和交互工作流的最佳方式，仍然是使用 Web 用户界面。

通过 Web UI，用户可以轻松可视化管道依赖关系，查看任务进度，访问日志，查看相关代码，触发任务，修复误报或漏报，分析任务耗时，并全面了解不同任务通常在一天中的哪个时间完成。

此外，用户界面还提供了一些管理功能，例如管理连接、连接池，以及暂停特定 DAG 的运行。

更进一步，用户界面还包含一个数据分析区域。用户可以在其中针对已注册的连接运行 SQL 查询、浏览结果集，并创建和分享简单图表。

这个图表应用融合了图表库、管理后台 CRUD 界面，以及 Airflow 的 Hook 和宏库。URL 参数可以传递给图表中的 SQL，Airflow 宏也可以通过模板引擎使用。借助这些能力，Airflow 用户可以轻松创建和共享查询、结果集和图表。

结语：Airflow 是数据团队规模化协作的催化剂

借助 Airflow，公司内部数据从业者的工作效率和积极性都得到了显著提升。数据管道的创建流程变得更快，监控和故障排查所需的时间也大幅减少。

更重要的是，Airflow 让用户能够在更高的抽象层次上工作，从而创建可复用的构建模块、计算框架和服务。

在实际落地这类数据平台或工作流管理体系时，技术工具本身只是其中一环，团队还需要围绕目标、需求、开发、测试、发布、文档和复盘建立完整协作流程。企业可以借助 PingCode 这类智能化研发管理工具，将研发全生命周期中的需求、项目、测试、发布和 Wiki 知识沉淀串联起来；如果团队更关注通用项目协作，也可以结合 Worktile 管理任务、文档、日历、甘特图、工时和审批等协同事项，让数据基础设施建设更容易被推进和持续维护。

它不仅是一个工作流调度工具，更是推动数据团队规模化协作和持续演进的基础平台。