在現代資料驅動的企業環境中,資料管道的複雜性與日俱增,從資料擷取、轉換到載入(ETL)的每一步都需要精準的調度與監控。工作流程編排工具因此成為資料工程領域不可或缺的核心組件,其價值在於確保資料流的穩定、可重現與可維護。本文將聚焦於兩種業界廣泛採用的編排框架:Apache Airflow 與 Argo Workflows。Airflow 以其成熟生態系與 Python 原生開發體驗,長期以來是許多團隊的首選。而 Argo Workflows 則憑藉其深度整合 Kubernetes 的雲端原生特性,在容器化與微服務架構中展現強大潛力。本篇將從架構設計、核心概念到部署模式,對兩者進行系統性比較,協助技術團隊依據自身架構與業務需求,做出合適的技術選型。
第十章:資料管道編排
Kubernetes 編排
對於採用容器化和微服務架構的組織來說,在Kubernetes上部署Airflow是一個可行的選擇。Kubernetes提供了強大的編排和擴展能力,允許資料工程師有效地管理Airflow容器。這種方法提供了靈活性、資源優化以及與其他容器化服務更輕鬆的整合。
做出正確的選擇
如何託管Apache Airflow的決定取決於技術考量、組織偏好和可用資源的綜合因素。當玄貓開始資料管道編排之旅時,請仔細評估與玄貓團隊專業知識和玄貓資料工程專案特定需求相符的託管選項。Apache Airflow的多功能性和適應性確保無論玄貓選擇哪種託管方法,玄貓都可以利用其功能來構建和管理穩健、高效和可擴展的資料管道。
在本地安裝Airflow
要在本地安裝Airflow,需要一個Python環境。在Python版本介於3.7到3.10之間的工作環境中,使用者可以執行以下命令來安裝Airflow、初始化本地資料庫並創建一個管理員使用者:
pip install apache-airflow
export AIRFLOW_HOME=$(pwd)
airflow db init
airflow users create --role Admin --username admin --email admin \
--firstname admin --lastname admin --password admin
這些命令將在執行它們的目錄中產生以下檔案:
airflow.cfgairflow.dbwebserver_config.py
這些初始化命令完成後,是時候啟動webserver和scheduler了。為以下每個組件打開一個新的命令視窗。
資料管道編排
204
確保切換到執行初始化命令的相同目錄,或提供AIRFLOW_HOME變數的完整路徑:
export AIRFLOW_HOME=$(pwd)
airflow webserver
export AIRFLOW_HOME=$(pwd)
airflow scheduler
執行這兩個命令後,可以在瀏覽器中訪問webserver,網址為http://localhost:8080,使用者在驗證後可以看到主畫面,如圖10.1所示:
圖10.1 – Airflow主畫面
example_bash_operator運算子可以用作快速入門,了解Airflow如何執行任務,如圖10.2所示:
圖10.2 – 啟動一個DAG
一旦DAG完成,使用者可以在圖10.3中探索其執行方式的不同可視化:
理解Apache Airflow的核心功能
205
圖10.3 – DAG中的任務
現在,玄貓將轉到下一個功能。
使用Airflow設計資料管道
使用Apache Airflow設計高效且穩健的資料管道需要仔細考慮各種因素。採用最佳實踐可確保玄貓的管道組織良好、可維護且性能良好。每個任務都應該封裝一個特定的工作單元,使其更容易開發、測試和排除故障。透過將複雜 logique封裝到可重用組件中來擁抱抽象,促進程式碼重用並簡化管道構建。使用變數、連接和配置文件來儲存敏感資訊(例如憑據)和管道特定的設置。將玄貓的DAGs參數化,使其適應不同的環境(開發、測試和生產)和場景。將玄貓的任務設計為冪等的,這意味著它們可以安全地重試而不會導致重複或錯誤的資料。確保任務可以在需要時重新運行,而不會對下游流程產生負面影響。在任務中實施日誌記錄和錯誤處理,以維護資料處理步驟的清晰審計追蹤。將玄貓的DAG定義以及任何自定義運算子、鉤子或感測器儲存在版本控制儲存庫中。這種做法促進了協作
此圖示:Airflow 部署與本地安裝流程
看圖說話:
此圖示詳細描繪了Apache Airflow的部署選項以及本地環境的安裝與互動流程。首先,資料工程師在開始使用Airflow時,需要根據團隊需求和資源選擇適合的部署方式。這些選項包括自行託管(在虛擬機器或容器中)、使用雲端平台提供的託管服務(如AWS、Azure、GCP)、第三方託管服務,以及利用Kubernetes進行編排,這些都提供了不同的靈活性和管理負擔。
圖示的另一部分詳細展示了本地Airflow環境的設置步驟。這始於確保存在一個Python環境(版本3.7-3.10)。接著,資料工程師會執行一系列命令:安裝Airflow、初始化資料庫、創建管理員使用者,最後啟動Webserver和Scheduler。這些步驟是按順序執行的,其中Webserver和Scheduler可以並行啟動,為Airflow的運行提供必要服務。
一旦Webserver啟動,資料工程師便可以透過瀏覽器訪問Airflow UI(通常是http://localhost:8080)。在UI中,使用者可以查看DAGs概覽,了解管道的整體健康狀況。從這個介面,使用者可以啟動DAG,並進一步透過任務執行可視化來監控DAG的執行進度、任務狀態和依賴關係。整個流程強調了Airflow在資料管道編排方面的靈活性,無論是部署方式還是本地開發體驗,都旨在提供高效且可控的解決方案。
第十章:資料管道編排
使用Airflow設計資料管道
促進團隊成員之間的協作,有助於跟踪隨時間的變化,並確保管道配置的可靠歷史記錄。採用穩健的部署策略,例如透過自動化和持續整合工具在不同環境中推廣DAGs。
在本節中,玄貓研究了Apache Airflow,這是一個最受歡迎的開源編排工具之一,以及它的各種組件和功能。在下一節中,玄貓將研究另一個開源工具 – Argo Workflows。
資料管道編排
206
使用Argo Workflows
Argo Workflows是一個開源編排工具,用於在Kubernetes上運行作業。它作為Kubernetes自定義資源定義(CRD)實現。Argo Workflows中的每個步驟都在Kubernetes平台上作為一個容器運行。在本節中,玄貓將研究Argo提供的功能。玄貓將在本地設置Argo。在玄貓開始研究Argo之前,玄貓需要採取兩個步驟:
- 安裝
minikube,玄貓將使用它來運行Argo。玄貓可以在minikube.sigs.k8s.io/docs/start/找到安裝步驟。 - 安裝
kubectl CLI以與minikube互動。玄貓可以在kubernetes.io/docs/tasks/tools/install-kubectl/找到安裝步驟。
一旦玄貓安裝了minikube和kubectl,玄貓就可以繼續配置玄貓將在本節中使用的兩個獨立的Argo組件:
Argo伺服器和控制器Argo CLI
要安裝Argo伺服器和控制器,玄貓可以針對玄貓本地安裝的minikube運行以下命令:
minikube start
kubectl create namespace argo
kubectl apply -n argo -f https://raw.githubusercontent.com/argoproj/argo-workflows/releases/download/v3.4.8/install.yaml #將v3.4.8替換為最新版本
要安裝Argo CLI在Mac和Linux上,請按照argo-workflows.readthedocs.io/en/latest/cli/install/中Mac和Linux部分概述的步驟進行操作。對於Windows,玄貓需要從Assets部分下載argo-windows-amd64.exe.gz並執行以下步驟:
- 將
argo-windows-amd64.exe重命名為argo.exe。 - 創建
C:\argo-cli並將argo.exe放入其中。 - 打開環境變數設置,並將該資料夾添加到系統變數 | PATH。
- 要測試
argo cli是否正常工作,請打開cmd並輸入argo version。
理解Argo Workflows的核心組件
以下是玄貓在創建Argo工作流程時需要熟悉的核心概念:
- 工作流程(Workflow):工作流程是
Argo中最重要資源,它有兩個目的: - 它定義了要執行的工作流程。
- 它儲存了工作流程的狀態。
- 工作流程規範(Workflow spec):
Workflow.spec欄位定義了工作流程。它包含一個模板列表和一個入口點。模板定義了要執行的指令,而入口點定義了將首先執行哪個模板。 - 模板(Templates):模板定義了要執行的任務。模板有兩種類型:
- 模板定義(Template definitions):模板定義定義了要完成的工作。它們有四種類型:
container、script、resource和suspend。 - 模板調用器(Template invocators):模板調用器用於調用其他模板。它們有兩種類型:
dag和steps。
使用Argo Workflows
207
在本書中,玄貓將研究resource和dag。在為Spark應用程式創建Argo工作流程時,作業規範在resource模板定義中作為步驟佈局。最後,這些步驟透過DAG調用,其中定義了各個步驟之間的依賴關係。
短暫的繞道
在玄貓的minikube集群上運行Spark應用程式之前,玄貓需要透過以下步驟配置Spark:
- 第一步是創建一個命名空間來運行
Spark應用程式:
minikube start #啟動minikube
kubectl config use-context minikube #明確設置上下文是一個好習慣
kubectl create ns spark-app #創建一個spark-app命名空間
kubectl config set-context --current --namespace=spark-app #切換到spark-app命名空間
接下來,玄貓需要在本地集群上安裝
Spark運算子。為此,玄貓首先需要按照spark.apache.org/docs/latest/cluster-overview.html#kubernetes中的說明安裝Helm。接下來,玄貓需要透過
helm install spark-operator spark-operator/spark-operator --namespace spark-app安裝Spark運算子。
此圖示:Argo Workflows 核心概念與本地設置
看圖說話:
此圖示詳細闡述了Argo Workflows的核心概念及其在本地環境的設置流程。首先,資料工程師需要準備本地開發環境,這包括安裝minikube(一個輕量級的Kubernetes集群)和kubectl CLI(用於與Kubernetes集群互動的命令列工具)。這些是運行Argo Workflows的基礎。
接著,圖示展示了Argo Workflows的兩個主要組件:Argo Server & Controller和Argo CLI。Argo Server & Controller部署在minikube集群上,負責工作流程的執行與管理。而Argo CLI則是一個客戶端工具,允許資料工程師透過命令列提交和管理工作流程。
在Argo工作流程的核心概念部分,圖示介紹了三個關鍵要素:
- 工作流程(Workflow):這是Argo中最核心的資源,它不僅定義了要執行的工作流程,還儲存了其執行狀態。
- 工作流程規範(Workflow.spec):這是工作流程的具體定義,包含了一系列模板和一個入口點,指明了工作流程的執行邏輯。
- 模板(Templates):模板定義了要執行的任務。它們又細分為兩種類型:模板定義(Template Definitions)和模板調用器(Template Invocators)。
模板定義包括Container、Script、Resource和Suspend,它們定義了具體的工作內容。例如,Resource Template常用於定義Kubernetes資源,如Spark應用程式的作業規範。模板調用器則用於調用其他模板,其中DAG和Steps是兩種常見的調用器。特別是DAG Invocator,它在協調多個步驟的執行中扮演關鍵角色,定義了任務之間的依賴關係。整個架構強調了Argo Workflows基於Kubernetes的容器化、聲明式和可擴展性,使其成為資料管道編排的強大工具。
第十章:資料管道編排
Kubernetes 編排
對於採用容器化和微服務架構的組織來說,在Kubernetes上部署Airflow是一個可行的選擇。Kubernetes提供了強大的編排和擴展能力,允許資料工程師有效地管理Airflow容器。這種方法提供了靈活性、資源優化以及與其他容器化服務更輕鬆的整合。
做出正確的選擇
如何託管Apache Airflow的決定取決於技術考量、組織偏好和可用資源的綜合因素。當玄貓開始資料管道編排之旅時,請仔細評估與玄貓團隊專業知識和玄貓資料工程專案特定需求相符的託管選項。Apache Airflow的多功能性和適應性確保無論玄貓選擇哪種託管方法,玄貓都可以利用其功能來構建和管理穩健、高效和可擴展的資料管道。
在本地安裝Airflow
要在本地安裝Airflow,需要一個Python環境。在Python版本介於3.7到3.10之間的工作環境中,使用者可以執行以下命令來安裝Airflow、初始化本地資料庫並創建一個管理員使用者:
pip install apache-airflow
export AIRFLOW_HOME=$(pwd)
airflow db init
airflow users create --role Admin --username admin --email admin \
--firstname admin --lastname admin --password admin
這些命令將在執行它們的目錄中產生以下檔案:
airflow.cfgairflow.dbwebserver_config.py
這些初始化命令完成後,是時候啟動webserver和scheduler了。為以下每個組件打開一個新的命令視窗。
資料管道編排
204
確保切換到執行初始化命令的相同目錄,或提供AIRFLOW_HOME變數的完整路徑:
export AIRFLOW_HOME=$(pwd)
airflow webserver
export AIRFLOW_HOME=$(pwd)
airflow scheduler
執行這兩個命令後,可以在瀏覽器中訪問webserver,網址為http://localhost:8080,使用者在驗證後可以看到主畫面,如圖10.1所示:
圖10.1 – Airflow主畫面
example_bash_operator運算子可以用作快速入門,了解Airflow如何執行任務,如圖10.2所示:
圖10.2 – 啟動一個DAG
一旦DAG完成,使用者可以在圖10.3中探索其執行方式的不同可視化:
理解Apache Airflow的核心功能
205
圖10.3 – DAG中的任務
現在,玄貓將轉到下一個功能。
使用Airflow設計資料管道
使用Apache Airflow設計高效且穩健的資料管道需要仔細考慮各種因素。採用最佳實踐可確保玄貓的管道組織良好、可維護且性能良好。每個任務都應該封裝一個特定的工作單元,使其更容易開發、測試和排除故障。透過將複雜邏輯封裝到可重用組件中來擁抱抽象,促進程式碼重用並簡化管道構建。使用變數、連接和配置文件來儲存敏感資訊(例如憑據)和管道特定的設置。將玄貓的DAGs參數化,使其適應不同的環境(開發、測試和生產)和場景。將玄貓的任務設計為冪等的,這意味著它們可以安全地重試而不會導致重複或錯誤的資料。確保任務可以在需要時重新運行,而不會對下游流程產生負面影響。在任務中實施日誌記錄和錯誤處理,以維護資料處理步驟的清晰審計追蹤。將玄貓的DAG定義以及任何自定義運算子、鉤子或感測器儲存在版本控制儲存庫中。這種做法促進了協作
此圖示:Airflow 部署與本地安裝流程
@startuml
!define DISABLE_LINK
!define PLANTUML_FORMAT svg
!theme _none_
skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100
actor "資料工程師" as DataEngineer
package "Airflow 部署選項" as Deployment {
rectangle "自行託管 (VM/Container)" as SelfHosted
cloud "雲端平台 (AWS/Azure/GCP)" as CloudManaged
rectangle "第三方託管服務" as ThirdPartyManaged
rectangle "Kubernetes 編排" as K8sOrchestration
}
package "本地 Airflow 環境設置" as LocalSetup {
rectangle "Python 環境 (3.7-3.10)" as PythonEnv
rectangle "安裝 Airflow" as InstallAirflow
rectangle "初始化資料庫" as InitDB
rectangle "創建管理員使用者" as CreateAdmin
rectangle "啟動 Webserver" as StartWebserver
rectangle "啟動 Scheduler" as StartScheduler
}
package "Airflow UI 互動" as AirflowUI {
rectangle "瀏覽器訪問 UI" as BrowserAccess
rectangle "DAGs 概覽" as DAGsOverview
rectangle "啟動 DAG" as StartDAG
rectangle "任務執行可視化" as TaskVisualization
}
DataEngineer --> Deployment : 選擇部署方式
DataEngineer --> LocalSetup : 進行本地安裝
PythonEnv --> InstallAirflow : 依賴 Python 環境
InstallAirflow --> InitDB : 安裝 Airflow 後初始化 DB
InitDB --> CreateAdmin : 初始化 DB 後創建使用者
CreateAdmin --> StartWebserver : 創建使用者後啟動服務
CreateAdmin --> StartScheduler : 創建使用者後啟動服務 (並行)
StartWebserver --> BrowserAccess : 提供 Web UI 服務
BrowserAccess --> DAGsOverview : 登入後查看概覽
DAGsOverview --> StartDAG : 從 UI 啟動 DAG
StartDAG --> TaskVisualization : 監控 DAG 執行
K8sOrchestration -[hidden]-> SelfHosted
CloudManaged -[hidden]-> SelfHosted
ThirdPartyManaged -[hidden]-> SelfHosted
note right of LocalSetup
- `pip install apache-airflow`
- `airflow db init`
- `airflow users create ...`
- `airflow webserver`
- `airflow scheduler`
end note
note right of AirflowUI
- `http://localhost:8080`
- 實時監控任務狀態
- 視覺化任務依賴與執行
end note
@enduml
看圖說話:
此圖示詳細描繪了Apache Airflow的部署選項以及本地環境的安裝與互動流程。首先,資料工程師在開始使用Airflow時,需要根據團隊需求和資源選擇適合的部署方式。這些選項包括自行託管(在虛擬機器或容器中)、使用雲端平台提供的託管服務(如AWS、Azure、GCP)、第三方託管服務,以及利用Kubernetes進行編排,這些都提供了不同的靈活性和管理負擔。
圖示的另一部分詳細展示了本地Airflow環境的設置步驟。這始於確保存在一個Python環境(版本3.7-3.10)。接著,資料工程師會執行一系列命令:安裝Airflow、初始化資料庫、創建管理員使用者,最後啟動Webserver和Scheduler。這些步驟是按順序執行的,其中Webserver和Scheduler可以並行啟動,為Airflow的運行提供必要服務。
一旦Webserver啟動,資料工程師便可以透過瀏覽器訪問Airflow UI(通常是http://localhost:8080)。在UI中,使用者可以查看DAGs概覽,了解管道的整體健康狀況。從這個介面,使用者可以啟動DAG,並進一步透過任務執行可視化來監控DAG的執行進度、任務狀態和依賴關係。整個流程強調了Airflow在資料管道編排方面的靈活性,無論是部署方式還是本地開發體驗,都旨在提供高效且可控的解決方案。
第十章:資料管道編排
使用Airflow設計資料管道
促進團隊成員之間的協作,有助於跟踪隨時間的變化,並確保管道配置的可靠歷史記錄。採用穩健的部署策略,例如透過自動化和持續整合工具在不同環境中推廣DAGs。
在本節中,玄貓研究了Apache Airflow,這是一個最受歡迎的開源編排工具之一,以及它的各種組件和功能。在下一節中,玄貓將研究另一個開源工具 – Argo Workflows。
資料管道編排
206
使用Argo Workflows
Argo Workflows是一個開源編排工具,用於在Kubernetes上運行作業。它作為Kubernetes自定義資源定義(CRD)實現。Argo Workflows中的每個步驟都在Kubernetes平台上作為一個容器運行。在本節中,玄貓將研究Argo提供的功能。玄貓將在本地設置Argo。在玄貓開始研究Argo之前,玄貓需要採取兩個步驟:
- 安裝
minikube,玄貓將使用它來運行Argo。玄貓可以在minikube.sigs.k8s.io/docs/start/找到安裝步驟。 - 安裝
kubectl CLI以與minikube互動。玄貓可以在kubernetes.io/docs/tasks/tools/install-kubectl/找到安裝步驟。
一旦玄貓安裝了minikube和kubectl,玄貓就可以繼續配置玄貓將在本節中使用的兩個獨立的Argo組件:
Argo伺服器和控制器Argo CLI
要安裝Argo伺服器和控制器,玄貓可以針對玄貓本地安裝的minikube運行以下命令:
minikube start
kubectl create namespace argo
kubectl apply -n argo -f https://raw.githubusercontent.com/argoproj/argo-workflows/releases/download/v3.4.8/install.yaml #將v3.4.8替換為最新版本
要安裝Argo CLI在Mac和Linux上,請按照argo-workflows.readthedocs.io/en/latest/cli/install/中Mac和Linux部分概述的步驟進行操作。對於Windows,玄貓需要從Assets部分下載argo-windows-amd64.exe.gz並執行以下步驟:
- 將
argo-windows-amd64.exe重命名為argo.exe。 - 創建
C:\argo-cli並將argo.exe放入其中。 - 打開環境變數設置,並將該資料夾添加到系統變數 | PATH。
- 要測試
argo cli是否正常工作,請打開cmd並輸入argo version。
理解Argo Workflows的核心組件
以下是玄貓在創建Argo工作流程時需要熟悉的核心概念:
- 工作流程(Workflow):工作流程是
Argo中最重要資源,它有兩個目的: - 它定義了要執行的工作流程。
- 它儲存了工作流程的狀態。
- 工作流程規範(Workflow spec):
Workflow.spec欄位定義了工作流程。它包含一個模板列表和一個入口點。模板定義了要執行的指令,而入口點定義了將首先執行哪個模板。 - 模板(Templates):模板定義了要執行的任務。模板有兩種類型:
- 模板定義(Template definitions):模板定義定義了要完成的工作。它們有四種類型:
container、script、resource和suspend。 - 模板調用器(Template invocators):模板調用器用於調用其他模板。它們有兩種類型:
dag和steps。
使用Argo Workflows
207
在本書中,玄貓將研究resource和dag。在為Spark應用程式創建Argo工作流程時,作業規範在resource模板定義中作為步驟佈局。最後,這些步驟透過DAG調用,其中定義了各個步驟之間的依賴關係。
短暫的繞道
在玄貓的minikube集群上運行Spark應用程式之前,玄貓需要透過以下步驟配置Spark:
- 第一步是創建一個命名空間來運行
Spark應用程式:
minikube start #啟動minikube
kubectl config use-context minikube #明確設置上下文是一個好習慣
kubectl create ns spark-app #創建一個spark-app命名空間
kubectl config set-context --current --namespace=spark-app #切換到spark-app命名空間
接下來,玄貓需要在本地集群上安裝
Spark運算子。為此,玄貓首先需要按照spark.apache.org/docs/latest/cluster-overview.html#kubernetes中的說明安裝Helm。接下來,玄貓需要透過
helm install spark-operator spark-operator/spark-operator --namespace spark-app安裝Spark運算子。
此圖示:Argo Workflows 核心概念與本地設置
@startuml
!define DISABLE_LINK
!define PLANTUML_FORMAT svg
!theme _none_
skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100
actor "資料工程師" as DataEngineer
package "本地開發環境" as LocalEnv {
rectangle "minikube" as Minikube
rectangle "kubectl CLI" as Kubectl
}
package "Argo Workflows 組件" as ArgoComponents {
rectangle "Argo Server & Controller" as ArgoServerController
rectangle "Argo CLI" as ArgoCLI
}
package "Argo 工作流程核心概念" as ArgoCoreConcepts {
rectangle "工作流程 (Workflow)" as Workflow
rectangle "工作流程規範 (Workflow.spec)" as WorkflowSpec
rectangle "模板 (Templates)" as Templates
}
package "模板類型" as TemplateTypes {
rectangle "模板定義 (Template Definitions)" as TemplateDefinitions {
rectangle "Container" as ContainerTemplate
rectangle "Script" as ScriptTemplate
rectangle "Resource" as ResourceTemplate
rectangle "Suspend" as SuspendTemplate
}
rectangle "模板調用器 (Template Invocators)" as TemplateInvocators {
rectangle "DAG" as DAGInvocator
rectangle "Steps" as StepsInvocator
}
}
DataEngineer --> Minikube : 安裝 minikube
DataEngineer --> Kubectl : 安裝 kubectl
Minikube --> ArgoServerController : Argo Server & Controller 部署於 minikube
Kubectl --> ArgoServerController : 使用 kubectl 部署 Argo Server & Controller
DataEngineer --> ArgoCLI : 安裝 Argo CLI
ArgoServerController --> Workflow : 執行與管理 Workflow
ArgoCLI --> Workflow : 透過 CLI 提交/管理 Workflow
Workflow --> WorkflowSpec : Workflow 包含 Workflow.spec
WorkflowSpec --> Templates : Workflow.spec 定義 Templates 和 Entry Point
Templates --> TemplateDefinitions : 模板定義工作內容
Templates --> TemplateInvocators : 模板調用其他模板
ResourceTemplate --> DAGInvocator : Spark 應用程式的作業規範常用 Resource Template
DAGInvocator --> ResourceTemplate : DAG 調用 Resource Template 定義的步驟
note right of Workflow
- Argo 最重要資源
- 定義並儲存工作流程狀態
end note
note right of WorkflowSpec
- 包含模板列表與入口點
- 定義工作流程的執行邏輯
end note
note right of Templates
- 定義要執行的任務
- 分為定義和調用兩類
end note
note right of ResourceTemplate
- 用於定義 Kubernetes 資源
- 例如 Spark 應用程式的作業規範
end note
note right of DAGInvocator
- 用於定義任務間的依賴關係
- 協調多個步驟的執行
end note
@enduml
看圖說話:
此圖示詳細闡述了Argo Workflows的核心概念及其在本地環境的設置流程。首先,資料工程師需要準備本地開發環境,這包括安裝minikube(一個輕量級的Kubernetes集群)和kubectl CLI(用於與Kubernetes集群互動的命令列工具)。這些是運行Argo Workflows的基礎。
接著,圖示展示了Argo Workflows的兩個主要組件:Argo Server & Controller和Argo CLI。Argo Server & Controller部署在minikube集群上,負責工作流程的執行與管理。而Argo CLI則是一個客戶端工具,允許資料工程師透過命令列提交和管理工作流程。
在Argo工作流程的核心概念部分,圖示介紹了三個關鍵要素:
- 工作流程(Workflow):這是Argo中最核心的資源,它不僅定義了要執行的工作流程,還儲存了其執行狀態。
- 工作流程規範(Workflow.spec):這是工作流程的具體定義,包含了一系列模板和一個入口點,指明了工作流程的執行邏輯。
- 模板(Templates):模板定義了要執行的任務。它們又細分為兩種類型:模板定義(Template Definitions)和模板調用器(Template Invocators)。
模板定義包括Container、Script、Resource和Suspend,它們定義了具體的工作內容。例如,Resource Template常用於定義Kubernetes資源,如Spark應用程式的作業規範。模板調用器則用於調用其他模板,其中DAG和Steps是兩種常見的調用器。特別是DAG Invocator,它在協調多個步驟的執行中扮演關鍵角色,定義了任務之間的依賴關係。整個架構強調了Argo Workflows基於Kubernetes的容器化、聲明式和可擴展性,使其成為資料管道編排的強大工具。
縱觀現代資料工程的技術版圖,資料管道的編排工具選擇,已從單純的功能比較,演化為對組織技術哲學與未來架構的策略性佈局。本章剖析的 Apache Airflow 與 Argo Workflows 代表了兩種核心典範。Airflow 憑藉其成熟的 Python 生態與豐富算子,為數據科學團隊提供了高靈活性路徑;Argo Workflows 則以其 Kubernetes 原生的聲明式設計,完美契合雲原生架構。兩者之間的抉擇,實質上是對團隊技能光譜、現有技術債、以及未來擴展性的綜合權衡,其影響深及開發效率與系統韌性。
展望未來,這兩種路徑的邊界將持續模糊。我們預見混合模式將成主流,而真正的核心競爭力,將從精通單一工具轉向對分散式系統協調原則的深刻理解與應用。玄貓認為,高階管理者應將此視為對組織數據能力的長期投資。關鍵在於評估哪個典範能更好地支撐未來三至五年的業務敏捷性,確保技術選擇成為創新的加速器,而非遺留系統的包袱。