我很自豪地宣布 Apache Airflow 2.0.0 已发布。
完整的变更日志约有 3,000 行（已不包括回移至 1.10 的内容），因此目前我只分享一下相较于 1.10.14 的 2.0.0 主要特性。
一种编写 DAG 的新方式：TaskFlow API（AIP-31）
（在 2.0.0alpha 版中称为 Functional DAGs。）
现在编写 DAG 更加友好，尤其是使用 PythonOperator 时。依赖关系处理更清晰，XCom 的使用也更便捷。
了解更多
TaskFlow API 教程
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()
完整的 REST API（AIP-32）
我们现在拥有一个完整支持、已不再是实验性的 API，并提供全面的 OpenAPI 规范。
了解更多
调度器性能大幅提升
作为 AIP-15（Scheduler HA+performance）以及 Kamil 其他工作的一部分，我们显著提升了 Airflow 调度器的性能。它现在启动任务的速度快得多，快得多。
在 Astronomer.io 上我们对调度器进行基准测试——它很快（我们必须三次核对数字，因为起初并不完全相信！）
调度器现已支持 HA（AIP-15）
现在可以且被支持运行多个调度器实例。这对于提高弹性（防止调度器宕机）以及调度性能都非常有用。
要完整使用此功能，需要 PostgreSQL 9.6+ 或 MySQL 8+（MySQL 5 以及 MariaDB 在多个调度器情况下无法使用，抱歉）。
无需任何配置或额外设置来运行多个调度器——只要在其他位置启动调度器（确保它能访问 DAG 文件），它就会通过数据库与现有调度器协同工作。
更多信息，请阅读调度器 HA 文档。
任务组（AIP-34）
SubDAG 过去常用于在 UI 中对任务进行分组，但它们在执行行为上有诸多缺点（主要是只能并行执行单个任务！）。为改善此体验，我们引入了“任务组”（Task Groups）：一种组织任务的方法，提供与 SubDAG 相同的分组行为，却没有任何执行时的缺陷。
SubDAG 目前仍然可用，但我们认为所有之前对 SubDAG 的使用现在都可以改用任务组。如果您发现有不适用的情况，请通过在 GitHub 上打开 issue 告诉我们。
更多信息，请查看任务组文档。
全新 UI
我们为 Airflow UI进行了一次视觉刷新并更新了一些样式。
我们还在图形视图中添加了自动刷新任务状态的选项，这样您就不必一直按刷新按钮了 :)。
更多内容请查看文档中的截图。
智能传感器用于降低传感器负载（AIP-17）
如果在 Airflow 集群中大量使用传感器，即使使用 “reschedule” 模式，传感器的执行也可能占用集群的大量资源。为了解决这个问题，我们新增了 “Smart Sensors” 模式。
此特性处于 “early‑access” 阶段：已被 Airbnb 大量测试，属于 “稳定”/可用状态，但我们保留在未来版本中进行向后不兼容更改的权利（如果必须的话。我们会努力避免！）。
更多信息请阅读智能传感器文档。
简化的 KubernetesExecutor
针对 Airflow 2.0，我们重新构建了 KubernetesExecutor，使其更快、更易理解，同时为用户提供更大的灵活性。用户现在可以通过完整的 Kubernetes API 创建 .yaml pod_template_file，而不是在 airflow.cfg 中指定参数。
我们还用 pod_override 参数取代了 executor_config 字典，该参数接受一个 Kubernetes V1Pod 对象用于覆盖设置。这些改动从 KubernetesExecutor 中移除了三千多行代码，使其运行更快并减少潜在错误。
了解更多
pod_template_file 文档
pod_override 文档
Airflow core 与 providers：将 Airflow 拆分为 60 多个包
Airflow 2.0 不再是一个“一揽子”包。我们将其拆分为 core 包和 61（目前）个 provider 包。每个 provider 包对应一个外部服务（Google、Amazon、Microsoft、Snowflake）、一种数据库（Postgres、MySQL）或一种协议（HTTP/FTP）。现在您可以通过“构建块”自定义 Airflow 安装，只挑选需要的部分，并额外加入其他需求。常用的 provider（ftp、http、imap、sqlite）会自动安装，因为它们使用广泛。安装 Airflow 时选择相应的 extras，其他 provider 也会自动安装。
这种 provider 架构让您更容易获得完全定制且保持一致的运行时环境，并拥有合适的 Python 依赖集合。
但这还不是全部：您可以编写自己的自定义 provider，添加自定义连接类型、连接表单的定制以及操作符的额外链接等，方式友好且易于管理。您可以将自定义 provider 打包为 Python 包进行安装，定制内容将在 Airflow UI 中直接呈现。
我们的 Jarek Potiuk 在博客中更详细地阐述了 provider。
关于provider 概念及自定义 provider 编写的文档
关于所有可用 provider 包的文档
安全
在 Airflow 2.0 的工作中，我们有意识地加强了安全性并降低了暴露面。比如在全新的 REST API 中，所有操作均需授权；在配置项中，Fernet 密钥现在是必填项。
配置
airflow.cfg 配置文件的结构进一步被划分为多个独立章节，尤其是“core”部分。同时，大量配置项已被废弃或迁移到各组件专属的配置文件，例如用于 Kubernetes 执行的 pod-template-file。
感谢大家
我们已尽量减少不兼容性修改，并在代码中提供了废弃路径，特别是针对 DAG 中调用的内容。尽管如此，请务必阅读 UPDATING.md 以了解可能影响您的地方。例如：我们重新组织了 operators 的路径（它们现在全部位于 airflow.providers.* 下），旧名称仍能工作，但会出现大量 DeprecationWarning，需自行处理。
衷心感谢所有为此做出贡献的伙伴（不分先后顺序）：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 变得更好的贡献者们。
分享