Зачем это нужно
Одна и та же фича «средний чек за 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 решает (идеально):
Feature definitions as code — имя, тип, transformation, owner, version.
Offline store — исторические значения для batch train / backtesting (Parquet, BigQuery, …).
Online store — low-latency lookup по entity key (Redis, DynamoDB, …).
Materialization — pipeline offline → online sync.
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 своими словами.