Сценарий ML: архитектура Feature Store

Условие

Опишите архитектуру feature store. Какие проблемы решает и какие компоненты обязательны.

Решение

Подход

Feature Store — централизованное хранилище features, поддерживающее:

1. Offline store (для train, batch inference): обычно колоночное хранилище (Parquet, Iceberg, BigQuery).
2. Online store (для real-time inference): low-latency KV-store (Redis, DynamoDB, Cassandra).
3. Feature definitions (registry): код для вычисления каждой фичи.
4. Materialization pipeline: ETL который пишет фичи в offline и синкает в online.
5. Point-in-time correctness: для train берём фичи по состоянию на момент события (как было бы на проде).

Проблемы, которые решает

1. Training-serving skew: фича считается одинаково в train и inference.
2. Time travel: историческое состояние фичей для бэктестов.
3. Reuse: одна фича доступна десяткам моделей.
4. Lineage / governance: знаем кто и когда поменял.

Архитектура

┌─────────────────────┐
│   Sources           │  Kafka, S3, DB, API
└──────────┬──────────┘
           │
   ┌───────▼───────┐
   │ Transformers  │  Spark / Beam / Flink
   └───┬───────┬───┘
       │       │
   Offline   Online
   ┌───▼───┐ ┌─▼────┐
   │Parquet│ │Redis │
   └───────┘ └──────┘
       │       │
       ▼       ▼
   Training  Serving

Point-in-time join

Ключевая операция: для каждого события в train, найти state фичи на момент t_event (не позже!). Иначе leakage.

# Псевдо-SQL point-in-time join
SELECT e.*, f.feature_value
FROM events e
LEFT JOIN feature_history f
  ON e.entity_id = f.entity_id
  AND f.timestamp = (
      SELECT MAX(timestamp) FROM feature_history
      WHERE entity_id = e.entity_id AND timestamp <= e.event_time
  )

В Feast / Tecton / Hopsworks реализовано через ASOF JOIN.

Online/offline parity

• Один код для вычисления (DRY).
• Регулярный assertion: считать одну фичу обоими путями, сравнить.
• Schema versioning.

Tooling

• Feast (open-source).
• Tecton, Hopsworks (enterprise).
• Self-built: на больших масштабах нередко.

Подводные камни

1. Training-serving skew — главный enemy. Простейший пример: на train scaler — global mean, на проде real-time mean of streaming.
2. Point-in-time leakage: фича обновилась после события, но взяли её текущее значение → train видит будущее.
3. Late-arriving data: фича вычисляется по event timestamp, но event пришёл late → feature пропущен.
4. Schema evolution: добавили поле → старые модели сломались. Versioning + backfill.
5. TTL для online: фичи устаревают, нужен compaction. Иначе Redis заполнится.
6. Online latency: TP99 < 10ms — это не easy. Cache hot features, predict shape запросов.

Эталонный ответ

Feature Store: offline (Parquet, train), online (Redis, inference), feature registry, materialization pipeline. Решает training-serving skew, point-in-time correctness, reuse. Ключ — ASOF JOIN по entity_id и timestamp ≤ event_time. Tooling: Feast / Tecton / Hopsworks или self-built.