airflow
Apache Airflow 2.10.3
Apache Airflow（或簡稱 Airflow）是一個以程式設計方式編寫、安排和監控工作流程的平台。
當工作流程被定義為程式碼時，它們變得更加可維護、可版本化、可測試和協作。
使用 Airflow 將工作流程創作為任務的有向無環圖 (DAG)。 Airflow 排程器在一組工作人員上執行您的任務，同時遵循指定的依賴關係。豐富的命令列實用程式使在 DAG 上執行複雜的操作變得輕而易舉。豐富的使用者介面可以輕鬆視覺化生產中運行的管道、監控進度並在需要時解決問題。
目錄
Airflow 最適合大多數靜態且緩慢變化的工作流程。當一次運行與下一次運行的 DAG 結構相似時，它澄清了工作單元和連續性。其他類似的項目包括 Luigi、Oozie 和 Azkaban。
Airflow 通常用於處理數據，但認為任務理想情況下應該是冪等的（即任務的結果將是相同的，並且不會在目標系統中創建重複的數據），並且不應傳遞大量數據從一個任務到下一個任務（儘管任務可以使用Airflow 的XCom 功能傳遞元資料）。對於大批量、資料密集型任務，最佳實踐是委託給專門從事該類型工作的外部服務。
Airflow 不是串流解決方案，但它通常用於處理即時數據，批量從流中提取數據。
Apache Airflow 經過以下測試：
| 主要版本（開發） | 穩定版本（2.10.3） | |
|---|---|---|
| Python | 3.9、3.10、3.11、3.12 | 3.8、3.9、3.10、3.11、3.12 |
| 平台 | AMD64/ARM64(*) | AMD64/ARM64(*) |
| 庫伯內斯 | 1.28、1.29、1.30、1.31 | 1.27、1.28、1.29、1.30 |
| PostgreSQL | 13, 14, 15, 16, 17 | 12, 13, 14, 15, 16 |
| MySQL | 8.0、8.4、創新 | 8.0、8.4、創新 |
| SQLite | 3.15.0+ | 3.15.0+ |
* 實驗性的
注意：MariaDB 未經測試/推薦。
注意：Airflow 測試中使用 SQLite。不要在生產中使用它。我們建議使用最新穩定版本的 SQLite 進行本機開發。
注意：Airflow 目前可以在符合 POSIX 標準的作業系統上運作。為了進行開發，它會定期在相當現代的 Linux 發行版和最新版本的 macOS 上進行測試。在 Windows 上，您可以透過 WSL2（適用於 Linux 2 的 Windows 子系統）或 Linux 容器來執行它。添加 Windows 支援的工作透過 #10388 進行跟踪，但這並不是一個高優先級。您應該僅使用基於 Linux 的發行版作為「生產」執行環境，因為這是唯一受支援的環境。我們的 CI 測試中使用的以及社群管理的 DockerHub 映像中使用的唯一發行版是Debian Bookworm 。
請造訪 Airflow 官方網站文件（最新穩定版本），以取得安裝 Airflow、入門或逐步完成更完整教學的協助。
注意：如果您正在尋找主分支（最新開發分支）的文件：您可以在 s.apache.org/airflow-docs 上找到它。
有關氣流改進建議 (AIP) 的更多信息，請訪問 Airflow Wiki。
相關項目的文檔，例如提供程式包、Docker 映像、Helm Chart，您可以在文檔索引中找到它。
我們在 PyPI 中將 Apache Airflow 作為apache-airflow套件發布。然而，安裝它有時可能會很棘手，因為 Airflow 既是一個庫，也是一個應用程式。庫通常保持它們的依賴關係開放，應用程式通常固定它們，但我們應該兩者都不做，或者同時做。我們決定盡可能保持依賴項的開放性（在pyproject.toml中），以便使用者可以根據需要安裝不同版本的程式庫。這意味著pip install apache-airflow有時會無法運作，或會產生無法使用的 Airflow 安裝。
然而，為了實現可重複安裝，我們在孤立的constraints-main和constraints-2-0分支中保留了一組「已知有效」的約束檔案。我們為每個主要/次要 Python 版本單獨保存那些「已知有效」的約束檔。從 PyPI 安裝 Airflow 時，您可以將它們用作約束檔。請注意，您必須在 URL 中指定正確的 Airflow 標記/版本/分支和 Python 版本。
注意：目前官方僅支援
pip安裝。
雖然可以使用 Poetry 或 pip-tools 等工具安裝 Airflow，但它們不與pip共享相同的工作流程 - 特別是在約束與需求管理方面。目前不支援透過Poetry或pip-tools安裝。
bazel存在一些已知問題，在使用 bazel 安裝 Airflow 時可能會導致循環依賴。如果遇到此類問題請切換到pip 。 Bazel社群致力於解決this PR <https://github.com/bazelbuild/rules_python/pull/1166>中的問題_因此較新版本的bazel可能會處理該問題。
如果您希望使用這些工具安裝 Airflow，則應使用約束檔案並將其轉換為您的工具所需的適當格式和工作流程。
pip install ' apache-airflow==2.10.3 '
--constraint " https://raw.githubusercontent.com/apache/airflow/constraints-2.10.3/constraints-3.9.txt "pip install ' apache-airflow[postgres,google]==2.10.3 '
--constraint " https://raw.githubusercontent.com/apache/airflow/constraints-2.10.3/constraints-3.9.txt "有關安裝提供程序包的信息，請檢查提供者。
Apache Airflow 是 Apache Software Foundation (ASF) 項目，我們的官方原始碼發布：
遵循 ASF 規則，發布的原始碼包必須足以讓使用者建立和測試該版本，前提是他們有權存取適當的平台和工具。
還有其他安裝和使用 Airflow 的方法。這些都是“方便”的方法 - 它們不是ASF Release Policy中規定的“官方發布”，但不想自己建立軟體的用戶可以使用它們。
這些是 - 按照人們安裝 Airflow 的最常見方式的順序排列：
pip工具安裝 Airflowdocker工具安裝airflow，在 Kubernetes、Helm Charts、 docker-compose 、 docker swarm等中使用它們。影像文件中。所有這些工件都不是官方發布的，但它們是使用官方發布的源代碼準備的。其中一些工件是「開發」或「預發布」工件，並且它們按照 ASF 政策明確標記為此類。
DAG ：環境中所有 DAG 的概述。
網格：跨越時間的 DAG 的網格表示。
圖表：DAG 的依賴關係及其特定運行的當前狀態的可視化。
任務持續時間：一段時間內花在不同任務上的總時間。
甘特圖：DAG 的持續時間和重疊。
代碼：查看 DAG 原始碼的快速方法。
從 Airflow 2.0.0 開始，我們對所有發布的軟體包都支援嚴格的 SemVer 方法。
我們同意的一些具體規則定義了不同套件的版本控制細節：
google 4.1.0和amazon 3.0.3提供者可以愉快地與Airflow 2.1.2一起安裝。如果提供者和 Airflow 套件之間存在交叉依賴關係限制，它們會作為install_requires限制出現在提供者中。我們的目標是保持提供者與所有先前發布的 Airflow 2 版本的向後相容性，但有時會出現重大更改，可能會使某些或所有提供者指定最低 Airflow 版本。Apache Airflow 版本生命週期：
| 版本 | 當前補丁/次要補丁 | 狀態 | 首次發布 | 有限支持 | EOL/終止 |
|---|---|---|---|---|---|
| 2 | 2.10.3 | 支援 | 2020 年 12 月 17 日 | 待定 | 待定 |
| 1.10 | 2015年10月1日 | 停產 | 2018 年 8 月 27 日 | 2020 年 12 月 17 日 | 2021 年 6 月 17 日 |
| 1.9 | 1.9.0 | 停產 | 2018 年 1 月 3 日 | 2018 年 8 月 27 日 | 2018 年 8 月 27 日 |
| 1.8 | 1.8.2 | 停產 | 2017 年 3 月 19 日 | 2018 年 1 月 3 日 | 2018 年 1 月 3 日 |
| 1.7 | 1.7.1.2 | 停產 | 2016 年 3 月 28 日 | 2017 年 3 月 19 日 | 2017 年 3 月 19 日 |
有限支援版本僅支援安全性和關鍵錯誤修復。 EOL 版本不會得到任何修復或支援。我們始終建議所有使用者針對正在使用的任何主要版本運行最新的可用次要版本。我們強烈建議您在 EOL 日期之前儘早升級到最新的 Airflow 主要版本。
從 Airflow 2.0 開始，我們同意遵循 Python 和 Kubernetes 支援的某些規則。它們基於 Python 和 Kubernetes 的官方發佈時間表，在 Python 開發人員指南和 Kubernetes 版本傾斜政策中得到了很好的總結。
當 Python 和 Kubernetes 版本達到 EOL 時，我們將不再支援它們。除 Kubernetes 之外，如果兩個主要雲端供應商仍然提供支持，則 Airflow 仍會支援該版本。在 EOL 日期之後，我們在 main 中放棄了對這些 EOL 版本的支持，當我們發布 Airflow 的第一個新的 MINOR（如果沒有新的 MINOR 版本，則為 MAJOR）時，它會有效刪除。例如，對於 Python 3.9，這意味著我們將在 2023 年 6 月 27 日之後放棄對 main 的支持，並且此後發布的 Airflow 的第一個 MAJOR 或 MINOR 版本將不再支援它。
在正式發布後，我們在main 中支援新版本的Python/Kubernetes，一旦我們讓它們在我們的CI 管道中工作（這可能不會立即發生，因為依賴項主要趕上新版本的Python），我們就會發布新鏡像Airflow 中的 /support 是基於工作 CI 設定。
此政策是盡力而為，這意味著在某些情況下，如果情況需要，我們可能會提前終止支援。
Airflow 社群提供方便的打包容器映像，每當我們發布 Apache Airflow 版本時都會發布這些映像。這些圖像包含：
基礎作業系統映像的版本是 Debian 的穩定版本。 Airflow 支援使用所有目前活動的穩定版本 - 只要所有 Airflow 依賴項都支援構建，並且我們設定了用於構建和測試作業系統版本的 CI 管道。在先前穩定版本作業系統的常規支援結束之前大約 6 個月，Airflow 將發布的映像切換為使用最新支援的作業系統版本。
例如，從Debian Bullseye到Debian Bookworm切換已在 2023 年 10 月發布 2.8.0 之前實現，並且Debian Bookworm將是 Airflow 2.10.0 起支援的唯一選項。
使用者將繼續能夠使用穩定的 Debian 版本來建立他們的鏡像，直到我們的 CI 中的常規支援和鏡像建置和驗證結束，但在main分支中沒有使用該鏡像執行單元測試。
Airflow 有很多依賴項- 直接依賴項和傳遞依賴項，而且Airflow 既是庫又是應用程序，因此我們對依賴項的策略必須包括- 應用程式安裝的穩定性，以及為開發的用戶安裝更新版本的依賴項的能力DAG。我們開發了一種方法，其中使用constraints來確保氣流可以以可重複的方式安裝，同時我們不會限制用戶升級大多數依賴項。因此，我們決定預設不設定 Airflow 依賴項的上限版本，除非我們有充分的理由相信需要對它們進行上限，因為依賴項的重要性以及升級特定依賴項所涉及的風險。我們也限制了已知會導致問題的依賴關係。
我們的約束機制負責自動尋找和升級所有非上限依賴項（前提是所有測試都通過）。我們的main建置失敗將表明是否存在破壞我們測試的依賴項版本 - 表明我們應該對它們進行上限綁定，或者我們應該修復我們的程式碼/測試以考慮這些依賴項的上游變更。
每當我們對這樣的依賴關係進行上限時，我們應該總是註釋為什麼我們這樣做——即我們應該有一個很好的理由為什麼依賴關係是上限。另外我們也應該提到解除綁定的條件是什麼。
這些依賴項保存在pyproject.toml中。
我們認為很少有依賴項足夠重要，可以在預設情況下對它們進行上限限制，因為眾所周知，它們遵循可預測的版本控制方案，並且我們知道這些依賴項的新版本很可能會帶來重大更改。我們承諾定期審查並嘗試升級到發布的較新版本的依賴項，但這是手動過程。
重要的依賴項是：
SQLAlchemy ：特定 MINOR 版本的上限（眾所周知，SQLAlchemy 會刪除棄用內容並引入重大更改，特別是對不同資料庫的支援各不相同且以不同的速度進行更改）Alembic ：以可預測和高效能的方式處理我們的遷移非常重要。它是與 SQLAlchemy 一起開發的。我們對 Alembic 的經驗是它在 MINOR 版本中非常穩定Flask ：我們使用 Flask 作為 Web UI 和 API 的骨幹。我們知道 Flask 的主要版本很可能會在這些版本之間引入重大更改，因此將其限制為主要版本是有意義的werkzeug ：已知該程式庫會在新版本中造成問題。它與 Flask 庫緊密耦合，我們應該一起更新它們celery ：Celery 是 Airflow 的重要組成部分，因為它用於 CeleryExecutor （和類似的）。 Celery 遵循 SemVer，因此我們應該將其上限限制為下一個 MAJOR 版本。另外，當我們升級庫的較高版本時，我們應該確保 Celery Provider 最低 Airflow 版本已更新。kubernetes ：Kubernetes 是 Airflow 的重要組成部分，因為它用於 KubernetesExecutor（以及類似的）。 Kubernetes Python 函式庫遵循 SemVer，因此我們應該將其上限限制為下一個主要版本。此外，當我們升級庫的更高版本時，我們應該確保 Kubernetes Provider 最低 Airflow 版本已更新。Airflow 的主要部分是 Airflow Core，但 Airflow 的強大功能也來自許多擴展核心功能並單獨發布的提供商，即使我們（目前）為了方便起見將它們保留在同一個 monorepo 中。您可以在提供程序文件中閱讀有關提供程序的更多資訊。我們也實施了一套用於維護和發布社群管理的提供者的政策，以及提供者文件中社群與第三方提供者的方法。
這些extras和providers依賴項均保存在每個提供者的provider.yaml中。
預設情況下，我們不應該對提供者的依賴關係設定上限，但是每個提供者的維護者可能會決定添加額外的限制（並透過註釋證明它們的合理性）。
想要幫助建立 Apache Airflow？查看我們的貢獻者指南，全面了解如何貢獻，包括設定說明、編碼標準和拉取請求指南。
如果您迫不及待想要貢獻，並希望盡快開始，請在此處查看貢獻快速入門！
映像中描述了 Apache Airflow 的官方 Docker（容器）映像。
+1s都被視為具有約束力的投票。 據我們所知，大約有 500 個組織正在使用 Apache Airflow（但可能還有更多）。
如果您使用 Airflow - 請隨時製作 PR 將您的組織新增至清單。
Airflow 是社群的工作，但核心提交者/維護者負責審查和合併 PR，以及圍繞新功能請求引導對話。如果您想成為維護者，請查看 Apache Airflow 提交者要求。
通常，您會看到分配給 Airflow 版本的特定里程碑的問題，或者合併到主分支的 PR，您可能想知道合併的 PR 將在哪個版本中發布，或者修復的問題將在哪個版本中發布這個問題的答案和往常一樣——這取決於不同的場景。 PR 和 Issue 的答案是不同的。
為了添加一些上下文，我們遵循 Airflow 發布流程中所述的 Semver 版本控制方案。更多細節在本自述文件的語意版本控制章節中進行了詳細解釋，但簡而言之，我們有 Airflow 的MAJOR.MINOR.PATCH版本。
MAJOR版本會增加MINOR版本會增加PATCH版本會增加通常，我們會從以 MINOR 版本命名的分支發布 Airflow 的MINOR版本。例如， 2.7.*版本是從v2-7-stable分支發布的， 2.8.*版本是從v2-8-stable分支發布的，等等。
在我們的發布週期中的大多數時候，當下一個MINOR分支的分支尚未建立時，所有合併到main PR（除非它們被恢復）將找到進入下一個MINOR版本的方式。例如，如果最後一個版本是2.7.3且尚未建立v2-8-stable分支，則下一個MINOR版本是2.8.0並且合併到 main 的所有 PR 將在2.8.0中發布。然而，一些 PR（錯誤修復和僅文件更改）在合併時可以被挑選到當前的MINOR分支並在下一個PATCHLEVEL版本中發布。例如，如果2.8.1已經發布，並且我們正在開發2.9.0dev ，那麼用2.8.2里程碑標記 PR 意味著它將被挑選到v2-8-test分支並在2.8.2rc1中發布，最終在2.8.2中。
當我們準備下一個MINOR版本時，我們會削減新的v2-*-test和v2-*-stable分支，並為下一個MINOR版本準備alpha 、 beta版本，合併到 main 的 PR 仍將在下一個MINOR版本中發布直到rc版本被砍掉。發生這種情況是因為當準備下一個beta和rc版本時， v2-*-test和v2-*-stable分支在 main 之上重新建構。例如，當我們削減2.10.0beta1版本時，在2.10.0rc1發布之前合併到main的任何內容都會找到2.10.0rc1的路徑。
然後，一旦我們為 MINOR 版本準備了第一個 RC 候選版本，我們就停止移動v2-*-test和v2-*-stable分支，合併到 main 的 PR 將在下一個MINOR版本中發布。但是，某些 PR（錯誤修復和僅文檔更改）在合併時可以挑選到當前MINOR分支並在下一個PATCHLEVEL版本中發布 - 例如，當v2-10-stable分支的最後發布版本是2.10.0rc1 ，來自main 的一些PR 可以被提交者標記為2.10.0里程碑，發布經理將嘗試將它們挑選到發布分支。如果成功，它們將在2.10.0rc2和隨後的2.10.0中發布。這也適用於後續的PATCHLEVEL版本。例如，當2.10.1已經發佈時，用2.10.2里程碑標記 PR 將意味著它將被挑選到v2-10-stable分支並在2.10.2rc1中發布，最終在2.10.2中發布。
關於挑選的最終決定由發布經理做出。
用里程碑標記問題有點不同。維護者通常不會用里程碑標記問題，通常只在 PR 中標記。如果與該問題相關的 PR（以及“修復它”）按照上述流程合併並在特定版本中發布，則該問題將自動關閉，不會為該問題設置里程碑，您需要檢查該 PR修復了該問題以查看它發布的版本。
然而，有時維護人員會用特定的里程碑來標記問題，這意味著問題對於成為準備發佈時要查看的候選人很重要。由於這是一個開源項目，基本上所有貢獻者都自願投入時間，因此不能保證特定問題將在特定版本中解決。我們不想因為某些問題未修復而推遲發布，因此在這種情況下，發布經理會將此類未修復的問題重新分配給下一個里程碑，以防它們沒有在當前版本中及時修復。因此，問題的里程碑更多的是應該專注於它的意圖，而不是承諾它將在版本中修復。
有關補丁等級版本的更多上下文和常見問題解答可以在儲存庫的dev資料夾中的下一個版本的內容文件中找到。
是的！請務必遵守 Apache 基金會商標政策和 Apache Airflow 品牌手冊。最新的徽標可以在此存儲庫和 Apache 軟體基金會網站上找到。
Apache Airflow 的 CI 基礎設施得到了以下機構的贊助：
