選擇變多了，預設答案也鬆動了
2019 年談 Orchestrator，問題大概是「用 Airflow，還是忍著用 Airflow」。它的社群大、整合多，也累積了足夠的企業使用經驗，幾乎就是預設選項。
然後 Dagster 和 Prefect 出現了，各自拿出了不同的設計哲學：Dagster 說「不要對任務建模，對資料資產建模」；Prefect 說「把調度這件事從 infrastructure 複雜度裡解耦出來」。幾年過去，這兩家工具在某些使用場景裡已經明顯優於傳統 Airflow 的做法。
2025 年 Airflow 釋出 3.0，帶來大幅架構調整、AI workload 支援與開發體驗改善，讓「舊系統直接換掉」也不再是理所當然的答案。
選型要回到幾個具體條件：既有 pipeline 規模、團隊組成、dbt／Spark 整合需求，以及願意承擔多少維運成本。
Airflow 3：既有投資仍然是它最大的優勢
Airflow 依然是企業環境裡佔有率最高的 orchestration 工具。2026 年 State of Airflow 報告訪問了 122 個國家、超過 5,800 位資料工程師，其中 94% 認為熟悉 Airflow 對職涯有幫助。這種生態系規模短期內不會消失。
2025 年四月釋出的 Airflow 3，有兩項值得納入選型的變化：
TaskFlow API 成熟化。在 Airflow 2.x 時代，TaskFlow 雖然存在但有邊界案例問題。3.0 版完整落地後，你可以用更接近一般 Python 函式的方式定義 task，少了很多 template variable 的奇特行為。
原生 AI 工作負載支援。Airflow 3 開始支援 LLM pipeline 與 training job 排程，把 MLOps 工作負載納入產品方向。
Airflow 2.x 將於 2026 年四月進入 limited support 模式，只接受安全性修補，不再有新功能。如果你現在還在 2.x，今年就是升級或評估遷移的時間窗口。
適合使用 Airflow 的情境：
- 既有 Airflow 環境，維護成本可控
- 需要廣泛第三方整合（operators 數量遠多於競品）
- 大型企業環境，需要 Astronomer 等 managed service 提供的 SLA
Dagster：dbt 重度使用者最值得看的選項
Dagster 的核心設計哲學是「軟體定義資產（Software-Defined Assets）」。你不是在定義一個「跑某件事的 task」，你是在宣告「這張 table / 這個 model file 的來源和依賴是什麼」。
這個差異會直接反映在 lineage 與 observability 上。
以 dbt 整合為例，Dagster 把每個 dbt model 對應到一個獨立 asset，完整保留 lineage，你可以看見一個 dbt model 何時被跑、跑了多久、輸入資料的狀態如何。相比之下，Airflow 的 dbt 整合方案通常是把整個 dbt run 包成一個 BashOperator 或 KubernetesPodOperator，lineage 到這裡就斷了。
Dagster 的 @dbt_assets decorator 會自動解析 dbt project 的 manifest.json，把所有 model 和 sources 變成 asset。你不用手動維護 DAG 結構——dbt 的 model dependencies 自動成為 Dagster 的 asset graph。
Dagster 的局限：
- 較陡的學習曲線。從 task-based 思維切換到 asset-based 思維需要時間
- 生態系整合數量仍少於 Airflow
- self-hosted 版本的運維複雜度不低
適合使用 Dagster 的情境：
- 深度使用 dbt，需要 model-level 的 lineage 和 observability
- analytics engineering 團隊，需要資料品質 + 依賴可視化
- Medium-scale team，願意投資在更現代的資料平台架構
Prefect：把 pipeline 保持在一般 Python 的樣子
Prefect 的核心主張是消除 pipeline 開發和一般 Python 程式之間的摩擦。你可以把任何 Python 函式加上 @flow 或 @task 就讓它成為可調度的 pipeline，幾乎沒有 boilerplate。
Prefect 3.0 在 deployment 體驗上做了大幅重新設計。過去 Prefect 2.x 的 deployment 設定需要相對複雜的 YAML 配置；3.0 簡化了這個流程，並且更清晰地分離了「在哪裡跑」（infrastructure）和「跑什麼」（flow definition）兩個概念。
Prefect Cloud 對中小型團隊的主要吸引力，是少掉 scheduler、metadata database 與 execution environment 的自行維護成本。
Prefect 的局限：
- 大規模環境下的 scalability 經驗不如 Airflow 成熟
- 第三方整合數量有限
- 社群規模仍是三者中最小
適合使用 Prefect 的情境：
- 小型到中型資料團隊，首要考量是開發速度
- 需要快速上線、不想負擔重基礎設施維護成本
- Python-first 的開發文化，希望 pipeline 程式碼讀起來就像一般 Python
三個工具放在一起比較
| 維度 | Airflow 3 | Dagster | Prefect 3 |
|---|---|---|---|
| 市場佔有率 | ★★★★★ 最大 | ★★★ 成長中 | ★★ 較小 |
| 學習曲線 | 中等（TaskFlow 後改善） | 較陡（需轉換思維） | 低（純 Python 直覺） |
| dbt 整合深度 | ★★★（operator-level） | ★★★★★（asset-level lineage） | ★★★（flow-level） |
| Observability | ★★★（需要外掛） | ★★★★★（內建 asset catalog） | ★★★（UI 清晰但較淺） |
| Self-hosted 運維 | 中到高 | 中到高 | 中等 |
| Managed 選項 | Astronomer | Dagster Cloud | Prefect Cloud |
| AI/MLOps 支援 | ★★★★（Airflow 3 主力） | ★★★ | ★★ |
先回答三個問題
這三個問題可以先把選項收斂：
你現在用 Airflow 2.x 嗎？ → pipeline 數量 < 100、團隊 < 5 人：可以把 Prefect 或 Dagster 納入遷移評估 → pipeline 數量 > 100、整合複雜：通常先評估升級 Airflow 3，避免低估遷移成本
dbt 是你的核心資料轉換工具嗎？ → 是：Dagster 是目前整合最深的選項，asset-level lineage 價值顯著 → 否：Airflow 或 Prefect 都可以，看團隊規模和運維能力
團隊規模和 infrastructure 偏好？ → 小型、快速迭代：Prefect Cloud（managed，低維護負擔） → 中型、看重 observability：Dagster → 大型企業、需要廣泛整合：Airflow + Astronomer
也可能根本不需要獨立 Orchestrator
2025 年後，orchestration 工具與資料平台的邊界愈來愈模糊。Databricks、Snowflake、BigQuery 都在加強原生 pipeline orchestration；部分團隊需要的能力，已經包含在既有平台裡。
如果你的資料棧高度集中在某個雲端平台（例如幾乎所有東西都在 Snowflake 裡跑），這個平台的原生排程功能加上 dbt Cloud 可能已經夠用——不一定需要 Airflow、Dagster、或 Prefect。
因此，選 Airflow、Dagster 或 Prefect 之前，先確認獨立 Orchestrator 是否真的補上現有平台缺少的能力。
最後怎麼選
既有 Airflow 環境龐大、整合複雜，優先評估 Airflow 3。dbt 是核心，而且 model-level lineage 會直接改善工作方式，Dagster 更有吸引力。小型 Python-first 團隊想降低維運負擔，Prefect Cloud 通常最容易開始。
如果資料工作幾乎都集中在單一雲端平台，則先測試平台原生排程加 dbt Cloud 是否已經足夠。這一步做完，再比較三套獨立工具，會比先看功能清單有效得多。