完整的变更日志大约有3,000行（已经排除了向后移植到1.10的所有内容），所以到目前为止，我将简单地分享2.0.0和1.10.14相比的一些主要功能：
DAG现在要好得多，尤其是在使用PythonOperator时。依赖关系处理更加清晰，XCom更易于使用
从airflow.decorators导入dag，从airflow.utils.dates导入任务days_ago @ dag（default_args = {＆＃39; owner＆＃39 ;:＆＃39; airflow＆＃39;}，schedule_interval = None，start_date = days_ago（2） ）def tutorial_taskflow_api_etl（）：@task def extract（）：返回{＆＃34; 1001＆＃34 ;: 301.27，＆＃34; 1002＆＃34 ;: 433.21，＆＃34; 1003＆＃34 ;: 502.22} @task def transform（order_data_dict：dict）-> dict：total_order_value = 0 for order_data_dict.values（）：total_order_value + = value return {＆＃34; total_order_value＆＃34 ;: total_order_value} @task（）def load（total_order_value：float）：print（＆＃34; Total订单值是：％.2f＆＃34;％total_order_value）order_data =提取（）order_summary =变换（order_data）负载（order_summary [＆＃34; total_order_value＆＃34;]）tutorial_etl_dag = tutorial_taskflow_api_etl（）
作为AIP-15（调度程序HA +性能）和Kamil所做的其他工作的一部分，我们大大改善了Airflow Scheduler的性能。现在，它可以更快地启动任务。
在Astronomer.io，我们对调度程序进行了基准测试-速度很快（由于一开始不太相信数字，我们不得不对数字进行三重检查！）
现在可以并且支持运行多个调度程序实例。这对于弹性（如果调度程序发生故障）和调度性能都非常有用。
要充分使用此功能，您需要Postgres 9.6+或MySQL 8+（MySQL 5，MariaDB不能与多个调度程序一起使用）。
运行多个调度程序不需要任何配置或其他设置，只需在其他地方启动调度程序（确保它可以访问DAG文件），它将通过数据库与您现有的调度程序配合使用。
SubDAG通常用于在UI中对任务进行分组，但是它们的执行行为有很多缺点（主要是它们只能并行执行一个任务！）为了改善这种体验，我们引入了“任务组”：一种用于组织任务，该任务提供与subdag相同的分组行为，而没有执行时的缺点。
SubDAG仍然可以使用，但我们认为现在可以用任务组代替以前使用的SubDAG。如果您找到的不是这种情况的示例，请通过在GitHub上打开问题来告知我们
我们对Airflow UI进行了视觉刷新，并更新了一些样式。
我们还添加了一个选项来自动刷新“图形视图”中的任务状态，因此您不再需要连续按下刷新按钮:)。
如果您在Airflow集群中大量使用传感器，则即使使用“重新安排”模式，您也可能会发现传感器执行会占据集群的很大一部分。为了改善这一点，我们添加了一种称为“智能传感器”的新模式。
此功能处于“早期访问”状态：它已通过AirBnB的严格测试，并且“稳定” /可用，但是我们保留在将来的版本中对其进行向后不兼容更改的权利（如果需要的话）。尽力不要！）
对于Airflow 2.0，我们以一种更快，更易于理解且对Airflow用户更加灵活的方式重新构造了KubernetesExecutor。用户现在可以访问完整的Kubernetes API来创建.yaml pod_template_file，而无需在airflow.cfg中指定参数。
我们还用pod_override参数替换了executor_config字典，该参数使用Kubernetes V1Pod对象进行1：1设置覆盖。这些更改已从KubernetesExecutor中删除了三千多行代码，这使其运行速度更快，并减少了潜在的错误。
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在Polidea博客上详细介绍了有关提供商的信息。
作为Airflow 2.0努力的一部分，我们有意识地将重点放在安全性和减少暴露区域上。这在不同的功能区域以不同的形式表示。例如，在新的REST API中，所有操作现在都需要授权。同样，在配置设置中，现在需要指定Fernet密钥。
以airflow.cfg文件形式进行的配置已在不同部分中进一步合理化，尤其是在“核心”周围。此外，不建议使用大量配置选项或将其移至特定于组件的单个配置文件，例如Kubernetes执行相关配置的pod模板文件。
我们尝试了尽可能少地进行重大更改，并在代码中提供了弃用路径，尤其是在DAG中进行任何调用的情况下。也就是说，请通读UPDATING.md来检查可能对您造成影响的内容。例如：r我们重新组织了操作员的布局（他们现在都生活在airflow.providers。*下），但是旧名称应该继续起作用-您会注意到很多DeprecationWarnings需要修复。
非常感谢所有促成这一点的贡献者，这些贡献者的顺序不分先后：Kaxil Naik，Daniel Imberman，Jarek Potiuk，Tomek Urbaszek，KamilBreguła，Gerard Casas Saez，邓小东，Kevin Kevin，James Timmins，Yingbo Wang ，钱宇，瑞安·汉密尔顿（Ryan Hamilton）和其他100多个人，他们不断为所有人打造更好的Airflow。