Airflow替代方案：Prefect和Dagster比較

深入瞭解 Airflow、Prefect 和 Dagster 以及三者之間的區別！

互操作性目前還是現代資料技術的棘手的問題：資料管道仍然涉及不完全適合 ETL 工作流的自定義指令碼和邏輯。無論是自定義內部服務，還是像下載檔案、解壓縮檔案和讀取其內容這樣簡單的事情，仍然需要編排工具。跨堆疊編排工作流是一個問題。

 Apache Airflow、Prefect 和 Dagster 等都屬於編排工具。這些工具是資料工程團隊的基礎。Apache Airflow 是三者中最老的一個，是經過實戰考驗且可靠的解決方案，它誕生於 Airbnb，由 Maxime Beauchemin 建立。那時，資料工程是一個不同的世界，主要關注定期安排的批處理作業，這些作業通常涉及帶有 Hive 和 Druid 之類的醜陋系統。今天你仍然可以在 Airflow 中看到很多這樣的傳統。

Prefect 和 Dagster 是較新的產品，均受其雲產品 Prefect Cloud 和 Dagster Cloud 的支援。Prefect Cloud 可免費啟動並託管排程程式，而混合架構允許您在本地或基礎架構上執行任務。Dagster Cloud 剛剛釋出，處於搶先體驗階段！ 

什麼是 Airflow，它的最佳替代品是什麼？

Airflow 是一種用於編排分散式應用程式的工作流編排工具。它通過使用 DAG（有向無環圖）跨不同伺服器或節點排程作業來工作。Apache Airflow 提供了豐富的使用者介面，可以輕鬆視覺化通過管道的資料流。您還可以監控每個任務的進度並檢視日誌。

如果您曾經對 Airflow 中日期的工作方式感到困惑，那麼您會看到其中的一些傳統。很少有人對 Airflow 的新手不會對執行日期以及為什麼他們的 DAG 沒有按預期執行感到困惑。

今天的 Airflow 現在是一個 Apache 專案，它被 Apache 基金會採用鞏固了該專案作為現狀開源編排和排程工具的地位。今天，成千上萬的公司使用 Airflow 來管理他們的資料管道，你很難找到一家在他們的堆疊中沒有一點 Airflow 的大公司。Astronomer 和 AWS 等公司甚至提供託管 Airflow 即服務，因此圍繞部署和維護例項的基礎設施不再是工程團隊關心的問題。

話雖如此，隨著資料環境的變化，Airflow 在測試、非計劃工作流、引數化、資料傳輸和儲存抽象方面經常會遇到一些障礙。

在我們深入探討其中的一些陷阱之前，有必要提一下 Airflow 的一些好處：毫無疑問，這個專案已經存在了十多年，得到了 Apache 基金會的支援，完全開源，並且被數千家公司使用是一個值得考慮的專案。在許多方面，使用 Airflow 是最安全的選擇，社群支援和經過驗證的實用性使它成為一個如此安全的選擇，你甚至可能會爭辯說，沒有人因為選擇 Airflow（可能）而被解僱。

例如，有關 Airflow 的 Stack Overflow 上的問題比其他任何競爭對手都多 2 個數量級。很有可能，如果您遇到問題，您並不孤單，並且希望其他人找到了解決方案。幾乎所有您能想到的工具都有 Airflow Providers，讓您可以輕鬆地使用現有資料工具建立管道。

隨著資料環境的不斷髮展，資料團隊正在使用他們的工具做更多的事情。他們正在構建複雜的管道以支援資料科學和機器學習用例，從各種系統和端點獲取資料以將它們收集到倉庫和資料湖中，併為跨多個資料系統的終端使用者工具編排工作流。有一段時間，Airflow 是唯一真正可用的編排工具，因此許多團隊試圖將他們日益複雜的需求壓縮到 Airflow 中，但經常碰壁。

我們在 Airflow 部署中看到的主要問題屬於以下幾類之一：

• 本地開發、測試和儲存抽象
• 一次性和不定期的任務
• 任務之間的資料移動
• 動態和引數化的工作流程

我們將通過探索 Dagster 和 Prefect 這兩種替代工具如何解決這些問題來深入探討這些問題。

看看 Dagster 和 Prefect

Dagster 是一個相對年輕的專案，由 Nick Schrock 於 2018 年 4 月開始，他之前是 Facebook GraphQL 的聯合創始人。同樣，Prefect 由 Jeremiah Lowin 於 2018 年創立，他在設計 Prefect 時作為 Apache Airflow 的 PMC 成員學習。

這兩個專案都在解決一個共同的問題，但具有不同的驅動理念。Dagster 採用第一原則的方法進行資料工程。它在構建時考慮了整個開發生命週期，從開發到部署，再到監控和可觀察性。另一方面，Prefect 堅持負向工程的哲學，建立在假設使用者知道如何編碼並儘可能簡單地獲取該程式碼並將其構建到分散式管道中，並得到其排程和支援的分散式管道中。編排引擎。

這兩個專案都獲得了很大的吸引力並迅速改善。讓我們看看這兩個專案如何處理 Airflow 所面臨的一些挑戰。

本地開發和測試

使用 Airflow，本地開發和測試可能是一場噩夢。如果您的生產 Airflow 例項使用 Kubernetes 作為執行引擎，那麼您的本地開發也將需要本地 Kubernetes，因為使用 S3Operator 編寫的任務需要連線到 AWS S3 才能執行：不適合本地開發。

使用 Dagster，計算和儲存是兩個不同的關注點，可以抽象出來。您的函式不是向您的 DAG 顯式提供特定的 Kubernetes 例項，而是接受輸入和輸出及其在執行時配置的資源以持久儲存資料，無論是用於開發的本地臨時檔案還是加密的物件儲存在生產中的雲中。

Prefect儘管通過 RunConfigs 還支援一定程度的儲存抽象，然而，這並沒有提供與 Dagster 相同的抽象級別，這會使本地開發更加棘手。對於 Prefect 來說，引數化是本地開發的重點。通過對流進行引數化，您可以為本地開發提供較小的資料集，為生產使用提供較大的資料集。

排程任務

在 Airflow 中，計劃外的任務可能會導致很多意外問題，並且所有 DAG 都需要某種型別的計劃，並且以相同的執行時間執行多個 DAG 是不可能的。

使用 Prefect，Flow 可以隨時執行，因為工作流是獨立的物件。雖然由於其排程程式的工作方式，我們經常等待 5-10 秒讓 Airflow DAG 從預定時間執行，但 Prefect 允許利用 Dask 等工具對 DAG 和任務進行難以置信的快速排程。

同樣，Dagster 為手動執行和計劃的 DAG 提供了很大的靈活性。您甚至可以根據計劃本身修改特定作業的行為，這非常強大。例如，如果您想在週末和工作日提供不同的執行時配置。

Airflow、Prefect 和 Dagster 中的資料流

Airflow 的最大痛點之一是相關任務之間的資料移動。傳統上，每個任務都必須將資料儲存在某個外部儲存裝置中，使用 XComs 傳遞有關其儲存位置的資訊（我們先不要談論 XComs 之前的生活），並且以下任務必須解析該資訊以檢索資料並處理它。

在 Dagster 中，作業的輸入和輸出可以更加明確。

在 Prefect 中，輸入和輸出也清晰且易於連線在一起。

。。。。

動態工作流程

Airflow 相比Dagster 和 Prefect 中缺少的的另一個重要功能是建立動態工作流的簡單介面。

在 Prefect 中，引數可以在 Cloud Interface 中指定或顯式提供給 Flow runner。這使得擴充套件到大型複雜計算變得容易，同時允許在您處理管道時進行合理的初始開發。

在 Dagster 中，您可以定義一個圖，然後對圖進行引數化以允許動態配置，從而能夠完全自定義資源、配置、掛鉤和執行器。