问题是什么？

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

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

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

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

Airflow 使定义不同作业之间的交互变得容易，扩展了我们在模型训练管道中可以做的事情的范围。现在，我们能够使用 DAGs 安排和协调所有作业，同时管理它们之间的依赖关系。我们的每个主要工作流，包括模型训练管道和 ETL 管道，都有自己的 DAG 代码来管理其任务的依赖关系和管道的执行计划。我们甚至使用 Airflow 的 ExternalTaskSensor 来定义不同 DAGs 之间的依赖关系。这使得我们的 DAGs 能够真正相互依赖，并使每个 DAG 的范围保持专注和紧凑。

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

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

结果如何？

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

但即使在那之后，Airflow 也帮助我们超越了最初的挑战，并扩大了我们能够实际应对的范围。Airflow 不仅使管理我们不断扩大的 ML 管道变得更容易，还使我们能够创建全新的管道，从备份生产数据的工作流到将数据转换为可用于实验格式的复杂 ETL 管道。

Airflow 还使我们能够支持更多样的工具集。Shell 脚本、Java、Python、Jupyter Notebooks 等等——所有这些都可以通过 Airflow DAG 进行管理，使开发人员能够利用我们的数据轻松测试新想法、产生见解并改进我们的模型。