データセットと ML モデルのバージョニング: 本番環境での DVC
94% の精度を達成するモデルをトレーニングし、本番環境にリリースしてから、 3 か月後、データセットのどのバージョンが使用されたかを正確に誰も知らないことがわかりました。 どのハイパーパラメータがアクティブであったか。モデルは生産中ですが、 再現不可能な。 残念ながら、このシナリオは ML チームを採用していない場合の例外ではなく標準です。 構造化されたバージョン管理の実践。
MLOps でのバージョニングはコード ファイルだけではありません。 データセット、モデル、 パイプラインと構成。 Git はソース コードを非常にうまく処理しますが、失敗します ML データセットに典型的な数百 GB のファイルを使用します。そしてここで登場します DVC (データバージョン) コントロール)、Git の原則をデータの世界にもたらすオープンソース ツールであり、 機械学習モデル。
In November 2025, lakeFS acquired DVC, confirming the centrality of this tool in the MLOps ecosystem and ensuring its continuity as a 100% open-source project.この中で article we will explore DVC in depth: setup, pipeline, remote storage, Git integration and MLflow, comparison with lakeFS and best practices for teams of any size.
この記事で学べること
- MLOps でバージョニングが基本である理由と、コードのバージョニングとの違い
- 完全な DVC セットアップ: 初期化、データ追跡、自動 .dvc ファイルおよび .gitignore
- dvc.yaml を使用した DVC パイプライン: ステージ、deps、outs、params、および dvc.lock ファイル
- リモート ストレージ: AWS S3、Google Cloud Storage、および Azure Blob Storage の構成
- DVC Python API: プログラムによるアクセス用の dvc.api.open() および dvc.api.get_url()
- データセットのバージョンを実験にリンクするための DVC + MLflow の統合
- DVC と LakeFS のアーキテクチャの比較: いつどのツールを使用するか
- 予算が限られている (年間 5,000 ユーロ未満) ML チーム向けのベスト プラクティス
MLOps シリーズと本番環境における機械学習
| # | アイテム | 集中 |
|---|---|---|
| 1 | MLOps: 実験から実稼働へ | 基盤と完全なライフサイクル |
| 2 | CI/CD を使用した ML パイプライン | ML 用の GitHub アクションと Docker |
| 3 | 現在地 - DVC と LakeFS のバージョン管理 | データセットとモデルのバージョン管理 |
| 4 | MLflow を使用した実験の追跡 | 追跡、モデル登録、比較 |
| 5 | モデルドリフトの検出 | 自動監視と再トレーニング |
| 6 | FastAPI + Uvicorn によるサービスの提供 | 本番環境へのモデルのデプロイメント |
| 7 | Kubernetes での ML のスケーリング | KubeFlow と Seldon コア |
| 8 | ML モデルの A/B テスト | 方法論と実装 |
| 9 | ML ガバナンス | コンプライアンス、EU の AI 法、倫理 |
| 10 | ケーススタディ: チャーン予測 | 本番環境におけるエンドツーエンドのパイプライン |
機械学習におけるバージョン管理の問題
従来のソフトウェア プロジェクトでは、Git はほとんどすべてのバージョン管理の問題を解決します。 これは軽くてテキストであり、自然に差分やマージに適しています。ただし、ML プロジェクトでは、 コードは方程式の一部にすぎません。モデルの再現性にはトレースが必要です 同時に:
- トレーニングと検証のデータセット: 多くの場合、ギガバイトまたはテラバイトの構造化データまたは非構造化データ
- モデルアーティファクト: 数百 MB になる可能性がある .pkl、.pt、.h5 ファイル
- ハイパーパラメータと設定: 学習率、アーキテクチャ、前処理ステップ
- 指標と結果: 各実験の精度、F1、AUC-ROC
- 環境の依存関係: Python のバージョン、ライブラリ、CUDA ドライバー
Git は大きなバイナリ ファイル用に設計されていません: 500 MB モデルの各プッシュ 履歴全体のクローンが作成されるため、リポジトリは数か月以内に使用できなくなります。解決策 バージョン管理を放棄するのではなく、アーティファクトの種類ごとに適切なツールを使用する必要があります。
ML バージョニングの欠如によるコスト
| シナリオ | バージョン管理なしのコスト | DVC ソリューション |
|---|---|---|
| 劣化した量産モデル | 以前のモデルにロールバックできません | git チェックアウト + dvc チェックアウト |
| パイプライン内の破損したデータセット | 再ダウンロードして最初から処理する | DVC チェックアウト前のデータセット |
| 規制監査（AI法EU） | どのデータがモデルを形成したかを証明することは不可能 | .dvc ファイルにプロットされたデータセットのハッシュ |
| チームのコラボレーション | すべてのデータ サイエンティストは異なるバージョンのデータを使用します | dvc pull はチーム全体を同期します |
| 実験再現 | 6 か月後には結果が再現できない | git checkout + dvc repro はすべてを再構築します |
DVC のセットアップと構成
DVC は、追加レイヤーとして既存の Git リポジトリに統合されます。サーバーは必要ありません 中央で実行され、ローカルで実行され、チームの成長に応じてクラウド ストレージに簡単に拡張できます。 インストールは pip 経由で行われ、さまざまなストレージ バックエンドがサポートされます。
# Installazione base
pip install dvc
# Con supporto remote storage (scegli in base al provider)
pip install dvc[s3] # Amazon S3
pip install dvc[gs] # Google Cloud Storage
pip install dvc[azure] # Azure Blob Storage
pip install dvc[ssh] # SSH/SFTP
pip install dvc[all] # Tutti i backend
# Verifica installazione
dvc --version
# DVC 3.x.xインストールしたら、Git リポジトリで DVC を初期化します。コマンドは構造を作成します 必要なディレクトリの .gitignore を自動的に更新してファイルを除外します Git 追跡からのデータ:
# Inizializza Git (se non già fatto)
git init
git add .
git commit -m "Initial commit"
# Inizializza DVC
dvc init
# Struttura creata da dvc init:
# .dvc/
# ├── config # Configurazione DVC (tracciato da Git)
# ├── .gitignore # Esclude cache e tmp
# ├── cache/ # Cache locale degli artefatti (NON tracciata da Git)
# └── tmp/
# Commit dei file di configurazione DVC
git add .dvc/ .gitignore
git commit -m "chore: initialize DVC"データセットとモデルの追跡
DVC の核心とコマンド dvc addと同様に機能します
git add ただし、大きなファイルの場合です。 DVC はファイルの MD5 ハッシュを計算します。
それをローカル キャッシュに移動し、ファイルを作成します .dvc (小さなテキストファイル
Git によって追跡されます) ハッシュを指します:
# Aggiungere un dataset al tracking DVC
dvc add data/raw/training_data.csv
# DVC ha creato:
# - data/raw/training_data.csv.dvc (puntatore, tracciato da Git)
# - data/raw/.gitignore (esclude il file originale da Git)
# Contenuto del file .dvc generato:
# outs:
# - md5: a1b2c3d4e5f6...
# size: 524288000
# path: training_data.csv
# Aggiungere il puntatore a Git
git add data/raw/training_data.csv.dvc data/raw/.gitignore
git commit -m "feat: add training dataset v1.0"
git tag "dataset-v1.0"
# Aggiungere un modello addestrato
dvc add models/churn_model.pkl
git add models/churn_model.pkl.dvc models/.gitignore
git commit -m "feat: add trained churn model v1 (accuracy=0.94)"
git tag "model-v1.0".dvc ファイルの仕組み
ファイル .dvc および、その MD5 (または SHA-256) ハッシュを含む軽量 YAML ファイル
元のファイルの内容、そのサイズ、相対パス。このハッシュは決定的です。
同じファイルは常に同じハッシュを生成するため、ファイルの整合性を検証できます。
いつでもデータを。 Git は、 .dvc ファイル、データ ファイル
実際にはローカル DVC キャッシュまたはリモート ストレージに存在します。
DVC を使用した日常のワークフロー
DVC を使用した一般的なワークフローは、Git サイクルに従い、次の点が追加されます。 dvc push e
dvc pull データをリモート ストレージと同期するには:
# Workflow DVC quotidiano
# 1. Pull dati aggiornati dal remote
git pull
dvc pull
# 2. Modifica dataset o allena nuovo modello
python scripts/preprocess.py
python scripts/train.py
# 3. Traccia nuovi artefatti
dvc add data/processed/features.parquet
dvc add models/churn_model_v2.pkl
# 4. Commit codice e puntatori
git add .
git commit -m "feat: retrain model with new features (F1=0.92)"
# 5. Push dati al remote storage
dvc push
# 6. Push codice a Git
git push
# ---- Sul computer di un collega ----
git pull # Scarica codice e .dvc files
dvc pull # Scarica i dati dal remote storageリモートストレージ: S3、GCS、Azure
リモート ストレージは DVC におけるコラボレーションの中心です。それがなければデータは存在します ローカルのみであり、バージョン管理はチームに利益をもたらしません。 DVC はすべての主要なものをサポートします クラウド プロバイダーだけでなく、SSH または NFS 経由のオンプレミス ソリューションも利用できます。
# ==================== AWS S3 ====================
# Prerequisiti: pip install dvc[s3], AWS credentials configurate
# Aggiungere S3 come remote di default
dvc remote add -d myremote s3://my-ml-bucket/dvc-storage
# Configurazione con access keys (per CI/CD, preferire IAM roles)
dvc remote modify myremote access_key_id $AWS_ACCESS_KEY_ID
dvc remote modify myremote secret_access_key $AWS_SECRET_ACCESS_KEY
dvc remote modify myremote region eu-west-1
# Per credenziali sensibili, usare config locale (non tracciata da Git)
dvc remote modify --local myremote access_key_id $AWS_ACCESS_KEY_ID
dvc remote modify --local myremote secret_access_key $AWS_SECRET_ACCESS_KEY
# ==================== Google Cloud Storage ====================
# Prerequisiti: pip install dvc[gs], gcloud auth configurato
dvc remote add -d gcsremote gs://my-ml-bucket/dvc-storage
# Con Service Account (per produzione)
dvc remote modify gcsremote credentialpath /path/to/service-account.json
# ==================== Azure Blob Storage ====================
# Prerequisiti: pip install dvc[azure]
dvc remote add -d azureremote azure://mycontainer/dvc-storage
# Configurazione connection string
dvc remote modify --local azureremote connection_string $AZURE_CONN_STRING
# ==================== Verifica e Operazioni ====================
# Mostra la configurazione remota
dvc remote list
# Push di tutti gli artefatti tracciati
dvc push
# Push solo di file specifici
dvc push models/churn_model.pkl.dvc
# Pull di tutti gli artefatti
dvc pull
# Verifica stato sincronizzazione
dvc status --cloud資格情報のセキュリティ
AWS、GCS、または Azure の認証情報をファイルに含めないでください。 .dvc/config 追跡された
Gitから。常に使用する --local 書き込む .dvc/config.local
(Git によって自動的に無視されます)、または変数を介して資格情報を構成します
CI/CD システムの環境または IAM ロール。 Kubernetes アーキテクチャでは、i を使用します。
S3 への安全なアクセスのための IRSA (サービス アカウントの IAM ロール) を備えた ServiceAccount
ハードコードされた資格情報。
限られた予算でのセットアップ: 無料の代替手段としての DagsHub
予算が年間 5,000 ユーロ未満のチーム向けに、DagsHub は DVC リモート ストレージの無料ホスティングを提供します (パブリック リポジトリあたり最大 10GB) MLflow のネイティブ統合。そして解決策 スタートアップや学術チームに最適:
# DagsHub come remote storage gratuito
# 1. Crea account su dagshub.com e un nuovo repository
# 2. Configura il remote DagsHub
dvc remote add origin https://dagshub.com/username/my-ml-project.dvc
# 3. Autenticazione con token personale
dvc remote modify origin --local auth basic
dvc remote modify origin --local user username
dvc remote modify origin --local password $DAGSHUB_TOKEN
# 4. Push e pull normali
dvc push
dvc pullDVC パイプライン: dvc.yaml による再現性
パイプラインは DVC の最も強力な機能です。パイプラインを使用すると、ワークフローを定義できます。 一連の ML を完成させる インターンシップ お互いに依存している。 DVC は、 ステージ間の依存関係と、入力が変更されたもののみを再実行します。 機械学習用のインテリジェントな Makefile。
パイプラインはファイルで定義されます dvc.yaml とその状態 (すべてのハッシュ
入力と出力) とプロット dvc.lock。走るとき
dvc repro, DVC は現在の状態を dvc.lock e
無効化されたステージのみを再実行します。
# dvc.yaml - Pipeline ML completa per churn prediction
stages:
# Stage 1: Download e validazione dei dati raw
fetch_data:
cmd: python src/data/fetch_data.py
deps:
- src/data/fetch_data.py
params:
- data.source_url
- data.date_range
outs:
- data/raw/transactions.parquet
- data/raw/customers.csv
# Stage 2: Preprocessing e feature engineering
preprocess:
cmd: python src/features/preprocess.py
deps:
- src/features/preprocess.py
- data/raw/transactions.parquet
- data/raw/customers.csv
params:
- features.window_days
- features.aggregations
outs:
- data/processed/features.parquet
- data/processed/feature_names.json
# Stage 3: Split train/validation/test
split:
cmd: python src/data/split.py
deps:
- src/data/split.py
- data/processed/features.parquet
params:
- split.train_ratio
- split.val_ratio
- split.random_seed
outs:
- data/splits/train.parquet
- data/splits/val.parquet
- data/splits/test.parquet
# Stage 4: Training del modello
train:
cmd: python src/models/train.py
deps:
- src/models/train.py
- data/splits/train.parquet
- data/splits/val.parquet
params:
- model.type
- model.n_estimators
- model.max_depth
- model.learning_rate
outs:
- models/churn_model.pkl
- models/feature_importance.json
metrics:
- metrics/train_metrics.json:
cache: false
# Stage 5: Valutazione sul test set
evaluate:
cmd: python src/models/evaluate.py
deps:
- src/models/evaluate.py
- models/churn_model.pkl
- data/splits/test.parquet
outs:
- reports/confusion_matrix.png:
cache: false
metrics:
- metrics/test_metrics.json:
cache: false
パイプラインパラメータはファイルで定義されます params.yaml、つまり
Git によって追跡されます。これにより、異なるハイパーパラメータを使用した実験を比較できます。
使用して dvc params diff:
# params.yaml - Configurazione centralizzata
data:
source_url: "s3://my-data-bucket/raw/2025/"
date_range: "2024-01-01:2025-01-01"
features:
window_days: 30
aggregations:
- mean
- std
- max
split:
train_ratio: 0.7
val_ratio: 0.15
random_seed: 42
model:
type: "xgboost"
n_estimators: 500
max_depth: 6
learning_rate: 0.05
subsample: 0.8パイプラインの実行と管理
# Eseguire l'intera pipeline (solo stage invalidati)
dvc repro
# Forzare ri-esecuzione di tutti gli stage
dvc repro --force
# Eseguire solo fino a uno stage specifico
dvc repro evaluate
# Visualizzare il DAG della pipeline
dvc dag
# Output:
# +------------+
# | fetch_data |
# +------------+
# * *
# *** ***
# * *
# +-----------+ +----------+
# | preprocess| | |
# +-----------+ +----------+
# *
# ...
# Confrontare metriche tra commit
dvc metrics show
dvc metrics diff HEAD~1
# Confrontare parametri tra branch
dvc params diff main feature/new-model
# Visualizzare differenze nei dati
dvc diffDVC の Python API: プログラムによるデータ アクセス
DVC の Python API を使用すると、バージョン管理されたデータセットとモデルに直接アクセスできます 最初にファイルを手動でダウンロードする必要がなく、Python コードからダウンロードできます。そして特に役立つのが 推論パイプラインまたは動的にロードしたいサービス提供システム内 モデルの正しいバージョン。
import dvc.api
import pandas as pd
import pickle
import json
# ==================== dvc.api.open() ====================
# Accede direttamente al remote storage senza download locale
# Leggere un dataset CSV da una versione specifica
with dvc.api.open(
"data/raw/customers.csv",
repo="https://github.com/myorg/ml-project",
rev="dataset-v2.1", # tag Git
mode="r"
) as f:
df = pd.read_csv(f)
print(f"Dataset caricato: {len(df)} righe")
# Leggere un file Parquet (file binario)
with dvc.api.open(
"data/processed/features.parquet",
rev="model-v3.0",
mode="rb"
) as f:
features_df = pd.read_parquet(f)
# ==================== dvc.api.get_url() ====================
# Ottiene l'URL diretto al remote storage per una versione specifica
url = dvc.api.get_url(
"models/churn_model.pkl",
repo="https://github.com/myorg/ml-project",
rev="model-v2.5"
)
print(f"Model URL: {url}")
# Output: s3://my-ml-bucket/dvc-storage/ab/cd1234...
# ==================== Caricamento Modello Versioned ====================
def load_model(version: str):
"""Carica un modello da una specifica versione DVC."""
with dvc.api.open(
"models/churn_model.pkl",
rev=version,
mode="rb"
) as f:
model = pickle.load(f)
# Carica anche i metadata del modello
with dvc.api.open(
"models/feature_importance.json",
rev=version,
mode="r"
) as f:
metadata = json.load(f)
return model, metadata
# Uso in produzione
model, metadata = load_model("model-v3.0")
print(f"Modello caricato. Features: {metadata['n_features']}")DVC と Git の統合: 完全なワークフロー
DVC の真の力は、Git と深く統合されたときに現れます。すべての Git コミット
ファイルを更新する .dvc o dvc.lock スナップショットを表します
ML プロジェクトの状態全体 (コード、データ、モデルを合わせて) を再現可能。
# Workflow Git+DVC per un ciclo di sviluppo ML
# ==================== Feature Branch Workflow ====================
# 1. Crea un branch per il nuovo esperimento
git checkout -b experiment/xgboost-v2
# 2. Aggiorna i parametri
# Modifica params.yaml: learning_rate: 0.01, n_estimators: 1000
# 3. Esegui la pipeline
dvc repro
# 4. Controlla le metriche
dvc metrics show
# Path accuracy f1_score auc_roc
# metrics/test_metrics.json 0.9423 0.8891 0.9234
# 5. Confronta con main
dvc metrics diff main
# Path Metric Old New Change
# metrics/test_metrics.json accuracy 0.9301 0.9423 +0.0122
# 6. Commit e push
git add dvc.lock params.yaml metrics/
git commit -m "experiment: XGBoost v2 - accuracy +1.2% (0.9423)"
dvc push
git push origin experiment/xgboost-v2
# 7. Crea Pull Request e, dopo merge, tagga il modello
git checkout main
git merge experiment/xgboost-v2
git tag -a "model-v2.0" -m "XGBoost v2: accuracy=0.9423, F1=0.8891"
git push --tags
# ==================== Rollback a Versione Precedente ====================
# Situazione: il modello v2.0 ha un bug in produzione
# 1. Torna al commit del modello v1.0
git checkout model-v1.0
# 2. Ripristina i dati e i modelli a quella versione
dvc checkout
# 3. Verifica il modello ripristinato
python src/models/evaluate.py
# 4. Il sistema di serving può ora ricaricare model-v1.0DVC + MLflow: データセットのバージョニングと実験の追跡
DVC と MLflow は相互に補完します: DVC はデータとモデルのバージョン管理を処理します (大きなアーティファクト)、MLflow はパラメータ、メトリクス、および 実験の実行。それらを統合するということは、それぞれについて完全な監査証跡を持つことを意味します。 MLflow を実行すると、どのバージョンのデータセットが使用されたかを正確に知ることができます。
import mlflow
import mlflow.sklearn
import dvc.api
import subprocess
import pandas as pd
from sklearn.metrics import accuracy_score, f1_score, roc_auc_score
from xgboost import XGBClassifier
def get_dvc_metadata() -> dict:
"""Raccoglie metadata DVC per il run MLflow corrente."""
# Hash del dataset corrente
result = subprocess.run(
["dvc", "status", "--json"],
capture_output=True, text=True
)
# Ottieni la revisione Git corrente (che punta ai dati)
git_rev = subprocess.run(
["git", "rev-parse", "HEAD"],
capture_output=True, text=True
).stdout.strip()
# URL del remote storage per il dataset
data_url = dvc.api.get_url("data/splits/train.parquet")
return {
"dvc.git_rev": git_rev,
"dvc.data_url": data_url,
"dvc.train_dataset": "data/splits/train.parquet",
"dvc.data_version": "v2.1",
}
def train_with_tracking(params: dict) -> None:
"""Training con tracking completo DVC + MLflow."""
mlflow.set_experiment("churn-prediction")
with mlflow.start_run(run_name="xgboost-dvc-integrated") as run:
# Logga metadata DVC - collega run MLflow a versione dati
dvc_metadata = get_dvc_metadata()
mlflow.log_params(dvc_metadata)
mlflow.log_params(params)
# Carica dati dalla versione DVC corrente
train_df = pd.read_parquet("data/splits/train.parquet")
val_df = pd.read_parquet("data/splits/val.parquet")
test_df = pd.read_parquet("data/splits/test.parquet")
X_train = train_df.drop("churn", axis=1)
y_train = train_df["churn"]
X_test = test_df.drop("churn", axis=1)
y_test = test_df["churn"]
# Training
model = XGBClassifier(**params)
model.fit(X_train, y_train,
eval_set=[(val_df.drop("churn", axis=1), val_df["churn"])],
early_stopping_rounds=50,
verbose=False)
# Metriche
y_pred = model.predict(X_test)
y_prob = model.predict_proba(X_test)[:, 1]
metrics = {
"accuracy": accuracy_score(y_test, y_pred),
"f1_score": f1_score(y_test, y_pred),
"auc_roc": roc_auc_score(y_test, y_prob),
"best_iteration": model.best_iteration,
}
mlflow.log_metrics(metrics)
mlflow.sklearn.log_model(model, "model")
print(f"Run ID: {run.info.run_id}")
print(f"Accuracy: {metrics['accuracy']:.4f}")
print(f"Dataset version: {dvc_metadata['dvc.data_version']}")
if __name__ == "__main__":
params = {
"n_estimators": 500,
"max_depth": 6,
"learning_rate": 0.05,
"subsample": 0.8,
"use_label_encoder": False,
"eval_metric": "logloss",
}
train_with_tracking(params)DVC と LakeFS: いつどのツールを使用するか
2025 年 11 月に、lakeFS は DVC を買収しましたが、2 つのツールは依然として区別されています。 さまざまな使用例。選択はデータの規模と複雑さによって異なります インフラストラクチャとチームのニーズ。 2 つのツールは次のことに注意することが重要です。 これらは相互に排他的ではありません。企業チームは両方を使用することがよくあります。
DVC と LakeFS のアーキテクチャの比較
| サイズ | DVC | レイクFS |
|---|---|---|
| 建築 | クライアントのみ、サーバーは不要 | クライアント/サーバー、LakeFS サーバーのデプロイメントが必要 |
| データスケール | 最大 TB までのデータセット | ペタバイト規模のエンタープライズ データ レイク |
| 統合 | Git との統合 (同一のワークフロー) | S3 互換 API、Spark、Hive、Athena |
| データ分岐 | Git + .dvc ファイルのコミットを通じて | オブジェクトストアレベルのネイティブブランチ |
| 設定 | pip install + dvc init (分) | Docker/Kubernetes のデプロイ (時間/日) |
| ターゲット | データ サイエンティスト、小規模な ML チーム | データ エンジニアリング チーム、エンタープライズ企業 |
| 料金 | オープンソース、無料 (ストレージの料金のみお支払いください) | オープンソース + 有料エンタープライズ プラン |
| ML フレームワーク | Python ネイティブ、MLflow、DVCLive | Spark、Presto、DuckDB、すべてのビッグデータ ツール |
LakeFS: アーキテクチャとユースケース
LakeFS は、オブジェクト ストレージ (S3、GCS、Azure Blob) 上のメタデータ レイヤーとして動作します。 S3 互換 API を公開します。を使用せずにデータ ビューのバージョンを作成する 基礎となるファイルを複製します: ブランチの作成には数ミリ秒かかります データセットのサイズに関係なく。
# lakeFS: esempio di workflow con Python SDK
from lakefs_sdk import Client, Repository, Branch, Commit
import pandas as pd
# Connessione al server lakeFS
client = Client(
host="https://lakefs.mycompany.com",
username="access_key",
password="secret_key"
)
# Crea un repository
repo = client.repositories.create_repository(
"churn-data-lake",
storage_namespace="s3://my-data-lake/churn/",
default_branch="main"
)
# Workflow Git-like per dati
# 1. Crea branch per nuovo esperimento
experiment_branch = repo.branch("experiment/new-features").create(
source_reference="main"
)
# 2. Upload nuovi dati sul branch sperimentale
# (non impatta il branch main - zero copy)
experiment_branch.object("data/features_v2.parquet").upload(
content=new_features_df.to_parquet()
)
# 3. Commit sul branch
experiment_branch.commit(
message="feat: add recency features for churn model",
metadata={"model_version": "v3.0", "engineer": "alice"}
)
# 4. Merge solo se i risultati sono soddisfacenti
# (dopo validazione e A/B testing)
repo.branch("main").merge(source_ref="experiment/new-features")
# 5. Rollback immediato se qualcosa va storto
repo.branch("main").revert(
reference="main~1" # Torna al commit precedente
)どのツールを選択するか?
アメリカ合衆国 DVC もし：
- あなたはデータ サイエンティストまたは小規模チーム (1 ～ 10 名) です
- データセットは GB ～数 TB 程度です
- インフラストラクチャを追加せずに Git とネイティブに統合したい
- 限られた予算 (<5,000 ユーロ/年)
- 単一の ML 実験に重点を置いたワークフロー
アメリカ合衆国 レイクFS もし：
- ペタバイト規模のデータを含むエンタープライズ データ レイクがある
- Spark、Athena、Presto、またはその他のビッグ データ フレームワークを使用している
- コンプライアンスのためのデータ ガバナンスと監査証跡が必要です (GDPR、AI 法)
- 大規模なデータ エンジニアリング チーム (10 人以上) と協力する
- サーバー展開用の Kubernetes インフラストラクチャがすでにある
本番環境での ML バージョニングのベスト プラクティス
1. リポジトリ構造
適切に整理されたリポジトリ構造により、DVC のバージョン管理がより効果的になります チームのコラボレーションを促進します。
ml-project/
├── .dvc/
│ ├── config # Remote storage config (no secrets)
│ └── .gitignore
├── data/
│ ├── raw/
│ │ ├── .gitignore # Generato da DVC
│ │ ├── customers.csv.dvc
│ │ └── transactions.parquet.dvc
│ ├── processed/
│ │ └── features.parquet.dvc
│ └── splits/
│ ├── train.parquet.dvc
│ └── test.parquet.dvc
├── models/
│ ├── .gitignore
│ └── churn_model.pkl.dvc
├── metrics/
│ └── test_metrics.json # Tracciato da Git (piccolo file JSON)
├── reports/
│ └── confusion_matrix.png # Tracciato da Git (con cache: false)
├── src/
│ ├── data/
│ │ ├── fetch_data.py
│ │ └── split.py
│ ├── features/
│ │ └── preprocess.py
│ └── models/
│ ├── train.py
│ └── evaluate.py
├── dvc.yaml # Definizione pipeline
├── dvc.lock # Snapshot stato pipeline (tracciato da Git)
├── params.yaml # Iperparametri e configurazione
└── requirements.txt2. Git タグの命名規則
# Schema di naming raccomandato per tag Git+DVC
# Dataset versioning
git tag "data/raw/v1.0" # Prima raccolta dati
git tag "data/processed/v2.3" # Dataset preprocessato v2.3
git tag "data/features/v1.0-30d" # Features con finestra 30 giorni
# Model versioning
git tag "model/baseline/v1.0" # Modello baseline
git tag "model/xgboost/v2.1" # XGBoost tuned v2.1
git tag "model/prod/v3.0" # Versione in produzione attuale
# Pipeline snapshot
git tag "pipeline/2025-Q1" # Snapshot pipeline Q1 2025
# Esempio di workflow release
git tag -a "model/prod/v3.0" \
-m "Production model v3.0
Metrics:
- accuracy: 0.9423
- f1_score: 0.8891
- auc_roc: 0.9567
Dataset: data/features/v2.1
MLflow run: a1b2c3d4e5f6"
git push origin "model/prod/v3.0"3. GitHub アクションによる自動化
DVC を CI/CD パイプラインに統合すると、すべてのプル リクエストが確実に検証されます。 実際のデータと更新されたメトリクスを使用して:
# .github/workflows/ml-pipeline.yml
name: ML Pipeline Validation
on:
pull_request:
branches: [main]
paths:
- 'src/**'
- 'params.yaml'
- 'dvc.yaml'
jobs:
run-pipeline:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0 # Necessario per dvc metrics diff
- name: Setup Python
uses: actions/setup-python@v5
with:
python-version: '3.11'
- name: Install dependencies
run: |
pip install dvc[s3] -r requirements.txt
- name: Configure DVC remote
env:
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
run: |
dvc remote modify --local myremote \
access_key_id $AWS_ACCESS_KEY_ID
dvc remote modify --local myremote \
secret_access_key $AWS_SECRET_ACCESS_KEY
- name: Pull data
run: dvc pull data/splits/
- name: Run pipeline
run: dvc repro
- name: Check metrics regression
run: |
# Confronta metriche con main branch
dvc metrics diff main --md >> $GITHUB_STEP_SUMMARY
# Fallisce se accuracy scende sotto soglia
python scripts/check_metrics.py \
--min-accuracy 0.90 \
--metrics metrics/test_metrics.json
- name: Push updated artifacts
run: dvc push避けるべきアンチパターン
- 大きなデータ ファイルを Git に直接追加しないでください: 200MB の .pkl ファイルが 1 つだけでも、リポジトリのクローン作成が永久に遅くなります。
- パイプラインで生成されたファイルには dvc add を使用しないでください: パイプライン出力ファイルは次のように定義する必要があります。
outsindvc.yaml、手動で追加されていません - .gitignore の dvc.lock を無視しないでください: このファイルは再現性のために不可欠であり、Git によって常に追跡される必要があります。
- トレーニング後は DVC プッシュを忘れないでください: 押しつけずに、押しつける同僚
dvc pull彼らは新しいアーティファクトを見つけられないでしょう - dvc.yaml では絶対パスを使用しないでください: 異なるマシン間の移植性を確保するために、常に相対パスを使用してください。
結論と次のステップ
データセットとモデルのバージョン管理は贅沢ではなく、あらゆるプロジェクトにとって必要不可欠です 真剣なML。 DVC は問題をエレガントに解決します。Git とシームレスに統合し、サポートします。 すべての主要なクラウド プロバイダーに対応しており、すでにクラウド プロバイダーを利用している人にとっては学習曲線が緩やかです Git に精通している。 2025 年の LakeFS による買収により、エコシステムは次のようになりました。 さらに堅牢になり、エンタープライズ データ レイクとのより深い統合への道が開かれます。
スタートアップまたは中小企業チームの場合、この組み合わせは DVC + Git + S3 (または DagsHub の場合) 無料ストレージ） 低コストでプロフェッショナルなバージョニング システムを提供します 5 ～ 10 人のチームの場合、月額 100 ユーロ。ペタバイト規模のデータレイクを持つ企業の場合、 LakeFS は、S3 およびメジャーとの互換性を維持しながら、エンタープライズ機能を提供します。 ビッグデータフレームワーク。
シリーズの次の記事では、詳しく説明します。 MLflow による実験追跡: パラメータ、メトリクス、アーティファクトをログに記録する方法、モデル レジストリを使用して管理する方法 モデルのライフサイクル、および完全な MLOps システムのために MLflow を DVC と統合する方法。
リソースと次のステップ
- DVC の公式ドキュメント: dvc.org/doc
- LakeFS のドキュメント: docs.lakefs.io
- DagsHub の無料ストレージ: ダグシュブ.com
- このシリーズのサンプル GitHub リポジトリ (すべての MLOps 記事)
- 次の記事: MLflow による実験追跡 - 完全ガイド
- クロスリンク: 高度なディープラーニング - 高度なトレーニング
- クロスリンク: コンピューター ビジョン - 物体検出パイプライン
ML バージョニングに推奨されるスタック (予算 <5,000 ユーロ/年)
| 成分 | 楽器 | 推定年間コスト |
|---|---|---|
| データとモデルのバージョン管理 | DVC (オープンソース) | 無料 |
| リモートストレージ（最大100GB） | DagsHub または AWS S3 | 無料 / 年間最大 28 ユーロ |
| 実験の追跡 | MLflow セルフホスト型 | Gratis (solo costi VM) |
| CI/CD pipeline | GitHub Actions | Gratis (2000 min/mese) |
| VM per MLflow server | EC2 t3.small o equivalente | ~180 EUR/anno |
| Totale stimato | <250 EUR/anno |