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

[[348345]]

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

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

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

管道編排

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

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

業(yè)務流程框架提供的一些功能是：

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

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

Apache Oozie

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

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

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

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

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

Apache Airflow

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

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

• 操作員：執(zhí)行一些操作。
• 傳感器：檢查過程或數據結構的狀態(tài)。

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

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

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

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

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

原則[2]：

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

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

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

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

Dagster

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

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

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

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

Prefect

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

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

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

Apache NiFi

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

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

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

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

用例

讓我們看一些例子…

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

結論

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

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

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