Apache Airflow 调查 2019
Apache Airflow 正在以前所未有的速度增长。因此，收集并根据用户反馈进行调整是必须的。我们创建了调查问卷，共收到了 308 份回复。下面看看谁在使用 Airflow、他们如何使用以及他们还有哪些需求。
用户概览
您当前的职业最符合哪一项？
| 否。 | % | |
|---|---|---|
| 数据工程师 | 194 | 62.99% |
| 开发者 | 34 | 11.04% |
| 架构师 | 23 | 7.47% |
| 数据科学家 | 19 | 6.17% |
| 数据分析师 | 13 | 4.22% |
| DevOps | 13 | 4.22% |
| IT 管理员 | 2 | 0.65% |
| 机器学习工程师 | 2 | 0.65% |
| 经理 | 2 | 0.65% |
| 运营 | 2 | 0.65% |
| 首席数据官 | 1 | 0.32% |
| 工程经理 | 1 | 0.32% |
| 实习生 | 1 | 0.32% |
| 产品负责人 | 1 | 0.32% |
| 量化分析师 | 1 | 0.32% |
在日常工作中，您使用 Airflow 做什么？
| 否。 | % | |
|---|---|---|
| 数据处理（ETL） | 298 | 96.75% |
| 人工智能与机器学习流水线 | 90 | 29.22% |
| 自动化 DevOps 操作 | 64 | 20.78% |
根据调查，大多数 Airflow 用户是“数据”相关人员。此外，28.57% 的受访者同时使用 Airflow 进行 ETL 和机器学习流水线，这说明这两个领域在某种程度上是相互关联的。仅有 5 位受访者只将 Airflow 用于 DevOps 操作，这意味着其余 59 位使用 DevOps 的用户也将 Airflow 用于 ETL／机器学习。
您在最大规模的 Airflow 实例中拥有多少活跃 DAG？
| 否。 | % | |
|---|---|---|
| 0-20 | 115 | 37.34% |
| 21-40 | 65 | 21.10% |
| 41-60 | 44 | 14.29% |
| 61-100 | 28 | 9.09% |
| 101-200 | 28 | 9.09% |
| 201-300 | 7 | 2.27% |
| 301-999 | 8 | 2.60% |
| 1000+ | 13 | 4.22% |
大多数用户的活跃 DAG 数量不超过 100。与此同时，也有用户的 DAG 数量达到数千，最高可达 5000。
您在单个 DAG 中使用的任务最大数量是多少？
| 否。 | % | |
|---|---|---|
| 0-10 | 61 | 19.81% |
| 11-20 | 60 | 19.48% |
| 21-30 | 31 | 10.06% |
| 31-40 | 21 | 6.82% |
| 41-50 | 26 | 8.44% |
| 51-100 | 36 | 11.69% |
| 101-200 | 28 | 9.09% |
| 201-500 | 21 | 6.82% |
| 501+ | 24 | 11.54% |
单个 DAG 的最大任务数达到 10 000（！）。任务数量取决于 DAG 的业务需求，因此很难直接判断用户的工作流是“简单”还是“复杂”。
在为新成员进行 Airflow 入职培训时，最大的难点是什么？
| 否。 | % | |
|---|---|---|
| 缺乏 DAG 开发最佳实践指南 | 160 | 51.95% |
| 关于 Airflow 各方面的教程数量不足 | 57 | 18.51% |
| 文档不够清晰 | 42 | 13.64% |
| 关于 Airflow 的博客数量少 | 6 | 1.95% |
| 其他 | 43 | 13.96% |
这是一个重要的结果。使用 Airflow 本质上是编写和调度 DAG。缺少完整的最佳实践指南是一个大问题。深入查看“其他”选项的回答，可发现：
- Airflow 的“魔法”（调度器、执行器、调度时间）难以理解
- DAG 测试不易进行且缺乏说明
- Airflow UI 需要改进。
您有多大可能向他人推荐 Apache Airflow？
| 否。 | % | |
|---|---|---|
| 非常可能 | 140 | 45.45% |
| 可能 | 124 | 40.26% |
| 中立 | 33 | 10.71% |
| 不太可能 | 8 | 2.60% |
| 非常不可能 | 3 | 0.97% |
这表明超过 85% 的用户喜欢 Airflow，说明它的工作表现不错。不过要记住，这份调查可能存在偏差——倾向于喜欢该工具的用户更愿意参与调查。我们是否应该重点关注那 11 位不喜欢 Airflow 的人？这是一个值得思考的问题。
Airflow 使用情况
在您当前的角色中，使用了哪些 Airflow 界面？
| 否。 | % | |
|---|---|---|
| 原生 Airflow 图形用户界面 | 297 | 96.43% |
| CLI | 126 | 40.91% |
| 原生 Airflow 图形用户界面、CLI | 117 | 37.99% |
| API | 60 | 19.48% |
| 原生 Airflow 图形用户界面、CLI、API | 32 | 10.39% |
| 自定义（自行开发的）Airflow 图形用户界面 | 25 | 8.12% |
可以看到，CLI 的使用往往伴随 Web UI。我们的调查包含了一些 UX 相关的问题，以帮助我们了解用户如何使用 Airflow 的 Web 服务器。
您使用图形用户界面来做什么？
您使用 CLI 来做什么？
在 Airflow 中，哪些 UI 视图对您很重要？
从结果看，大多数人主要使用 Web UI 进行监控。
- 监控 DAG
- 查看日志
有趣的结果是，很多人似乎并未使用回填功能，因为只能通过 CLI 实现。
您使用哪种执行器？
| 否。 | % | |
|---|---|---|
| Celery | 138 | 44.81% |
| Local（本地） | 85 | 27.60% |
| Kubernetes | 52 | 16.88% |
| Sequential（顺序） | 22 | 7.14% |
| 其他 | 11 | 3.57 |
其他选项大多是用户同时使用多种执行器或正在迁移的情况。相比之前Ash 的调查，Local 和 Kubernetes 执行器的使用率有所上升。
您是否在 Kubernetes 环境中部署 Airflow？
| 否。 | % | |
|---|---|---|
| 否——近期没有计划使用 Kubernetes | 88 | 28.57% |
| 是——通过 Helm Chart 或类似方式自行部署 | 65 | 21.10% |
| 尚未——但我们组织中已有 Kubernetes，未来可能迁移 | 61 | 19.81% |
| 是——使用云托管服务（Composer / Astronomer 等） | 45 | 14.61% |
| 尚未——但计划在组织内部部署 Kubernetes | 42 | 13.64% |
| 其他 | 7 | 2.27% |
最有意思的发现是，近 30% 的用户并不使用 Kubernetes，且暂无迁移计划。这意味着在构建 Airflow 2.0 时仍需考虑其他部署方式。而大约 70% 的用户已经在使用或可以接受 Kubernetes。
您是否会组合多个 DAG？
| 否。 | % | |
|---|---|---|
| 不，我不组合多个 DAG | 127 | 41.23% |
| 会，通过 SubDAG | 73 | 23.70% |
| 会，通过触发另一个 DAG | 72 | 23.38% |
| 其他 | 36 | 11.69% |
在“其他”选项中，9 位受访者明确提到使用 ExternalTaskSensor，这也可以视为通过触发其他 DAG 来实现子 DAG 的方式。
您使用 Airflow 插件吗？如果使用，主要用途是什么？
| 否。 | % | |
|---|---|---|
| 添加新的 operators / sensors 和 hooks | 187 | 60.71% |
| 我不使用 Airflow 插件 | 109 | 35.39% |
| 添加 AppBuilder 视图和菜单项 | 31 | 10.06% |
| 添加新的执行器 | 18 | 5.84% |
| 添加 OperatorExtraLinks | 7 | 2.27% |
60% 的受访者选择“添加新的 operators / sensors 和 hooks”，这出乎意料，因为实际上添加这些并不一定需要插件机制——只要将相应的 Python 对象放到 PYTHONPATH 中即可使用。这可能反映出用户缺乏最佳实践指南。
插件在添加视图和菜单项时更受欢迎——但比例仅为 10%。OperatorExtraLinks 虽然相对新颖，却几乎未被使用，这并不奇怪。
还有一点让人意外的是，有人使用插件来添加自定义执行器。我们曾考虑移除这一选项，但现在需要重新审视我们的实现方式。
您使用哪些指标来监控 Airflow？
回答多种多样。有的使用 Prometheus 等监控系统，有的则没有监控。一个有趣的回答提到了airflow_operators_metrics 解决方案。
外部服务
在您的 Airflow DAG 中使用了哪些外部服务？
| 否。 | % | |
|---|---|---|
| Amazon Web Services（AWS） | 160 | 51.95% |
| 公司内部系统 | 150 | 48.7% |
| Hadoop / Spark / Flink / 其他 Apache 软件 | 119 | 38.64% |
| Google Cloud Platform（GCP）/ Google API | 112 | 36.36% |
| 微软 Azure | 28 | 9.09% |
| 在我的 Airflow DAG 中未使用外部服务 | 18 | 5.84% |
AWS 位居首位并不意外，因为它是最成熟的云服务提供商。内部系统和其他 Apache 产品紧随其后，这与大多数用户使用 Airflow 进行 ETL 处理相吻合。
在您的 Airflow DAG 中使用了哪些外部服务？（混合供应商）
| 否。 | % | |
|---|---|---|
| Google Cloud Platform / Google API，Amazon Web Services | 44 | 14.29% |
| Amazon Web Services，Microsoft Azure | 5 | 1.62% |
| Google Cloud Platform / Google API，Microsoft Azure | 4 | 1.3% |
这一结果并不令人惊讶，因为企业通常倾向于选择单一云供应商。
您怎样与外部服务集成？
| 否。 | % | |
|---|---|---|
| 使用 Bash / Python operator | 220 | 71.43% |
| 使用已有的专用 operators / hooks | 217 | 70.45% |
| 使用自定义 operators / hooks | 216 | 70.13% |
我们有一些轶事表明，用户更倾向于使用 Python/Bash operators 而不是专用的 operators，但整体来看，所有方式的受欢迎程度相当。
可以改进的方面
在您看来，Airflow 哪些地方可以改进？
| 否。 | % | |
|---|---|---|
| 调度器性能 | 189 | 61.36% |
| Web UI | 180 | 58.44% |
| 日志、监控与告警 | 145 | 47.08% |
| 示例、操作指南、入门文档 | 143 | 46.43% |
| 技术文档 | 137 | 44.48% |
| 可靠性 | 112 | 36.36% |
| REST API | 96 | 31.17% |
| 身份认证与授权 | 89 | 28.9% |
| 外部集成（如 AWS、GCP、Apache 产品） | 49 | 15.91% |
| CLI | 41 | 13.31% |
| 我不清楚 | 5 | 1.62% |
结果相当直观：提升调度性能、优化 UI、加强监控是大家的共同诉求。但这需要配合更完善的文档与入门资源，尤其是针对新用户的引导。
另一个有趣的点是，仅有 16% 认为应当扩展和改进 operators，这表明我们应侧重于提升 Airflow 核心功能，而不是不断增加集成。
您最感兴趣的功能是什么？
| 否。 | % | |
|---|---|---|
| 生产级的 Airflow Docker 镜像 | 175 | 56.82% |
| 声明式 DAG 编写方式 / 自动生成 DAG | 155 | 50.32% |
| 水平自动扩缩容 | 122 | 39.61% |
| 异步 Operators | 97 | 31.49% |
| 无状态 Web 服务器 | 81 | 26.3% |
| Knative Executor | 48 | 15.58% |
| 我已经拥有所需的一切 | 13 | 4.22% |
生产 Docker 镜像位居首位，这并不惊讶。大家都知道部署 Airflow 并非即插即用，官方镜像正由 Jarek Potiuk 负责完善。意外的是，约有一半的用户希望拥有声明式的 DAG 创建方式。这看似与 Airflow “坚持纯 Python 编写工作流”的理念相冲突，但 DAG 生成器的需求早已存在，说明用户仍渴望一种声明式的 DAG 定义方式。
分享