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 很好地完成了它的工作。然而，我们必须记住，这项调查可能存在偏差——如果你喜欢你使用的工具，你更有可能回应调查。那么我们是否应该关注那 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 的使用与 Airflow Web UI 的使用是相辅相成的。我们的调查包含了一些与用户体验相关的问题，以便我们了解用户如何使用 Airflow Webserver。
您使用图形用户界面主要做什么？
您使用 CLI 主要做什么？
在 Airflow 中，哪些 UI 视图对您很重要？
在这里，我们看到大多数用户主要使用 Web UI 进行监控
- 监控 DAG
- 访问日志
一个有趣的结果是，许多人似乎不使用回填 (backfilling)，因为除了通过 CLI 之外没有其他方法可以做到这一点。
您使用哪种执行器类型？
| 序号 | % | |
|---|---|---|
| Celery | 138 | 44.81% |
| 本地 | 85 | 27.60% |
| Kubernetes | 52 | 16.88% |
| 顺序 | 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 插件？如果使用，您用它做什么？
| 序号 | % | |
|---|---|---|
| 添加新的 Operator/Sensor 和 Hook | 187 | 60.71% |
| 我不使用 Airflow 插件 | 109 | 35.39% |
| 添加 AppBuilder 视图和菜单项 | 31 | 10.06% |
| 添加新的 Executor | 18 | 5.84% |
| 添加 OperatorExtraLinks | 7 | 2.27% |
高百分比——60% 用于“添加新的 operator/sensor 和 hook”——这对我们中的一些人来说是相当令人惊讶的结果，尤其是在添加这些东西时，您实际上不需要使用插件机制。它们是标准的 Python 对象，您只需将 hook/operator/sensor 代码放在 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 Operator | 220 | 71.43% |
| 使用现有、专用的 Operator / Hook | 217 | 70.45% |
| 使用自己的、自定义的 Operator / Hook | 216 | 70.13% |
我们有一些非官方证据表明人们使用 Python/Bash Operator 比专用 Operator 更多——但看起来所有使用 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% 的人认为 Operator 应该得到扩展和改进。这表明我们应该专注于改进 Airflow 核心，而不是添加越来越多的集成。
对您来说，最有趣的功能是什么？
| 序号 | % | |
|---|---|---|
| 生产就绪的 Airflow Docker 镜像 | 175 | 56.82% |
| 声明式编写 DAG 的方式 / 自动化 DAG 生成 | 155 | 50.32% |
| 水平自动扩展 | 122 | 39.61% |
| 异步 Operator | 97 | 31.49% |
| 无状态 Web Server | 81 | 26.3% |
| Knative Executor | 48 | 15.58% |
| 我已经拥有所需的一切 | 13 | 4.22% |
生产就绪的 Docker 镜像呼声最高，这并不令人意外。我们都知道部署 Airflow 并非即插即用的过程，这也是 Jarek Potiuk 正在开发官方镜像的原因。一个意想不到的结果是，一半的用户希望有一种声明式创建 DAG 的方式。这似乎有点“违背 Airflow 的理念”，因为我们总是强调可以使用纯 Python 编写工作流。关于 DAG 生成器的故事并不新鲜，这证实了确实存在一种声明式定义 DAG 的需求。
分享