Сравнение Feature Stores¶

~8 минут чтения

Предварительно: Паттерны ML System Design, Сравнение Experiment Tracking

Training-serving skew -- одна из самых коварных причин деградации ML-моделей в production: метрики на validation завышены на 5-15%, потому что фичи в training вычислялись иначе, чем при serving. Feature store решает эту проблему, обеспечивая единый код вычисления фичей для обоих сценариев. Feast (open-source, 5K+ GitHub stars) с Redis дает p99 latency 10-20ms для online serving, Hopsworks на RonDB -- 5-10ms, а Tecton (managed SaaS) добавляет real-time feature pipelines с Rift engine. В system design интервью feature store -- обязательный компонент для recommendation, fraud detection и search ranking систем.

Зачем нужен Feature Store¶

Без feature store: фичи вычисляются по-разному для training (batch Python) и serving (real-time Java). Результат -- training-serving skew: модель обучена на одних фичах, а в production получает другие.

Ключевой инсайт: feature store -- это не просто хранилище. Это единый источник правды для фичей, который гарантирует что training и serving видят одинаковые данные.

1. Архитектура¶

graph LR
    subgraph Sources["Data Sources"]
        A[Streaming: Kafka]
        B[Batch: Data Lake]
    end

    subgraph FS["Feature Store"]
        A --> C[Feature Pipeline]
        B --> C
        C --> D[Online Store<br/>Redis/DynamoDB]
        C --> E[Offline Store<br/>S3/BigQuery]
    end

    subgraph Consumers["Consumers"]
        D --> F[Model Serving<br/>p99 < 10ms]
        E --> G[Model Training<br/>batch read]
    end

    style C fill:#e8eaf6,stroke:#3f51b5
    style D fill:#fce4ec,stroke:#c62828
    style E fill:#e8f5e9,stroke:#4caf50

Online vs Offline Store¶

Аспект	Online Store	Offline Store
Назначение	Serving (real-time predictions)	Training (batch feature retrieval)
Latency	< 10ms (p99)	Секунды-минуты
Backend	Redis, DynamoDB, Bigtable	S3, BigQuery, Parquet files
Данные	Latest value per entity	Full history (point-in-time)
Access pattern	Key-value lookup	Scan/join

Training-Serving Skew¶

Главная проблема, которую решает feature store:

Тип skew	Причина	Последствие
Feature skew	Разный код computation для train vs serve	Модель видит "невозможные" значения
Time-travel skew	Training использует future data	Утечка данных, завышенные метрики
Distribution skew	Train на старых данных, serve на свежих	Model degradation (data drift)

Point-in-time correctness -- самая частая ошибка в feature pipelines

При подготовке training dataset НЕЛЬЗЯ использовать фичи, которые были вычислены ПОСЛЕ события. Пример: предсказание churn на 1 января -- нельзя использовать среднее за январь, только данные до 1 января. Feast и Tecton автоматически обеспечивают point-in-time correctness через get_historical_features(). Если строите свой pipeline -- это ваша ответственность. Без point-in-time join метрики на validation будут на 5-15% выше реальных.

2. Сравнение инструментов¶

Tool	Тип	Online Store	Offline Store	Streaming	Цена
Feast	Open-source	Redis, DynamoDB	S3, BigQuery, Parquet	Да (push-based)	Бесплатно
Tecton	Managed SaaS	DynamoDB	S3	Да (Spark/Rift)	Enterprise
Hopsworks	Managed / Self-hosted	RonDB (MySQL NDB)	Hudi	Да (Flink/Spark)	Free tier + Enterprise
Databricks Feature Store	Integrated	Delta Lake	Delta Lake	Через Spark Streaming	Часть Databricks
SageMaker Feature Store	AWS managed	DynamoDB	S3	Нет (batch)	Pay-per-use

Performance¶

Store	Online Read (p50)	Online Read (p99)	Batch Read (1M rows)
Feast + Redis	1-5ms	10-20ms	30-60s
Tecton	2-5ms	10-15ms	15-30s
Hopsworks (RonDB)	1-3ms	5-10ms	20-40s
Redis (raw)	< 1ms	2-5ms	N/A (не для batch)
DynamoDB (raw)	2-5ms	10-20ms	60-120s (scan)

Минимальный код (Feast)¶

from feast import FeatureStore

store = FeatureStore(repo_path="feature_repo/")

# Online serving: real-time prediction
features = store.get_online_features(
    features=["user_features:avg_purchase_30d", "user_features:login_count_7d"],
    entity_rows=[{"user_id": 12345}],
).to_dict()

# Offline training: historical features with point-in-time join
training_df = store.get_historical_features(
    entity_df=events_df,  # DataFrame with user_id + event_timestamp
    features=["user_features:avg_purchase_30d", "user_features:login_count_7d"],
).to_df()

3. Decision Framework¶

graph TD
    A[Нужен Feature Store?] --> B{Online serving < 10ms?}
    B -->|Нет, только batch| C[Parquet + DVC достаточно]
    B -->|Да| D{Managed OK?}
    D -->|Да, облако| E{AWS?}
    D -->|Нет, self-hosted| F[Feast + Redis]
    E -->|Да| G[SageMaker FS / Tecton]
    E -->|Databricks| H[Databricks FS]
    E -->|Другое| I[Tecton / Hopsworks]

    style A fill:#e8eaf6,stroke:#3f51b5
    style C fill:#e8f5e9,stroke:#4caf50
    style F fill:#fff3e0,stroke:#ef6c00
    style G fill:#f3e5f5,stroke:#9c27b0

Когда Feature Store НЕ нужен¶

Batch predictions раз в день -- Parquet файлы + cron достаточно
Модель использует < 5 фичей из одного источника
Нет online serving (все offline)
Команда < 3 ML-инженеров, один pipeline

4. Feature Store в System Design¶

На собеседовании feature store -- обязательный компонент для:

Система	Роль Feature Store
Recommendation system	User embeddings, item popularity, interaction history (p99 < 5ms)
Fraud detection	Velocity features (txn count last 1h), device fingerprint, user risk score
Search ranking	Query-document features, CTR history, freshness signals
Ad bidding	User profile, advertiser budget, contextual features

Feature Categories¶

Категория	Частота обновления	Пример	Store
Static	Дни-недели	User demographics, item metadata	Offline (materialize to online)
Batch	Часы	7-day rolling average, monthly stats	Offline -> Online (cron)
Streaming	Минуты-секунды	Click count last 5 min, session features	Streaming pipeline -> Online
Real-time	Request-time	Query embedding, request context	Computed on-the-fly (не в store)

Для интервью¶

Q: "Зачем нужен Feature Store?"¶

Три причины: (1) Training-serving consistency -- одни и те же feature definitions для training и serving, нет skew. (2) Feature reuse -- фичи вычислены один раз, используются многими моделями. (3) Point-in-time correctness -- training dataset автоматически использует фичи "на момент события", без data leakage.

Q: "Feast vs Tecton -- когда что?"¶

Feast если: open-source, self-hosted, гибкость, бюджет ограничен. Минус: operational complexity, нет managed real-time transformations. Tecton если: enterprise, managed, нужны real-time feature pipelines (Rift engine), SLA < 10ms. Минус: дорого, vendor lock-in. Компромисс: Feast + Redis для online, S3 для offline -- покрывает 80% use cases.

Q: "Design feature store for recommendation system."¶

Online store (Redis): user embedding (128-dim), last 50 interactions, 7-day activity stats. Offline store (S3/Parquet): full interaction history, item co-occurrence matrix. Pipeline: batch (hourly aggregations), streaming (click events -> Kafka -> Flink -> Redis). Latency budget: feature retrieval < 5ms из 50ms total SLA. Key metric: training-serving skew rate < 0.1%.

Заблуждение: feature store нужен каждому ML-проекту

Feature store добавляет значительную operational complexity: нужно поддерживать online store (Redis/DynamoDB), offline store (S3/Parquet), feature pipelines, materialization jobs. Если у вас: batch predictions раз в день, < 5 фичей из одного источника, нет online serving, команда < 3 ML-инженеров -- Parquet файлы + cron достаточно. Feature store окупается при: >10 моделей, shared features между командами, online serving с SLA < 50ms.

Заблуждение: Feast -- бесплатная альтернатива Tecton

Feast open-source = бесплатный код, но production deployment требует: Redis cluster (managed ~$200-500/mo), S3 для offline ($50-200/mo), monitoring и alerting для materialization jobs, on-call для онлайн store. Feast не имеет managed real-time transformations -- streaming features нужно вычислять вне Feast (Flink/Spark Streaming -> push в Redis). Tecton стоит дороже, но включает managed Rift engine, SLA, monitoring. Для команд < 5 ML-инженеров Feast + Redis покрывает 80% use cases дешевле Tecton.

Заблуждение: online store latency = feature store latency

Redis raw read < 1ms, но feature store добавляет overhead: SDK serialization, network hop, feature join (если несколько feature views), type casting. Feast + Redis: p50 1-5ms, p99 10-20ms. Для SLA < 5ms на feature retrieval нужно: (1) co-locate Redis с serving infrastructure, (2) batch feature requests (одним запросом все фичи), (3) cache hot features in-memory на serving side. На собеседовании feature retrieval -- часть latency budget: если total SLA 50ms, feature retrieval должен быть < 10ms.

Interview Questions¶

Q: Зачем нужен feature store и когда без него можно обойтись?

Red flag: "Feature store нужен всегда, это best practice"

Strong answer: "Три причины использовать: (1) training-serving consistency -- одни feature definitions, нет skew (метрики на validation завышены на 5-15% без этого). (2) Feature reuse -- фичи вычислены один раз, используются многими моделями. (3) Point-in-time correctness -- training dataset автоматически использует фичи 'на момент события', без data leakage. Без feature store можно: batch predictions < 1 раз в день, < 5 фичей, нет online serving, команда < 3 человек"

Q: Как бы вы спроектировали feature store для recommendation system?

Red flag: "Просто положить все фичи в Redis"

Strong answer: "Два слоя: online store (Redis) -- user embedding (128-dim), last 50 interactions, 7-day activity stats, p99 < 5ms. Offline store (S3/Parquet) -- full interaction history, item co-occurrence matrix для training. Pipeline: batch (hourly aggregations), streaming (click events -> Kafka -> Flink -> Redis). Feature categories: static (user demographics, дни-недели), batch (rolling averages, часы), streaming (click count last 5 min, секунды), real-time (query embedding -- computed on-the-fly, не в store). Latency budget: feature retrieval < 5ms из 50ms total SLA"

Q: Feast vs Tecton -- когда что выбрать?

Red flag: "Feast лучше, потому что бесплатный"

Strong answer: "Feast если: self-hosted, гибкость, бюджет ограничен -- но учитываем operational cost (Redis cluster $200-500/mo, S3 $50-200/mo, DevOps время). Нет managed real-time transformations. Tecton если: enterprise SLA, managed real-time feature pipelines (Rift engine), нужна streaming feature computation без Flink/Spark. Компромисс: Feast + Redis для online + S3 для offline покрывает 80% use cases. Decision tree: данные в облако OK? -> managed OK? -> бюджет? Если self-hosted обязателен -- Feast единственный production-ready open-source вариант"

Sources¶

Feast documentation -- "Feature Store Architecture" (2025)
Tecton -- "Feature Engineering for Real-Time ML" (2025)
Hopsworks -- "Feature Store for Machine Learning" documentation
Google -- "ML Design Patterns: Feature Store" (O'Reilly, 2020)
Uber -- "Michelangelo: Uber's Machine Learning Platform" (2017)