はじめに
先日の講座で「モデルの共有や共同開発をDatabricksでどのように行うか」という質問をいただきました。Delta Sharing、Clean Rooms、MLflow Projectsなど複数の選択肢がありますが、ユースケースによって最適な方法が異なります。
特に多いのが「手元のPCでモデルを開発し、会社のDatabricksに持っていきたい」というケースです。本記事では、各オプションの概要と、このユースケースに対する具体的な解決策を解説します。
モデル共有オプションの比較
Databricksでは主に3つのアプローチでモデル共有・共同開発が可能です。
| 機能 | Delta Sharing | Clean Rooms | MLflow Projects |
|---|---|---|---|
| 主なユースケース | 組織間のモデル配布 | プライバシー保護下での共同開発 | チーム内のコード共有・再利用 |
| モデル共有 | ✅ (Public Preview) | ✅ | ✅ |
| 共同開発 | △ (読み取り専用) | ✅ (コード実行可能) | ✅ |
| データ保護 | 共有側が制御 | 双方のデータを保護 | N/A |
| クラウド横断 | ✅ | ✅ | ✅ (Git経由) |
| 非Databricksユーザー | ✅ (Open Sharing) | ❌ | ✅ |
Delta Sharing
Delta SharingはAIモデルの共有に対応しており、モデルを一箇所でトレーニングし、どこにでも展開できます。冗長性がなく、クラウドや複数のリージョンにまたがってシームレスに配信され、ネットワーク遅延を最適化できるなど、共有モデルにとって画期的な利点があります。
主な特徴
受信者がUnity Catalog対応のDatabricksワークスペースを使用している場合は、ノートブックファイル、ビュー(行レベルと列レベルでアクセスを制限する動的ビューを含む)、Unity Catalogボリューム、Unity Catalogモデルを共有に含めることができます。
- Databricks-to-Databricks共有でモデル、ノートブック、ボリュームを共有可能
- 外部パーティ(HuggingFace、PyTorchなど)でもモデルをロード可能
- データ複製なしでクラウド・リージョン横断で配布
適したユースケース
- 学習済みモデルを他組織に配布
- マルチクラウド環境でのモデル展開
- Marketplace経由でのモデル公開
📖 参考: Delta Sharingとは
Clean Rooms
Clean Roomsは、Delta Sharingとサーバーレスコンピューティングを使用して、複数の関係者がお互いのデータに直接アクセスすることなく、機密性の高い企業データについて共同で作業できる安全でプライバシー保護された環境を提供します。
主な特徴
クリーンルーム内では、参加者が自分のデータを安全に共有・結合し、Pythonなどの言語を使って複雑なワークロードを実行できます。PythonはML(機械学習)向けのネイティブサポートも提供しています。
Databricks Lakehouseプラットフォームは、機械学習やデータワークロードなどの複雑な計算をSQL、R、Scala、Java、Pythonなどあらゆる言語でデータ上で実行できる柔軟性をクリーンルーム参加者に提供します。
- 最大10のコラボレーターと協業可能
- AIモデル、テーブル、ボリュームの共有をサポート
- 機密データに直接アクセスせずにモデルをトレーニング
適したユースケース
- 医療データなど機密データを使ったML共同開発
- 複数企業間での不正検知モデル構築
- プライバシー規制下でのモデルトレーニング
📖 参考: Databricksクリーンルームとは
MLflow Projects
大規模な組織では、MLflowを使用してプロジェクト、モデル、結果を共有できます。どのチームもMLflow Projectsを使用して他のチームのコードを実行できるため、他のチームが使用できる有用なトレーニングやデータ準備のステップをパッケージ化したり、多くのチームの結果を同じタスクで比較したりできます。
主な特徴
- 再現可能なMLコードをパッケージング
- GitHubリポジトリから直接実行可能
- Model Registryで中央集権的なモデル管理
- 環境(Conda/Docker)を含めた再現性確保
適したユースケース
- 社内チーム間での前処理・学習コードの共有
- MLパイプラインの標準化
- R&Dから本番への移行
# 他チームのプロジェクトを直接実行
mlflow run https://github.com/team/ml-project.git -P alpha=0.5
📖 参考: MLflow Projects
ユースケース別の推奨
| シナリオ | 推奨 |
|---|---|
| 学習済みモデルを外部パートナーに配布 | Delta Sharing |
| 機密データで複数組織がモデル共同開発 | Clean Rooms |
| 社内チーム間でMLコード・モデルを共有 | MLflow Projects + Model Registry |
| マルチクラウドでモデルをデプロイ | Delta Sharing |
| プライバシー保護下でファインチューニング | Clean Rooms |
PC → Databricks のモデル共有
ここからは、よくある「手元のPCでモデルを開発し、会社のDatabricksに持っていきたい」というケースについて詳しく解説します。
ネットワークアクセスがある場合: リモートTracking Server
PCから会社のDatabricksに直接アクセスできる場合、MLflowのリモートTracking Server機能が最もシンプルです。
リモートMLflow追跡サーバーへの接続を設定することで、ローカルで開発しながら、Databricksホスト型サーバーに対して追跡できます。
import os
import mlflow
# Databricksワークスペースへの認証設定
os.environ["DATABRICKS_HOST"] = "https://<your-workspace>.cloud.databricks.com"
os.environ["DATABRICKS_TOKEN"] = "your-personal-access-token"
# Databricksをトラッキングサーバーとして設定
mlflow.set_tracking_uri("databricks")
mlflow.set_experiment("/Shared/my-project/experiment")
# 通常通りモデルを学習・記録
with mlflow.start_run():
model = train_model(...)
mlflow.log_param("learning_rate", 0.01)
mlflow.log_metric("accuracy", 0.95)
mlflow.sklearn.log_model(model, "model")
これでPCで学習したモデルが直接Databricksのエクスペリメントに記録されます。
📖 参考: MLflowデータの格納場所を選択する
ネットワーク制限がある場合
企業環境では、セキュリティポリシーにより会社のDatabricksへの直接アクセスが制限されることが多いです。その場合は以下のアプローチを検討してください。
方法1: MLflowモデルをファイルとしてエクスポート → 持ち込み(推奨)
PCでの作業
import mlflow
# ローカルでモデルを学習・保存
model = train_model(...)
# MLflow形式でローカル保存
mlflow.sklearn.save_model(model, "my_model")
# または
mlflow.pyfunc.save_model(
path="my_model",
python_model=model,
pip_requirements=["scikit-learn==1.3.0", "pandas==2.0.0"]
)
生成されるディレクトリ構造:
my_model/
├── MLmodel # モデルのメタデータ
├── model.pkl # モデル本体
├── conda.yaml # Conda環境定義
├── python_env.yaml # Python環境定義
└── requirements.txt # pip依存関係
Databricks側での作業
# 1. モデルファイルをUnity Catalog Volumeにアップロード(UIまたはCLI)
# 2. Databricksノートブックでロード・登録
import mlflow
# Volumeからモデルをロード
model = mlflow.pyfunc.load_model("/Volumes/catalog/schema/volume/my_model")
# Model Registryに登録
mlflow.register_model(
"file:///Volumes/catalog/schema/volume/my_model",
"catalog.schema.my_model"
)
方法2: Git経由でMLflow Projectsを共有
コードと環境定義をGitで管理し、Databricks側で再学習する方法です。
プロジェクト構成
my-ml-project/
├── MLproject
├── python_env.yaml
├── train.py
└── models/
└── (学習済みモデルは含めない or Git LFSで管理)
# MLproject
name: my-ml-project
python_env: python_env.yaml
entry_points:
main:
parameters:
data_path: {type: str, default: "/dbfs/data"}
command: "python train.py --data {data_path}"
GitHubにプッシュ後、Databricks側でGit連携して再学習:
mlflow.run(
"https://github.com/username/my-ml-project",
parameters={"data_path": "/Volumes/catalog/schema/data"}
)
方法3: ONNX/標準形式でエクスポート
MLflow以外の汎用形式でも持ち込み可能です:
# 個人PCで
import onnx
from skl2onnx import convert_sklearn
# ONNX形式でエクスポート
onnx_model = convert_sklearn(model, initial_types=[...])
onnx.save(onnx_model, "model.onnx")
推奨フロー(ネットワーク制限下)
[PC] [ファイル転送] [Databricks]
│ │ │
│ 1. モデル学習 │ │
│ 2. MLflow形式で保存 │ │
│ save_model() │ │
│ │ │
│ ─── zip/tar.gz ──────────> │ ── UI/CLI Upload ──────> │
│ (許可された方法で) │ Volumes/DBFS │
│ │ │
│ │ │ 3. load_model()
│ │ │ 4. register_model()
│ │ │ 5. Model Serving
ファイル転送の選択肢
| 方法 | 説明 |
|---|---|
| Databricks UI | Workspace → Import でファイルアップロード |
| Unity Catalog Volumes | UI経由でファイルをアップロード |
| 社内ファイル共有 | 許可されたストレージ経由 |
| Git + Git LFS | 大きなモデルファイルはLFSで管理 |
重要なポイント
MLflow形式で保存すれば、依存関係(requirements.txt)も一緒に保存されるため、Databricks側での再現性が確保されます。単なるpickleファイルではなくMLflow形式を使うことをお勧めします。
まとめ
| シナリオ | 推奨アプローチ |
|---|---|
| 組織間でモデルを配布 | Delta Sharing |
| 機密データで共同開発 | Clean Rooms |
| チーム内でコード共有 | MLflow Projects |
| PC → Databricks(ネットワークあり) | リモートTracking Server |
| PC → Databricks(ネットワーク制限) | MLflow形式でエクスポート → Volumes経由で持ち込み |
モデル共有の方法は状況によって異なりますが、いずれの場合もMLflow形式でモデルを管理することで、依存関係の再現性が確保され、Unity Catalog Model Registryでの一元管理が可能になります。