Kubeflow：KFServing 的基礎架構解析

– 19 分鐘閱讀

要真正理解 KFServing 的強大之處，我們需要深入其基礎架構堆積積疊。KFServing 是以雲原生方式構建的，與 Kubeflow 一樣，它受益於底層每一層的功能。KFServing 的架構堆積積疊包括：

硬體層

底層硬體是所有上層的基礎構建塊。叢集可以執行各種硬體裝置，包括 CPU、GPU 甚至 TPU。上層的責任是簡化硬體型別的切換，並盡可能抽象複雜性。

Kubernetes 層

Kubernetes 是緊接在計算叢集之上的關鍵層，它管理、協調和佈署各種資源，成功地抽象了底層硬體。我們主要關注的資源包括：

  • Deployments：管理應用程式的佈署
  • Horizontal Pod Autoscalers (HPA)：根據負載自動調整 Pod 數量
  • Ingresses：管理外部存取路徑

由於 Kubernetes 抽象了底層硬體，這使得在堆積積疊的上層使用 GPU 等硬體加速器變得可能。

Istio 服務網格

Istio 是一個開放原始碼服務網格，透明地層疊在 Kubernetes 叢集上。它整合到任何日誌平台、遙測系統或策略系統，並提供統一的方式來保護、連線和監控微服務。

在服務網格中，每個服務例項都與一個側車網路代理共存。所有網路流量（HTTP、REST、gRPC 等）都透過本地側車代理流向適當的目的地。因此，服務例項不瞭解大型網路，只知道其本地代理。

Istio 擴充套件了 Kubernetes 資源，如 Ingress，提供了服務網格基礎功能：

  • 認證/存取控制：安全管理
  • 入口和出口策略管理：控制流量進出
  • 分散式追蹤：監控請求流程
  • 多叢集聯邦：透過多叢集入口和路由
  • 人工智慧流量管理：高階流量控制

這些工具對需要管理、安全和監控的生產推論應用至關重要。

Knative 層

KFServing 堆積積疊的最後一個元件是 Knative，它利用 Istio 提供的抽象。KFServing 主要借鑑了 Knative Serving 和 Eventing。

Knative Serving 建立在 Kubernetes 和 Istio 之上，支援佈署和提供無伺服器應用程式。透過建立在 Kubernetes 資源（如 Deployments 和 HPAs）和 Istio 資源（如虛擬服務）之上，Knative Serving 提供：

  • 抽象化的服務網格
  • CPU/GPU 自動擴充套件（根據每秒查詢數或指標）
  • 版本管理，用於安全佈署和金絲雀/固定佈署策略

這些功能對於希望將精力集中在模型開發上，而讓擴充套件和版本管理自動處理的資料科學家來說非常有價值。

KFServing 與現代 ML 佈署實踐

在實際應用中，KFServing 的這種分層架構為 ML 模型佈署帶來了幾個顯著優勢：

關注點分離

最令我欣賞的是 KFServing 實作了關注點的清晰分離：

  • 資料科學家可以專注於模型開發和訓練
  • ML 工程師可以專注於模型服務和效能最佳化
  • 平台工程師可以專注於基礎設施和擴充套件性

這種分離使得團隊協作更加順暢，每個角色都能發揮其專長。

簡化的操作流程

傳統的 ML 模型佈署涉及許多手動步驟：封裝模型、構建容器、設定網路、設定監控等。KFServing 將這些步驟抽象為簡單的宣告式設定，大簡化了操作流程。

例如，我曾經參與的一個專案，從手動佈署流程轉向 KFServing 後，模型佈署時間從幾天縮短到幾分鐘，同時還提高了佈署的可靠性和一致性。

統一的 API 介面

KFServing 為不同框架（TensorFlow、PyTorch、ONNX 等）的模型提供統一的 REST API 介面，這使得客戶端應用程式可以使用一致的方式與不同模型互動，而無需關心底層實作細節。

成本效益

透過無伺服器架構和自動擴充套件能力，KFServing 幫助組織實作更好的資源利用和成本控制。在流量低谷時自動縮減資源，在流量高峰時自動擴充套件，這種彈性確保了資源與需求的比對。

在一個零售推薦系統專案中，我們利用 KFServing 的縮至零功能，在非營業時間將資源使用降至最低，估計節省了約 40% 的雲端運算成本。

KFServing 透過結合 Kubernetes、Istio 和 Knative 的強大功能，為機器學習模型佈署提供了一個強大而靈活的框架。它不僅簡化了佈署流程，還提供了豐富的生產級功能，如自動擴充套件、版本管理、流量分割和監控。

對於資料科學團隊而言，KFServing 代表了一種正規化轉變 - 從手動、繁瑣的佈署流程，到自動化、宣告式的模型服務管理。這種轉變不僅提高了效率，還促進了更快的創新迴圈，因為團隊可以更快地將模型從實驗推向生產。

隨著機器學習在企業中的普及，像 KFServing 這樣的工具將變得越來越重要，它們填補了模型開發和生產佈署之間的鴻溝，使組織能夠真正實作 ML 驅動的業務轉型。在未來，我們可能會看到 KFServing 進一步發展，提供更多自動化功能和與其他 ML 生態系統工具的整合，進一步簡化端對端 ML 生命週期管理。

KFServing的進階功能：開發靈活的推論服務

在機器學習模型佈署的世界中，KFServing已成為Kubernetes上的關鍵推論解決方案。然而，真正讓KFServing脫穎而出的不只是其基本功能，而是其豐富的擴充套件性。透過設計精良的「逸出機制」(escape hatches)，KFServing允許開發者深入調整底層技術堆積積疊，實作更精細的控制。今天，玄貓將帶你深入探索這些進階功能，幫助你開發更強大的生產級推論服務。

逸出機制：深入控制底層技術

KFServing的設計理念之一是提供高層次的抽象，同時保留深入調整底層技術的能力。這些「逸出機制」讓資料科學家能夠：

  • 在Istio層級最佳化安全性設定
  • 在Knative層級調整效能引數
  • 根據特定需求微調推論服務行為

這種設計哲學讓KFServing既簡單易用，又不犧牲靈活性和控制力 - 這正是生產環境中不可或缺的特性。

自動擴充套件調整：實際案例解析

讓我們透過一個具體例子來理解這些逸出機制的實際應用 - 調整推論服務的自動擴充套件行為。

要理解這個機制，首先需要了解Knative如何實作自動擴充套件。Knative Serving的Pod中有一個稱為「queue proxy」的代理元件，它負責：

  1. 執行請求佇列引數控制（並發限制）
  2. 向自動擴充套件器報告客戶端並發指標

自動擴充套件器根據這些指標來增減Pod數量。每秒鐘，queue proxy會發布該時間段內觀察到的並發請求數量。

KFServing預設將目標並發量（每個Pod的平均進行中請求數）設為1。這意味著如果服務同時接收5個並發請求，自動擴充套件器會嘗試擴充套件到5個Pod。

自訂目標並發量

透過增加autoscaling.knative.dev/target註解，你可以自訂目標並發量。讓我們重新檢視之前的InferenceService範例：

apiVersion: "serving.kubeflow.org/v1alpha2"
kind: "InferenceService"
metadata:
  name: "recommender"
  namespace: my-namespace
spec:
  default:
    predictor:
      tensorflow:
        serviceAccount: default
        storageUri: "s3://models/recommender"

如果你對此服務進行負載測試，每次維持30秒與保持5個同時進行的請求，你會發現自動擴充套件器將推論服務擴充套件到5個Pod。

這種預設行為反映了KFServing的保守擴充套件策略 - 每個Pod處理一個請求，確保最佳回應時間。然而，這可能導致資源利用率不高，特別是當你的模型能夠有效處理多個並發請求時。

需要注意的是，初始擴充套件時會有冷啟動成本，包括生成Pod和下載模型的時間。如果節點上沒有快取服務映像，冷啟動可能需要更長時間。

自訂目標並發量

透過應用如下所示的註解，可以將目標並發量設定為5：

apiVersion: "serving.kubeflow.org/v1alpha2"
kind: "InferenceService"
metadata:
  name: "recommender"
  namespace: my-namespace
  annotations:
    autoscaling.knative.dev/target: "5"
spec:
  default:
    predictor:
      tensorflow:
        serviceAccount: default
        storageUri: "s3://models/recommender"

使用這個設定，如果你的服務接收5個並發請求，你將只需要1個Pod來處理推論服務。這種調整對於資源最佳化非常有價值，特別是當你的模型能夠高效處理多個請求時。

這個簡單的註解展示了KFServing逸出機制的強大之處 - 只需一行設定，你就能深入調整Knative自動擴充套件器的行為，顯著影響資源使用和成本效益。

InferenceService的故障排除與除錯

KFServing的抽象介面在隱藏底層複雜性的同時提供了豐富功能。但當問題出現時，瞭解請求流程對於有效排除故障至關重要。

請求流程解析

當請求到達你的推論服務時，流程如下：

  1. 流量入口：

    • 外部流量透過Istio入口閘道器(ingress gateway)進入
    • 內部流量透過Istio叢集本地閘道器(cluster local gateway)進入

  2. 頂層路由：

    • KFServing為所有元件建立一個Istio VirtualService，指定頂層路由規則
    • 來自閘道器的流量路由到這個頂層VirtualService

  3. Knative路由：

    • Knative建立Istio虛擬服務，設定閘道器將使用者流量路由到所需的修訂版本
    • 目標規則中的目的地是指向最新就緒的Knative修訂版本的Kubernetes服務

  4. 佇列處理：

    • 一旦修訂版本的Pod就緒，Kubernetes服務將請求傳送到queue-proxy
    • 如果queue-proxy的請求數超過KFServing容器的並發能力，自動擴充套件器會建立更多Pod

  5. 最終處理：

    • queue-proxy將流量傳送到KFServing控制器進行處理

理解這個流程對於故障排除非常關鍵。每一步都涉及不同的Kubernetes和Istio資源，當問題發生時，你需要檢查每個環節的狀態。例如，如果流量未到達你的服務，問題可能出在Istio閘道器或VirtualService設定上。如果服務擴充套件不如預期，則可能是queue-proxy或自動擴充套件器設定有問題。

實際故障排除案例

假設你建立了InferenceService，但Ready狀態為false：

kubectl get inferenceservice -n my-namespace recommender
NAME          URL                                              READY   DEFAULT TRAFFIC   CANARY TRAFFIC   AGE
recommender                                                    False                                      3s

你可以按照請求流程逐步檢查建立的資源，檢視每個資源的狀態物件，找出阻塞點。

當InferenceService顯示為非就緒狀態時，問題可能出在多個環節。透過檢查各個元件的狀態，你可以找出確切的問題所在：

  1. 首先檢查Istio VirtualService是否正確建立
  2. 然後檢查Knative服務和修訂版本的狀態
  3. 檢視Pod的事件和日誌，尋找錯誤訊息
  4. 檢查儲存URI是否可存取，模型是否能正確下載

這種系統化的故障排除方法能幫助你在複雜的KFServing堆積積積堆疊中快速定位問題。

效能問題除錯

如果你的InferenceService佈署成功但效能未達預期，KFServing提供了多種儀錶板和工具來調查這類別問題：

  • 監控工具：透過Knative提供的資源，可以存取Prometheus和Grafana進行效能監控
  • 請求追蹤：使用分散式追蹤技術，可以檢視KFServing請求流程中每一步驟所花費的時間
  • 效能分析：Knative提供的可以幫助你分析和解決效能瓶頸

效能問題通常比功能問題更難診斷，因為它們可能涉及多個因素的互動。使用這些工具，你可以：

  1. 確定是網路延遲、模型載入時間還是推論計算導致的效能問題
  2. 識別是否有資源限制（CPU/記憶體）影響了服務效能
  3. 分析自動擴充套件行為是否符合預期，是否存在擴充套件延遲
  4. 檢測序列化/反序列化過程是否成為瓶頸

Knative Eventing與KFServing的整合

KFServing透過引入Knative，不僅實作了無伺服器架構(透過Knative Serving)，還啟用了事件源和事件消費者(透過Knative Eventing)。這大擴充套件了推論服務的應用場景。

Knative Eventing工作原理

Knative Eventing實施了Lambda風格的事件源和事件消費者架構，遵循以下設計原則：

  • 鬆散耦合：事件服務彼此獨立，無需直接依賴
  • 獨立運作：事件生產者可以在沒有活躍消費者的情況下生成事件；事件消費者可以在沒有生產者建立事件之前表達對事件的興趣
  • 靈活連線：可以連線到任何事件系統，無需修改事件生產者或消費者，並能選擇和目標特定的事件子集

Knative Eventing提供兩種事件傳遞方式：

  1. 從源到單一服務的直接傳遞
  2. 使用頻道和訂閱從源到多個端點的扇出傳遞

整合Kafka事件源

Knative Eventing預設提供多種事件源，其中一個是KafkaSource。下面是如何使用KafkaSource將Kafka接收到的事件傳送到推薦器範例的方法：

apiVersion: sources.knative.dev/v1alpha1
kind: KafkaSource
metadata:
  name: kafka-source
spec:
  consumerGroup: knative-group
  # Broker URL. Replace this with the URLs for your Kafka cluster, which
  # is in the format of my-cluster-kafka-bootstrap.my-kafka-namespace:9092.
  bootstrapServers: my-cluster-kafka-bootstrap.my-kafka-namespace:9092.
  topics: recommender
  sink:
    ref:
      apiVersion: serving.kubeflow.org/v1alpha2
      kind: InferenceService
      name: recommender

這個設定展示了KFServing與事件驅動架構的無縫整合能力。透過簡單的13行YAML，你就能將Kafka事件源連線到推論服務，實作事件驅動的模型推論。

這種整合特別適用於以下場景：

  1. 實時推論：當新資料到達Kafka主題時立即進行模型推論
  2. 事件驅動的工作流程：將模型推論作為更大事件驅動系統的一部分
  3. 非同步處理：處理大量請求而不阻塞使用者介面或其他系統

在實際應用中，你可以構建更複雜的端對端範例，例如結合MinIO和Kafka的解決方案，實作從資料儲存到事件處理再到模型推論的完整流程。

KFServing的其他功能與API檔案

KFServing包含許多持續改進的功能。你可以在GitHub上找到其功能的全面列表。對於API的更多訊息，可以參考KFServing Kubernetes API和KFServing Python API的檔案。

KFServing透過在Seldon Core的圖形推論基礎上構建無伺服器功能，提供了一個完整的推論解決方案，彌補了TFServing和Seldon Core的不足。KFServing致力於透過將模型伺服器作為Knative元件執行來統一整個模型伺服器社群。

從本文的探討中，我們可以看到KFServing如何透過其靈活的逸出機制、強大的自動擴充套件能力、全面的故障排除工具以及與事件系統的無縫整合，為機器學習模型的生產佈署提供了強大支援。這些功能使KFServing成為Kubernetes環境中模型推論的首選解決方案，特別是對於需要高可靠性、可擴充套件性和可觀察性的企業級應用。

隨著機器學習在企業中的持續採用，像KFServing這樣的工具將變得越來越重要，幫助組織縮小模型訓練與生產佈署之間的差距，實作真正的機器學習價值。

KFServing：雲原生模型服務的強大選擇

在機器學習工作流程中，模型訓練完成後的佈署與服務階段常被低估，但實際上這是將模型真正轉化為商業價值的關鍵環節。KFServing 作為 Kubeflow 生態系統中的核心元件，提供了強大而靈活的模型服務解決方案，讓資料科學家能夠專注於機器學習的洞察，而不必過度關注佈署細節。

KFServing 的核心優勢

KFServing 不僅在支援多種框架方面表現出色，更在不同框架間標準化了資料平面，大幅降低了在不同模型伺服器間切換的複雜度。它遵循 Kubernetes 的設計模式，將請求批次處理、日誌記錄和管道處理等常見功能移至 sidecar 容器中。這種設計理念有幾個顯著優勢：

  1. 模型伺服器變得更輕量化：移除了非核心功能後，模型伺服器能夠更專注於其主要任務
  2. 關注點分離：不具備這些功能的模型服務可以立即從佈署到 KFServing 中獲益
  3. 多協定支援：同時支援 REST、gRPC 以及 GPU 加速
  4. 事件流整合：可透過 Knative Eventing 與串流輸入介接
  5. 硬體無關的自動擴充套件：得益於 Knative Serving，KFServing 提供了 GPU 自動擴充套件功能

在實際佈署中，這些特性讓 KFServing 成為一個極具彈性的解決方案。舉例來說，當我在處理一個需要同時支援批次預測和即時推論的專案時，KFServing 的彈性架構讓我能夠用相同的基礎設施滿足這兩種截然不同的需求，大幅降低了維護成本。

模型監控能力

KFServing 繼承了 Seldon Core 及其基礎架構堆積積疊的優勢，完全滿足模型監控需求。它以一級方式利用 Seldon Core 的模型直譯器和漂移檢測器，同時為開發者提供了一個高度靈活與強大的資料平面，讓他們能夠定義自己的監控元件。

藉助 Istio 和 Knative 在其基礎架構堆積積疊中的網路功能，KFServing 提供了可擴充套件的網路監控和遙測功能，支援：

  • Prometheus
  • Grafana
  • Kibana
  • Zipkin
  • Jaeger

這些工具能夠滿足監控 Kubernetes 指標（記憶體/CPU 容器限制）和伺服器指標（每秒查詢數和分散式追蹤）的需求。在實務中，這種整合式的監控方案讓我能夠快速識別效能瓶頸，例如在一個高流量的推薦系統中，我能夠立即發現某個模型版本的延遲異常，並在影響使用者經驗前進行調整。

模型更新策略

KFServing 策略性地使用 Knative，為模型更新提供了複雜的功能。因此，KFServing 滿足了關於佈署策略和版本發布的所有需求。

透過利用 Istio 的虛擬服務和抽象 CRD 的簡潔性，KFServing 使佈署策略的切換變得簡單。它使藍綠佈署 → 固定流量 → 金絲雀發布的流程變得簡單，只需更改幾行 YAML 即可。此外，憑藉其基礎堆積積疊多樣化與不斷擴充套件的功能，KFServing 能夠輕鬆擴充套件以支援更複雜的佈署策略，如多臂老虎機。

使用 Knative Serving，KFServing 採用了修訂管理，使 Kubernetes 佈署不可變。這確保了安全發布，在轉移流量前先對新修訂的 Pod 進行健康檢查。修訂版本實作了：

  • 自動化與安全的發布
  • 記錄所有先前建立的修訂版本
  • 回復到已知的良好設定

這充分滿足了開發中、正在佈署中和生產中的模型版本控制需求。

在這個部分，玄貓解釋了 KFServing 如何處理模型更新的策略。關鍵在於它藉助了 Knative 和 Istio 的能力，使得佈署策略的切換變得簡單。例如，藍綠佈署（同時執行新舊兩個版本，然後一次性切換流量）、固定流量（將特定比例的流量固定導向某版本）和金絲雀發布（逐漸增加新版本的流量比例）這些複雜的策略，在 KFServing 中只需修改幾行 YAML 設定即可實作。

此外，KFServing 採用的修訂管理機制確保了佈署的安全性，它會在轉移流量前先檢查新版本是否健康，並且保留所有歷史版本記錄，方便在問題出現時回復到之前的穩定版本。

模型服務解決方案的選擇

在 Kubeflow 生態系統中，我們有多種推論解決方案可供選擇。根據優先考慮的推論需求以及希望基礎架構堆積積疊的深度，每種解決方案都有其獨特的優勢。

TensorFlow Serving

TensorFlow Serving 為 TensorFlow 模型提供了極高效能與複雜的開箱即用整合方案。它的主要優勢在於：

  • 專為 TensorFlow 模型最佳化，提供最佳效能
  • 支援模型版本控制和熱載入
  • 高度穩定與生產就緒
  • 適合純 TensorFlow 工作流程

在我處理的一個電腦視覺專案中，模型完全根據 TensorFlow 構建，TensorFlow Serving 的效能優勢非常明顯，特別是在處理批次推論時，其吞吐量比通用解決方案高出約 30%。

Seldon Core

Seldon Core 提供了可擴充套件性和複雜推論圖的複雜開箱即用支援，以及模型洞察。其主要特點包括：

  • 支援複雜的推論圖和模型組合
  • 強大的 A/B 測試和多模型佈署能力
  • 內建模型解釋和監控工具
  • 支援幾乎所有主流機器學習框架

對於需要組合多個模型的場景，Seldon Core 表現出色。在一個需要串聯預處理、多模型推論和後處理的專案中，Seldon Core 的推論圖功能讓整個流程變得清晰與易於管理。

KFServing

KFServing 提供了更簡單與具有主見的佈署定義，具有無伺服器功能：

  • 簡化的佈署流程，降低入門檻
  • 無伺服器架構，按需擴充套件資源
  • 標準化的資料平面，易於切換框架
  • 與 Kubeflow 生態系統的深度整合

對於需要快速佈署與資源使用波動較大的場景，KFServing 的無伺服器特性特別有價值。在一個流量高度不穩定的推薦系統中，KFServing 的自動擴充套件能力讓我們在高峰期維持穩定服務的同時，在低谷期大幅節省了資源成本。

這些專案之間分享技術和開發，Seldon Core 甚至將支援新的 KFServing 資料平面，目標是提供簡單的互操作性和轉換。KFServing 的其他令人興奮的功能包括多模型服務、漸進式發布以及更先進的圖形推論技術，如管道和多臂老虎機。

多工具協作案例研究：CT 掃描降噪

在實際的機器學習專案中，往往需要使用多種工具和語言來處理特定的資料科學管道。Python 擁有豐富的工具來處理各種資料格式；R 語言有大量的高階數學函式庫；Scala 是 Apache Spark 和 Apache Flink 等大資料處理引擎的預設語言；而許多成本高昂的遺留程式則以各種語言存在。

Kubeflow 的一個重要優勢是，使用者不再需要為整個管道選擇最佳語言，而是可以為每個任務使用最佳語言（只要該語言和程式碼可容器化）。

CT 掃描降噪例項簡介

電腦斷層掃描（CT）被廣泛用於醫療目的。這些掃描透過從多個角度拍攝 X 光，形成影像「切片」，然後堆積積疊這些切片來建立人體內部的 3D 影像。在美國，健康工作者建議一個人一生接受的輻射不超過 100 毫西弗（mSv），大約相當於 25 次胸部 CT 掃描（每次約 7 mSv）。

在二十世紀末和二十一世紀初，研究人員開始研究「低劑量」CT 掃描。低劑量胸部 CT 掃描只輸送 1 到 2 mSv 的輻射，但代價是影像更加嘈雜，更難閱讀。這些掃描是篩查習慣性吸煙者肺癌的流行工具。

低劑量 CT 掃描的代價是產生的影像品質較低或更嘈雜。在 2000 年代，研究人員對這些低劑量 CT 掃描進行了大量降噪研究。大多數論文僅提供方法和結果（沒有程式碼）。此外，FDA 限制了可用於 CT 掃描降噪的方法，這導致幾乎所有解決方案都是專有與昂貴的。降噪旨在透過去除低劑量 CT 掃描中常見的白噪聲來提高影像品質。

專案目標與技術選擇

在這個綜合案例中，我們將展示如何使用 Kubeflow 協調多種工具來處理 CT 掃描降噪問題：

  1. 資料載入與預處理：CT 掃描以 DICOM 格式存在，我們將使用具有專門函式庫 pydicom 的容器來載入並將資料處理成 numpy 矩陣。

  2. 數學降噪處理：我們將使用奇異值分解（SVD）方法來分解影像成分，其中「最不重要」的成分通常是噪聲。具體實作上，我們使用 Apache Spark 與 Apache Mahout 函式庫進行奇異值分解。

  3. 結果處理與視覺化：最後，我們再次使用 Python 對 CT 掃描進行降噪並視覺化結果。

技術實作流程

在實際實作中，我們將這個過程分解為幾個關鍵步驟：

  1. DICOM 檔案處理：使用 pydicom 函式庫載入 CT 掃描資料，並將其轉換為可處理的數值矩陣。

  2. 資料準備：將影像資料轉換為適合進行 SVD 的格式，並將其傳輸到 Spark 處理環境。

  3. SVD 降噪：利用 Apache Spark 和 Mahout 函式庫執行奇異值分解，識別並移除代表噪聲的低重要性成分。

  4. 結果重建：將處理後的資料重建為 CT 影像，並且原始影像進行比較評估。

  5. 視覺化與驗證：使用 Python 視覺化工具展示降噪前後的影像差異，評估降噪效果。

Kubeflow 管道實作

這個多工具協作案例可以使用 Kubeflow 管道優雅地實作。以下是一個簡化的管道定義範例：

@dsl.pipeline(
    name='CT Scan Denoising Pipeline',
    description='A pipeline to denoise CT scans using SVD'
)
def ct_denoising_pipeline(
    dicom_data_path: str,
    output_path: str,
    svd_components: int = 50
):
    # 步驟1：載入 DICOM 資料
    load_data = dsl.ContainerOp(
        name='load-dicom-data',
        image='pydicom-processor:latest',
        arguments=[
            '--input-path', dicom_data_path,
            '--output-path', '/tmp/processed_data'
        ],
        file_outputs={'processed_data': '/tmp/processed_data'}
    )
    
    # 步驟2：使用 Spark/Mahout 執行 SVD
    perform_svd = dsl.ContainerOp(
        name='perform-svd',
        image='spark-mahout:latest',
        arguments=[
            '--input-data', load_data.outputs['processed_data'],
            '--components', svd_components,
            '--output-path', '/tmp/svd_result'
        ],
        file_outputs={'svd_result': '/tmp/svd_result'}
    )
    
    # 步驟3：重建並視覺化結果
    visualize_results = dsl.ContainerOp(
        name='visualize-results',
        image='python-visualizer:latest',
        arguments=[
            '--original-data', load_data.outputs['processed_data'],
            '--svd-result', perform_svd.outputs['svd_result'],
            '--output-path', output_path
        ]
    )
    
    # 設定資源需求
    load_data.set_cpu_request('1').set_memory_request('2G')
    perform_svd.set_cpu_request('4').set_cpu_limit('8').set_memory_request('16G')
    visualize_results.set_cpu_request('2').set_memory_request('4G')
    
    # 設定步驟順序
    load_data.after(perform_svd)
    visualize_results.after(perform_svd)

這段程式碼展示瞭如何使用 Kubeflow 管道 DSL 建立一個 CT 掃描降噪處理流程。管道包含三個主要步驟：

  1. load_data：使用 pydicom 處理容器載入 DICOM 格式的 CT 掃描資料，並轉換為可處理的格式。
  2. perform_svd：使用 Spark 和 Mahout 容器執行奇異值分解（SVD），這是降噪的核心數學處理步驟。
  3. visualize_results：使用 Python 視覺化工具展示和比較降噪前後的結果。

每個步驟都明確定義了所需的輸入、輸出和資源需求。這種方式允許在同一個工作流程中無縫結合不同技術堆疊的工具，充分發揮各自的優勢。例如，Spark/Mahout 適合大規模矩陣運算，而 Python 則擅長資料處理和視覺化。

多工具協作的優勢

這個 CT 掃描降噪案例完美展示了 Kubeflow 支援多語言、多工具協作的優勢：

  1. 專業工具利用：每個步驟都使用最適合該任務的工具 - pydicom 處理醫學影像格式、Spark/Mahout 進行大規模矩陣運算、Python 進行視覺化。

  2. 資源最佳化：不同步驟可以根據需求分配不同的計算資源，例如為 SVD 計算分配更多的 CPU 和記憶體。

  3. 工作流程自動化：整個複雜流程透過 Kubeflow 管道自動化，減少了人工干預和錯誤機會。

  4. 可重複性：整個流程被封裝為容器和管道定義，確保結果的可重複性和一致性。

  5. 擴充套件性：可以輕鬆擴充套件管道以處理更大的資料集或增加更多處理步驟。

在實際應用中，這種多工具協作方式讓我們能夠充分利用各種開放原始碼和專有工具的優勢，而不必受限於單一技術堆疊的侷限。

玄貓

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。