问题是什么？

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

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

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

Apache Airflow 如何帮助解决此问题？

Airflow 让我们可以轻松地明确定义各个作业之间的交互，扩展了我们在模型训练管道中能够完成的工作范围。我们现在能够使用 DAG（有向无环图）来调度和协调所有作业，并管理它们之间的依赖关系。我们每个主要的工作流，包括模型训练管道和 ETL 管道，都有自己的 DAG 代码来管理任务依赖和管道的执行计划。我们甚至通过 Airflow 的 ExternalTaskSensor 在不同的 DAG 之间定义依赖关系。这使得我们的 DAG 实际上可以相互依赖，同时保持每个 DAG 的关注点明确、结构紧凑。

在我们自定义的 Airflow 设置中，我们还构建了一个针对短期实验性 DAG 的独立 Airflow 生态系统，这样我们就可以在隔离的环境中测试作业的更改或运行单独的模型训练管道。通过部署脚本在将 DAG 上传到 Airflow 时进行编辑，同一套代码既可以驱动已有的 DAG，又可以在独立的实验环境中部署带有实验性修改的版本。这意味着每个实验都拥有自己的隔离代码，可与其他管道并行运行，而不会意外影响其他作业或其依赖。

最后，Airflow 通过其用户界面让我们能够管理任务的成功与失败。Airflow 让我们在一个统一的 UI 中追踪任务的失败情况、运行时长、历史记录和日志，同一界面还可以轻松地对单个任务、DAG 的某个分支或整个 DAG 进行重试。

结果如何？

Airflow 最初为我们提供了解决现有问题的方式：我们使用 Airflow 用明确定义的 DAG 依赖取代了僵硬的 cron，构建了使用短期 DAG 的隔离机器学习实验，并跟踪管道的成功与失败。

即便如此，Airflow 仍帮助我们超越最初的挑战，扩展了我们可以实际处理的范围。Airflow 不仅让管理日益扩大的机器学习管道更加容易，还使我们能够创建全新的管道，从备份生产数据的工作流到将数据转换为实验准备格式的复杂 ETL 管道。

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