Apache Airflow 2.0 新特性一览

今天有空对大约半年前的Apache Airflow 2.0 的Release文档做一个整理,主要的文章的内容来自于Apache Airflow官方的Apache Airflow 2.0 is here!和Astronomer(Apache Airflow云服务提供商)的Introducing Airflow 2.0.
主要以官方文档为主,以翻译+注解的方式来说明Apache Airflow 2.0 版本的新特性.

A new way of writing dags: the TaskFlow API (AIP-31)

TaskFlow API(AIP-31): 一种新的编写dags的方式
DAGs现在更容易进行编写,特别是在使用到PythonOperator的时候.任务之间的依赖更清楚,XCom更加的好用.
使用TaskFlow API来编写dag的案例如下:

from airflow.decorators import dag, task
from airflow.utils.dates import days_ago

@dag(default_args={'owner': 'airflow'}, schedule_interval=None, start_date=days_ago(2))
def tutorial_taskflow_api_etl():
   @task
   def extract():
       return {"1001": 301.27, "1002": 433.21, "1003": 502.22}

   @task
   def transform(order_data_dict: dict) -> dict:
       total_order_value = 0

       for value in order_data_dict.values():
           total_order_value += value

       return {"total_order_value": total_order_value}

   @task()
   def load(total_order_value: float):

       print("Total order value is: %.2f" % total_order_value)

   order_data = extract()
   order_summary = transform(order_data)
   load(order_summary["total_order_value"])

tutorial_etl_dag = tutorial_taskflow_api_etl()

从上面的代码可以看到,编写airflow的task变得更为简单,只需要在dag 和 task都只需要在方法上面添加注解就行,极大的提高了生产力,很棒.
更多详细的信息请参考:
TaskFlow API Tutorial
TaskFlow API Documentation

Fully specified REST API (AIP-32)

完全可用的REST API(AIP-32)
我们现在有一个完全可用的,不再是实验性的 API 和一个全面的 OpenAPI 规范.
文档的REST API提供了两套在线文档,可以在界面进行交互的Swagger和静态的Redoc,对需要使用Airflow REST API的用户非常友好.

Swagger

Redoc

更多关于REST API的详细信息可以参考.
REST API Documentation.

Massive Scheduler performance improvements

调度器性能的显著提升
作为 AIP-15(Scheduler HA+performance)和 Kamil 所做的其他工作的一部分,我们显着提高了 Airflow Scheduler 的性能.它现在可以更快地启动任务.
在 Astronomer.io,我们已经对调度程序进行了基准测试——它很快(我们不得不对数字进行三次检查,因为我们一开始不太相信他们!)

具体的性能测试可以参考下面的两个表格,分别是延迟基准测试及调度器水平扩展基准测试:

Benchmarked Performance Gains

We have been using “task latency” as the key metric to benchmark scheduler performance and validate improvements. Often evident in the “Gantt” view of the Airflow UI, we define task latency as the time it takes for a task to begin executing once its dependencies have been met.

Along with the above architectural changes, Airflow 2.0 also incorporates optimizations in the task startup process and in the scheduler loop, which reduces task latency.

To sufficiently test this, without skewing numbers based on the actual task “work” time, we have chosen to benchmark using a simple BashOperator task with a trivial execution time. The benchmarking configuration was: 4 Celery Workers, PostgreSQL DB, 1 Web Server, 1 Scheduler.

Results for 1,000 tasks run, measured as total task latency (referenced below as task lag).

Scenario	DAG shape	1.10.10 Total Task Lag	2.0 beta Total Task Lag	Speedup
100 DAG files, 1 DAG per file, 10 Tasks per DAG	Linear	200 seconds	11.6 seconds	17 times
10 DAG files, 1 DAG per file, 100 Tasks per DAG	Linear	144 seconds	14.3 seconds	10 times
10 DAG files, 10 DAGs per file, 10 Tasks per DAG	Binary Tree	200 seconds	12 seconds	16 times

As the above benchmark results show, even a single Airflow 2.0 Scheduler has proven to schedule tasks at much faster speeds.
从上可以看出, airflow在task之间的流转上的延迟大大的降低了,较1.10版本取得了十几倍的提升.

Scalability Benchmarks

We have been using task throughput as the key metric for measuring Airflow scalability and to identify bottlenecks. Task throughput is measured in “tasks per minute”. This represents the number of tasks that can be scheduled, queued, executed, and monitored by Airflow every minute.

To sufficiently test this, without skewing numbers based on the actual task “work” time, we have chosen to benchmark using a simple PythonOperator task with a trivial execution time. The benchmarking configuration was: Celery Workers, PostgreSQL DB, 1 Web Server.

Results for task throughput (metric explained above) using Airflow 2.0 beta builds, run with 5,000 DAGs, each with 10 parallel tasks on a single Airflow deployment. The benchmark was performed on Google Cloud and each Scheduler was run on a n1-standard-1 machine type.

Schedulers	Workers	Task Throughput (average)	Task Throughput (low)	Task Throughput (high)
1	12	285	248	323
2	12	541	492	578
3	12	698	632.5	774

As the results show, adding Schedulers consistently increases task throughput. This enables flexible scale up / scale down of Schedulers based on demand.
从上可以知道,airflow 2.0 的调度器具备线性扩展能力,这显著的提升了airflow的调度能力,很强很棒.

Scheduler is now HA compatible (AIP-15)

调度器高可用兼容 (AIP-15)
现在可以并支持运行多个调度程序实例. 这对于弹性(以防调度程序出现故障)和调度性能都非常有用.
要完全使用此功能,您需要 Postgres 9.6+ 或 MySQL 8+(MySQL 5 和 MariaDB 恐怕不能使用多个调度程序).
运行多个调度程序不需要任何配置或其他设置——只需在其他地方启动一个调度程序(确保它可以访问 DAG 文件),它将通过数据库与您现有的调度程序合作.
更多关于调度器高可用的信息可以参考 Scheduler HA documentation.

Task Groups (AIP-34)

SubDAG 通常用于在 UI 中对任务进行分组,但它们的执行行为有许多缺点(主要是它们只能并行执行单个任务!)为了改善这种体验,我们引入了"Task Group(任务组)":一种组织任务的方法,它提供与 SubDAG 相同的分组行为,而没有任何执行时间缺陷.
SubDAG 现在仍然有效,但我们认为 SubDAG 之前的任何使用现在都可以替换为Task Group(任务组).如果您发现不是这种情况的示例,请在 GitHub 创建一个issue告诉我们.
更多关于任务组的详细信息可以参考 Task Group documentation.

Refreshed UI

崭新的用户界面(Refreshed UI)
我们已经给 Airflow UI a visual refresh 并更新了一些样式.

我们还在图表视图中添加了一个自动刷新任务状态的选项，因此您不再需要连续按下刷新按钮:).
查看 文档中的屏幕截图 了解更多信息.

Smart Sensors for reduced load from sensors (AIP-17)

用于减少传感器负载的智能传感器 (AIP-17)
如果您在 Airflow 集群中大量使用传感器,您可能会发现即使使用"reschedule"模式,传感器执行也会占用集群的很大一部分.为了改善这一点,我们添加了一种称为"Smart Sensors(智能传感器)“的新模式.
此功能处于"抢先体验"阶段:它已经过 Airbnb 的充分测试并且"稳定”/可用,但我们保留在未来版本中对其进行向后不兼容更改的权利(如果必须的话.我们会 非常努力地不要!)
Read more about it in the Smart Sensors documentation.

Simplified KubernetesExecutor

简化的KubernetesExecutor
对于 Airflow 2.0,我们重新架构了 KubernetesExecutor,同时让 Airflow 用户更快,更容易理解且更灵活。 用户现在可以访问完整的 Kubernetes API 来创建 .yaml pod_template_file,而不是在他们的 airflow.cfg 中指定参数。
我们还用 pod_override 参数替换了 executor_config 字典,该参数采用 Kubernetes V1Pod 对象进行 a1:1 设置覆盖。 这些更改从 KubernetesExecutor 中删除了 3000 多行代码，这使其运行速度更快并减少了潜在错误。

更多关于简化的KubernetesExecutor相关的信息,请参考:
Docs on pod_template_file
Docs on pod_override

Airflow core and providers: Splitting Airflow into 60+ packages:

Airflow core(核心)和providers(第三方安装包):将 Airflow 拆分为 60 多个包:

Airflow 2.0 不是一个单一的"一统天下"的包了.我们已将 Airflow 分为core(核心)和 61 个(目前)provider packages(第三方安装包).每个provider package(第三方安装包)都用于特定的外部服务(Google,Amazon,Microsoft,Snowflake),数据库(Postgres,MySQL)或协议 (HTTP/FTP).现在,您可以从“构建”块创建自定义 Airflow 安装并仅选择您需要的内容,并添加您可能有的任何其他要求.一些常见的提供程序会自动安装(ftp,http,imap,sqlite),因为它们是常用的.当您在安装 Airflow 时选择适当的附加功能时,会自动安装其他提供程序.

provider architecture (第三方安装包架构)应该更容易获得一个完全定制的,但具有正确的 Python 依赖项集的一致运行时.

但这还不是全部:您可以编写自己的自定义提供程序,并以可管理的方式添加自定义连接类型,连接表单的自定义以及指向操作员的额外链接等内容.您可以构建自己的提供程序并将其安装为 Python 包,并在 Airflow UI 中直接显示您的自定义设置.
我们的 Jarek Potiuk 在他的博客上写了关于 providers in much more detail 的文章.
更多关于providers相关的信息可用参考:
Docs on the providers concept and writing custom providers
Docs on the all providers packages available

Security

作为 Airflow 2.0 努力的一部分,有意识地关注安全性和减少暴露区域. 这在不同的功能领域以不同的形式表现出来. 例如,在新的 REST API 中,所有操作现在都需要授权.同样,在配置设置中,现在需要指定 Fernet 密钥.

Configuration

airflow.cfg 文件形式的配置在不同的部分得到了进一步的合理化,特别是围绕“core”模块.此外,大量配置选项已被弃用或移至各个特定于组件的配置文件,例如用于 Kubernetes 执行相关配置的 pod-template-file.

Thanks to all of you

我们尝试尽可能少地进行重大更改,并在代码中提供弃用路径,尤其是在 DAG 中调用的任何内容的情况下. 也就是说,请通读 UPDATING.md 以检查可能会影响您的内容.例如:我们重新组织了操作符的布局(它们现在都位于 airflow.providers.* 下),但旧名称应该继续有效 - 您只会注意到许多需要修复的 DeprecationWarnings.

非常感谢让我们走到这一步的所有贡献者,排名不分先后:Kaxil Naik,Daniel Imberman,Jarek Potiuk,Tomek Urbaszek,Kamil Breguła,Gerard Casas Saez,Xiaodong DENG,Kevin Yang,James Timmins,Yingbo Wang ,Qian Yu,Ryan Hamilton 以及其他百余位致力于让 Airflow 更好地服务于每个人的人.

小结

感谢所有参与Apache Airflow贡献的人,同时欢迎更多的人使用Apache Airflow,加入到Apache Airflow社区中,为更好的调度系统作出自己的贡献!

更多关于Apache Airflow的文章，请查看 Apache Airflow系列文章。
若在实践中遇到什么问题的话,欢迎大家加入Apache Airflow 技术交流群进行讨论.
​​
或者加入QQ群 704721809。