Apache Airflow(或简称Airflow)是以编程方式创作、计划和监控工作流的平台
将工作流定义为代码后,它们将变得更具可维护性、可版本化、可测试性和协作性
使用Airflow将工作流创作为任务的有向无环图(DAG)。气流调度器在遵循指定依赖关系的同时对一组工作人员执行任务。丰富的命令行实用程序使在DAG上执行复杂操作变得轻而易举。丰富的用户界面使您可以轻松地可视化生产中运行的管道、监控进度以及在需要时排除问题故障
目录
- Project Focus
- Principles
- Requirements
- Getting started
- Installing from PyPI
- Official source code
- Convenience packages
- User Interface
- Semantic versioning
- Version Life Cycle
- Support for Python and Kubernetes versions
- Contributing
- Who uses Apache Airflow?
- Who Maintains Apache Airflow?
- Can I use the Apache Airflow logo in my presentation?
- Airflow merchandise
- Links
- Sponsors
项目重点
气流与主要为静电且变化缓慢的工作流配合使用效果最好。当DAG结构从一次运行到下一次运行类似时,它允许围绕工作单元和连续性保持清晰。其他类似的项目包括Luigi,Oozie和Azkaban
Airflow通常用于处理数据,但认为任务理想上应该是幂等的(即,任务的结果将是相同的,并且不会在目标系统中创建重复数据),并且不应该将大量数据从一个任务传递到下一个任务(尽管任务可以使用Airflow的传递元数据Xcom feature)。对于大容量、数据密集型任务,最佳做法是将任务委托给专门从事该类型工作的外部服务
Airflow不是一种流解决方案,但它通常用于处理实时数据,成批地将数据从流中拉出
原则
- 动态的:气流管道配置为代码(Python),允许动态生成管道。这允许编写动态实例化管道的代码
- 可扩展的:轻松定义您自己的运算符、执行器和扩展库,使其符合适合您的环境的抽象级别
- 优雅的:气流管道是精干而清晰的。将脚本参数化内置到气流的核心中,使用功能强大的金家模板引擎
- 可扩展:Airflow采用模块化架构,并使用消息队列来编排任意数量的工作人员
要求
Apache Airflow使用以下各项进行测试:
主版本(Dev) | 稳定版本(2.1.1) | |
---|---|---|
python | 3.6、3.7、3.8、3.9 | 3.6、3.7、3.8 |
库伯内斯 | 1.20、1.19、1.18 | 1.20、1.19、1.18 |
PostgreSQL | 9.6、10、11、12、13 | 9.6、10、11、12、13 |
MySQL | 5.7,8 | 5.7,8 |
SQLite | 3.15.0+ | 3.15.0+ |
MSSQL(试验性) | 2017、2019年 |
注:MySQL5.x版本不能运行多个调度程序或有限制–请参阅Scheduler docs未测试/推荐使用MariaDB
注:SQLite用于气流测试。请不要在生产中使用它。我们建议使用SQLite的最新稳定版本进行本地开发
快速入门
访问Airflow官方网站文档(最新稳定版本)以获取以下方面的帮助installing Airflow,getting started,或通过更完整的tutorial
注意:如果您正在查找主分支(最新开发分支)的文档:您可以在s.apache.org/airflow-docs
有关气流改善建议(AIP)的更多信息,请访问Airflow Wiki
相关项目的文档,如提供程序包、Docker映像、Helm Chart,您可以在the documentation index
从PyPI安装
我们将Apache Airflow发布为apache-airflow
PyPI格式的包。然而,安装它有时可能会很棘手,因为Airflow既是一个库,也是一个应用程序。库通常使它们的依赖项保持打开,而应用程序通常将它们钉住,但是我们不应该同时做这两件事。我们决定使我们的依赖项尽可能地开放(在setup.py
),因此如果需要,用户可以安装不同版本的库。这就是说,时不时地,明摆着pip install apache-airflow
将无法工作或将产生无法使用的气流安装
但是,为了实现可重复安装,我们还在孤儿中保留了一组“已知可以工作”的约束文件constraints-main
,constraints-2-0
树枝。对于每个主要/次要Python版本,我们将那些“已知正在工作”的约束文件分开保存。从PyPI安装气流时,可以将它们用作约束文件。请注意,您必须在URL中指定正确的气流标签/版本/分支和Python版本
- 仅安装气流:
注:仅限
pip
目前官方支持安装
虽然他们使用其他工具(如poetry或pip-tools,它们共享的工作流不同于pip
-尤其是在约束与需求管理方面。通过以下方式安装Poetry
或pip-tools
当前不支持
如果要使用这些工具安装气流,则应使用约束文件并将其转换为工具所需的适当格式和工作流
pip install apache-airflow==2.1.1 \
--constraint "https://raw.githubusercontent.com/apache/airflow/constraints-2.1.1/constraints-3.7.txt"
- 使用附加软件安装(例如Postgres、Google)
pip install apache-airflow[postgres,google]==2.1.1 \
--constraint "https://raw.githubusercontent.com/apache/airflow/constraints-2.1.1/constraints-3.7.txt"
有关安装提供程序包的信息,请查看providers
官方源代码
阿帕奇气流是一种Apache Software Foundation(ASF)项目,我们的官方源代码发布:
- 请遵循ASF Release Policy
- 可从以下地址下载the ASF Distribution Directory
- 由发布管理器进行加密签名
- 是由PMC成员在选举期间正式投票表决的Release Approval Process
遵循ASF规则,发布的源包必须足以让用户构建和测试版本,前提是他们可以访问适当的平台和工具
便利套餐
还有其他安装和使用气流的方法。这些都是“方便”的方法–它们不是“官方发布”,正如ASF Release Policy
,但是它们可以由不想自己构建软件的用户使用
这些是-按照人们安装气流的最常见方式的顺序:
- PyPI releases使用标准安装风量的步骤
pip
工具 - Docker Images要通过以下方式安装风量,请执行以下操作
docker
工具,在Kubernetes,Helm图表中使用它们,docker-compose
,docker swarm
等。您可以在中阅读有关使用、自定义和扩展图像的更多信息Latest docs中的内部结构的详细信息。IMAGES.rst文档 - Tags in GitHub要检索用于通过git生成官方源码包的git项目源代码,请执行以下操作:
所有这些工件都不是官方发布的,但它们都是使用官方发布的来源准备的。其中一些工件是“开发”或“预发布”的,它们按照ASF政策被清楚地标记为“开发”或“预发布”
用户界面
- DAGS:环境中所有DAG的概述
- 树:跨时间的DAG的树表示形式
- 图表:可视化特定运行的DAG依赖项及其当前状态
- 任务工期:一段时间内花在不同任务上的总时间
- 甘特图:DAG的持续时间和重叠
- 代码:查看DAG源代码的快捷方式
语义版本化
从Airflow 2.0.0开始,我们支持严格SemVer适用于已发布的所有软件包的方法
我们几乎没有达成一致的特定规则来定义不同包的版本控制细节:
- 气流:SemVer规则仅适用于核心气流(不包括对供应商的任何更改)。更改气流依赖性版本的限制本身并不是突破性的更改
- 气流供应器:SemVer规则仅适用于特定提供程序代码中的更改。软件包的SemVer主要版本和次要版本独立于气流版本。例如
google 4.1.0
和amazon 3.0.3
提供程序可以随同安装在一起Airflow 2.1.1
如果提供程序和气流包之间存在交叉依赖限制,则它们在提供程序中显示为install_requires
限制。我们的目标是保持供应商与之前发布的所有Airflow 2版本的向后兼容性,但有时会有突破性的更改,这可能会使一些或所有供应商指定最低气流版本。更改最低支持气流版本对提供商来说是一项突破性更改,因为安装新提供商可能会自动升级气流(这可能是升级提供商的不良副作用) - 气流舵图:SemVer规则仅适用于图表中的更改。该图表的SemVer主要版本和次要版本独立于气流版本。我们的目标是保持头盔图表与所有发布的Airflow 2版本的向后兼容性,但一些新功能可能只能从特定的Airlfow版本开始工作。但是,我们可能会将舵图限制为依赖于最小气流版本
- Airflow API客户端:SemVer主要版本和次要版本跟随气流的主要版本和次要版本。气流的第一个主要或次要X.Y.0版本之后应始终跟随所有客户端的X.Y.0版本。然后,客户端可以独立于气流补丁版本,发布其自己的带有错误修复的补丁版本
版本生命周期
Apache Airflow版本生命周期:
版本 | 当前修补程序/次要修补程序 | 状态 | 第一个版本 | 有限的支持 | 停产/终止 |
---|---|---|---|---|---|
2个 | 2.1.1 | 支持 | 2020年12月17日 | 2021年12月 | 待定 |
1.10 | 1.10.15 | 停产 | 2018年8月27日 | 2020年12月17日 | 2021年6月17日 |
1.9 | 1.9.0 | 停产 | 2018年1月03日 | 2018年8月27日 | 2018年8月27日 |
1.8 | 1.8.2 | 停产 | 2017年3月19日 | 2018年1月03日 | 2018年1月03日 |
1.7 | 1.7.1.2 | 停产 | 2016年3月28日 | 2017年3月19日 | 2017年3月19日 |
有限的支持版本将仅受安全和关键错误修复支持。EOL版本将不会得到任何修复,也不会获得支持。我们始终建议所有用户针对正在使用的任何主要版本运行最新的可用次要版本。我们高度建议在最早方便的时间并在停产日期之前升级到最新的Airflow主要版本
支持Python和Kubernetes版本
从AirFlow2.0开始,我们同意使用某些规则来支持Python和Kubernetes。它们基于Python和Kubernetes的官方发布时间表,在Python Developer’s Guide和Kubernetes version skew policy
- 当Python和Kubernetes版本达到EOL时,我们不再支持它们。我们在EOL日期之后立即在Main中取消对这些EOL版本的支持,当我们发布第一个新的次要版本(或如果没有新的次要版本,则为主要版本)时,它将被有效地删除。例如,对于Python 3.6,这意味着我们在2021年12月23日之后立即在Main中停止支持,并且在此之后发布的第一个主要或次要版本将不会包含它
- 支持Python/Kubernetes的“最旧”版本是默认版本。“默认”仅在使用DockerHub中提供的此默认版本和默认参考图像运行的配置项PR中的“冒烟测试”方面有意义。目前
apache/airflow:latest
和apache/airflow:2.1.1
图像都是Python 3.6图像,但是,2021年12月23日之后的Airflow版本的第一个次要/主要版本将成为Python 3.7图像 - 正式发布后,我们在Main中支持新版本的Python/Kubernetes,一旦我们让它们在我们的CI管道中工作(这可能不是立即进行的,因为大多数情况下依赖于Python的新版本),我们就会基于工作CI设置发布新的图像/Airflow中的支持
有关Python版本要求的其他说明
- 以前的版本requires使用Python 3时至少使用Python 3.5.3
贡献
想要帮助构建Apache Airflow吗?请查看我们的contributing documentation
中描述了Apache Airflow的官方Docker(容器)图像IMAGES.rst
谁使用Apache Airflow?
400多个组织正在使用Apache Airflowin the wild
谁维护阿帕奇气流?
气流是community,但是core committers/maintainers负责审核和合并PR,并围绕新功能请求指导对话。如果您想成为一名维护员,请查看Apache Airflowcommitter requirements
我可以在演示文稿中使用Apache Airflow徽标吗?
是!一定要遵守阿帕奇基金会trademark policies和阿帕奇气流Brandbook有关最新徽标的信息,请参阅this repo和Apache软件基金会website
气流商品
如果你想要阿帕奇气流贴纸、t恤等,那就去看看吧。Redbubble Shop
链接
赞助商
Apache Airflow的CI基础设施由以下各方赞助: