Databricks Feature Serving入門: オンライン推論・特徴量配信・Online Table設定

MLモデルをオンラインで推論する際、学習時と同じ特徴量を低遅延で取得する仕組みが必要です。 DatabricksのFeature Servingは、Unity Catalog上のFeature Storeテーブルを専用エンドポイント経由で配信し、 Training-Serving一貫性（学習時と推論時で同じ特徴量定義を使う）を実現します。 本稿ではFeature Servingの仕組み、Online Table設定、エンドポイント作成、一貫性の確保方法を解説します。

なぜFeature Servingが必要か

バッチ推論ではDeltaテーブルから直接特徴量を読み取れますが、オンライン推論（リアルタイムAPIリクエスト）では Deltaテーブルへのクエリはレイテンシが高すぎます（秒〜数十秒）。Feature Servingは以下の課題を解決します。

Feature Servingのアーキテクチャ

[Training]
  │  Feature Engineering in UC
  │  fe.create_training_set(
  │      entity_df, feature_lookups=[...])
  │  → 学習時に特徴量をルックアップ
  v
[Feature Table (Delta, UC)]
  │  ソーステーブル
  │  ├─ customer_features (customer_id, avg_spend, ...)
  │  └─ product_features  (product_id, category, ...)
  v
[Online Table]
  │  Deltaからの差分同期 (Snapshot / Triggered / Continuous)
  │  → 低遅延KVストアに変換
  v
[Feature Serving Endpoint]
  │  REST API (POST /serving-endpoints/{name}/invocations)
  │  → customer_id をキーに特徴量ベクトルを返却
  v
[Model Serving / Application]
  │  特徴量 + リアルタイム入力 → 推論結果

Online Tableの設定

Online TableはDeltaテーブルを低遅延のKVストアに同期する仕組みです。 ソースとなるDeltaテーブル（Feature Table）とプライマリキーを指定して作成します。

-- Online Tableの作成（SQL）
CREATE ONLINE TABLE ml.features.customer_features_online
SOURCE ml.features.customer_features
PRIMARY KEY (customer_id)
SYNC MODE TRIGGERED;

プライマリキーはFeature Tableのルックアップキーと一致させます。 複合キーも指定可能です（例: PRIMARY KEY (customer_id, product_id)）。

Feature Serving Endpointの作成

Python SDK（databricks-feature-engineering）を使ってFeature Serving Endpointを作成します。

from databricks.feature_engineering import FeatureEngineeringClient
from databricks.feature_engineering.entities.feature_serving_endpoint import (
    EndpointCoreConfig,
    ServedEntity,
)

fe = FeatureEngineeringClient()

fe.create_feature_serving_endpoint(
    name="customer-features-endpoint",
    config=EndpointCoreConfig(
        served_entities=ServedEntity(
            feature_table_name="ml.features.customer_features",
            scale_to_zero_enabled=True,
        )
    )
)

scale_to_zero_enabledをTrueにすると、リクエストがない期間はエンドポイントがスケールダウンしてコストを抑えます。 ただしコールドスタート時にレイテンシが増加するため、SLAが厳しい場合はFalseにして常時稼働させます。

エンドポイントへのリクエスト

import requests
import json

endpoint_url = "https://<workspace-url>/serving-endpoints/customer-features-endpoint/invocations"
headers = {"Authorization": "Bearer <token>", "Content-Type": "application/json"}

payload = {
    "dataframe_records": [
        {"customer_id": "C001"},
        {"customer_id": "C002"}
    ]
}

response = requests.post(endpoint_url, headers=headers, json=payload)
features = response.json()
# => {"dataframe_records": [
#   {"customer_id": "C001", "avg_spend": 150.5, "total_orders": 42, ...},
#   {"customer_id": "C002", "avg_spend": 89.2, "total_orders": 15, ...}
# ]}

Training-Serving一貫性の実現

Training-Serving Skew（学習時と推論時で特徴量の定義や計算方法が異なる問題）は、MLシステムの信頼性を損なう最大の落とし穴です。 DatabricksのFeature Engineering in Unity Catalogは以下の仕組みでこの問題を構造的に解消します。

• 単一の特徴量定義: UC上のFeature Tableがバッチ学習とオンライン推論の両方のソースになる
• FeatureLookup: 学習データセット作成時にcreate_training_setで特徴量をルックアップし、推論時も同じテーブルから取得
• モデルのリネージ: MLflowにログされたモデルには、使用した特徴量テーブルとバージョンが記録される

from databricks.feature_engineering import FeatureEngineeringClient, FeatureLookup

fe = FeatureEngineeringClient()

training_set = fe.create_training_set(
    df=labels_df,  # ラベルデータ (customer_id, label)
    feature_lookups=[
        FeatureLookup(
            table_name="ml.features.customer_features",
            lookup_key=["customer_id"],
        ),
        FeatureLookup(
            table_name="ml.features.product_features",
            lookup_key=["product_id"],
        ),
    ],
    label="label",
)

training_df = training_set.load_df()

# モデルのログ（特徴量リネージが自動記録される）
fe.log_model(
    model=trained_model,
    artifact_path="model",
    flavor=mlflow.sklearn,
    training_set=training_set,
    registered_model_name="ml.models.recommendation_model",
)

fe.log_modelでログされたモデルには特徴量テーブルの参照が埋め込まれます。 このモデルをModel Servingにデプロイすると、推論リクエスト時にFeature Serving経由で自動的に特徴量がルックアップされます（Feature Function）。

設計上の考慮事項

Feature Servingの監視

• エンドポイントのレイテンシ: P50/P99をモニタリングし、SLA（例: P99 < 100ms）を設定
• Online Tableの同期遅延: ソースDeltaの最終更新からOnline Tableへの反映までの時間差を監視
• 特徴量ドリフト: Lakehouse Monitorをソースの特徴量テーブルに設定し、分布変化を検出
• エンドポイントのエラー率: 4xx/5xxの割合を監視し、キー不一致やスキーマ変更を検出

問題で確認

よくある質問