大數據是復雜的，我已經寫了很多關于廣闊的生態系統和廣泛的可用選項的文章。 通常被忽略但很關鍵的一個方面是管理大數據管道的不同步驟的執行。 框架的決定或執行過程的設計經常會推遲到稍后的階段，從而導致許多問題并延誤項目。

[[348345]]

您應該盡早設計管道編排，以避免在部署階段出現問題。 編排應像其他可交付成果一樣對待; 所有利益相關者都應該對其進行計劃，實施，測試和審查。

編排框架通常被忽略，許多公司最終為其管道實施定制解決方案。 這不僅成本高昂，而且效率低下，因為自定義業務流程解決方案往往會面臨現成框架已經解決的相同問題。 造成漫長的反復試驗。

在本文中，我將介紹一些最常見的開源業務流程框架。

管道編排

數據管道編排是一個交叉過程，可管理管道任務之間的依賴關系，調度作業等。 如果使用流處理，則需要編排每個流應用程序的依賴關系，而對于批處理，則需要安排和編排作業。

請記住，任務和應用程序可能會失敗，因此您需要一種以統一的方式調度，重新調度，重放，監視，重試和調試整個數據管道的方法。

業務流程框架提供的一些功能是：

• 作業調度
• 依賴管理
• 錯誤管理和重試
• 工作參數化
• SLA跟蹤，警報和通知
• 具有儀表板的用戶界面，例如甘特圖和圖形
• 歷史和審計
• 元數據的數據存儲
• 日志匯總

讓我們回顧一下一些選項…

Apache Oozie

Apache Oozie是Hadoop的調度程序，作業創建為DAG，并且可以由基于cron的調度或數據可用性觸發。 Oozie是作為Java Web應用程序運行的可伸縮，可靠和可擴展的系統。 它與Sqoop等提取工具和Spark等處理框架集成在一起。

Oozie工作流程定義以hPDL(XML)編寫。 工作流包含控制流節點和動作節點。 控制流節點定義工作流的開始和結束(開始，結束和失敗節點)，并提供一種機制來控制工作流的執行路徑(決策，派生和聯接節點)[1]。

動作節點是一種機制，工作流通過該機制觸發任務的執行。 Oozie支持不同類型的操作(map-reduce，Pig，SSH，HTTP，電子郵件…)，并且可以擴展以支持其他類型的操作[1]。

同樣，可以對工作流程進行參數設置，并且可以同時執行幾個相同的工作流程作業。

它是Hadoop的第一個調度程序，非常流行，但是已經有點過時了，如果您完全依賴Hadoop平臺，它仍然是一個不錯的選擇。

Apache Airflow

Airflow是一個平臺，可用于計劃，運行和監視工作流程。 由于其易用性和創新的工作流作為代碼方法，它已成為大數據管道的最著名協調者，其中DAG在Python代碼中定義，可以像其他任何可交付的軟件一樣進行測試。

它使用DAG創建復雜的工作流程。 圖中的每個節點都是一個任務，邊定義了任務之間的依賴關系。 任務分為兩類：

• 操作員：執行一些操作。
• 傳感器：檢查過程或數據結構的狀態。

Airflow Scheduler在遵循您描述的指定依賴項的同時，在一組工作線程上執行您的任務。 它具有模塊化架構，并使用消息隊列來協調任意數量的工作程序，并且可以擴展到無窮大[2]。

它為您生成DAG，從而最大程度地提高了并行度。 DAG是用Python編寫的，因此您可以在本地運行它們，對其進行單元測試并將其與開發工作流程集成。 當工作流定義為代碼時，它們變得更加可維護，可版本控制，可測試和協作[2]。

豐富的用戶界面可以輕松地可視化生產中運行的管道，監視進度并在需要時對問題進行故障排除[2]。 它快速，易于使用且非常有用。 它具有多種視圖和多種方法來解決問題。 它保留了運行的歷史記錄，以供以后參考。

> Airflow UI[2]: https://airflow.apache.org/docs/stable/

安裝非常簡單。 您只需要Python。 它具有兩個獨立運行的進程，即UI和Scheduler。

原則[2]：

• 動態的：氣流管道是通過代碼(Python)配置的，從而可以動態生成管道。 這允許編寫可動態實例化管道的代碼。
• 可擴展：輕松定義您自己的運算符，執行程序并擴展庫，使其適合于您的環境的抽象級別。
• 優雅：氣流管道簡潔明了。 使用強大的Jinja模板引擎將參數化腳本內置到Airflow中。
• 可擴展

盡管氣流是作為代碼編寫的，但是氣流并不是數據流解決方案[2]。 此外，工作流預計大部分是靜態的或緩慢變化的，對于非常小的動態作業，還有其他選項，我們將在后面討論。

盡管XCOM功能用于在經常需要的任務之間傳遞小的元數據，例如當您需要某種相關性ID時，它卻是簡單且無狀態的。 它還支持變量和參數化作業。 最后，它具有支持SLA和警報。 它可以與用于監視的通話工具集成在一起。

Luigi是具有類似功能的Airflow的替代產品，但Airflow具有更多功能，并且比Luigi具有更好的擴展性。

Dagster

Dagster是機器學習，分析和ETL的新編排者[3]。 主要區別在于，您可以像Apache NiFi一樣跟蹤數據的輸入和輸出，從而創建數據流解決方案。 這意味著它可以跟蹤執行狀態，并可以將值具體化為執行步驟的一部分。 您可以使用數據管道和資產的統一視圖在本地測試并在任何地方運行。 它支持任何云環境。

Dagster對業務流程圖中各步驟之間的數據依賴關系進行建模，并處理它們之間的數據傳遞。 輸入和輸出上的可選類型有助于盡早發現錯誤[3]。 管道由共享的，可重用的，可配置的數據處理和基礎架構組件構建而成。 Dagster的網絡用戶界面使任何人都可以檢查這些對象并發現如何使用它們[3]。

> Dagster UI[4]: https://docs.dagster.io/

它還可以并行運行多個作業，易于添加參數，易于測試，提供簡單的版本控制，出色的日志記錄，故障排除功能等等。 與Airflow相比，它具有更多功能，但是它還有些不成熟，并且由于它需要跟蹤數據，因此可能難以擴展，由于狀態性，這是NiFi面臨的一個問題。 而且它很大程度上基于Python生態系統。

Prefect

Prefect與Dagster相似，提供本地測試，版本控制，參數管理等等。 它也是基于Python的。

Prefect之所以與眾不同，是為了克服Airflow執行引擎的局限性，例如改進的調度程序，參數化的工作流，動態工作流，版本控制和改進的測試。 對于許多面向DevOps的組織來說，必須具有版本控制功能，但Airflow仍不支持版本控制，Prefect確實支持該功能。

它具有一個核心的開源工作流管理系統以及一個完全不需要設置的云產品。 Prefect Cloud由GraphQL，Dask和Kubernetes支持，因此可以隨時使用[4]。 UI僅在云產品中可用。

Apache NiFi

Apache NiFi不是業務流程框架，而是更廣泛的數據流解決方案。 NiFi還可以安排作業，監視，路由數據，警報等等。 它專注于數據流，但您也可以處理批處理。

它不需要任何類型的編程，并提供拖放UI。 它非常易于使用，您可以將其用于中等難度的作業，而不會出現任何問題，但是對于較大的作業，它往往存在可伸縮性問題。

它在Hadoop外部運行，但可以觸發Spark作業并連接到HDFS / S3。

> NiFi UI[5]: https://nifi.apache.org/

用例

讓我們看一些例子…

• 我有一個舊的Hadoop集群，其Spark批處理作業的運行速度很慢，您的團隊符合Scala開發人員的要求，而您的DAG并不太復雜。 在這種情況下，Ozzie是一個不錯的選擇，因為它提供了計劃Spark作業的簡單方法。
• 我有許多具有復雜依賴關系的運行緩慢的Spark作業，您需要能夠測試依賴關系并最大化并行性，您需要一個易于部署且提供大量故障排除功能的解決方案。 在這種情況下，Airflow是您最好的選擇。
• 我需要從許多來源實時獲取數據，您需要跟蹤數據沿襲，路由數據，豐富數據并能夠調試任何問題。 這是您的BA所需要的實時數據流傳輸管道，他們沒有太多的編程知識。 在這種情況下，Apache NiFi是您最好的選擇，因為它不需要Python技能即可提供所需的所有功能。 如果您的團隊具備Python技能，請考慮使用Dagster。
• 我想在云中創建實時和批處理管道，而不必擔心維護服務器或配置系統。 我需要一個快速，強大的解決方案來增強基于Python的分析團隊的能力。 在這種情況下，請使用Prefect Cloud。
• 我有短暫的，瞬息萬變的工作，要處理要跟蹤的復雜數據，我需要一種方法來解決問題并快速進行生產變更。 在這種情況下，請考慮Dagster。
• 我處理數百TB的數據，我有一個復雜的依賴項，我想自動化我的工作流程測試。 對于這種情況，請使用Airflow，因為它可以擴展，與許多系統交互并可以進行單元測試。 Dagster或Prefect可能在此規模的數據上存在規模問題。
• 我不確定我需要什么。 在這種情況下，請從Airflow開始，因為它是最受歡迎的選擇。

結論

我們似乎是一些最常見的業務流程框架。 如您所見，它們中的大多數將DAG用作代碼，因此您可以在將新的工作流程投入生產之前在本地進行測試，調試管道并對其進行正確的測試。 考慮本文討論的所有功能，并選擇最適合該工作的工具。

簡而言之，如果您的需求只是編排不需要共享數據的獨立任務，并且/或者您的工作很慢，并且/或者您不使用Python，請使用Airflow或Ozzie。 對于需要數據沿襲和跟蹤的數據流應用程序，請對非開發人員使用NiFi; 或Dagster或Prefect(適用于Python開發人員)。

在可能的情況下，請嘗試使工作保持簡單并在Orchestrator外部管理數據依賴關系，這在Spark中很常見，在Spark中您將數據保存到深度存儲中而不傳遞。 在這種情況下，Airflow是一個不錯的選擇，因為它不需要跟蹤數據流，并且您仍然可以使用XCOM傳遞小的元數據，例如數據的位置。 對于更小，運行速度更快，基于python的作業或更多動態數據集，您可能希望在Orchestrator中跟蹤數據依賴性并使用Dagster之類的工具。