MLMD 與 MLflow 機器學習後設資料管理

– 12 分鐘閱讀

MLMD 和 MLflow 作為開源方案，各有其優缺點，適用於不同的場景。MLMD 輕量且靈活，適合對後設資料有精細化管理需求的團隊，可以與現有系統深度整合。但它缺乏 UI 和視覺化工具，需要使用者自行開發查詢和展示介面。MLflow 提供了更全面的 MLOps 功能，包括實驗跟蹤、模型管理和佈署，易於使用且功能豐富，適合需要一站式解決方案的團隊。但其功能的完整性也意味著更高的學習成本和系統複雜度。選擇哪種工具取決於團隊的規模、技術堆疊和專案需求。小型團隊或專注於特定後設資料管理的專案可以考慮 MLMD，而追求完整 MLOps 功能的團隊則更適合 MLflow。

8.4 開源解決方案：MLMD 與 MLflow 的介紹與比較

在機器學習（ML）的開發過程中，後設資料（metadata）的管理是至關重要的。後設資料提供了有關資料、模型和訓練過程的資訊，能夠幫助資料科學家和機器學習工程師更好地理解、追蹤和最佳化模型訓練流程。本文將介紹兩個廣泛使用的開源後設資料管理工具：MLMD（ML Metadata）和 MLflow。

8.4.1 ML Metadata（MLMD）

MLMD 是一個輕量級的函式庫，用於記錄和檢索與機器學習開發者和資料科學家工作流程相關的後設資料。它是 TensorFlow Extended（TFX）的一部分，但設計為可以獨立使用。例如，Kubeflow 使用 MLMD 來管理其管道和筆記本服務所產生的後設資料。

系統概述

MLMD 的後設資料儀表化（instrumentation）可以透過兩種不同的後端進行設定：SQL 或 gRPC 伺服器。如圖 8.6 所示，每個 ML 管道/工作流程的步驟使用 MLMD 函式庫（MLMD 使用者端 API）來儀表化後設資料。在後端，MLMD 將後設資料儲存到關聯式資料函式庫中，例如 mySQL 或 PostgreSQL。

您可以選擇讓每個 MLMD 函式庫直接與 SQL 伺服器通訊（圖 8.6，A），或者使用 MLMD 函式庫中的伺服器設定程式碼來設定 gRPC 伺服器，並讓使用者端函式庫與伺服器通訊（圖 8.6，B）。方法 A 很簡單，您不需要託管專用的日誌記錄伺服器，但建議使用方法 B，因為它避免了暴露後端資料函式庫。

# 定義資料集後設資料
data_artifact = metadata_store_pb2.Artifact()
data_artifact.uri = 'path/to/data'
data_artifact.properties["day"].int_value = 1
data_artifact.properties["split"].string_value = 'train'
data_artifact.type_id = data_type_id
[data_artifact_id] = store.put_artifacts([data_artifact])

# 定義訓練執行後設資料
trainer_run = metadata_store_pb2.Execution()
trainer_run.type_id = trainer_type_id
trainer_run.properties["state"].string_value = "RUNNING"
[run_id] = store.put_executions([trainer_run])

# 定義模型後設資料
model_artifact = metadata_store_pb2.Artifact()
model_artifact.uri = 'path/to/model/file'
model_artifact.properties["version"].int_value = 1
model_artifact.properties["name"].string_value = 'MNIST-v1'
model_artifact.type_id = model_type_id
[model_artifact_id] = store.put_artifacts([model_artifact])

# 定義實驗後設資料
my_experiment = metadata_store_pb2.Context()
my_experiment.type_id = experiment_type_id
my_experiment.name = "exp1"
my_experiment.properties["note"].string_value = "My first experiment."
[experiment_id] = store.put_contexts([my_experiment])

# 宣告模型、訓練執行和實驗之間的關係
attribution = metadata_store_pb2.Attribution()
attribution.artifact_id = model_artifact_id
attribution.context_id = experiment_id
association = metadata_store_pb2.Association()
association.execution_id = run_id
association.context_id = experiment_id
store.put_attributions_and_associations([attribution], [association])

#### 內容解密：

  1. metadata_store_pb2.Artifact()：用於建立 Artifact 物件，表示資料或模型等實體。
  2. store.put_artifacts() 和 store.put_executions()：將 Artifact 和 Execution 物件儲存到儲存後端。
  3. metadata_store_pb2.Context()：定義一個邏輯群組，用於將 Artifact 和 Execution 聯絡在一起。
  4. put_attributions_and_associations()：儲存 Artifact、Execution 和 Context 之間的關係。

搜尋後設資料

MLMD 不提供 UI 來顯示其儲存的後設資料。因此，為了查詢後設資料，我們需要使用其使用者端 API。以下是一個程式碼示例：

# 使用 MLMD API 查詢後設資料

#### 內容解密：

  1. 查詢後設資料：使用 MLMD 的使用者端 API 可以查詢儲存的後設資料。
  2. 靈活性：MLMD 允許透過不同的後端（SQL 或 gRPC 伺服器）進行設定，提供了靈活性。

8.4 開源後設資料管理解決方案

8.4.1 MLMD 與 MLflow 簡介

在機器學習（ML）開發的生命週期中，後設資料（metadata）和工件（artifact）的管理至關重要。開源社群提供了多種解決方案，其中包括 MLMD（Metadata）和 MLflow。本文重點介紹這兩種工具。

MLMD

MLMD 是用於記錄和管理機器學習工作流程中後設資料的函式庫。它提供了一種結構化的方式來儲存和查詢與 ML 工作流程相關的後設資料，如工件、執行和上下文。MLMD 的設計允許使用者靈活地定義自己的資料模型，並透過其 API 進行後設資料的儲存和檢索。

以下是一個使用 MLMD 檢索工件的範例：

artifacts = store.get_artifacts()
[stored_data_artifact] = store.get_artifacts_by_id([data_artifact_id])
artifacts_with_uri = store.get_artifacts_by_uri(data_artifact.uri)
artifacts_with_conditions = store.get_artifacts(
    list_options=mlmd.ListOptions(
        filter_query='uri LIKE "%/data" AND properties.day.int_value > 0'
    )
)

內容解密：

  • store.get_artifacts()：查詢所有已註冊的工件。
  • store.get_artifacts_by_id()：根據 ID 查詢特定的工件。
  • store.get_artifacts_by_uri()：根據 URI 查詢工件。
  • store.get_artifacts() 結合 filter_query：根據特定條件（如 URI 和屬性）查詢工件。

8.4.2 MLflow

MLflow 是一個開源的 MLOps 平台，旨在管理 ML 生命週期，包括實驗、重現性、佈署和模型註冊。與 MLMD 相比，MLflow 不僅是一個函式庫，而是一個完整的系統，提供多個元件來支援 ML 工作流程的不同方面。

MLflow 的主要元件

  1. MLflow Tracking：用於記錄和查詢後設資料的服務。
  2. MLflow Projects：用於封裝程式碼以實作可重複使用的格式。
  3. MLflow Models：用於封裝 ML 模型，以便在不同的服務工具中使用。
  4. MLflow Model Registry：用於管理 MLflow 模型的整個生命週期，包括模型沿襲、版本控制、註解和生產環境的升級。

使用 MLflow 進行後設資料管理

MLflow 提供了一種簡單的方式來記錄後設資料和工件到其跟蹤伺服器。使用者可以透過建立一個活動的執行（run）並使用日誌函式來記錄引數、指標、標籤和工件。

import mlflow

remote_server_uri = "..."
mlflow.set_tracking_uri(remote_server_uri)
mlflow.set_experiment("/my-experiment")

with mlflow.start_run():
    mlflow.log_param("parameter_a", 1)
    mlflow.log_metric("metric_b", 2)
    mlflow.log_artifact("features.txt")

內容解密：

  • mlflow.set_tracking_uri()：設定 MLflow 跟蹤伺服器的 URL。
  • mlflow.set_experiment()：設定實驗名稱。
  • mlflow.start_run()：建立一個新的執行或還原一個已有的執行。
  • mlflow.log_param()、mlflow.log_metric()、mlflow.log_artifact()：分別用於記錄引數、指標和工件。

自動記錄後設資料

MLflow 支援自動記錄後設資料的功能，使用者可以透過呼叫 mlflow.autolog() 或特定函式庫的自動記錄函式（如 mlflow.tensorflow.autolog()）來自動記錄後設資料和工件，而無需手動指定每一個日誌陳述式。

查詢後設資料

MLflow 的跟蹤 UI 允許使用者視覺化、搜尋和比較執行結果，以及下載執行工件或後設資料進行進一步分析。此外，使用者也可以透過 MLflow 的客戶端 API 以程式設計方式執行這些操作。

from mlflow.tracking import MlflowClient

client = MlflowClient()
active_run = client.get_run(run_id)
print("run_id: {}; lifecycle_stage: {}".format(run_id, active_run.info.lifecycle_stage))

內容解密：

  • MlflowClient()：初始化 MLflow 客戶端。
  • client.get_run(run_id)：根據執行 ID 取得執行後設資料。
  • active_run.info.lifecycle_stage：取得執行的生命週期階段。

本文介紹了 MLMD 和 MLflow 在後設資料管理方面的功能和用法。這些工具對於構建和管理機器學習工作流程至關重要，能夠幫助團隊更好地跟蹤和管理他們的 ML 專案。

工作流程協調（Workflow Orchestration）

在深度學習系統中，工作流程協調扮演著至關重要的角色。它負責管理工作流程的執行、監控和自動化。工作流程是一個抽象且廣泛的概念，本質上是一系列操作的有序集合，旨在完成某項較大的任務。

什麼是工作流程？

一般而言，工作流程是一系列操作的有序集合，這些操作共同構成了一個較大的任務。工作流程可以被視為一個有向無環圖（DAG），其中每個節點代表一個步驟，而邊則代表步驟之間的依賴關係。

步驟與依賴關係

  • 步驟（Step）：是最小的可重複計算單元，用於描述一個動作，如取得資料或觸發服務。一個步驟要麼成功，要麼失敗。
  • DAG（有向無環圖）：定義了步驟之間的依賴關係以及執行的順序。

以圖9.1中的自然語言處理（NLP）模型訓練工作流程為例，該工作流程包含多個步驟，每個步驟之間存在依賴關係。這些依賴關係透過實線箭頭表示，形成了一個無環的工作流程DAG。

為什麼深度學習系統需要工作流程協調？

手動執行工作流程並不是理想的選擇。當有多個工作流程需要管理和執行時，我們需要一個專門的系統來處理這些複雜性，這就是工作流程協調系統。

工作流程協調系統的功能

  • 管理工作流程的生命週期：包括建立、執行和故障排除。
  • 提供控制平面：讓資料科學家能夠管理深度學習系統中的所有自動化任務。

設計通用工作流程協調系統

在設計工作流程協調系統時，需要考慮以下幾個關鍵方面：

  1. 工作流程的定義和管理：如何定義和管理工作流程的DAG結構。
  2. 步驟的執行和管理：如何執行和管理每個步驟，包括錯誤處理和重試機制。
  3. 依賴關係的管理：如何管理步驟之間的依賴關係，確保工作流程的正確執行。
  4. 監控和日誌記錄：如何監控工作流程的執行情況，並記錄相關的日誌資訊。

流行的開源工作流程協調系統

本章將介紹三個流行的開源工作流程協調系統：Airflow、Argo Workflows和Metaflow。

Airflow

Airflow是一個流行的開源工作流程協調系統，用於協調複雜的計算工作流程。它的主要特點包括：

  • 根據DAG的工作流程定義：使用Python程式碼定義工作流程的DAG結構。
  • 豐富的運算子：提供了多種內建的運算子，用於執行不同的任務，如執行Shell命令、執行Python程式碼等。
  • 可擴充套件性：支援自定義運算子和感測器，可以根據需要擴充套件其功能。

Argo Workflows

Argo Workflows是一個為Kubernetes設計的開源工作流程協調系統。它具有以下特點：

  • Kubernetes原生支援：充分利用Kubernetes的資源管理和排程能力。
  • 高效能：針對大規模工作流程進行了最佳化，能夠高效地管理和執行大量任務。
  • 靈活的工作流程定義：使用YAML或JSON檔案定義工作流程，支援複雜的工作流程結構。

Metaflow

Metaflow是一個由Netflix開源的工作流程協調系統，旨在簡化資料科學和機器學習工作流程的管理。它具有以下特點：

  • 以Python為中心：使用Python定義和管理工作流程，與資料科學家常用的工具和語言緊密整合。
  • 簡化的工作流程管理：提供了簡單易用的API，用於定義和管理工作流程。
  • 與AWS緊密整合：原生支援AWS服務，能夠無縫地與AWS上的資源進行整合。
本章重點

 工作流程是一個由一系列操作構成的有序集合，用於完成較大的任務。  工作流程協調系統負責管理工作流程的執行、監控和自動化。  Airflow、Argo Workflows和Metaflow是三個流行的開源工作流程協調系統，每個系統都有其特定的優點和適用場景。  選擇合適的工作流程協調系統可以提高深度學習系統的效率和可管理性。

9.1 工作流程協調簡介

在資訊科技產業中，工作流程（workflow）無處不在。只要能夠將一個流程定義為一系列單一任務或步驟的有向無環圖（DAG），這個流程就可以被視為一個工作流程。工作流程對於深度學習模型的開發至關重要。在生產環境中，大多數深度學習模型的建立活動都以工作流程的形式呈現和執行。

9.1.1 為什麼需要工作流程？

在深度學習專案的開發過程中，將一個大型的程式碼拆分成多個可重複使用的元件（步驟）是非常重要的。這種做法可以提高資料科學家的生產力，並促進團隊之間的協作。例如，在圖9.2中，三個不同的模型訓練專案（A、B和C）具有不同的DAG，但每個DAG中的步驟高度重疊。這意味著許多步驟可以被重複使用，從而避免了重複勞動。

9.1.2 什麼是工作流程協調？

一旦定義了一個工作流程，下一步就是執行它。執行工作流程意味著根據工作流程DAG中定義的順序執行工作流程步驟。工作流程協調是指對工作流程的執行和監控。它的目標是自動化工作流程中定義的任務執行。在實踐中，工作流程協調的概念通常擴充套件到整個工作流程管理，包括建立、排程、執行和監控多個工作流程。

為什麼深度學習系統需要工作流程協調？

理想情況下，我們應該能夠將整個深度學習專案編碼為一個整體。然而，在原型設計階段之後，我們需要將原型程式碼轉換為工作流程，並在工作流程協調系統中執行它。這是因為工作流程協調提供了自動化和工作分享的優勢。

圖9.1：一個範例模型訓練工作流程的DAG

在圖9.1中，我們可以看到一個範例模型訓練工作流程的DAG，其中包含多個步驟。橢圓形和菱形代表不同的步驟型別，實線箭頭表示步驟之間的依賴關係，虛線箭頭代表從步驟傳送的外部Web請求。

圖9.2：深度學習工作流程由許多可重複使用的任務組成

圖9.2展示了三個不同的模型訓練專案（A、B和C）的工作流程。儘管每個專案的工作流程DAG不同，但步驟之間存在高度重疊。這意味著許多步驟可以被重複使用，從而提高生產力。

9.1.3 在深度學習中使用工作流程協調的挑戰

雖然工作流程系統可以為深度學習專案開發提供許多好處，但在原型設計階段使用工作流程來測試深度學習演算法思想卻很麻煩。這是因為在本地孵化階段，資料科學家需要在本地/開發環境中進行資料探索和模型訓練原型設計。當原型設計完成並且專案看起來很有前景時，資料科學家才開始進行生產上線，將原型程式碼轉移到生產系統。

原型設計與生產之間的差距

在生產階段，資料科學家將原型程式碼轉換為工作流程，將程式碼分解為多個步驟，並定義一個工作流程DAG，然後將工作流程提交給工作流程協調系統。之後，協調系統接管並根據其排程執行工作流程。

圖9.3：資料科學家對深度學習專案開發過程的看法

圖9.3展示了資料科學家對深度學習專案開發過程的看法。可以看到，這個過程分為兩個階段：本地孵化階段和生產階段。在本地孵化階段，資料科學家進行資料探索和模型訓練原型設計。當原型設計完成後，他們開始進行生產上線，將原型程式碼轉移到生產系統。

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title MLMD 與 MLflow 機器學習後設資料管理

package "機器學習流程" {
    package "資料處理" {
        component [資料收集] as collect
        component [資料清洗] as clean
        component [特徵工程] as feature
    }

    package "模型訓練" {
        component [模型選擇] as select
        component [超參數調優] as tune
        component [交叉驗證] as cv
    }

    package "評估部署" {
        component [模型評估] as eval
        component [模型部署] as deploy
        component [監控維護] as monitor
    }
}

collect --> clean : 原始資料
clean --> feature : 乾淨資料
feature --> select : 特徵向量
select --> tune : 基礎模型
tune --> cv : 最佳參數
cv --> eval : 訓練模型
eval --> deploy : 驗證模型
deploy --> monitor : 生產模型

note right of feature
  特徵工程包含：
  - 特徵選擇
  - 特徵轉換
  - 降維處理
end note

note right of eval
  評估指標：
  - 準確率/召回率
  - F1 Score
  - AUC-ROC
end note

@enduml

此圖示說明瞭深度學習專案開發過程中的不同階段，以及它們之間的依賴關係。

在實踐中，這個過程對於資料科學家來說存在一些問題。雖然工程師可能會覺得這個過程不錯，但實際上它存在一些挑戰。資料科學家需要在不同的環境之間切換，並將原型程式碼轉換為工作流程，這需要額外的努力和時間。

內容解密：

  1. 圖9.3的意義：圖9.3展示了深度學習專案開發過程中的兩個主要階段：本地孵化階段和生產階段。它強調了在不同階段之間轉換的挑戰。
  2. 原型設計與生產之間的差距：在原型設計階段，資料科學家專注於模型的開發，而在生產階段，他們需要將模型佈署到生產環境中。這兩個階段之間存在明顯的差異，需要額外的努力來橋接這兩個階段。
  3. 工作流程協調的重要性：工作流程協調是深度學習專案開發中的關鍵組成部分，它能夠自動化任務執行、促進團隊協作並提高生產力。

透過瞭解這些挑戰和工作流程協調的重要性，我們可以更好地設計和實作深度學習專案，從而提高開發效率和模型品質。

玄貓 BlackCat

玄貓 BlackCat

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