我荣幸地宣布 Apache Airflow 2.0.0 已发布。

完整的更新日志长达约 3000 行（已排除回流到 1.10 的所有内容），因此目前我将只分享 2.0.0 相较于 1.10.14 的一些主要功能。

编写 DAGs 的新方式：TaskFlow API (AIP-31)

（在 2.0.0 Alpha 版本中称为函数式 DAGs。）

现在编写 DAGs 变得更加方便，尤其在使用 PythonOperator 时。依赖关系的处理更加清晰，并且 XCom 更易于使用。

在此阅读更多内容

TaskFlow API 教程
TaskFlow API 文档

快速预览现在 DAGs 的外观

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()

完整规范的 REST API (AIP-32)

我们现在拥有一个完全支持、不再是实验性的 API，附带全面的 OpenAPI 规范。

在此阅读更多内容

REST API 文档.

调度器性能大幅提升

作为 AIP-15（调度器 HA+性能）和 Kamil 所做其他工作的一部分，我们显著提升了 Airflow 调度器的性能。现在它启动任务的速度快得多，非常快。

在 Astronomer.io，我们已经对调度器进行了基准测试——它速度很快（我们不得不三次检查数据，因为一开始我们不太相信！）

调度器现在兼容 HA（高可用性）(AIP-15)

现在可以支持运行多个调度器实例。这对于提高容错性（以防某个调度器宕机）和提升调度性能都非常有用。

要充分利用此功能，您需要使用 Postgres 9.6+ 或 MySQL 8+（恐怕 MySQL 5 和 MariaDB 无法与多个调度器一起工作）。

运行多个调度器无需任何配置或其他设置——只需在其他地方启动一个调度器（确保它可以访问 DAG 文件），它就会通过数据库与您现有的调度器协同工作。

欲了解更多信息，请阅读调度器 HA 文档。

任务组（Task Groups）(AIP-34)

SubDAGs 通常用于在 UI 中分组任务，但它们在执行行为上有很多缺点（主要是它们只能并行执行一个任务！）。为了改善这种体验，我们引入了“任务组（Task Groups）”：一种组织任务的方法，它提供了与 subdag 相同的分组行为，同时没有任何执行时的缺点。

SubDAGs 目前仍然可用，但我们认为以前使用 SubDAGs 的地方现在都可以用任务组来替代。如果您发现并非如此的示例，请通过在 GitHub 上提交 issue 告知我们。

欲了解更多信息，请查看任务组文档。

更新的 UI

我们对 Airflow UI 进行了视觉更新并修改了一些样式。

我们还在图视图（Graph View）中添加了自动刷新任务状态的选项，这样您就无需持续点击刷新按钮了 :)。

请查看文档中的截图了解更多信息。

智能传感器（Smart Sensors）降低传感器负载 (AIP-17)

如果您在 Airflow 集群中大量使用传感器，您可能会发现即使在“reschedule”模式下，传感器执行也会占用相当大的集群资源。为了改善这一点，我们添加了一种新模式，称为“智能传感器（Smart Sensors）”。

此功能处于“早期访问”阶段：它已由 Airbnb 充分测试并“稳定”/可用，但我们保留在未来版本中对其进行向后不兼容更改的权利（如果我们必须这样做。我们会尽力避免！）

请在智能传感器文档中阅读更多信息。

简化的 KubernetesExecutor

对于 Airflow 2.0，我们重新设计了 KubernetesExecutor，使其同时更快、更容易理解，并且对 Airflow 用户更灵活。用户现在可以访问完整的 Kubernetes API 来创建 .yaml pod_template_file，而不是在 airflow.cfg 中指定参数。

我们还将 executor_config 字典替换为 pod_override 参数，该参数接受一个 Kubernetes V1Pod 对象以进行 1:1 的设置覆盖。这些更改从 KubernetesExecutor 中移除了三千多行代码，使其运行更快并减少了潜在错误。

在此阅读更多内容

pod_template_file 文档
pod_override 文档

Airflow 核心和提供者：将 Airflow 拆分为 60 多个软件包

Airflow 2.0 不是一个庞大的“一统天下”软件包。我们已将 Airflow 拆分为核心和 61 个（目前）提供者软件包。每个提供者软件包要么针对特定的外部服务（Google, Amazon, Microsoft, Snowflake），要么针对数据库（Postgres, MySQL），要么针对协议（HTTP/FTP）。现在，您可以从“构建块”创建自定义的 Airflow 安装，只选择您需要的，并添加您可能有的任何其他要求。一些常用的提供者（ftp, http, imap, sqlite）由于常用而自动安装。在安装 Airflow 时选择相应的额外选项时，其他提供者也会自动安装。

提供者架构应该使得获得完全定制但一致的运行时环境变得更加容易，并拥有正确的 Python 依赖集合。

但这还不是全部：您可以编写自己的自定义提供者，并以可管理的方式添加自定义连接类型、连接表单的定制以及操作器的额外链接。您可以构建自己的提供者并将其作为 Python 包安装，然后在 Airflow UI 中直接看到您的定制。

我们自己的 Jarek Potiuk 在他的博客上更详细地介绍了提供者。

提供者概念和编写自定义提供者的文档
所有可用提供者软件包的文档

安全性

作为 Airflow 2.0 工作的一部分，我们有意识地将重点放在安全性和减少暴露区域上。这在不同的功能领域以不同的形式体现。例如，在新的 REST API 中，所有操作现在都需要授权。类似地，在配置设置中，现在必须指定 Fernet 密钥。

配置

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

感谢所有贡献者

我们尽量减少了破坏性更改，并在代码中提供了弃用路径，特别是对于在 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 对每个人都变得更好的数百名其他贡献者。