关于 Apache Airflow 的 6 个让人不愿面对的真相（以及相关应对方式）

处理复杂数据采集流程的团队偏爱 Apache Airflow。

您可以用 Python 定义工作流，系统具备广泛的扩展能力，并提供丰富的插件生态。86% 的用户表示满意，并计划继续使用它，而非其他工作流引擎。同样比例的用户会推荐该产品。

然而，像所有软件一样，尤其是开源软件，Airflow 存在诸多缺陷和不足，需要额外弥补。对于刚接触 Airflow 的开发者而言，上手缓慢且使用过程充满挑战。本文将探讨这些问题及若干可能的解决方案。

Airflow 能干耐用，却像戴着眼罩一样，只能专注于既定路径。如果数据出现问题，Airflow 并不会纠正数据，只能调整管道。几乎每位用户都遇到过这样的情况：Airflow 显示任务已完成，但检查数据时发现缺少某列或数据根本未流经系统。

当数据组织成熟，DAG 数量从十个增加到数千个时，这种情况尤为明显。此时，您很可能用 DAG 从外部数据源和 API 采集数据，使得在 Airflow 中控制数据质量变得更加困难。您无法在源数据处“清理”数据或执行治理策略。

虽然可以通过 Slack 警报手动检查每次运行，但若要让 Airflow 成为数据工程团队的有效工具并满足 SLA，自动化质量检查是必需的。为此，您不仅需要知道任务是否执行，还要了解其执行是否正确。若执行不正确，需要追溯原因及错误来源。否则，您将不断重复同样的问题，如同“土拨鼠日”。

这并非易事，说实话，这也是 IBM® Databand® 诞生的原因。大多数产品可观测性工具（如 Datadog 和 New Relic）并非为管道分析而设计，无法追踪问题来源、将共现问题分组以确定根因，或提出修复方案。

即便在 Airflow 社区内部，对可观测性的需求仍未被充分理解。目前，只有 32% 的用户表示已实施数据质量度量，但调查提出此问题显示情况已有所改善。2019 年和 2020 年的调查中未曾涉及此问题。

在 Airflow 中应如何监控数据质量？实际上，Airflow 只能帮您完成一半工作。其维护者指出，“当工作流以代码定义时，它们更易维护、版本管理、测试及协作。”

Airflow 提供了这种正式的代码表示形式。您需要专为监控数据管道设计的可观测性工具。用于监控产品的工具只能算是权宜之计，但由于已有许可，通常仍会被使用。

我们发现，工程组织在实现完整可观测性成熟度的过程中，通常会经历几个阶段：

• 意识不足：未进行数据质量监控（占 Airflow 社区 68%）。
• 权宜之计：借用现有产品可观测性工具，使其勉强可用，但并非最优。
• 专用解决方案：使用 Databand 等全流程可观测工具，实现自动警报、根因隔离及更快的问题修复。基于预期数据参数设置机器学习，接收 Airflow Scheduler 缺失数据或模式变更的 Slack 警报，追踪问题源头，并通过历史数据进行回测。

学习 Airflow 需要投入大量时间。大量文章及 Stack Overflow 讨论记录了开发者在基础问题上遇到的困扰，例如，“为何我调度的任务未启动？”（常见解释：Airflow Scheduler 在调度时间段结束时才开始调度，而非开始时。稍后详细说明。）

此外，要精通 Airflow，必须学习 Celery Executor 及 RabbitMQ 或 Redis，这是绕不开的。

这种使用摩擦促使一些组织（如 CMS 公司 Bluecore）选择开发自定义 Airflow 界面。这样，每位新加入的开发者无需学习所有新操作符，而可使用已熟悉的 Kubernetes 操作符。

这些学习障碍反复困扰社区，以至于“入职问题”在 Airflow 2021 年社区调查中被单独列为问题（见下图）。

用户最常抱怨的问题包括“缺乏 DAG 开发最佳实践”以及“缺乏简便启动选项”。后者在 Airflow 2.0（调查后发布）中得到部分解决，但该版本在 SQLite 数据库上运行，无法并行处理，所有操作按顺序执行。Airflow 快速入门指南指出，“这非常受限”，并建议“应快速适应”。

Airflow 主要用于周期性批处理调度，而非频繁执行，其文档亦指出：“工作流大多静态或缓慢变化”。这意味着需要临时或持续采样/推送数据的场景功能有限，因此不太适合某些 ETL 或数据科学用例。

还有更多问题。我们之前提到过，Airflow Scheduler 会在调度间隔结束时（而不是开始时）运行 schedule_interval 作业，这意味着您可能需要做比预期更多的计算，有时还会因此感到意外。

为了正确执行这些计划作业，您需要掌握 Airflow 的特有细节，包括运算符与任务之间的差异、DAG 的工作原理、默认参数、Airflow 元数据数据库、用于部署 DAG 的主目录，以及其他相关内容。

破局之道？您也可以考虑加入那 6% 的 Airflow 用户——他们选择自行开发图形用户界面，并将运算符重新命名为更符合自身理解和使用习惯的术语。

你会发现，Airflow 缺少许多传统的软件开发和 DevOps 实践，其中一个非常重要的缺失点就是对数据管道进行版本维护的能力。目前并不存在一种简单的方法，可以系统性地记录你已经构建的所有内容，或在需要时回退到之前的版本。例如，如果你从 DAG 中删除某个任务并重新部署，该任务实例所关联的元数据将会丢失。

这使得 Airflow 在一定程度上显得较为脆弱；除非你自行编写脚本来捕获这些信息，否则问题排查将变得更加困难。同时，也无法基于历史数据对潜在的修复方案进行回溯测试以加以验证。

再次强调，Airflow 确实提供了形式化的代码表示方式。真正的挑战在于，如何结合其他软件开发与 DevOps 工具来弥补这些功能上的缺失。

这一点其实没什么可多说的。除非使用并不包含在主仓库中的特定 Docker Compose 文件，否则无法实现本地部署。

Airflow Scheduler 无法正常工作？那最好先给你的咖啡续一杯。因为接下来，你可能要面对一段相当耗时的调试过程。

在我们看来，原因在于 Airflow 并未充分区分负责编排的运算符与负责执行的运算符。许多运算符同时承担了这两种职责。尽管这种设计在平台早期开发阶段可能有所帮助，但从调试角度来看，却是一个致命的设计缺陷。一旦出现问题，开发人员每一次都不得不先检查 DataFlow 参数，再检查运算符本身。

正因如此，Databand 等工具往往能提供极大的帮助。Databand 擅长从多个层面帮助你全面了解基础架构的健康状况，包括：整体 Airflow、DAG、任务级别以及面向用户的层面。与其让数据工程师把时间花在学习高度特定的功能上，Databand 更能帮助他们真正专注于为业务解决问题。

如同所有花时间提出改进建议的开源贡献者一样，我们希望这篇文章被理解为一封“情书”。Databand 团队一直是 Airflow 社区的积极贡献者，也期待 Airflow 能突破现有局限，更好地服务于更多 ETL 与数据科学的使用场景。

正如前文所述，86% 的用户计划继续使用 Airflow，而非转向其他调度引擎。另有 86% 的用户表示会强烈推荐它。我们很高兴地表示，自己正是这两类用户之一——它确实是一款出色的工具。对于刚开始接触 Airflow 的读者而言，只要提前了解并意识到上述问题，Airflow Scheduler 依然非常值得投入精力。了解 Databand 如何能整合企业所有的 Airflow 可观察性活动，以简化并集中 Apache Airflow 可观察性。如果您准备深入了解，请立即预约演示。