问题是什么？

拥有数百万的日活跃用户，管理 Onefootball 的数据工程复杂性是一项持续的挑战。冗长的 crontab、自定义 API 客户端的倍增、对分析结果的信心下降、日益增长的英雄主义（“只有一个人可以解决这个问题”）。这些是大多数团队面临的挑战，除非他们有意识地投资于他们的工具和流程。

最重要的是，每个月都会出现新的数据工具：第三方数据源、云提供商解决方案、不同的存储技术……管理所有这些集成成本高昂且脆弱，尤其是对于那些试图以更少资源做更多事情的小型数据工程团队。

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

Airflow 一直在我们的关注范围内，直到有一天我们迈出了这一步。我们使用 DAG 范式来迁移在 crontab 上运行的管道。我们受益于社区的 Hooks 和 Operators 来删除我们的部分代码，或者重构我们业务特定的 API 客户端。我们使用警报、SLAs 和 Web UI 来重新获得对分析的信心。我们使用 Airflow 内部的 PR 作为团队讨论的催化剂，并挑战我们的技术设计。

我们有 DAG 在我们的数据仓库中编排 SQL 转换，也有 DAG 在我们的 Kubernetes 集群上编排运行的函数，用于训练机器学习模型和发送每日分析电子邮件。

结果如何？

学习曲线陡峭，但在大约 100 天内，我们能够有效地使用 Airflow 来管理我们数据工程的复杂性。我们目前有 17 个 DAG（平均每周增加 1 个），我们在 apache/airflow 上有 2 个贡献，我们有 7 个内部 hooks 和 operators，并计划随着我们的迁移工作继续添加更多。