Feature Storeとは？Databricksの特徴量管理

Feature Store（特徴量ストア）は、MLモデルの入力データである特徴量（Feature）を 集中管理・共有・再利用するためのリポジトリです。Databricksでは「Feature Engineering in Unity Catalog」として 提供されており、Unity Catalogのガバナンス機能と統合された特徴量管理基盤を構築できます。 ML Associate試験では全体の10〜15%を占め、Feature Table作成・FeatureLookup・Point-in-Time Joinが頻出です。

Feature Storeが解決する課題

MLプロジェクトでは、データから特徴量を作成する工程が開発時間の大半を占めます。Feature Storeがない環境では以下の問題が頻繁に発生し、モデルの品質と開発効率を低下させます。

Feature Tableの作成

Feature Table（特徴量テーブル）は、主キー（Primary Key）を持つDelta Tableです。Unity Catalogで管理され、通常のテーブルと同様にアクセス制御・リネージ追跡が適用されます。

from databricks.feature_engineering import FeatureEngineeringClient

fe = FeatureEngineeringClient()

# Feature Table の作成（DataFrameから初期データを投入）
fe.create_table(
    name="catalog.schema.customer_features",
    primary_keys=["customer_id"],
    timestamp_keys=["timestamp"],       # Point-in-Time Lookup 用
    df=customer_features_df,
    description="顧客行動特徴量（チャーン予測用）"
)

# 特徴量を DataFrame として読み出し
features_df = fe.read_table(name="catalog.schema.customer_features")

primary_keys は各行を一意に識別する必須パラメータです。timestamp_keys はPoint-in-Time Lookupに使用するオプションパラメータで、 時系列特徴量を扱う場合に指定します。

特徴量の書き込み（write_table）

既存のFeature Tableに新しい特徴量データを追加・更新するには fe.write_table() を使用します。mode パラメータで書き込みモードを制御します。

# 既存の Feature Table に特徴量を追加・更新
fe.write_table(
    name="catalog.schema.customer_features",
    df=new_features_df,
    mode="merge"  # 主キーが一致する行は更新、新規行は挿入
)

# 全データを上書きする場合
fe.write_table(
    name="catalog.schema.customer_features",
    df=full_features_df,
    mode="overwrite"
)

• merge: 主キーが一致する行は更新（UPSERT）、一致しない行は新規挿入
• overwrite: テーブル全体を置き換え（日次バッチ更新で使用）

Feature Lookup（特徴量ルックアップ）

Feature Lookupは、Feature Tableからトレーニングデータセットを構築する仕組みです。ラベルを含むDataFrameと、Feature Tableの主キーを指定するだけで自動的にJOINが実行されます。

from databricks.feature_engineering import FeatureLookup

# 複数の Feature Table からルックアップを定義
feature_lookups = [
    FeatureLookup(
        table_name="catalog.schema.customer_features",
        feature_names=["total_purchases", "avg_session_time", "days_since_last_visit"],
        lookup_key="customer_id"
    ),
    FeatureLookup(
        table_name="catalog.schema.product_features",
        feature_names=["category", "price_tier"],
        lookup_key="product_id"
    )
]

# トレーニングデータセットの構築
training_set = fe.create_training_set(
    df=label_df,          # ラベルと主キーを含む DataFrame
    feature_lookups=feature_lookups,
    label="churn",
    exclude_columns=["customer_id"]  # モデル入力から除外する列
)

training_df = training_set.load_df()
print(training_df.columns)
# ['total_purchases', 'avg_session_time', 'days_since_last_visit',
#  'category', 'price_tier', 'churn']

この仕組みにより、トレーニング時と推論時で同じFeature Tableを参照することが保証され、Training-Serving Skew（トレーニング時とサービング時の特徴量の不一致）を防止できます。

Point-in-Time Join

Point-in-Time Joinは、時系列データの特徴量を扱う際に「データリーケージ」を防ぐための仕組みです。各トレーニングサンプルのラベル時点で実際に利用可能だった特徴量のみを結合し、未来の情報が学習に混入することを防ぎます。

# Point-in-Time Lookup の設定
feature_lookups = [
    FeatureLookup(
        table_name="catalog.schema.customer_features",
        feature_names=["total_purchases", "avg_session_time"],
        lookup_key="customer_id",
        timestamp_lookup_key="event_timestamp"  # ラベル側のタイムスタンプ列
    )
]

# ラベル DataFrame（各行に timestamp 列が必要）
# customer_id | event_timestamp       | churn
# C001        | 2026-03-15 10:00:00   | 1
training_set = fe.create_training_set(
    df=label_df,
    feature_lookups=feature_lookups,
    label="churn"
)

上記の例で、ラベルの日時が2026-03-15 10:00の行に対しては、Feature Tableの中で 2026-03-15 10:00以前の最新の特徴量のみが結合されます。 03-15 10:01以降に計算された特徴量は使われません。 ML Associate試験では、Point-in-Time Joinが何を防ぐか（データリーケージ）を問う問題が頻出です。

モデルとFeature Storeの統合

fe.log_model() でモデルを記録すると、Feature Tableへの参照情報（リネージ）が 自動的にMLflowに記録されます。推論時にはモデルが自動的にFeature Tableから特徴量を取得し、 呼び出し側は主キーのみを渡せばよくなります。

import mlflow

# Feature Store を使ったモデルのトレーニングとログ
with mlflow.start_run():
    model = train_model(training_df)

    fe.log_model(
        model=model,
        artifact_path="model",
        flavor=mlflow.sklearn,
        training_set=training_set,
        registered_model_name="catalog.schema.churn_model"
    )

# 推論時: 主キーのみの DataFrame を渡すと Feature Table から特徴量を自動取得
predictions = fe.score_batch(
    model_uri="models:/catalog.schema.churn_model/1",
    df=inference_df  # customer_id 列のみで OK
)

fe.log_model() と mlflow.sklearn.log_model() の違いは試験頻出ポイントです。fe.log_model() でのみFeature Storeとの連携情報がモデルに記録され、 推論時の自動特徴量取得が有効になります。

Online Feature Serving

リアルタイム推論（Model Serving）では、低レイテンシで特徴量を取得する必要があります。DatabricksのOnline Feature Servingは、Feature Tableのデータをリアルタイム推論エンドポイントから直接利用可能にする機能です。

from databricks.feature_engineering.online_store_spec import (
    AmazonDynamoDBSpec
)

# オンラインストアの設定（DynamoDB の例）
online_store_spec = AmazonDynamoDBSpec(
    region="ap-northeast-1",
    table_name="customer_features_online"
)

# Feature Table をオンラインストアに公開
fe.publish_table(
    name="catalog.schema.customer_features",
    online_store=online_store_spec,
    mode="merge"
)

旧Workspace版 vs Unity Catalog版 比較

試験では「FeatureStoreClient」と「FeatureEngineeringClient」のどちらを使うべきかを問う問題が出ます。 新規プロジェクトでは常にUnity Catalog版の FeatureEngineeringClient を選択します。

ML Associate試験の出題ポイント

• fe.create_table(): primary_keys・timestamp_keysの役割と設定方法
• FeatureLookup: lookup_keyの指定方法、複数テーブルからのルックアップ構成
• Point-in-Time Join: データリーケージの定義と、timestamp_lookup_keyによる防止メカニズム
• fe.log_model() vs mlflow.log_model(): Feature Store連携の有無の違い
• write_tableのモード: mergeとoverwriteの使い分け
• Training-Serving Skew: Feature Storeがどのようにこの問題を解決するか

サンプル問題

よくある質問