问题是什么？

在 Sift，我们不断训练机器学习模型，这些模型是 Sift 的数字信任与安全平台的核心。该平台为我们的客户提供了一种区分可疑在线行为和可信行为的方法，使我们的客户能够保护其在线交易、维护其内容平台的完整性并确保其用户帐户的安全。为了实现这一点，我们构建了由 MapReduce 和 Spark 中的数百个步骤组成的模型训练管道，这些步骤之间存在复杂的依赖关系。

当我们构建这些工作流时，我们发现我们需要一种集中的方式来组织每个工作流中许多步骤之间的交互。但在使用 Airflow 之前，我们没有一种简单的方法来表达这些依赖关系。并且随着我们向工作流中添加步骤，协调它们的依赖关系并保持 ML 实验同步变得越来越困难。

很快，我们清楚地意识到，我们需要一种方法来编排作业的计划执行以及不仅是单个工作流，而且是多个工作流的步骤之间的依赖关系。我们需要一种方法来动态地一次创建多个实验性 ML 工作流，每个工作流都可以有自己的代码、依赖关系和任务。此外，我们需要一种方法来能够监控任务的状态，并轻松地从工作流中的任何给定点重新运行或重新启动任务。

Apache Airflow 如何帮助解决这个问题？

Airflow 可以轻松地清楚地定义各种作业之间的交互，从而扩展我们在模型训练管道中可以执行的操作范围。我们现在可以使用 DAG 来调度和协调所有作业，同时管理它们之间的依赖关系。我们的每个主要工作流，包括我们的模型训练管道和 ETL 管道，都有自己的 DAG 代码，用于管理其任务的依赖关系和管道的执行计划。我们甚至通过使用 Airflow 的 ExternalTaskSensor 来定义不同 DAG 之间的依赖关系。这允许我们的 DAG 真正相互依赖，并使每个 DAG 的范围都集中且紧凑。

作为我们自定义 Airflow 设置的一部分，我们还为短期的实验性 DAG 构建了一个单独的 Airflow 生态系统，以便我们可以测试对作业的更改或隔离运行单独的模型训练管道。当我们上传 DAG 到 Airflow 时，使用编辑我们 DAG 的部署脚本，为现有 DAG 提供支持的相同代码可以部署在单独的隔离环境中，并进行实验性编辑。这意味着每个实验都可以有自己隔离的代码，与其他管道并行运行，而不会意外地影响其他人的作业或依赖关系。

最后，Airflow 使我们能够通过其用户界面管理任务的成功和失败。Airflow 允许我们在一个中央 UI 中跟踪任务的失败、持续时间、历史记录和日志，并且同一个 UI 还允许我们轻松地重试单个任务、DAG 的分支或整个 DAG。

结果是什么？

Airflow 最初为我们提供了一种解决现有问题的方法：我们使用 Airflow 将僵化的 cron 作业替换为定义明确的 DAG 依赖关系，使用短期的 DAG 构建隔离的 ML 实验，并跟踪管道的成功和失败。

但即便如此，Airflow 还是帮助我们超越了最初的挑战，并扩展了我们能够切实解决的问题范围。Airflow 不仅使管理我们不断扩展的 ML 管道变得更容易，而且还允许我们创建全新的管道，从备份我们生产数据的工作流到将数据转换为可用于实验的格式的复杂 ETL 管道。

Airflow 还允许我们支持更多样化的工具集。Shell 脚本、Java、Python、Jupyter 笔记本等等 - 所有这些都可以从 Airflow DAG 进行管理，使开发人员可以轻松地利用我们的数据来测试新想法、生成见解并改进我们的模型。