我榮幸地宣佈 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 規範。
在此閱讀更多內容
排程器效能大幅提升
作為 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 對每個人都變得更好的數百名其他貢獻者。
分享