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 和 ML 管道，这意味着这两个领域在某种程度上是相关的。只有五名受访者仅将 Airflow 用于 DevOps 操作，这意味着其他 59 名使用 Airflow 进行 DevOps 工作的人也将其用于 ETL/ML 目的。
在您最大的 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% |
大多数用户每个 Airflow 实例的活跃 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。没有关于开发 DAG 的最佳实践的指南或任何其他完整的资源是一个大问题。深入研究“其他”答案，我们可以发现
- Airflow 的“魔力”（调度程序、执行器、调度时间）很难理解
- DAG 测试不容易完成和解释
- Airflow UI 需要改进。
您有多大可能推荐 Apache Airflow？
| 编号 | % | |
|---|---|---|
| 非常有可能 | 140 | 45.45% |
| 有可能 | 124 | 40.26% |
| 中立 | 33 | 10.71% |
| 不太可能 | 8 | 2.60% |
| 非常不可能 | 3 | 0.97% |
这意味着超过 85% 的使用 Airflow 的人都喜欢它。似乎 Airflow 确实做得很好。但是，我们必须记住，此调查可能存在偏差 - 如果您喜欢使用的工具，则更有可能回复调查。那么我们应该关注那些不喜欢 Airflow 的 11 个人吗？这是一个好问题。
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 的使用与使用 Airflow Web UI 是同步的。我们的调查包含一些与 UX 相关的问题，以使我们了解用户如何使用 Airflow Web 服务器。
您将图形用户界面用于什么？
您将 CLI 用于什么？
在 Airflow 中，哪个 UI 视图对您来说很重要？
在这里，我们看到大多数人主要将 Web UI 用于监控目的
- 监控 DAG
- 访问日志
一个有趣的结果是，许多人似乎没有使用回填，因为除了通过 CLI 进行回填之外，没有其他方法。
您使用哪种执行器类型？
| 编号 | % | |
|---|---|---|
| Celery | 138 | 44.81% |
| 本地 | 85 | 27.60% |
| Kubernetes | 52 | 16.88% |
| 顺序 | 22 | 7.14% |
| 其他 | 11 | 3.57 |
其他选项主要包含有人使用几种类型或正在从一个执行器迁移到另一个执行器的信息。可以观察到，与早些时候 Ash 做的调查 的结果相比，本地和 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 插件？如果是，您将其用于什么？
| 编号 | % | |
|---|---|---|
| 添加新的运算符/传感器和钩子 | 187 | 60.71% |
| 我不使用 Airflow 插件 | 109 | 35.39% |
| 添加 AppBuilder 视图和菜单项 | 31 | 10.06% |
| 添加新的执行器 | 18 | 5.84% |
| 添加 OperatorExtraLinks | 7 | 2.27% |
“添加新的运算符/传感器和钩子”的高百分比 - 60% 对我们中的一些人来说是一个相当令人惊讶的结果 - 特别是您实际上不需要使用插件机制来添加任何这些。这些是标准的 python 对象，您可以简单地将您的钩子/运算符/传感器代码放入 PYTHONPATH 环境变量中，它们就可以工作。似乎这可能是缺乏最佳实践指南的结果。
插件对于添加视图和菜单项更有用 - 但只有 10%。OperatorExtraLinks 是一种更有用的（尽管相对较新的）功能，因此它们很少使用并不完全令人惊讶。
有人完全使用插件来使用自己的执行器也令人有点惊讶。我们最近考虑删除该选项 - 但现在我们必须重新考虑我们的方法。
您使用哪些指标来监控 Airflow？
有很多不同的回复。有些人使用 Prometheus 和其他服务，有些人不使用任何监控。其中一个有趣的回复链接到了这个 airflow_operators_metrics 解决方案。
外部服务
您在 Airflow DAG 中使用哪些外部服务？
| 编号 | % | |
|---|---|---|
| Amazon Web Services | 160 | 51.95% |
| 公司内部系统 | 150 | 48.7% |
| Hadoop/Spark/Flink/其他 Apache 软件 | 119 | 38.64% |
| Google Cloud Platform/Google API | 112 | 36.36% |
| Microsoft Azure | 28 | 9.09% |
| 我不在 Airflow DAG 中使用外部服务 | 18 | 5.84% |
Amazon Web Services 处于领先地位并不奇怪，因为它们被认为是发展最成熟的云提供商。如果我们考虑到大多数人将 Airflow 用于 ETL 流程，那么内部系统和其他 Apache 产品排在前两位是相当容易理解的。
您在 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 操作符 | 220 | 71.43% |
| 使用现有的、专用的操作符/钩子 | 217 | 70.45% |
| 使用自定义的操作符/钩子 | 216 | 70.13% |
我们有一些轶事证据表明，人们使用 Python/Bash 操作符比专用操作符更多——但看起来所有使用 Airflow 连接到外部服务的方式都同样受欢迎。
可以改进什么
您认为 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% |
结果相当不言自明。Airflow 的性能提升、更好的 UI 以及更多的遥测数据是大家所期望的。但这应该与改进 Airflow 的文档和使用资源相结合，尤其是在考虑到新用户入门的问题时。
这个问题的另一个有趣的观点是，只有 16% 的人认为应该扩展和改进操作符。这表明我们应该专注于改进 Airflow 的核心，而不是添加越来越多的集成。
对您来说，最有趣的功能是什么？
| 编号 | % | |
|---|---|---|
| 生产就绪的 Airflow Docker 镜像 | 175 | 56.82% |
| 编写 DAG 的声明式方法/自动生成 DAG | 155 | 50.32% |
| 水平自动伸缩 | 122 | 39.61% |
| 异步操作符 | 97 | 31.49% |
| 无状态 Web 服务器 | 81 | 26.3% |
| Knative 执行器 | 48 | 15.58% |
| 我已经拥有我所需要的一切 | 13 | 4.22% |
生产 Docker 镜像胜出，这并不令人意外。我们都知道部署 Airflow 不是一个即插即用的过程，这就是为什么 Jarek Potiuk 正在开发官方镜像。一个意想不到的结果是，一半的用户希望有一种声明式的方式来创建 DAG。这似乎与 “Airflow 的宗旨” 相悖，因为我们一直强调用纯 Python 编写工作流的可能性。关于 DAG 生成器的讨论并不新鲜，并证实了对声明 DAG 的方式的需求。
分享