6.4.1 · блок 6

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

Зачем это нужно

Одна и та же фича «средний чек за 30 дней» считается в Spark для обучения, в Kafka-consumer для online, в SQL для отчёта — и в трёх местах разная логика. Результат: модель в prod работает хуже, чем в notebook. Feature Store — слой платформы, который хранит определения фич, обеспечивает единую логику для train и serve и ускоряет reuse между командами.

Для MLOps это не «модная база данных», а ответ на train/serve skew и хаос дублирования.

Основные идеи

Проблемы без Feature Store.

| Проблема | Последствие |

|----------|-------------|

| Дублирование feature code | Расхождение train vs serve |

| Нет каталога фич | DS не знает, что уже есть |

| Point-in-time joins вручную | Data leakage в training |

| Online features ad hoc в Redis | Нет версий, нет lineage |

| Долгий onboarding новой модели | Weeks to rebuild features |

Feature Store решает (идеально):

1. Feature definitions as code — имя, тип, transformation, owner, version.

2. Offline store — исторические значения для batch train / backtesting (Parquet, BigQuery, …).

3. Online store — low-latency lookup по entity key (Redis, DynamoDB, …).

4. Materialization — pipeline offline → online sync.

5. Point-in-time joins — корректные training datasets без leakage.

Entity и feature view.

Entity — объект, к которому привязаны фичи: customer_id, product_id.
Feature view — группа связанных фич с общим источником и refresh policy.
Feature vector — набор значений для inference request.

Offline vs online store.

| Store | Latency | Use case |

|-------|---------|----------|

| Offline | Seconds–hours | Train, batch scoring, analytics |

| Online | Milliseconds | Real-time inference |

Не все фичи нужны online — только те, что использует low-latency API.

Feast — open-source Feature Store, популярен в K8s / cloud-native стеках (урок 6.4.2). Альтернативы: Tecton (commercial), Hopsworks, AWS SageMaker Feature Store — принципы схожи.

Feature reuse и governance. Каталог: «фича avg_check_30d v2, owner: team-retail, SLA refresh: daily 06:00». Новая модель подключает существующие фичи вместо переписывания.

Не путать с Model Registry. Model Registry (MMS, ClearML) хранит модели. Feature Store — данные/фичи. Связаны через training dataset metadata.

Когда Feature Store overkill.

Одна модель, 5 фич, команда 2 человека, batch-only scoring.
Нет online inference.
→ Достаточно shared library + versioned Parquet (ADR в 6.4.3).

Когда Feature Store must-have.

Много моделей на общих entity.
Online + batch training на одних фичах.
Regulatory requirement на lineage фич.

Как это выглядит на практике

Architecture sketch:


Spark / Flink (batch/stream)
        │ write
        ▼
  Offline store (Parquet on MinIO)
        │ materialize
        ▼
  Online store (Redis)
        │ get_online_features(entity_keys)
        ▼
  Inference (KServe + preprocessing)

Training:


# Концептуально (Feast API)
training_df = store.get_historical_features(
    entity_df=labels_df,  # customer_id + event_timestamp
    features=["customer_features:avg_check_30d", "customer_features:tx_count_7d"],
).to_df()

Feast выполняет as-of join — значения фич на момент label timestamp.

Inference:


features = store.get_online_features(
    features=["customer_features:avg_check_30d", ...],
    entity_rows=[{"customer_id": "c-9912"}],
).to_dict()

Organization: platform team ops Feast; DS/MLE публикуют feature views через MR в Git; materialization — Argo CronWorkflow.

Что сделать после занятия

[ ] Назовите 3 проблемы из таблицы, которые актуальны для вашего учебного проекта.
[ ] Разделите 5 фич на «нужны online» vs «только batch».
[ ] Объясните разницу entity и feature view своими словами.

Официальные материалы

Открыть интерактивную версию