build-feature-store
について
このスキルは、集中型ML特徴量管理のためのFeastベースの特徴量ストアを構築します。バッチ処理とリアルタイム提供のためのオフライン/オンラインストアを設定し、変換を伴う特徴量ビューを定義し、ポイントインタイム正しい結合を保証します。トレーニングと提供の一貫性を維持し、低遅延の特徴量を提供し、複数のモデル間で定義を再利用するためにご利用ください。
クイックインストール
Claude Code
推奨npx skills add pjt222/agent-almanac -a claude-code/plugin add https://github.com/pjt222/agent-almanacgit clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/build-feature-storeこのコマンドをClaude Codeにコピー&ペーストしてスキルをインストールします
ドキュメント
Build Feature Store
See Extended Examples for complete configuration files and templates.
Implement centralized feature management with Feast for consistent feature serving across training and inference.
适用场景
- Managing features for multiple ML models across teams
- Ensuring training-serving consistency for features
- Implementing point-in-time correct historical features
- Serving low-latency features for real-time inference
- Reusing feature definitions across projects
- Versioning feature transformations
- Building feature catalog for discovery and governance
- Preventing feature leakage in training pipelines
输入
- 必需: Raw data sources (databases, data lakes, data warehouses)
- 必需: Python environment with Feast installed
- 必需: Offline store backend (BigQuery, Snowflake, Redshift, or Parquet files)
- 必需: Online store backend (Redis, DynamoDB, Cassandra, or SQLite for dev)
- 可选: Feature transformation logic (Python, SQL, Spark)
- 可选: Entity key definitions (user_id, product_id, etc.)
- 可选: Kubernetes cluster for Feast server deployment
步骤
第 1 步:Initialize Feast Feature Repository
Set up Feast project structure and configure storage backends.
# Install Feast with required extras
pip install 'feast[redis,postgres]' # Add backends as needed
# Initialize new feature repository
feast init my_feature_repo
cd my_feature_repo
# Directory structure created:
# my_feature_repo/
# ├── feature_store.yaml # Configuration
# ├── features.py # Feature definitions
# └── data/ # Sample data (dev only)
Configure feature_store.yaml:
# feature_store.yaml
project: customer_analytics
registry: data/registry.db # SQLite for dev, use S3/GCS for prod
provider: local
# Offline store for training data
offline_store:
type: postgres
# ... (see EXAMPLES.md for complete implementation)
Production configuration with cloud backends:
# feature_store.prod.yaml
project: customer_analytics
registry: s3://feast-registry/prod/registry.db
provider: aws
offline_store:
type: bigquery
project_id: my-gcp-project
# ... (see EXAMPLES.md for complete implementation)
预期结果: Feast repository initialized with config file, sample feature definitions created, offline and online stores configured, registry path accessible.
失败处理: Verify database/Redis credentials (psql -U feast_user -h localhost), check connection strings format, ensure databases exist (CREATE DATABASE feature_store), verify cloud permissions for S3/BigQuery/DynamoDB, test connectivity to storage backends, check Feast version compatibility with backends (feast version).
第 2 步:Define Entities and Data Sources
Create entity definitions and connect to raw data sources.
# entities.py
from feast import Entity, ValueType
# Define entities (primary keys for features)
customer = Entity(
name="customer",
description="Customer entity",
value_type=ValueType.INT64,
# ... (see EXAMPLES.md for complete implementation)
Define data sources:
# data_sources.py
from feast import FileSource, BigQuerySource, RedshiftSource
from feast.data_format import ParquetFormat
from datetime import timedelta
# Development: File-based source
customer_transactions_source = FileSource(
path="data/customer_transactions.parquet",
# ... (see EXAMPLES.md for complete implementation)
预期结果: Entity definitions reference correct ID columns, data sources connect to raw data successfully, event_timestamp_column exists in source data, created_timestamp_column allows point-in-time queries.
失败处理: Verify source data files exist and are readable, check BigQuery/Redshift credentials and table access, ensure timestamp columns have correct format (Unix timestamp or ISO8601), verify Kafka connectivity and topic existence, check schema compatibility between sources and entities.
第 3 步:Define Feature Views with Transformations
Create feature views that define how raw data becomes ML-ready features.
# feature_views.py
from feast import FeatureView, Field
from feast.types import Float32, Int64, String, Bool
from datetime import timedelta
from entities import customer, product
from data_sources import customer_features_source
# Simple feature view without transformations
# ... (see EXAMPLES.md for complete implementation)
预期结果: Feature views registered successfully, schema matches source data, transformations execute without errors, TTL values appropriate for use case, on-demand views combine batch and request features.
失败处理: Verify field names match source columns exactly, check dtype compatibility (Int64 vs Int32), ensure entity references exist, validate transformation logic with sample data, check for division by zero in calculations, verify request source schema matches inference payload.
第 4 步:Apply Feature Definitions and Materialize Features
Deploy feature definitions to registry and materialize to online store.
# Apply feature definitions to registry
feast apply
# Expected output:
# Created entity customer
# Created feature view customer_stats
# Created on demand feature view customer_segments
# ... (see EXAMPLES.md for complete implementation)
Programmatic materialization:
# materialize_features.py
from feast import FeatureStore
from datetime import datetime, timedelta
# Initialize feature store
fs = FeatureStore(repo_path=".")
# Materialize all feature views
# ... (see EXAMPLES.md for complete implementation)
预期结果: Feature definitions applied to registry without conflicts, materialization job completes successfully, online store populated with features, feature freshness within configured TTL.
失败处理: Check offline store query succeeds (feast feature-views describe customer_stats), verify time range has data, ensure online store writable (Redis/DynamoDB permissions), check for duplicate feature names across views, verify entity keys exist in source data, monitor materialization job logs for errors, check disk space for local stores.
第 5 步:Retrieve Features for Training
Fetch point-in-time correct historical features for model training.
# get_training_data.py
from feast import FeatureStore
import pandas as pd
from datetime import datetime
# Initialize feature store
fs = FeatureStore(repo_path=".")
# ... (see EXAMPLES.md for complete implementation)
Point-in-time correctness validation:
# validate_pit_correctness.py
import pandas as pd
from datetime import datetime, timedelta
def validate_point_in_time_correctness(training_df, entity_df):
"""
Ensure features don't leak future information.
"""
# ... (see EXAMPLES.md for complete implementation)
预期结果: Historical features retrieved successfully, entity_df timestamps preserved, no NaN values for materialized features, point-in-time correctness guaranteed (no future data leakage), feature service groups features logically.
失败处理: Check entity_df has required columns (entity names + event_timestamp), verify feature view names match registry, ensure offline store has data for requested time range, check for timezone mismatches (use UTC), verify entity IDs exist in source data, inspect logs for SQL query errors, validate feature view TTL covers requested time range.
第 6 步:Serve Features for Real-Time Inference
Retrieve low-latency features from online store for model serving.
# serve_features.py
from feast import FeatureStore
import time
# Initialize feature store
fs = FeatureStore(repo_path=".")
def get_inference_features(customer_ids: list, request_data: dict = None):
# ... (see EXAMPLES.md for complete implementation)
FastAPI integration:
# api.py
from fastapi import FastAPI
from pydantic import BaseModel
from feast import FeatureStore
import mlflow
app = FastAPI()
fs = FeatureStore(repo_path=".")
# ... (see EXAMPLES.md for complete implementation)
预期结果: Online features retrieved in <10ms for single entity, batch retrieval scales efficiently, on-demand transformations execute correctly, request-time features merged with batch features, API responds quickly (<50ms end-to-end).
失败处理: Check online store populated (run materialize if empty), verify Redis/DynamoDB connectivity and latency, ensure entity keys exist in online store, check for cold start issues (warm up cache), verify on-demand transformation logic, monitor online store memory/CPU usage, check network latency between service and online store.
验证清单
- Feast repository initialized and configured
- Offline and online stores connected successfully
- Entity definitions match source data
- Feature views registered in registry
- On-demand transformations execute correctly
- Materialization completes without errors
- Historical features retrieved with point-in-time correctness
- Online features served with low latency (<10ms)
- Feature freshness within configured TTL
- Training-serving consistency verified
- Feature catalog accessible for discovery
常见问题
- Feature leakage: Using future data in historical features - always validate point-in-time correctness, use created_timestamp column
- Inconsistent transformations: Different logic for training vs serving - use Feast on-demand views for consistency
- Stale features: Online store not materialized regularly - set up scheduled materialization jobs (cron/Airflow)
- Missing entity keys: Entities in training set not in online store - ensure comprehensive materialization, handle missing keys gracefully
- Type mismatches: Schema types don't match source data - validate dtypes before apply, use explicit Field definitions
- Slow online retrieval: Network latency or overloaded online store - co-locate feature store with inference service, use connection pooling
- Large feature views: Materializing millions of entities is slow - partition by date, use incremental materialization, optimize offline queries
- No feature versioning: Breaking changes affect production models - version feature views, maintain backward compatibility
- Timezone confusion: Mixing timezones causes incorrect joins - always use UTC for timestamps
- Ignoring TTL: Serving expired features - set appropriate TTL values, monitor feature freshness
相关技能
track-ml-experiments- Log feature metadata in MLflow experimentsorchestrate-ml-pipeline- Schedule feature materialization jobsversion-ml-data- Version raw data sources for feature engineeringdeploy-ml-model-serving- Integrate feature store with model servingserialize-data-formats- Choose efficient storage formats for featuresdesign-serialization-schema- Design schemas for feature sources
GitHub リポジトリ
関連スキル
content-collections
メタこのスキルは、Content Collections(Markdown/MDXファイルを型安全なデータコレクションに変換するTypeScriptファーストのツール)の本番環境でテストされた設定を提供します。Zodバリデーションによる型安全性を実現し、ブログ、ドキュメントサイト、コンテンツ重視のVite + Reactアプリケーション構築時にご利用ください。Viteプラグインの設定、MDXコンパイルから、デプロイ最適化、スキーマバリデーションまで、すべてを網羅しています。
polymarket
メタこのスキルは、開発者がPolymarket予測市場プラットフォームを活用したアプリケーション構築を可能にします。API統合による取引や市場データの取得に加え、WebSocketを介したリアルタイムデータストリーミングにより、ライブ取引や市場活動を監視できます。取引戦略の実装や、ライブ市場更新を処理するツールの作成にご利用ください。
creating-opencode-plugins
メタこのスキルは、開発者がコマンド、ファイル、LSP操作など25種類以上のイベントタイプにフックするOpenCodeプラグインを作成することを支援します。JavaScript/TypeScriptモジュール向けに、プラグイン構造、イベントAPI仕様、および実装パターンを提供します。カスタムイベント駆動ロジックでOpenCode AIアシスタントのライフサイクルをインターセプト、監視、または拡張する必要がある場合にご利用ください。
sglang
メタSGLangは、高性能なLLMサービングフレームワークであり、RadixAttentionプレフィックスキャッシュを活用したJSON、正規表現、エージェントワークフロー向けの高速で構造化された生成を特長とします。特にプレフィックスが繰り返されるタスクにおいて、大幅に高速な推論を実現し、複雑な構造化出力やマルチターン対話に最適です。制約付きデコードが必要な場合や、広範なプレフィックス共有を伴うアプリケーションを構築する場合は、vLLMなどの代替案ではなくSGLangを選択してください。
