Apache Airflow(简称 Airflow)是一个用于以编程方式编写、调度和监控工作流的平台。
当工作流被定义为代码时,它们变得更容易维护、版本控制、测试和协作。
使用 Airflow 将工作流编写为任务的有向无环图(DAG)。Airflow 调度器在遵循指定依赖关系的同时,在一系列工作节点上执行您的任务。丰富的命令行工具使得对 DAG 进行复杂 操作变得轻而易举。直观的用户界面使得可视化生产中运行的管道、监控进度以及在需要时排除故障变得容易。
<!-- 结束 Apache Airflow,请保留此注释以允许自动更新 PyPI readme.md --> <!-- 开始由 doctoc 生成的目录,请保留此注释以允许自动更新 --> <!-- 请勿编辑此部分,而是重新运行 doctoc 以更新 -->目录
Airflow 最适合处理大多数静态且缓慢变化的工作流。当 DAG 结构在每次运行之间相似时,它可以明确工作单元和连续性。其他类似的项目包括 Luigi、Oozie 和 Azkaban。
Airflow 通常用于处理数据,但其理念是任务理想情况下应该是幂等的(即任务的结果将保持一致,不会在目标系统中创建重复数据),并且不应该在任务之间传递大量数据(尽管任务可以使用 Airflow 的 XCom 功能 传递元数据)。对于高容量、数据密集型任务,最佳实践是委托给专门处理该类型工作的外部服务。
Airflow 不是流处理解决方案,但它经常用于处理实时数据,以批处理方式从流中提取数据。
Apache Airflow 经过以下测试:
主版本(开发版) | 稳定版本(2.9.3) | |
---|---|---|
Python | 3.8, 3.9, 3.10, 3.11, 3.12 | 3.8, 3.9, 3.10, 3.11, 3.12 |
平台 | AMD64/ARM64(*) | AMD64/ARM64(*) |
Kubernetes | 1.27, 1.28, 1.29, 1.30 | 1.26, 1.27, 1.28, 1.29 |
PostgreSQL | 12, 13, 14, 15, 16 | 12, 13, 14, 15, 16 |
MySQL | 8.0, 8.4, Innovation | 8.0, Innovation |
SQLite | 3.15.0+ | 3.15.0+ |
注意: MySQL 5.x 版本无法运行多个调度器或存在限制 - 请参阅调度器文档。 不推荐使用 MariaDB。
注意: SQLite 用于 Airflow 测试。请勿在生产环境中使用。我们建议在本地开发中使用最新的稳定版 SQLite。
注意: Airflow 目前可以在符合 POSIX 标准的操作系统上运行。对于开发,它定期在相当现代的 Linux 发行版和最新版本的 macOS 上进行测试。
在 Windows 上,你可以通过 WSL2(Windows Subsystem for Linux 2)或 Linux 容器运行它。
添加 Windows 支持的工作通过 #10388 进行跟踪,但不是高优先级。你应该只使用基于 Linux 的发行版作为"生产"执行环境,因为这是唯一受支持的环境。我们的 CI 测试中使用的唯一发行版,也是社区管理的 DockerHub 镜像中使用的是 Debian Bookworm
。我们还支持传统的 Debian Bullseye
基础镜像,如果你想构建自定义镜像,但它已被弃用,并且在随 Airflow 2.9.3 一起提供的 Dockerfile 中将删除该选项,因此建议你为自定义镜像切换到 Debian Bookworm
。
访问官方 Airflow 网站文档(最新稳定版本)以获取有关安装 Airflow、入门或完成更完整教程的帮助。
注意:如果你正在寻找主分支(最新开发分支)的文档:你可以在 s.apache.org/airflow-docs 找到它。
有关 Airflow 改进提案(AIP)的更多信息,请访问 Airflow Wiki。
对于提供程序包、Docker 镜像、Helm Chart 等相关项目的文档,你可以在文档索引中找到。
我们将 Apache Airflow 作为 apache-airflow
包发布在 PyPI 上。然而,安装它有时可能会比较棘手,因为 Airflow 既是库又是应用程序。库通常保持依赖项开放,而应用程序通常固定它们,但我们既不应该这样做,又应该同时这样做。我们决定尽可能保持依赖项开放(在 pyproject.toml
中),以便用户可以在需要时安装不同版本的库。这意味着 pip install apache-airflow
有时可能无法正常工作或会产生不可用的 Airflow 安装。
然而,为了实现可重复安装,我们在孤立的 constraints-main
和 constraints-2-0
分支中保留了一组"已知可用"的约束文件。我们为每个主要/次要 Python 版本单独保留这些"已知可用"的约束 文件。
从 PyPI 安装 Airflow 时,可以将它们用作约束文件。请注意,你必须在 URL 中指定正确的 Airflow 标签/版本/分支和 Python 版本。
注意:目前仅官方支持
pip
安装。
虽然可以使用 Poetry 或 pip-tools 等工具安装 Airflow,但它们与 pip
的工作流程不同 - 尤其是在约束与需求管理方面。
目前不支持通过 Poetry
或 pip-tools
安装。
使用 bazel
安装 Airflow 时存在已知问题,可能会导致循环依赖。如果遇到此类问题,请切换到 pip
。Bazel
社区正在 这个 PR <https://github.com/bazelbuild/rules_python/pull/1166>
_ 中修复这个问题,因此较新版本的 bazel
可能会处理这个问题。
如果你希望使用这些工具安装 Airflow,应该使用约束文件并将它们转换为你的工具所需的适当格式和工作流程。
pip install 'apache-airflow==2.9.3' \ --constraint "https://raw.githubusercontent.com/apache/airflow/constraints-2.9.3/constraints-3.8.txt"
pip install 'apache-airflow[postgres,google]==2.8.3' \ --constraint "https://raw.githubusercontent.com/apache/airflow/constraints-2.9.3/constraints-3.8.txt"
有关安装提供程序包的信息,请查看 providers。
Apache Airflow 是 Apache 软件基金会 (ASF) 的项目,我们的官方源代码发布:
还有其他安装和使用Airflow的方法。这些是"便利"方法 - 它们不是ASF发布政策所述的"官方发布",但可以被不想自己构建软件的用户使用。
这些方法按照人们安装Airflow最常见的方式排序如下:
所有这些制品都不是官方发布,但它们是使用官方发布的源码准备的。其中一些制品是"开发"或"预发布"版本,并按照ASF政策明确标记。
DAGs:环境中所有DAG的概览。
网格:跨时间的DAG网格表示。
图表:特定运行的DAG依赖关系及其当前状态的可视化。
任务持续时间:不同任务随时间花费的总时间。
甘特图:DAG的持续时间和重叠。
代码:查看DAG源码的快速方式。
从Airflow 2.0.0开始,我们对所有发布的包采用严格的SemVer方法。
我们同意了一些特定规则,定义了不同包版本控制的细节:
Apache Airflow版本生命周期:
(表格内容略)
有限支持版本将只获得安全和关键错误修复支持。 EOL版本将不会获得任何修复或支持。 我们始终建 议所有用户运行所使用的任何主版本的最新可用次要版本。 我们强烈建议在最方便的时间和EOL日期之前升级到最新的Airflow主版本。
从Airflow 2.0开始,我们同意了某些规则,用于Python和Kubernetes支持。这些规则基于Python和Kubernetes的官方发布计划,在Python开发者指南和Kubernetes版本偏差政策中有很好的总结。
当Python和Kubernetes版本达到EOL时,我们会停止对它们的支持。对于Kubernetes,如果两个主要云提供商仍然支持某个版本,Airflow就会继续支持它。我们在EOL日期后立即在主分支中停止对这些EOL版本的支持,并在发布Airflow的第一个新的次要版本(或者如果没有新的次要版本,则在主要版本)时有效移除。例如,对于Python 3.8,这意味着我们将在2023年6月27日之后立即在主分支中停止支持,之后发布的第一个Airflow主要或次要版本将不会包含它。
我们在Python/Kubernetes官方发布后,会在主分支中支持新版本。一旦我们使其在CI管道中正常运行(由于依赖项需要时间来适应新版本的Python,这可能不会立即实现),我们就会基于可正常运行的CI设置发布新的镜像/支持。
这项政策是尽力而为的,这意味着在某些情况下,如果环境需要,我们可能会提前终止支持。
Airflow社区提供了方便打包的容器镜像,这些镜像在发布Apache Airflow版本时同步发布。这些镜像包含:
基础操作系统镜像的版本是Debian的稳定版。Airflow支持使用所有当前活跃的稳定版本——只要所有Airflow依赖项支持构建,并且我们为构建和测试该操作系统版本设置了CI管道。在前一个稳定操作系统版本常规支持结束约6个月前,Airflow会将发布的镜像切换到最新支持的操作系统版本。
例如,由于Debian Buster
的生命周期在2022年8月结束,Airflow在2022年2月/3月将main
分支中的镜像切换为使用Debian Bullseye
。这个版本在切换后的下一个MINOR版本中使用。对于Bullseye切换,2.3.0版本使用了Debian Bullseye
。前一个MINOR版本发布的镜像继续使用该MINOR版本的所有其他发布所使用的版本。类似地,从Debian Bullseye
到Debian Bookworm
的切换在2023年10月的2.8.0版本发布之前实施,并且从Airflow 2.9.0开始,Debian Bookworm
将成为唯一支持的选项。
用户将能够继续使用稳定的Debian发行版构建他们的镜像,直到常规支持结束,并且在我们的CI中进行镜像的构建和验证,但在main
分支中不会使用这个镜像执行单元测试。
Airflow有许多直接和间接的依赖项,而且Airflow既是库又是应用程序,因此我们的依赖项政策必须同时考虑应用程序安装的稳定性和为开发DAG的用户提供升级依赖项的能力。我们开发了一种使用约束
的方法,确保Airflow可以以可重复的方式安装,同时不限制用户升级大多数依赖项。因此,我们决定默认不对Airflow依赖项设置上限版本,除非我们有充分理由认为由于依赖项的重要性以及升级特定依赖项的风险,需要设置上限。我们也会对已知会造成问题的依赖项设置上限。
我们的约束机制会自动查找和升级所有没有设置上限的依赖项(前提是所有测试都通过)。如果有依赖项的版本导致我们的测试失败,我们的main
构建会失败,这表明我们应该为它们设置上限或者修改我们的代码/测试以适应这些依赖项的上游变化。
每当我们为依赖项设置上限时,我们都应该解释这样做的原因——也就是说,我们应该有充分的理由来设置上限。我们还应该提及移除该限制的条件。
这些依赖项在pyproject.toml
中维护。
有几个依赖项我们认为足够重要,需要默认设置上限版本,因为它们遵循可预测的版本控制方案,并且我们知道这些依赖项的新版本很可能带来重大变化。我们承诺定期审查并尝试升级到这些依赖项的新版本,但这是一个手动过程。
重要的依赖项包括:
SQLAlchemy
:限制到特定的MINOR版本(SQLAlchemy已知会移除废弃功能并引入重大变化,特别是对不同数据库的支持会以不同速度变化和改变)Alembic
:以可预测和高效的方式处理我们的迁移很重要。它与SQLAlchemy一起开发。我们的经验表明,Alembic在MINOR版本中非常稳定Flask
:我们使用Flask作为Web UI和API的骨干。我们知道Flask的主要版本很可能在这些版本之间引入重大变化,所以将其限制在MAJOR版本内是有意义的werkzeug
:这个库在新版本中已知会引起 问题。它与Flask库紧密耦合,我们应该一起更新它们celery
:Celery是Airflow的一个关键组件,因为它用于CeleryExecutor(及类似执行器)。Celery遵循SemVer,所以我们应该将其上限设置为下一个MAJOR版本。此外,当我们提高库的上限版本时,应确保更新Celery Provider的最低Airflow版本要求kubernetes
:Kubernetes是Airflow的一个关键组件,因为它用于KubernetesExecutor(及类似执行器)。Kubernetes Python库遵循SemVer,所以我们应该将其上限设置为下一个MAJOR版本。此外,当我们提高库的上限版本时,应确保更新Kubernetes Provider的最低Airflow版本要求Airflow的主要部分是Airflow Core,但Airflow的强大功能还来自于许多扩展核心功能的providers,这些providers单独发布,即使为了方便,我们目前将它们保存在同一个monorepo中。你可以在Providers文档中阅读更多关于providers的信息。我们还在providers文档中实施了一系列政策,用于维护和发布社区管理的providers,以及处理社区vs第三方providers的方法。
这些extras
和providers
依赖项在每个provider的provider.yaml
中维护。
默认情况下,我们不应该为providers设置依赖项的上限版本,但每个provider的维护者可以决定添加额外的限制(并用注释解释原因)。
想要帮助构建Apache Airflow吗?查看我们的贡献文档。
Apache Airflow的官方Docker(容器)镜像在images中描述。
+1
都被视为有约束力的投票。我们知道大约有500个组织正在使用Apache Airflow(实际上可能还有更多)。
如果您使用Airflow,欢迎提交PR将您的组织添加到列表中。
Airflow是社区的作品,但核心提交者/维护者负责审查和合并PR,以及引导关于新功能请求的讨论。如果您想成为维护者,请查看Apache Airflow的提交者要求。
通常您会看到一个问题被分配到特定的里程碑和Airflow版本,或者一个PR被合并到主分支,您可能会想知道这些合并的PR会在哪个版本发布,或者修复的问题会在哪个版本中。这个问题的答案通常是 - 取决于各种情况。PR和问题的答案是不同的。
为了增加一些背景,我们遵循Semver版本控制方案,如Airflow发布流程中所述。更多细节在本README的语义版本控制章节中有详细解释,简而言之,我们有Airflow的MAJOR.MINOR.PATCH版本。
通常,我们从以MINOR版本命名的分支发布Airflow的MINOR版本。例如,2.7.*版本从v2-7-stable分支发布,2.8.*版本从v2-8-stable分支发布,等等。
在我们的发布周期中,大多数时候,当下一个MINOR分支还没有创建时,所有合并到main的PR(除非被撤销)都会进入下一个MINOR版本。例如,如果最新版本是2.7.3,而v2-8-stable分支还没有创建,那么下一个MINOR版本是2.8.0,所有合并到main的PR都会在2.8.0中发布。然而,一些PR(bug修复和仅文档变更)在合并后,可以被cherry-pick到当前的MINOR分支,并在下一个PATCHLEVEL版本中发布。例如,如果2.8.1已经发布,我们正在开发2.9.0dev,那么将PR标记为2.8.2里程碑意味着它将被cherry-pick到v2-8-test分支,并在2.8.2rc1中发布,最终在2.8.2中发布。
当我们准备下一个MINOR版本时,我们会切出新的v2--test和v2--stable分支,并准备下一个MINOR版本的alpha、beta版本,合并到main的PR仍然会在下一个MINOR版本中发布,直到rc版本被切出。这是因为在准备下一个beta和rc版本时,v2--test和v2--stable分支会在main的基础上重新基准。例如,当我们切出2.10.0beta1版本时,在2.10.0rc1发布之前合并到main的任何内容都会进入2.10.0rc1。
然后,一旦我们准备了MINOR版本的第一个RC候选版本,我们就停止移动v2--test和v2--stable分支,合并到main的PR将在下一个MINOR版本中发布。然而,一些PR(bug修复和仅文档变更)在合并后,可以被cherry-pick到当前的MINOR分支,并在下一个PATCHLEVEL版本中发布 - 例如,当v2-10-stable分支的最后发布版本是2.10.0rc1时,一些来自main的PR可以被提交者标记为2.10.0里程碑,发布经理将尝试将它们cherry-pick到发布分支。如果成功,它们将在2.10.0rc2中发布,随后在2.10.0中发布。这也适用于后续的PATCHLEVEL版本。例如,当2.10.1已经发布时,将PR标记为2.10.2里程碑意味着它将被cherry-pick到v2-10-stable分支,并在2.10.2rc1中发布,最终在2.10.2中发布。
关于cherry-picking的最终决定由发布经理做出。
用里程碑标记问题有点不同。维护者通常不会用里程碑标记问题,通常只在PR中标记。如果链接到问题(并"修复它")的PR按照上述过 程被合并并在特定版本中发布,问题将自动关闭,不会为问题设置里程碑,你需要查看修复该问题的PR以了解它在哪个版本中发布。
然而,有时维护者会用特定的里程碑标记问题,这意味着该问题很重要,成为在准备发布时需要关注的候选问题。由于这是一个开源项目,基本上所有贡献者都是自愿贡献时间,所以不能保证特定问题会在特定版本中得到修复。我们不希望因为某个问题没有修复而延迟发布,所以在这种情况下,如果问题没有及时修复,发布经理会将这些未修复的问题重新分配到下一个里程碑。因此,问题的里程碑更多的是一种应该关注的意图,而不是承诺它将在该版本中修复。
关于补丁级别发布的更多背景和FAQ可以在存储库dev文件夹中的"下一个版本会包含什么"文档中找到。
可以!请确保遵守Apache基金会的商标政策和Apache Airflow的品牌手册。最新的logo可以在这个存储库和Apache软件基金会网站上找到。
Apache Airflow的CI基础设施由以下机构赞助: <a href="https://astronomer.io"><img src="https://yellow-cdn.veclightyear.com/835a84d5/068b620f-a8db-4954-9ef9-5dd251aa6fd5.png" alt="astronomer.io" width="250px"></a> <a href="https://aws.amazon.com/opensource/"><img src="https://yellow-cdn.veclightyear.com/835a84d5/7da836d2-a7d5-41bf-ade8-980204d54e5e.png" alt="AWS开源" width="130px"></a>
<!-- 遥测/分析像素: --> <img referrerpolicy="no-referrer-when-downgrade" src="https://yellow-cdn.veclightyear.com/835a84d5/5ae324f4-917c-4f7f-a552-25161bc5e91a.png?x-pxid=1b5a5e3c-da81-42f5-befa-42d836bf1b54" alt="追踪像素" />字节跳动发布的AI编程神器IDE
Trae是一种自适应的集成开发环境(IDE),通过自动化和多元协作改变开发流程。利用Trae,团队能够更快速、精确地编写和部署代码,从而提高编程效率和项目交付速度。Trae具备上下文感知和代码自动完成 功能,是提升开发效率的理想工具。
全能AI智能助手,随时解答生活与工作的多样问题
问小白,由元石科技研发的AI智能助手,快速准确地解答各种生活和工作问题,包括但不限于搜索、规划和社交互动,帮助用 户在日常生活中提高效率,轻松管理个人事务。
实时语音翻译/同声传译工具
Transly是一个多场景的AI大语言模型驱动的同声传译、专业翻译助手,它拥有超精准的音频识别翻译能力,几乎零延迟的使用体验和支持多国语言可以让你带它走遍全球,无论你是留学生、商务人士、韩剧美剧爱好者,还是出国游玩、多国会议、跨国追星等等,都可 以满足你所有需要同传的场景需求,线上线下通用,扫除语言障碍,让全世界的语言交流不再有国界。
一键生成PPT和Word,让学习生活更轻松
讯飞智文是一个利用 AI 技术的项目,能够帮助用户生成 PPT 以及各类文档。无论是商业领域的市场分析报告、年度目标制定,还是学生群体的职业生涯规划、实习避坑指南,亦或是活动策划、旅游攻略等内容,它都能提供支持,帮助用户精准表达,轻松呈现各种信息。
深度推理能力全新升级,全面对标OpenAI o1
科大讯飞的星火大模型,支持语言理解、知识问答和文本创作等多功能,适用于多种文件和业务场景,提升办公和日常生活的效率。讯飞星火是一个提供丰富智能服务的平台,涵盖科技资讯、图像创作、写作辅助、 编程解答、科研文献解读等功能,能为不同需求的用户提供便捷高效的帮助,助力用户轻松获取信息、解决问题,满足多样化使用场景。
一种基于大语言模型的高效单流解耦语音令牌文本到语音合成模型
Spark-TTS 是一个基于 PyTorch 的开源文本到语音合成项目,由多个知名机构联合参与。该项目提供了高效的 LLM(大语言模型)驱动的语音合成方案,支持语音克隆和语音创建功能,可通过命令行界面(CLI)和 Web UI 两种方式使用。用户可以根据需求调整语音的性别、音高、速度等参数,生成高质量的语音。该项目适用于多种场景,如有声读物制作、智能语音助手开发等。
AI助力,做PPT更简单!
咔片是一款轻量化在线演示设计工具,借助 AI 技术,实现从内容生成到智能设计的一站式 PPT 制作服务。支持多 种文档格式导入生成 PPT,提供海量模板、智能美化、素材替换等功能,适用于销售、教师、学生等各类人群,能高效制作出高品质 PPT,满足不同场景演示需求。
选题、配图、成文,一站式创作,让内容运营更高效
讯飞绘文,一个AI集成平台,支持写作、选题、配图、排版和发布。高效生成适用于各类媒体的定制内容,加速品牌传播,提升内容营销效果。
专业的AI公文写作平台,公文写作神器
AI 材料星,专业的 AI 公文写作辅助平台,为体制内工作人员提供高效的公文写作解决方案。拥有海量公文文库、9 大核心 AI 功能,支持 30 + 文稿类型生成,助力快速完成领导讲话、工作总结、述职报告等材料,提升办公效率,是体制打工人的得力写作神器。
OpenAI Agents SDK,助力开发者便捷使用 OpenAI 相关功能。
openai-agents-python 是 OpenAI 推出的一款强大 Python SDK,它为开发者提供了与 OpenAI 模型交互的高效工具,支持工具调用、结果处理、追踪等功能,涵盖多种应用场景,如研究助手、财务研究等,能显著提升开发效率,让开发者更轻松地利用 OpenAI 的技术优势。