DatabricksのUnity Catalogを活用したMLOps（1編、概念・事例紹介）

はじめに

エーピーコミュニケーションズGDAI事業部Lakehouse部の鄭(ジョン)です。

この記事では、DatabricksのUnity Catalogを活用したMLOpsについてご紹介いたします。シリーズ投稿の第1回として、基本的な概念と実際の運用事例を取り上げます。本記事は「MLOpsとは何か」といった入門的な解説ではなく、すでにMLOpsの概念を理解しており、実際にどのように導入すべきかを検討している方を対象としています。そのため、詳細な理論説明は省略し、一般的なMLOpsとDatabricksにおけるMLOpsの違いを比較し、さらに実際のDatabricks MLOps構築事例をご紹介します。

一般的なMLOps概要

MLOps（Machine Learning Operations）とは、機械学習モデルの開発からデプロイ・モニタリングまでの一連の流れを自動化し、モデルのライフサイクル全体を管理するプロセスです。これは、DevOpsにおけるCI/CDの概念をMLワークフローに適用することで、モデルを効率的かつ安定的にスケールさせることを可能にします。

MLOps は、機械学習、アプリケーション開発、IT 運用を組み合わせます。出典: Neal Analytics

主要な構成要素

実験トラッキング（Experiment Tracking）：モデル実験のパラメータとメトリクスを記録・比較し、最適なモデルを特定します。
バージョン管理（Versioning）：コード、データセット、モデルアーティファクト（パラメータなど）、実行環境までをすべてバージョン管理し、再現性を担保します。
CI/CDパイプライン（CI/CD Pipeline）：データ収集・前処理、モデル学習・検証・デプロイの各段階を自動化し、迅速かつ効率的な開発を支援します。
モデルモニタリング・アラート(Monitoring & Alerting)：本番環境でのモデル性能を監視し、異常や性能低下が発生した際に即時にアラートを送信します。
継続的トレーニング（Continuous Training）：新しいデータを活用してモデルを継続的に再学習させ、性能を向上させます。

ツール紹介

実験トラッキング（Experiment Tracking）：MLflow、Comet ML、Weights & Biases (W&B)、など
学習パラメータやメトリクス、アーティファクトを記録・比較し、実験の再現性とチーム開発を支援します。

出典: Sachin Soni, Medium「A Practical Guide to Experiment Tracking in MLOps」

ワークフローオーケストレーション（Workflow Orchestration） ：Kubeflow Pipelines、Apache Airflow、Dagsterなど
Kubernetesベースまたはコード定義型のパイプラインで、データ前処理から学習・デプロイまでの一連の処理を自動化します。

出典: Rafael Afonso Rodrigues, Giffgaff「Journey towards end-to-end MLOps: Event-driven orchestration」

データ＆パイプラインバージョン管理（Data & Pipeline Versioning）：DVC (Data Version Control)、Git LFS、Amazon S3 Versioning など
コードだけでなく大容量データやパイプライン定義の変更履歴を管理し、実験の再現性とコラボレーションを確保します。

出典: MLOps Guide「Versioning – Data and Model Versioning」

フィーチャーストア（Feature Store）：Feast、Hopsworks、Meta など
学習時・推論時に一貫したフィーチャーを提供し、再利用・共有を容易にするプラットフォームです。

出典: MLOps Guide「Feature Storing – Common Architecture」

モデルテスト（Model Testing）：SHAP、TensorFlow など
モデルの性能や公平性、予測の安定性を多角的にテスト・検証します。

出典: Deep Learning University「MLOps: Model Testing Tutorial - A/B Testing」

モデルサービング（Model Serving）： Knative Serving、Amazon SageMaker など
Kubernetesベースまたはサーバーレス環境で、学習済みモデルをREST / gRPC APIとしてデプロイ・スケールできます。

出典: Hopsworks「Model Serving - What Features does Model Serving support?」

モデル監視＆可観測性（Model Monitoring & Observability）：Prometheus、Grafana、Amazon CloudWatch など
リアルタイムの性能指標を収集・可視化し、異常検知や性能劣化発生時にアラートを発信します。

出典: Evidently AI「How to stop worrying and start monitoring your ML models: a step-by-step guide」

このように、各フェーズで数多くのMLOpsツールが存在し、プロジェクトの規模やチームの要件に合わせて適切に組み合わせて利用するのが一般的です。

ツールに関する詳細は、以下のリンクで確認出来ます。

www.analyticsvidhya.com

DatabricksにおけるMLOps

Databricksは、上記のMLOps構成要素をひとつの統合プラットフォームとして提供することで、初期設定や運用の負担を大幅に軽減します。

主要な構成要素

MLflowネイティブ統合
Databricksは管理されたMLflowをワークスペースに組み込んでおり、追加インストールなしで実験トラッキング（Experiment Tracking）、モデルレジストリ（Model Registry）、プロジェクト機能（Project）を即座に利用できます。
Delta Lakeベースのデータパイプライン
データレイクハウスのストレージとしてDelta Lakeを採用し、ACIDトランザクション、スキーマ進化、タイムトラベル機能を提供します。さらに、Delta Live Tables（旧称Lakeflow Declarative Pipelines）を使ってETLパイプラインを宣言的に定義し、自動実行できます。
Unity Catalogによるガバナンス・セキュリティ
テーブルやビューだけでなく、MLflow RunやMLモデルまで一元的に権限管理・監査（Audit）し、dev、staging、prodといった環境単位できめ細かなアクセス制御をサポートします。
Feature Store
Unity Catalogを基盤とした中央フィーチャーストアを提供し、フィーチャーの定義、登録、共有を行うだけでなく、モデル学習時やサービング時に一貫したフィーチャー取得を自動化します。
Jobs & Workflows（Lakeflow Jobs）
ノートブック、スクリプト、Delta Live Tablesなど多様なジョブをひとつのワークフローとして連結し、スケジューリングやモニタリングを行うオーケストレーション機能です。
モデルサービング（Model Serving）
Mosaic AI Model Servingによって、MLflow形式のモデルをREST APIエンドポイントとしてデプロイし、自動スケーリングやリアルタイムモニタリングを実現。バッチ推論にも対応しています。

一般MLOps vs Databricks MLOps 比較

一般的なMLOpsは、さまざまなツールを自由に組み合わせられるため、自由度が高く特定のクラウドに依存しない環境を望む組織に向いています。たとえば、すでにオープンソースベースのパイプラインを運用している場合や、自社インフラを細かく制御したい企業には、一般MLOpsの方が有利となることがあります。

一方、Databricks MLOpsは、エンドツーエンドで統合された環境を提供するため、迅速な構築と運用効率を重視する企業に適しています。特に大規模データを扱う組織、機械学習モデルを素早く実験・デプロイ・管理する必要があるチーム、チーム間の協業効率を高めたい場合には、Databricksの方が効果的です。

つまり、自由度や柔軟性を最優先にする場合は一般的なMLOps、生産性や安定性を重視する場合はDatabricks MLOpsを推奨できます。

一般的なMLOpsとDatabricksにおけるMLOpsのツールを比較すると、以下のようになります。

構成要素	一般的な MLOps	Databricks MLOps
実験トラッキング（Experiment Tracking）	MLflow、Comet ML、W&B など	管理型 MLflow 統合
ワークフローオーケストレーション（Workflow Orchestration）	Kubeflow Pipelines、Apache Airflow、Dagster など	Workflows（Jobs）統合
データ＆パイプラインバージョン管理（Data & Pipeline Versioning）	DVC、Git LFS、Amazon S3 Versioning など	Delta Lake + Delta Live Tables 統合
フィーチャーストア（Feature Store）	Feast、Hopsworks、Meta など	Databricks Feature Store 統合
モデルテスト（Model Testing）	SHAP、TensorFlow など	MLflow モデル検証機能
モデルサービング（Model Serving）	Knative Serving、Amazon SageMaker など	Mosaic AI Model Serving
モデル監視＆可観測性（Model Monitoring & Observability）	Prometheus、Grafana、Amazon CloudWatch など	MLflow メトリクス + Unity Catalog Audit
インフラ管理（Infrastructure Management）	Kubernetes、Terraform など	サーバーレス・自動スケーリング環境標準提供

Databricks MLOpsの事例

本事例は、2025年の「Databricks Data Intelligence Day」韓国イベントで発表された、中古品取引プラットフォーム「Joonggonara」の実際のMLOps構築事例です。

事例の背景および要件
「Joonggonara」では、約500以上のカテゴリにまたがる商品に対してユーザーのポストなどを処理し、「Top 5おすすめリスト」を生成しています。この過程において、テキスト分類（NLP）モデルをML/DLベースでファインチューニングし適用することが主要課題でした。
データパイプライン設計
既存の生データにメダリオンアーキテクチャ（Bronze→Silver→Goldレイヤー）を適用して段階的にクレンジングし、事前学習済みのTransformerエンコーダーを用いてテキストを前処理しました。前処理済みデータはHugging Face Transformersライブラリでトークナイズおよび特徴ベクトル化を行っています。
モデルの学習および保存
DatabricksのマネージドMLflow（統合Unity Catalogモデルレジストリ）を利用して学習パラメータとメトリクスをトラッキングし、Dataset.from_spark APIを用いてSpark DataFrameを直接学習に活用しました。最終的に学習されたモデルアーティファクトはローカルアーティファクトとしてHugging Face Hubへ保存し、再利用性とバージョン管理を強化しています。
モデルのサービングおよびデプロイ
学習済みモデルはMLflowとFastAPIを組み合わせてRESTfulサービングエンドポイントとしてデプロイし、Delta Volumesを活用してモデルの入力・出力履歴をトラッキングしました。これによりリアルタイム推論とログ収集の自動化を実現しています。
モデルライフサイクル管理
Champion/Challenger戦略を適用し、プロダクションモデルと新規モデルを比較評価しました。Unity CatalogのModel Alias（@alias）およびバージョン（/version）機能を使ってステージング環境で性能を検証し、MLflow APIを介してチャンピオンモデルへの切り替えを行いました。
再学習およびテスト環境
Delta Sharingを通じてステージング環境にチャンピオン・チャレンジャーモデルのデータを共有し、再実験を行いました。その後、最終性能を検証し、チャンピオンモデルをプロダクションに適用する自動化パイプラインを構築しました。