Airflow® 安装

本页面介绍了在考虑如何安装 Airflow® 时可能用到的安装选项。Airflow 由多个组件组成，通常分布在许多物理机或虚拟机上，因此根据您选择的选项，Airflow 的安装可能会非常复杂。

您还应查看安装 Airflow 时必须满足的先决条件，以及支持的版本，以了解关于 Airflow、Python 和 Kubernetes 的支持策略。

Airflow 需要安装额外的依赖项——可以通过 extras 和 providers 进行安装。

安装 Airflow 时，您需要设置数据库，并且在升级 Airflow 时必须保持数据库更新。

本地开发与测试启动

您只是想尝试 Apache Airflow 而不想处理生产环境的复杂性？如果您安装了 pipx，可以通过以下命令直接从 PyPI 安装 Airflow

pipx run apache-airflow standalone

或者使用 Astral uv 进行类似操作

uvx apache-airflow standalone

这将启动一个带有自动生成的管理员密码和 SQLite 数据库的最小化系统，以便您可以立即开始使用 Airflow。这是熟悉 Airflow 并进行试用的绝佳方式，无需搭建复杂的环境。

请注意，独立模式（standalone mode）不适用于生产环境。但它对于本地开发来说是一个简单的起点。

使用发布源代码

更多详细信息：从源码安装

此选项的最佳适用场景

目标用户

  • 熟悉从源码安装和构建软件，并且非常关注所使用软件在尽可能底层上的完整性和来源的用户。

您需要处理的事项

  • 您需要自行构建并安装 Airflow 及其组件。

  • 您应该开发并处理 Airflow 所有组件的部署。

  • 您负责设置数据库，使用 airflow db 命令创建和管理数据库模式，以及负责 Airflow 和 Airflow Providers 的自动启动、恢复、维护、清理和升级。

  • 您需要设置系统监控，以便能够观察资源并对问题做出反应。

  • 您需要根据监控反馈和循环，为安装配置和管理适当的资源（内存、CPU 等）。请参阅关于要求的说明。

Apache Airflow 社区为该方法提供的支持

  • 您拥有关于如何构建软件的说明文档，但由于您可能使用各种环境和工具，可能会遇到特定于您的部署和环境的问题，需要您自行诊断和解决。

去哪里寻求帮助

  • Slack 上的 #user-troubleshooting 频道可用于快速解决常规故障排除问题。GitHub Discussions 适合需要更深入讨论或有更多信息需要分享的情况。

  • Slack 上的 #user-best-practices 频道可用于询问和分享有关使用及部署 Airflow 的最佳实践。

  • 如果您能描述一个可重现的 Airflow 软件问题，可以在 GitHub Issues 上开启问题。

  • 如果您想为 Airflow 做出贡献，请使用 #contributors Slack 频道，该频道致力于 Airflow 本身的开发。

使用 PyPI

更多详细信息：从 PyPI 安装

此选项的最佳适用场景

  • 当您不熟悉容器和 Docker，且希望在物理机或虚拟机上安装 Apache Airflow，并且习惯使用自定义部署机制安装和运行软件时，此安装方法非常有用。

  • 唯一官方支持的安装机制是通过 pip 使用约束（constraint）机制。约束文件由 Apache Airflow 发布管理员维护，以确保您可以可重复地从 PyPI 安装带有所有 Provider 和所需依赖项的 Airflow。

  • 如果是通过 PyPI 安装，您也可以按照安装页面上的说明验证从 PyPI 下载的包的完整性和来源，但您从 PyPI 下载的软件是为您预构建好的，因此您无需自行构建，也不需要从源码构建软件。

目标用户

  • 熟悉安装和配置 Python 应用程序、管理 Python 环境、依赖项以及使用自定义部署机制运行软件的用户。

您需要处理的事项

  • 您需要自行安装 Airflow 的所有组件。

  • 您应该开发并处理 Airflow 所有组件的部署。

  • 您负责设置数据库，使用 airflow db 命令创建和管理数据库模式，以及负责 Airflow 和 Airflow Providers 的自动启动、恢复、维护、清理和升级。

  • 您需要设置系统监控，以便能够观察资源并对问题做出反应。

  • 您需要根据监控反馈和循环，为安装配置和管理适当的资源（内存、CPU 等）。

Apache Airflow 社区为该方法提供的支持

  • 您拥有关于如何安装软件的从 PyPI 安装文档，但由于您可能使用各种环境和工具，可能会遇到特定于您的部署和环境的问题，需要您自行诊断和解决。

  • 您拥有快速入门指南，其中可以看到在本地运行 Airflow 的快速入门示例，可用于快速启动 Airflow 进行本地测试和开发。然而，这仅供参考。不要指望快速入门适用于生产环境安装，如果您采用此方法，需要自行构建生产就绪的部署。

去哪里寻求帮助

  • Airflow Slack 上的 #user-troubleshooting 频道可用于快速解决常规故障排除问题。GitHub Discussions 适合需要更深入讨论或有更多信息需要分享的情况。

  • Slack 上的 #user-best-practices 频道可用于询问和分享有关使用及部署 Airflow 的最佳实践。

  • 如果您能描述一个可重现的 Airflow 软件问题，可以在 GitHub Issues 上开启问题。

使用生产级 Docker 镜像

更多详细信息：Apache Airflow Docker 镜像

此选项的最佳适用场景

当您熟悉容器/Docker 堆栈时，此安装方法非常有用。它提供了在与同一物理机或虚拟机上运行的其他软件隔离的情况下运行 Airflow 组件的能力，并能轻松维护依赖项。

这些镜像由 Apache Airflow 发布管理员构建，并使用来自 PyPI 的官方发布包和官方约束文件——与从 PyPI 安装 Airflow 时使用的相同。

目标用户

  • 熟悉容器和 Docker 堆栈，并了解如何构建自己的容器镜像的用户。

  • 如果想扩展或自定义镜像，了解如何使用约束从 PyPI 安装 Provider 和依赖项的用户。

  • 知道如何通过连接多个 Docker 容器并维护此类部署来创建 Docker 部署的用户。

您需要处理的事项

  • 如果您想添加额外的依赖项，需要能够自定义或扩展容器/Docker 镜像。您需要组装一个由多个容器组成的部署（例如使用 docker-compose），并确保它们已正确连接。

  • 您负责设置数据库，使用 airflow db 命令创建和管理数据库模式，以及负责 Airflow 和 Airflow Providers 的自动启动、恢复、维护、清理和升级。

  • 您负责管理自己的自定义项和扩展，以满足自定义依赖需求。对于官方 Airflow Docker 镜像，作为参考镜像一部分的 Airflow 和 Airflow Providers 的升级由社区处理——您需要确保在发布新版本时通过升级基础镜像来获取这些更改。但是，您有责任创建一个流水线来构建添加了自己依赖项和 Provider 的自定义镜像，并且当新版 Airflow 镜像发布时，您需要重复自定义和构建自己的镜像。

  • 您应该选择正确的部署机制。有许多可用的容器部署选项。您可以使用自己的自定义机制、自定义 Kubernetes 部署、自定义 Docker Compose、自定义 Helm charts 等，您应该根据自己的经验和预期来选择。

  • 您需要设置系统监控，以便能够观察资源并对问题做出反应。

  • 您需要根据监控反馈和循环，为安装配置和管理适当的资源（内存、CPU 等）。

Apache Airflow 社区为该方法提供的支持

  • 您拥有以下说明：构建镜像，了解如何构建和自定义您的镜像。

  • 您拥有在 Docker 中运行 Airflow指南，其中可以看到快速入门示例，可用于快速启动 Airflow 进行本地测试和开发。然而，这仅供参考。不要指望将此 docker-compose.yml 文件用于生产安装，如果您选择 Docker Compose 进行部署，则需要熟悉 Docker Compose 及其功能，并自行构建生产就绪的部署。

  • Docker 镜像由构建 Airflow 的同一批人管理，他们致力于在 Airflow 发布新功能和新能力时保持镜像更新。

去哪里寻求帮助

  • 对于有关官方 Docker 镜像的快速问题，Airflow Slack 中设有 #production-docker-image 频道。

  • Airflow Slack 上的 #user-troubleshooting 频道可用于快速解决常规故障排除问题。GitHub Discussions 适合需要更深入讨论或有更多信息需要分享的情况。

  • Slack 上的 #user-best-practices 频道可用于询问和分享有关使用及部署 Airflow 的最佳实践。

  • 如果您能描述一个可重现的 Airflow 软件问题，可以在 GitHub Issues 上开启问题。

使用官方 Airflow Helm Chart

更多详细信息：Apache Airflow Helm Chart

此选项的最佳适用场景

  • 当您不仅熟悉容器/Docker 堆栈，而且还使用 Kubernetes 并希望通过 Helm chart 使用社区管理的 Kubernetes 安装机制来安装和维护 Airflow 时，此安装方法非常有用。

  • 它不仅提供了在与同一物理机或虚拟机上运行的其他软件隔离的情况下运行 Airflow 组件并管理依赖项的能力，还提供了以标准化且由社区维护的方式更轻松地维护、配置和升级 Airflow 的能力。

  • 该 Chart 使用官方 Airflow 生产级 Docker 镜像来运行 Airflow。

目标用户

  • 熟悉容器和 Docker 堆栈，并了解如何构建自己的容器镜像的用户。

  • 如果想扩展或自定义镜像，了解如何使用约束从 PyPI 安装 Provider 和依赖项的用户。

  • 使用 Kubernetes 管理基础设施并使用 Helm Charts 管理其应用程序的用户。

您需要处理的事项

  • 如果您想添加额外的依赖项，需要能够自定义或扩展容器/Docker 镜像。您需要组装一个由多个容器组成的部署（例如使用 Docker Compose），并确保它们已正确连接。

  • 您负责设置数据库。

  • Helm Chart 会管理您的数据库模式、自动化应用程序组件的启动、恢复和重启并将它们连接起来，因此您无需为此担忧。

  • 您负责管理自己的自定义项和扩展，以满足自定义依赖需求。对于官方 Airflow Docker 镜像，作为参考镜像一部分的 Airflow 和 Airflow Providers 的升级由社区处理——您需要确保在发布新版本时通过升级基础镜像来获取这些更改。但是，您有责任创建一个流水线来构建添加了自己依赖项和 Provider 的自定义镜像，并且当新版 Airflow 镜像发布时，您需要重复自定义和构建自己的镜像。

  • 您需要设置系统监控，以便能够观察资源并对问题做出反应。

  • 您需要根据监控反馈和循环，为安装配置和管理适当的资源（内存、CPU 等）。

Apache Airflow 社区为该方法提供的支持

  • 您拥有以下说明：构建镜像，了解如何构建和自定义您的镜像。

  • 您拥有Apache Airflow Helm Chart——关于如何配置和安装 Helm Chart 的完整文档。

  • Helm Chart 由构建 Airflow 的同一批人管理，他们致力于在 Airflow 发布新功能和新能力时保持更新。

去哪里寻求帮助

  • 对于有关官方 Docker 镜像的快速问题，Airflow Slack 中设有 #production-docker-image 频道。

  • 对于有关官方 Helm Chart 的快速问题，Slack 中设有 #helm-chart-official 频道。

  • Airflow Slack 上的 #user-troubleshooting 频道可用于快速解决常规故障排除问题。GitHub Discussions 适合需要更深入讨论或有更多信息需要分享的情况。

  • Slack 上的 #user-best-practices 频道可用于询问和分享有关使用及部署 Airflow 的最佳实践。

  • 如果您能描述一个可重现的 Airflow 软件问题，可以在 GitHub Issues 上开启问题。

使用托管 Airflow 服务

请访问生态系统 (Ecosystem)页面，查找所有 Airflow 托管服务。

此选项的最佳适用场景

  • 当您更喜欢让别人为您管理 Airflow 安装时，可以使用托管 Airflow 服务。

目标用户

  • 更倾向于让别人管理 Airflow 并愿意为此付费的用户。

您需要处理的事项

  • 托管服务通常提供运行 Airflow 所需的一切。详情请参阅各托管服务的文档。

Apache Airflow 社区为该方法提供的支持

  • Airflow 社区不提供针对托管服务的任何特定文档。详情请参阅各托管服务的文档。

去哪里寻求帮助

  • 您的第一选择应该是托管服务提供的支持。Apache Airflow Slack 中有几个频道专门针对不同用户群体，如果您得出的结论是问题更多与 Airflow 本身相关，而非托管服务，则可以使用这些频道。

使用第三方镜像、Chart 和部署

请访问生态系统 (Ecosystem)页面，查找所有第三方部署选项。

此选项的最佳适用场景

  • 这些安装方法在上述官方方法均不适用或您一直以来使用这些方法时很有用。但建议您在考虑任何更改时，应考虑切换到 Apache Airflow 社区正式支持的方法或托管服务。

目标用户

  • 以往一直使用其他安装方法，或由于其他原因认为官方方法不足够的用户。

您需要处理的事项

  • 取决于第三方提供的功能。请查看该第三方的文档。

Apache Airflow 社区为该方法提供的支持

  • Airflow 社区不提供针对第三方方法的任何特定文档。详情请参阅托管服务的文档。

去哪里寻求帮助

  • 取决于第三方提供的功能。请查看您所使用的第三方部署的文档。

关于最低要求的说明

人们经常询问生产系统的 Airflow 最低要求，但这个问题无法给出简单的答案。

Airflow 可能需要的资源要求取决于许多因素，包括但不限于：

  • 您安装 Airflow 所使用的部署方式（见上文安装 Airflow 的各种方式）

  • 部署环境的需求（例如 Kubernetes、Docker、Helm 等），这些需求与 Airflow 完全独立（例如 DNS 资源、共享节点/资源），可能需要更多（或更少）的 Pod 和容器，具体取决于您对技术/云/监控集成等的选择。

  • 您的部署所运行的数据库、硬件、网络等的技术细节。

  • 您添加到 DAGs 中的代码、配置、插件、设置等的复杂性（请注意，Airflow 运行的是 DAG 作者和部署经理提供的代码）。

  • 您安装和使用的 Provider 的数量和选择（Airflow 有超过 80 个 Provider），这些由部署经理选择，使用它们可能需要更多资源。

  • 调整 Airflow 时使用的参数选择。Airflow 有许多配置参数可以根据您的需求进行微调。

  • 您运行的 DagRuns 和任务实例的数量（考虑每个任务的并行实例）。

  • 您运行的任务的复杂程度。

上述“DAG”特征会随时间变化，甚至根据一天或一周的时间而变化，因此您必须准备好持续监控系统并调整参数，以使其顺利运行。

虽然我们可以为某些开发“快速启动”提供一些特定的最低要求——例如我们的在 Docker 中运行 Airflow快速启动指南，但无法为生产系统提供任何最低要求。

考虑 Airflow 实例资源分配的最佳方式是使用过程控制理论来思考——其中有两种类型的系统：

  1. 完全可预测的系统，具有很少的控制旋钮和变量，您可以可靠地设置这些旋钮的值，并能轻易确定系统的行为。

  2. 具有多个变量的复杂系统，难以预测，您需要持续监控系统并调整旋钮，以确保系统顺利运行。

Airflow（以及通常运行在云服务上的任何现代系统，具有多个负责资源的层以及多个控制行为的参数）是一个复杂系统，它更属于第二类。如果您决定自行在生产环境中运行 Airflow，则应做好“监控/观察/调整”反馈循环的准备，以确保系统顺利运行。

拥有一个良好的监控系统，允许您监控系统并调整参数，是将其付诸实践的必要条件。

还有一些指南可以帮助您优化资源使用。 微调调度器性能 是微调调度器的一个良好起点，您还可以遵循最佳实践指南，确保以最高效的方式使用 Airflow。

此外，托管 Airflow 服务提供的一个重要价值是，它们会做出许多“主观”选择并为您微调系统，因此您无需过度担心。对于此类托管服务，通常需要调整的旋钮和做出的选择要少得多。您所支付的费用部分包含了托管服务提供商为您管理系统、提供付费支持、允许您根据需要扩展系统并分配正确资源——并遵循该服务在您所选部署类型上所做出的最佳选择。

此条目是否有帮助？