MLOps実践ワークショップ：Unity CatalogとMLflowで学ぶ特徴量・モデル管理

データサイエンティストやMLエンジニア向けに、Databricksを活用したMLOpsの基礎を学ぶハンズオンです。Unity Catalog、MLflow、Feature Storeを使い、特徴量の管理・再利用からモデルの開発・評価、推論パイプラインのデプロイまでを体験します。特徴量の再利用性とモデル開発の再現性を確保しながら、機械学習モデルの開発から本番活用までをつなぐ一連の流れを習得できます。

Transcript

1. MLOps ワークショップ Unity Catalog と MLflow で 特徴量とモデルのライフサイクルを管理 データブリックス・ジャパン株式会社
2. このワークショップについて Databricks を活用した MLOps の基礎を習得する 主な対象者 • 特徴量やMLモデルを作成するデータサイエンティスト • 本番環境で推論や再学習等の MLパイプラインを実装する MLエ ンジニア ※ Python の基本的なコード、典型的な機械学習ライブラリ(本WSでは sklearn, LightGBMを使用)と、PySpark、SQL の使用経験があることを前 提としています。 事前準備 • 環境： お客様のDatabricks環境(ワークスペース )を利用。本 ワークショップに参加される方がワークスペースにログインでき ること。 • サンプルデータ： サンプルデータ作成用ノートブックを事前に 実行し、参加者にアクセス権を付与 ゴール • Databricksの機械学習/MLOpsに関するソリューションの全体像を理解する • 主に Unity Catalog、MLflow、Feature Store を使い、特徴量の再利用性や再現性を確保しながら、モデルの開 発と評価、推論パイプラインのデプロイまでを行う MLOpsのサイクルを身につける
3. 本ワークショップのアジェンダ サンプルのデータとシナリオと使って、ハンズオンを主体に進める 1. 機械学習 MLOps ソリューションの全体像 2. 環境セットアップ & サンプルデータ確認 3. 特徴量の作成と管理：Feature Store 4. モデルの学習と評価：MLflow Tracking 5. モデル管理：Unity Catalog モデルレジストリ 6. 推論・再学習のパイプライン化：Lakeflow Jobs 7. Appendix 1 : 管理者向け 事前準備 2 〜 6 はパート毎に 説明 → ハンズオン の流れで進行
4. 機械学習・ MLOps ソリューション全体像
5. MLはすべての インテリジェント アプリケーションを 支えるエンジン インテリジェントアプリケーション 95% の本番AIワークロードは クラシックML、GenAIではない エージェントにはMLモデルが必要: レコメンデーション、予測、リスクスコア GenAIが注目を集める— クラシックMLが収益を牽引 AIで勝利する企業は 大規模な本番MLを持っている 不正検知 レコメンデーション 動的価格設定 予測 リスクスコア
6. なぜ MLOps が必要か モデルは作った瞬間から劣化し、仕組みを欠いた運用は品質の課題を生む モデルは作った瞬間から劣化が始まる。特徴量やモデル、評価結果等が管理できていないと・・・ ◦ 学習時と推論時で特徴量が微妙に食い違い、本番だけ精度が出ない ◦ 本番で動いているのがどのモデルのどのバージョンか分からない ◦ 実験結果が残らず、後から再現できない ◦ モデルが劣化しても、新しいデータへの作り直し（再学習）と本番切替が属人的で回らない MLOps とは、これらを仕組みで解決 する考え方。ML の開発・デプロイ・運用を「再現可能・ガバナンスが効 く・自動化された」プロセス にすること。
7. Databricks のアプローチ 統合ガバナンス、 開発者の速度向上、 オープン標準が3つの 問題すべてを解決 ガバナンス “基本的なコンプライアンス管 理を適用できない。 ” Unity Catalog データ、特徴量、モデル、エンドポイントに またがる1つのガバナンスレイヤー 生産性 “モデルを本番稼働させるま でに 6ヶ月かかる。” 管理された MLライフサイクル 設備追跡、トレーニング、 特徴量再利用、サービング —すべて対応 ロックイン “ベンダーや自分のスタックに 縛られている。 ” どこでもオープン標準 MLflow、Delta Lake、その他 フレームワーク、マルチクラウド
8. Unity Catalogを通じたビルトインのガバナンス 初日からコンプライアンスと監査性 単一ガバナンスレイヤー データ、モデル、特徴量、関数— すべてUnity Catalogの配下に データ資産 ML資産 監査証跡 アクセス制御 リネージ 関数 きめ細かなアクセス制御 列レベル、行レベル、 属性ベースのポリシー 自動リネージ すべてのモデルを トレーニングデータまで追跡 コンプライアンス対応 UNITY CATALOG | ガバナンスレイヤー GDPR、HIPAA、SOC2、 PCI、FedRAMP
9. インフラではなく MLに集中 6ヶ月から数日へ—実験と本番のギャップを縮小 数週間ではなく、 数分で構築開始 事前パッケージ化されたGPU 最適化ランタイム—セットアップ 不要、依存関係の問題なし データサイエンスエージェント： 目標を説明するだけで、カタログ を閲覧してベストプラクティスに 従った実用的なノートブックを取 得 最初からではなく、 フルコンテキストで 反復 データが すでに存在する場所に デプロイ すべての実験を 自動追跡—パラメータ、 メトリクス、成果物、完全なリ ネージ 同一プラットフォーム、同一ガバ ナンス—バッチ スコアリングまたはリアルタイム エンドポイント、 引き渡しなし、 データ移動なし チーム間で再利用可能な特徴 量、自動チューニング—反復 ループが 大幅に短縮
10. オープン標準、ロックインなし データとモデルは常にポータブル—常に MLflow: オープンソース、Databricksが 創設、10,000社以上が利用 Delta Lake: オープンソース—データが 閉じ込められることはない あらゆる MLフレームワーク : マルチクラウド : MLフレームワーク オープンフォーマット クラウドプロバイダー 既存のものと統合 — 自分のペースで導入
11. MLトレーニングのための柔軟なコンピュート フル機能クラスターとサーバーレス—CPUとGPUの両方を完全サポート クラシック MLランタイム サーバーレスコンピュート フル機能のクラスター ベーストレーニング オンデマンドのシングルノード および分散トレーニング 分散Spark、主要な MLアルゴリズム向けに最適化 プロビジョニング不要、アイドルコストなし —最大128 H100 GPU 両方のパス オンデマンドGPU：A10とH100、透明な時間単位の価格設定 事前パッケージ化されたMLランタイム、GPU最適化、同一ガバナンス 強制的な移行なし—MLRから始め、自分のペースでサーバーレスへ移行
12. Genie Code: MLライフサイクルを自動化する AIエキスパート Genie Codeが構築、トレーニング、デバッグ、反復を担当—チームはプロセスでは なく問題に集中 構築とトレーニング : データを分析し、本番対応MLパイプラインを生成 し、最適なモデルを見つけるための 最適化を実行 デバッグ : 本番エラーを診断し、根本原因を説明し、 修正案を提示 ループを閉じる : ドリフトを監視し、再トレーニングを トリガーし、再デプロイ前に検証 チームを 10倍に: 専門スキルが少なくても迅速に進める— GenieがMLの専門知識を提供
13. 1つの統合プラットフォーム、データから本番まで MLはデータと共に存在—生データ取り込みから本番監視まで 1つのデータプラットフォーム 生データ アップストリームデータエンジニアリングが 組み込み: ETL、品質、オーケストレーション MLはダッシュボードを 動かすのと同じデータでトレーニング 監視 ETL/パイプライン サービング 特徴量Eng 組み込みリネージ : すべての予測をソースデータまで追跡 1つのMLライフサイクル エンドツーエンド : 特徴量 → トレーニング → サービング → 監視 → 反復 オフライン/オンラインのスキューなし—特徴量はど こでも一貫性 トレーニング
14. 環境セットアップ サンプルデータについて
15. ワークショップ用 Notebookのインポート ① ワークスペース左側のメニュー から “Workspace” を開く ② 右上の方にある 3点リーダーの 様な部分から、 “Import” を開く ③ インポート画面が開くので、 配布されたワークショップ用コードの zipファイ ルをそのままドラッグ &ドロップする
16. ワークショップ用 Notebookの変数書き換え ① インポートしたフォルダの中にある 00_setup というノートブックを開く ② 00_setup ノートブックの最初のセルで、 CATALOG という変数の値を管理者または 講師から案内があるカタログ名に書き換える
17. 使用するコンピュート、カタログ、スキーマ 管理者/講師側で準備したデータソースを使い、各自のスキーマに書き出す • コンピュート ：サーバレスコンピュートを使用 (作成作業は不要) • カタログ、スキーマ等 ：下記の表の通り。(必要なものは管理者側で予め作成済み、またはワークショップ中の初期セット アップ用Notebookで自動作成するため、手動で作成するものは無し) オブジェクト 名前（例） 用途 カタログ <ワークショップ用カタログ名 > 予め作成済みの 1つカタログを全員で共有 参加者用スキーマ <ワークショップ用カタログ名 >.mlops_ws_<user_name> ワークショップの中で各自が作成する Bronze / Silver / Gold の各テーブルを格納するスキーマ 共有スキーマ mlops_ws_shared 管理者側で予め作成済みの共有スキーマ
18. サンプルデータセット一覧 架空のキャッシュレス決済サービスのデータを題材に、 不正決済検知のMLモデルを作成する 区分 テーブル名 内容 マスターテーブル m_customers 会員情報（属性・通信プラン・平均利用額 等） m_merchants 加盟店情報（店名・業種カテゴリ・所在地） m_payment_methods 決済手段（QR / クレカ / iD / デビット） t_payments 決済履歴（主テーブル・不正ラベル付き・約 100万件） t_point_transactions ポイント取引（付与 / 利用 / 失効） t_charges チャージ履歴（残高入金） t_login_events ログイン履歴（乗っ取り検知の補助） ファクトテーブル 上記のテーブルは全て、ワークショップの共有スキーマ上にUnity Catalog マネージドテーブルとして格納済み
19. 本ワークショップで作成する MLパイプライン 特徴量の作成からモデルの学習・評価、推論と再学習のジョブ作成まで
20. 特徴量の作成と管理 Feature Store
21. 特徴量エンジニアリングにおける課題 重複開発、学習と推論のズレ、学習時のリークの発生 特徴量をモデルや案件毎に個別作成し、管理と共有ができていないと・・・ 重複開発が発生 「顧客ごとの過去30日の平均決済額」のような特徴量を案件ごとに作り直し、計 算コストと工数が多重に発生 ガバナンス欠如 どの特徴量がどのデータから作られ、どのモデルが使っているか追跡できない。 学習時にリークが発生 時系列データを扱う際、データ発生時点より未来の情報をうっかり特徴量に混ぜ てしまい、テストでは高品質なのに本番では全く品質が出ない 学習と推論で 特徴量に差異が発生 特徴量の加工ロジックが学習時と推論時で矛盾した結果、本番のモデル性能が 低下（多くの場合、本番投入後に初めて発覚）
22. Feature Store による解決策 特徴量を Unity Catalog 上で管理し、再利用性と再現性を確保、リークを防止 1 特徴量の再利用性とトレーサビリティを高める • Unity Catalog に特徴量を集中管理し、権限管理の下で様々なモデルやプロジェクトで再利用可能にする • Unity Catalogと統合されたリネージ可視化により、特徴量がどのモデルで使用されているかを追跡可能 2 モデルの品質を低下させる特徴量の ”ズレ” を仕組みで防ぐ • 複数テーブルを跨いだ特徴量の選択、結合を簡単に定義(create_training_set／FeatureLookup) • 学習時のデータリーク (未来データの混入) を防止し、本番での品質低下を回避 (Point-in-Time Join ) • 推論時は学習時と同じ特徴量定義・取得ロジックを自動的に使用することで、Train/Serve Skew (学習時と推論時の データのズレ)、重複実装を削減 (score_batch)
23. Feature Store を使用する基本ステップ 専用の PythonAPI “FeatureEngineeringClient” を使って簡単に操作 1. PySparkやSQLで特徴量を作成し、 create_table() でUnity Catalog上に特徴量テーブルとして書き出す。 2. FeatureLookup で複数の特徴量テーブルから必要なカラムだけを選択、結合して、 create_training_set() で 学習データ セットを作成する。 3. 作成した学習データセットを使って、モデルの学習を実行する。 4. 学習したモデルと使用した特徴量を log_model() で紐づけて記録する。 5. 推論時は score_batch() を使うことで、必要な特徴量を自動的に選択 /結合された上で推論が実行される。
24. 学習データセットの定義 特徴量の選択・結合を宣言的に定義し、学習データセットを作成 学習データセット作成のポイント • FeatureLookup で、利用する特徴量テーブ ル・特徴量カラム・結合キーを宣言 • モデルごとに必要な特徴量だけを選択し、不要 なカラムを除外 • create_training_set で、ラベル付き データと複数の FeatureLookup をキー結合 • 入力データには、各特徴量テーブルの主キーに 対応するカラムが必要 • 出力は、ラベル・結合キー・選択した特徴量を含 む学習データセット
25. 学習時のデータリークの防止 時系列を含む特徴量では、自動的に Point-in-Time 結合を実施 Point-in-Time 結合とは • 各ラベル観測時刻以前に利用可能だった、最 新の特徴量値を採用 • 主キーと時刻キーによるAS OF結合で、未来の 情報の混入を防止 • 時系列・イベント・時間集約で変化する特徴量に 適用 実装のポイント • 特徴量テーブル作成時、主キーに時刻列 を含め、timeseries_columns を指定 • FeatureLookup に timestamp_lookup_key を指定 • create_training_set() が観測時刻 以前の最新値を自動結合
26. Feature Store で何が変わるか 特徴量を Unity Catalog 上で管理し、再利用性と再現性を確保、リークを防止 • 重複開発から再利用へ ：作った特徴量テーブルを複数モデル・複数チームで共有。計算コスト と重複開発を削減。 • Train/Serve Skew を防止：学習時に組み立てた特徴量取得ロジックがモデルに同梱される。 推論時は「顧客IDと取引情報」を渡すだけで同じ特徴量が再現され、意図しない特徴量の差異 による本番での品質低下を防ぐ。 • 学習時のリーク防止 ：Point-in-Time 結合により、推論時に入手不可能な未来情報が学習に 混入しない。時系列の正しさを担保。 • リネージの可視化 ：Unity Catalog により、どのデータから作られ、どのモデルが使っているか を自動追跡・権限管理。 特徴量が組織の再利用可能な資産になり、品質低下を防止
27. ハンズオン： Feature Store による特徴量管理 3種類の特徴量テーブルを作り、Unity Catalog に保存 ノートブック 01_feature_engineering に沿って、特徴量を作成しましょう 関連するテーブル等 • データソーステーブル： m_customers / m_merchants / t_login_events / t_payments • 作成する特徴量テーブル： ◦ customer_features（キー：customer_id）：年齢、口座継続日数、平均月間利用額、契約プラン、ステータス。 ◦ merchant_features（キー：merchant_id）：カテゴリ、都道府県、過去の不正発生率、平均取引額。 ◦ login_features（キー：customer_id ＋ タイムスタンプ）：直近の失敗ログイン数、累計ログイン数などの時系列特徴量。 このハンズオンで出てくるポイント PySparkで特徴量を作成し、 create_table() でUnity Catalog上に特徴量テーブルとして書き出す。 ※ FeatureLookup による特徴量の選択・結合や、 create_training_set() による学習データセット作成のステップは次のパートで モデルの学習・評価と一緒に行います。
28. モデルの学習と評価 MLflow Tracking
29. 実験管理における課題 試行錯誤の記録が残らないと、比較も再現もできず、勘に頼ったモデル選定に 機械学習は試行錯誤の連続。ハイパーパラメータや特徴量等を変えながらの試行が何十回も発 生する。これらの試行錯誤の結果が記録されていないと・・・ 再現性の問題 実験結果の比較や 分析ができない 実験結果が 共有できない どの条件で、どの結果だったかが手元のメモやファイル名頼みになり、再現でき ない 数十〜数百の試行を横並びで比較できず、客観的にベストを選べない チームで知見が共有されず、同じ試行を各自が繰り返す
30. MLflow Tracking とは？ モデル開発中の実験管理を仕組み化し、再現性の確保や比較分析を容易にする モデル、パラメーター、評価指標、データセット、コードやアーティファクトを関連付けて記録
31. MLflow Tracking を使用する基本ステップ モデルの学習コードは大きく変更せず、mlflow APIの操作で実験管理を実現
32. ハンズオン： MLflow で実験管理 条件を変えて モデルの学習を複数回実行し、結果を比較分析する ノートブック 02_train_register ( 前半) に沿って、実験管理を体験しよう 関連するデータ等 • 学習データ：前のパートで作成した特徴量テーブルから作成 • 使用するモデル：LightGBM このハンズオンで 出てくるポイント • 前のパートで作成した特徴量テーブルから、FeatureLookup で特徴量の選択・結合し、create_training_set() で学習 データセット作成 • ハイパーパラメータを変えてLightGBMの学習を複数回実行し、MLflow Trackingで結果を記録 • Databricks 上の MLflow UI で結果を比較分析する
33. モデルの管理 Unity Catalog モデルレジストリ
34. モデル管理における課題 モデルレジストリが不在の場合、モデルがコードの中に埋没して管理が困難に モデルレジストリによる管理がされていないと・・・ どれが本番か 分からない バージョン管理欠如 ファイルやノートブックに散在し、「今動いているのはどれ」が曖昧。 差し替え・ロールバックが手作業で危険。 ガバナンス不足 誰がアクセスでき、何のデータから作られたかを追えず、監査に耐えない。 デプロイが硬直的 モデルを更新する度に、推論コードの修正が必要になりミスが発生。 本番運用には、モデルを正式な「管理された資産」に昇格させる仕組みが必要
35. Models in Unity Catalog とは Unity CatalogでデータとAIアセットの両方にガバナンスを適用 学習済みモデルを Unity Catalog に登録し、バージョン 管理・エイリアス運用・権限管理 • バージョン管理 ：学習したモデルをに Unity Catalogに登録 することで、のたびに version が自動採番される。 • エイリアスとタグ ：@champion / @challenger など任意の エイリアスや、 key-value形式の任意のタグをモデルバー ジョンに付け、「今の本番はどれか」等のモデルの状態やメ タデータを管理する。 • 一貫したモデル参照 ：推論を実行する際は models:/catalog.schema.model@champion のような URI 指定で常に本番を参照（モデルを差し替えても推論コー ドは変えない） • 権限管理 ：Unity Catalog上 で USE / SELECT / EXECUTE 等のモデルへのアクセス権限を管理
36. ハンズオン： Unity Catalog でモデル管理 ベストモデルをUCに登録し、バージョンやエイリアスで管理する ノートブック 02_train_register ( 後半) に沿って、モデル管理を体験しよう このハンズオンで出てくるポイント • 前半で記録した実験結果から最も評価指標が良かった結果を選択 • fe.log_model で Unity Catalog へ登録 • 最新 version に @champion エイリアスを付与 • models:/...@champion でロード確認 • Catalog Explorer でリネージを確認
37. 推論・再学習のパイプライン化 Lakeflow Jobs
38. 本番MLが価値を生み出す 2つの方法 バッチとリアルタイムはどちらも重要—Databricksはどちらも世界クラス 大規模バッチ推論 リアルタイムプロダクションサービング 数百万行 ライブリクエスト エンタープライズMLの根幹— 予測、スコアリング、リスク ミリ秒以下の意思決定— 不正検知、価格設定、レコメンデーション 数百万の予測をオフラインで計算 レイテンシに敏感な、高スループット、 常時稼働エンドポイント クラシックML収益の大部分が 生まれる場所 ML実践を成熟させるための最前線
39. Lakeflow Jobs 様々の種類の処理を簡単に組み合わせ、本番ジョブとしてオーケストレーション Triggers • データ鮮度を最適に保つ、様々な トリガー設定 • 条件分岐や繰り返しを含む複雑な 処理にも対応可能な制御フロー Scheduled ジョブの実行状況、コストやパ フォーマンスの監視、分析が可能 な可観測性 Continuous • • • サーバーレス / クラシックのコン ピュートでコスパも運用負荷も調 整可能 データ加工からモデル学習、ダッ シュボード更新、3rdパーティツー ルも含む様々な処理を簡単に統 合 Control Flow Observability ETL ML/AI File arrival Table update Serverless Analytics/BI
40. シンプルなジョブの作成と管理 データ取り込み・加工処理のコードを実装するのと同じ場所で 本番ジョブの作成までシームレスに行える 様々なタスクタイプを 数クリックで組み合わせ、 本番運用可能なジョブを構成 Databricks Automation BundlesやREST API、CLI等、環境に合うツールで ジョブの作成や管理を CI/CDに組み込み
41. リアルタイムなモニタリング ジョブの実行状況を直感的に把握可能なUIで、即座にアクションを取りやすく シンプルで直感的な監視 UIが、 ワークフロー実行ごとのリアルタイムな メトリクスと詳細な分析を提供 どのタスクがなぜ失敗しているのかを 把握し、顧客に影響が出る前に問題を トラブルシューティング可能
42. コストやパフォーマンスの分析 実行ステータス、コスト、パフォーマンスに関する様々なログを すぐに分析可能なテーブルとして提供し、可視化の仕組みもセット 製品、ワークスペース、ジョブ、ノートブック、 ユーザーごとにコストを追跡可能 ジョブ実行の健全性、失敗、 ランタイムメトリクス、リソース使用率等を追跡可能
43. Lakeflow Jobs のタスクタイプや制御フロー タスクを選択し、制御フローを作成し、Jobsのデータトリガーを定義する ジョブは 1 つ以上の タスクをまとめて管 理可能 タスク間に柔軟な制 御フローを構築可 能 ジョブは柔軟なトリ ガー設定をサポート Spark Databricks SQL Files/ Declarative Notebooks Queries Pipelines Sequential Scheduled (Cron) Python Scripts Parallel API Trigger Python Wheels AI/BI Dashboards Conditionals (If/else) File Arrival Triggers Table Triggers Spark Submit dbt Run Job (Modular) Continuous (Streaming) Java JAR file Power BI For each Manual Trigger
44. ハンズオン：バッチ推論のジョブ化 基盤やツールを変えず、ノートブックの推論コードをそのまま本番ジョブ化 ノートブック 03_batch_inference で推論コードの内容を確認してから、 Lakeflow Jobs で自動実行されるようジョブ化しよう このハンズオンで出てくるポイント • 推論コードのノートブック (03_batch_inference) を Lakeflow Jobs のタスクとして設定し、自動実行 • Feature Store で特徴量の選択・結合をモデルと紐づけて記録しているため、fe.score_batch() で推論処理を実 行すると必要な特徴量の選択・結合が自動で行われる（学習時との一貫性が保たれる）
45. ハンズオン：ジョブの新規作成画面を開く 1. 左側のメインメニューから「ジョブとパイプライン」を開く 2. 「ジョブ」ボタンからジョブの新規作成画面を開く 3. 「＋別のタスクタイプを追加」ボタンを押し、どんなタスクタイプが用意 されているのかをスクロールしながら観察 4. 「ノートブック」を選択する
46. ハンズオン：データ取り込みのタスクを作成 1. 2. ノートブックタスクの設定画面で、最低限以下の項目のみ設定。他に もどんな内容が設定できるか観察。 a. タスク名：batch_inference b. 種類：ノートブック（デフォルト） c. ソース：ワークスペース（デフォルト） d. パス：自身の 03_batch_inference ノートブックを指定 e. コンピュート：サーバーレス 「タスクを作成」ボタンでタスクを保存
47. ハンズオン：ジョブの起動トリガーを設定 定期実行だけでなく、新規ファイル到着や上流テーブル更新も設定可能 1. 右側の設定メニューの「スケジュールとトリガー」から「トリガーを追加」を開く 2. トリガータイプとして選択できるものを見ながら、各トリガータイプで設定できる内容を UIから観察 3. 本ワークショップでは「なし（手動）」のままにしておく
48. ハンズオン：ジョブ通知の設定 ジョブの失敗や長時間化等をSlack, Teams, メール等でリアルタイムに通知 1. 右側の設定メニューの「ジョブ通知」から「通知を編集」を開く 2. 「＋通知を追加」ボタンを押す 3. 配信先を設定し、通知を出したいイベント種類を選択する(本ワークショップでは自身のメールアドレスを設定)
49. ハンズオン：ジョブ名を変更し、実行する 1. ジョブ画面左上のジョブ名を、分かりやすい名前に変更（例：不正決済検知_<自身の名前>） 2. 「今すぐ実行」ボタンでジョブを手動実行する
50. 追加ハンズオン：再学習とモデル更新 再学習とモデルアップデートを、バージョンとエイリアスで管理する ノートブック 04_retrain で再学習コードの内容を確認してから、 再学習 → バージョニング → 品質テスト → エイリアスで昇格 の流れを理解しよう このハンズオンで出てくるポイント • 再学習を実行後、新たなモデルバージョンとしてUnity Catalogに登録 (@challenger という エイリアスを付与) • 本番で稼働中のモデルバージョン (@champion エイリアスを持つ) と品質を比較 ◦ 新モデルバージョンが良い場合：@champion エイリアスを付け替えて、新モデルバージョンを本番に昇格 ◦ 現行モデルバージョンが良い場合：現行バージョンを維持(@champion エイリアスを現行バージョンが保持) 再学習のノートブック 04_retrain も、 Lakeflow Jobs でジョブ化することを想定したものです。 ジョブ作成の手順は前のバッチ推論のジョブ作成と同じなので、時間があれば作成してみましょう。
51. 本ワークショップのまとめ
52. Databricks のアプローチ 統合ガバナンス、 開発者の速度向上、 オープン標準が3つの 問題すべてを解決 ガバナンス “基本的なコンプライアンス管 理を適用できない。 ” Unity Catalog データ、特徴量、モデル、エンドポイントに またがる1つのガバナンスレイヤー 生産性 “モデルを本番稼働させるま でに 6ヶ月かかる。” 管理された MLライフサイクル 設備追跡、トレーニング、 特徴量再利用、サービング —すべて対応 ロックイン “ベンダーや自分のスタックに 縛られている。 ” どこでもオープン標準 MLflow、Delta Lake、その他 フレームワーク、マルチクラウド
53. 本ワークショップで扱っていない機能 モデル品質監視・リアルタイム化・CI/CD など・・・他にも多数の機能を提供 • Data Profiling：推論結果のドリフトやラベル判明後の精度推移を継続監視 • Deployment Jobs：モデルアップデート時のテスト・承認フローに Human-in-the-loop を入れる • Model Serving：モデルをAPIエンドポイントしてデプロイし、リアルタイム推論 • Online Feature Store：リアルタイム推論時の低遅延な特徴量参照 • Genie Code：学習や推論のコードやジョブ作成を含め、Databricks上での実装作業をAIが支援 • Genie Agents：AIとのインタファクティブな対話によるEDA、アドホック分析 • AI/BI ダッシュボード ：データ可視化 • Databricks Asset Bundles (DAB)：ジョブ等の設定のコード化・CI/CD
55. Appendix 1 : 管理者向け 事前準備
56. STEP 0：事前チェック 1. 参加者全員のアカウント（メールアドレス）が対象ワークスペースに追加済みか確認 2. 参加者を1つのグループ（例：<参加者用グループ>）にまとめておく（個別付与を避けるため推奨） 3. 対象ワークスペースにサーバレス、または汎用クラスタ／SQLウェアハウスが起動できることを確認
57. STEP 1：SQLウェアハウスの準備 1. Serverless SQLウェアハウスを1台作成（参加者全員で共用） a. SQL → SQLウェアハウス → 作成 → タイプ：Serverless b. サイズは参加者数に応じて選択（目安：〜10名で 2X-Small〜Small、Auto-stop を有効化） c. 参加者グループに「使用可能（CAN USE）」権限を付与 d. 作成したウェアハウスの権限設定 → <参加者用グループ> グループに Can use を付与 ※ 本ワークショップではサーバーレスコンピュートを使用するため、参加者個別のコンピュート準備は不要。
58. STEP 2：カタログの準備 1. ワークショップで使用する共有カタログを新規作成（既存なら省略） CREATE CATALOG IF NOT EXISTS <ワークショップ用カタログ名>; ※ 共有スキーマは、STEP 3 の初期セットアップノートブック内で自動作成されるため手動作成は不要。 ※ 参加者ごとのスキーマ（mlops_ws_<ユーザー名>）は、参加者自身のノートブック実行によって自動作成されるため、手動 作成は不要。
59. STEP 3： 初期データの生成 1. 2. 3. 4. ノートブック一式の中から、管理者用フォルダadmin 配下の 00_generate_sample_data を開く 冒頭のパラメータを確認・設定 a. CATALOG = <ワークショップ用カタログ名 > ノートブックを上から順に全セル実行。ノートブック内では主に以下の処理が実行される。 実行すると、共有スキーマ mlops_ws_shared 内に以下のマスターとトランザクションの各サンプルテーブルが作成され る。 区分 テーブル名 内容 マスターテーブル m_customers 会員情報（属性・通信プラン・平均利用額 等） m_merchants 加盟店情報（店名・業種カテゴリ・所在地） m_payment_methods 決済手段（QR / クレカ / iD / デビット） t_payments 決済履歴（主テーブル・不正ラベル付き・約100万件） t_point_transactions ポイント取引（付与 / 利用 / 失効） t_charges チャージ履歴（残高入金） t_login_events ログイン履歴（乗っ取り検知の補助） ファクトテーブル
60. STEP 4：参加者への権限付与 1. 参加者が共有スキーマ内のテーブルを読み取り、かつ自分のスキーマを作成できるよう権限を付与します（グループ推 奨）。 -- カタログ／スキーマの利用権限 GRANT USE CATALOG ON CATALOG <ワークショップカタログ名 > TO <参加者用グループ >; -- 各参加者が自分のスキーマ（ mlops_ws_<user_name>）を作成できるように GRANT CREATE SCHEMA ON CATALOG <ワークショップカタログ名 > TO <参加者用グループ >; -- マスタテーブルの参照 GRANT USE SCHEMA ON SCHEMA <ワークショップカタログ名 >.mlops_ws_shared TO <参加者用グループ >; GRANT SELECT ON SCHEMA <ワークショップカタログ名 >.mlops_ws_shared TO <参加者用グループ >; ※ グループ名（<参加者用グループ>）とカタログ名 (<ワークショップカタログ名>)は環境に合わせて置き換え。
61. STEP 5：ノートブックと資料の事前配布 1. ワークショップ用のノートブック一式＋説明資料(本資料) は管理者から全参加者へ予め配布しておく。