Feature stores на собеседовании ML Engineer
Зачем feature stores на собесе MLE
Feature store — централизованное хранилище features для ML моделей. Решает два главных вопроса: train/serve skew (features в обучении ≠ features в проде) и reuse (одну фичу используют несколько моделей). На собесе ML Engineer feature stores — обязательная тема для middle+.
Слабый ответ — «features в SQL-таблице». Сильный — про online/offline store, point-in-time correctness, feature serving API.
Train / serve skew
Главная проблема, которую решают feature stores.
Сценарий:
- DS пишет SQL для features в training notebook
- MLE переписывает на Python для real-time inference
- Логика расходится → модель в проде делает predictions на different features → катастрофа
Решение:
- Single source of truth для feature definitions
- Same code generates features в обоих контекстах
Архитектура feature store
Offline store:
- Historical features для training
- Хранилище: data lake (Parquet on S3), DWH (BigQuery, Snowflake)
- Доступ через batch (Spark, dbt)
Online store:
- Latest values для real-time inference
- Хранилище: Redis, DynamoDB, Cassandra
- Low-latency lookup (< 10ms)
Registry:
- Feature definitions (SQL / Python)
- Schemas, owners, descriptions
- Versioning
Serving API:
- Get features для prediction
- Bulk lookup для batch jobs
Tools
Feast (open-source): самый популярный. Декларативный YAML + Python. Поддерживает разные offline / online backends.
Hopsworks: enterprise, full-featured. Своя платформа.
Tecton: managed, основан экспертами Uber.
SageMaker Feature Store / Vertex AI Feature Store: AWS / GCP managed.
Внутренние решения: в крупных компаниях часто in-house (Uber Michelangelo, Netflix Atlas, Airbnb Zipline).
В РФ — open-source Feast популярен.
Point-in-time correctness
Главная техническая сложность.
Проблема: для training нужны features as of moment of decision. Пример: «при заказе X — каков был user-LTV?». В data lake может быть updated LTV (более свежий) — training-time LTV ≠ inference-time LTV → leakage.
Решение:
- Каждое feature value с timestamp
feature_timestamp - Каждый training example с timestamp
event_timestamp - Join по
feature_timestamp ≤ event_timestamp - ASOF JOIN в SQL
Feast и аналоги делают это автоматически.
Online vs offline serving
Offline (training, batch):
- Spark / SQL чтобы прочитать features за период
- Bulk lookups
- Point-in-time correctness
Online (real-time inference):
- Key-value lookup из Redis (< 10ms)
- Latest value (current state)
- Иногда — pre-computed aggregates («last 7d transactions count»)
Materialization:
- Job вычисляет offline features → pushes в online store
- Schedule: hourly / daily
- Real-time updates через streaming для critical features
Feature definitions
Standard format:
@on_demand_feature_view(
sources=[orders_source],
schema=[Field(name="order_count_7d", dtype=Int64)],
)
def order_count_7d(features_df: pd.DataFrame) -> pd.DataFrame:
return features_df.groupby("user_id").agg(
order_count_7d=("order_id", "count")
).reset_index()Single definition → используется в training и inference.
Типичные вопросы
«Зачем feature store, если у нас уже есть DWH?»
DWH не solves: train/serve skew (no online API), point-in-time correctness (нужно ASOF JOIN ручками), online serving (DWH не для real-time lookup).
«Что такое point-in-time correctness?»
Features at moment of decision, не latest values. Без этого — data leakage и optimistic training metrics.
«Online store — какой выбрать?»
Redis (popular), DynamoDB (AWS), Cassandra (scale). Зависит от QPS и latency требований. Latency target < 10ms.
«Feast или Tecton?»
Feast — open-source, self-host, OK для small/mid. Tecton — managed, расширенные фичи, дорого.
«Streaming features — как реализовать?»
CDC из транзакционной БД → Kafka → Flink / Spark Streaming → update online store. Latency: секунды.
Частые ошибки
- Train/serve skew ignored. Models в проде делают predictions на different features.
- Без point-in-time correctness. Data leakage в training.
- Online store на 500ms latency. Не работает для real-time inference.
- Features duplicated everywhere. Owner / source unclear.
- Без feature monitoring. Drift не детектится.
FAQ
Feature store обязателен?
Для small team (1-3 models) — overhead. Для 10+ models в проде с real-time inference — must.
Feast или in-house?
Feast — старт. In-house когда нужны фичи, которых нет в Feast.
Streaming + Feast?
Feast поддерживает streaming через Kafka source. Latency: seconds.
Как версионировать features?
В Feast — feature view versioning. Изменение feature = new version → migration plan.
Feature store и DWH — relationship?
Offline store часто использует DWH как backend. Online store — отдельная Redis / DynamoDB.