Databricks Feature Views、学習と推論の特徴量定義を統合

Databricksは、機械学習の特徴量を一度定義し、実験・学習用の履歴データと本番推論用のデータへ共通利用するFeature Viewsをパブリックプレビューで公開しました。Unity Catalogの管理対象として登録し、バッチとストリーミングのパイプラインをDatabricks側で運用します。

今回のブログ記事で語られていること

機械学習では、ノートブックで試した特徴量を本番へ移す際に、履歴学習用とリアルタイム推論用で同じ計算を別々に実装することがあります。この重複は、学習時と推論時の値がずれる原因になり、過去分の再計算、オンラインストアへの投入、ストリーム処理、系譜管理も個別に必要になります。Feature Viewsは、データ源、エンティティ、時刻列、計算内容を一つの定義にまとめ、Feature Storeが時点整合性を保った学習データと推論用データを生成します。

利用者はノートブックでFeature Engineering Client SDKを使って定義し、実験後にUnity Catalogへ登録してmaterialize_featuresを呼び出します。Databricksはオフライン・オンラインストアへ書き込む管理パイプラインを作ります。バッチとストリーミングで定義方法を揃え、長期間の再計算や古いオンライン行の失効なども管理対象にします。MLflowでモデルを記録すると特徴量の依存関係も保存され、モデルサービングが推論時に必要な値を取得します。

Kafkaをデータ源にするストリーミング特徴量では、イベントからオンライン利用可能になるまでのP99を200ミリ秒と説明しています。RollingWindowはイベント時刻から過去をミリ秒単位で集計し、Sparkリアルタイムモード、Lakebase、モデルサービングを組み合わせます。ただし200ミリ秒は記事で示された構成上の目標・実績で、すべての地域、データ量、計算内容を保証する値ではありません。ストリーミングの物質化にはLakebase対応地域のEnterpriseワークスペースが必要です。

Feature Viewsはパブリックプレビューです。本番利用では、型や欠損値、遅延イベント、再計算、オンラインストアの整合性を確認する必要があります。共通定義にまとめるとずれを減らせますが、定義変更が学習と推論の双方へ広く影響するため、版管理、承認、再学習の条件も必要になります。

今回のブログ記事が関係する人

不正検知、推薦、個別化など鮮度の高い特徴量を使うデータサイエンティストと機械学習基盤担当者、特徴量パイプラインやオンラインストアを自前で運用しているチームに関係します。Unity Catalogで特徴量の権限と系譜を管理したい組織も対象です。

利用前に確認したいこと

• 利用地域とワークスペース階層がストリーミング物質化へ対応しているか
• 履歴計算とオンライン計算で時刻、遅延、欠損値が一致するか
• 定義変更時の再計算、モデル再学習、ロールバック手順
• P99遅延を自社のイベント量と特徴量計算で再現できるか
• Unity Catalogの権限とモデル利用者の参照権限が整合するか

結局、今回のブログ記事をどう読むべきか

Feature Viewsは、特徴量コードの再利用だけでなく、学習・推論・系譜・提供パイプラインを一つの管理対象へまとめる機能です。リアルタイム処理の運用負担を減らせる可能性がありますが、現在はプレビューで、200ミリ秒という数値も個別検証が必要です。まず一つの既存特徴量で履歴値と本番値を照合し、変更時の影響範囲を確認するのが適切です。