问题是什么？

拥有数百万日活用户，Onefootball 在数据工程方面的复杂性管理是一项持续的挑战。冗长的 crontab、成倍增长的自定义 API 客户端、对提供的分析失去信心、以及日益增加的“英雄主义”（“只有某个人能解决这个问题”）——这些都是大多数团队面临的难题，除非他们有意识地在工具和流程上进行投入。

此外，每月都有新数据工具出现：第三方数据源、云服务商的解决方案、不同的存储技术……管理这些集成既昂贵又脆弱，特别是对于希望以更少资源做更多事的小型数据工程团队而言。

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

Airflow 已在我们的视野中关注了一段时间，直到有一天我们决定一试。我们采用 DAG 模式迁移了原本依赖 crontab 的流水线。借助社区提供的 Hook 和 Operator，我们删除了部分代码，或对特定业务的 API 客户端进行重构。我们使用警报、SLA 和 Web UI 重新获得对分析结果的信心，并将内部的 Airflow PR 作为团队讨论的催化剂，以挑战我们的技术设计。

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

结果如何？

学习曲线虽然陡峭，但大约 100 天后，我们已经能够高效地使用 Airflow 来管理数据工程的复杂性。目前我们拥有 17 条 DAG（平均每周新增 1 条），对 apache/airflow 贡献了 2 次，内部实现了 7 个 Hook 与 Operator，并计划在迁移工作持续进行的同时继续添加更多。