问题是什么？

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

除此之外，每个月都会出现新的数据工具：第三方数据源、云提供商解决方案、不同的存储技术……管理所有这些集成既昂贵又脆弱，特别是对于那些试图用更少资源做更多事情的小型数据工程团队而言。

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

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

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

结果如何？

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