ストーリー
田
田中VPoE
特徴量ストアには「オフラインストア」と「オンラインストア」の2つの顔がある。この使い分けがMLOpsの肝だ
田
田中VPoE
そうだ。学習時は大量の履歴データが必要だからオフラインストア。推論時は低レイテンシで最新値が必要だからオンラインストア。両者の同期が「Feature Freshness」の課題だ
2層アーキテクチャ
┌─────────────────┐
│ 特徴量パイプライン │
└────────┬────────┘
│
┌────────┴────────┐
│ │
┌─────┴─────┐ ┌──────┴──────┐
│ オフライン │ │ オンライン │
│ ストア │ │ ストア │
└─────┬─────┘ └──────┬──────┘
│ │
バッチ学習 リアルタイム推論
比較
| 項目 | オフラインストア | オンラインストア |
|---|
| 用途 | モデル学習、バッチ推論 | リアルタイム推論 |
| レイテンシ | 秒〜分 | ミリ秒 |
| データ量 | 大量(TB級) | 最新値のみ |
| バックエンド | S3, BigQuery, Redshift | Redis, DynamoDB |
| クエリ | 時系列JOIN | Key-Value Lookup |
オフラインストアの設計
Point-in-Time JOIN
学習データ作成時に最も重要な概念:
# 正しい: 予測時点で利用可能だった特徴量のみ使用
training_data = feast_store.get_historical_features(
entity_df=entity_df, # customer_id + event_timestamp
features=[
"customer_features:total_purchases",
"customer_features:avg_order_value",
],
)
# 注意: 未来の情報がリークしていないか確認
# event_timestamp 以前のデータのみが返される
データリーケージ防止
| リスク | 対策 |
|---|
| 未来のデータ混入 | Point-in-Time JOINの厳格な適用 |
| ターゲットリーケージ | 目的変数と相関が高すぎる特徴量のチェック |
| サンプル汚染 | 学習/検証/テスト分割の時系列考慮 |
オンラインストアの設計
低レイテンシの実現
# Feastでオンラインストアから取得
feature_vector = feast_store.get_online_features(
features=[
"customer_features:total_purchases",
"customer_features:avg_order_value",
],
entity_rows=[{"customer_id": "C001"}],
).to_dict()
# レスポンス: ~10ms
バックエンド選定
| バックエンド | レイテンシ | スケーラビリティ | コスト |
|---|
| Redis | < 1ms | 中 | 高(メモリ) |
| DynamoDB | < 10ms | 高 | 従量課金 |
| Bigtable | < 10ms | 非常に高 | 中〜高 |
| SQLite | < 5ms | 低 | 低 |
同期戦略(Materialization)
オフラインストア → [Materialization Job] → オンラインストア
│
定期実行(cron)
or イベント駆動
| 戦略 | 頻度 | 鮮度 | 複雑さ |
|---|
| 定期バッチ | 時間〜日 | 低〜中 | 低 |
| マイクロバッチ | 分〜時間 | 中〜高 | 中 |
| ストリーミング | リアルタイム | 高 | 高 |
まとめ
- オフラインストアは学習用(大量・履歴)、オンラインストアは推論用(低レイテンシ・最新値)
- Point-in-Time JOINでデータリーケージを防止する
- オンラインストアのバックエンドはレイテンシ要件で選定
- Materialization戦略で2つのストアを同期する
チェックリスト
次のステップへ
次はFeature Servingの実装パターンと、特徴量ストアの運用について学びます。
推定読了時間: 30分