我很榮幸地宣布 Apache Airflow 2.0.0 版本已發布。
完整的變更日誌大約有 3,000 行（已經排除所有回溯移植到 1.10 的內容），所以目前我將僅分享與 1.10.14 相比，2.0.0 版本中的一些主要功能
撰寫 DAG 的新方法：TaskFlow API (AIP-31)
（在 2.0.0 alpha 版本中稱為 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（排程器 HA+效能）和其他 Kamil 完成的工作的一部分，我們顯著提高了 Airflow 排程器的效能。現在它啟動任務的速度快非常多。
在 Astronomer.io，我們對排程器進行了基準測試 — 速度很快（我們不得不三度檢查數字，因為我們一開始不太相信！）
排程器現在與 HA 相容 (AIP-15)
現在可以支援運行多個排程器實例。這對於彈性（以防排程器故障）和排程效能都非常有用。
若要完整使用此功能，您需要 Postgres 9.6+ 或 MySQL 8+（MySQL 5 和 MariaDB 恐怕無法與多個排程器一起運作）。
不需要任何設定或其他設定即可運行多個排程器 — 只需在其他地方啟動排程器（確保它可以存取 DAG 檔案），它將透過資料庫與您現有的排程器協作。
如需更多資訊，請閱讀排程器 HA 文件。
任務群組 (AIP-34)
SubDAGs 通常用於在 UI 中群組任務，但它們在執行行為方面存在許多缺點（主要是它們一次只並行執行一個任務！）。為了改善這種體驗，我們推出了「任務群組」：一種組織任務的方法，它提供與 SubDAG 相同的群組行為，而沒有任何執行時的缺點。
SubDAGs 目前仍然可以使用，但我們認為先前 SubDAGs 的任何使用案例現在都可以替換為任務群組。如果您發現有任何無法替換的情況，請在 GitHub 上開啟 issue 讓我們知道
如需更多資訊，請查看任務群組文件。
重新整理的 UI
我們為 Airflow UI 進行了視覺更新並更新了一些樣式。
我們還新增了一個選項，可以在圖形視圖中自動重新整理任務狀態，因此您不再需要持續按下重新整理按鈕了 :)。
查看文件中的螢幕截圖以了解更多資訊。
智慧型感測器，減少感測器的負載 (AIP-17)
如果您在 Airflow 叢集中大量使用感測器，您可能會發現即使在「重新排程」模式下，感測器執行也會佔用叢集中相當大的比例。為了改善這一點，我們新增了一種稱為「智慧型感測器」的新模式。
此功能處於「搶先體驗」階段：它已經過 Airbnb 的充分測試，並且是「穩定」/可用的，但我們保留在未來版本中對其進行向後不相容變更的權利（如果我們必須這樣做。我們會盡力避免！）
在智慧型感測器文件中閱讀更多相關資訊。
簡化的 KubernetesExecutor
對於 Airflow 2.0，我們以更快、更易於理解且對 Airflow 使用者更靈活的方式重新架構了 KubernetesExecutor。使用者現在將能夠存取完整的 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 在 Jarek 的部落格上撰寫了關於提供者的更多詳細資訊。
關於提供者概念和編寫自訂提供者的文件
關於所有可用的提供者套件的文件
安全性
作為 Airflow 2.0 工作的一部分，我們有意識地關注安全性並減少暴露區域。這在不同功能領域以不同形式呈現。例如，在新的 REST API 中，所有操作現在都需要授權。同樣，在組態設定中，現在需要指定 Fernet 金鑰。
組態
airflow.cfg 檔案形式的組態已在不同的區段中進一步合理化，特別是圍繞「核心」。此外，大量的組態選項已被棄用或移至個別組件特定的組態檔案，例如 Kubernetes 執行相關組態的 pod-template-file。
感謝各位
我們已盡力減少破壞性變更，並在程式碼中提供棄用路徑，特別是在 DAG 中呼叫的任何內容的情況下。也就是說，請仔細閱讀 UPDATING.md 以檢查哪些內容可能會影響您。例如：我們重新組織了運算子的佈局（它們現在都位於 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 變得更好的貢獻者。
分享