6.4.3 · блок 6
ADR: нужен ли Feature Store
ADR: нужен ли Feature Store
Зачем это нужно
Feature Store — серьёзная инвестиция: infra (Redis, registry), процессы (feature repo, materialization jobs), обучение команды. Не каждому проекту на втором курсе он нужен сейчас. Architecture Decision Record (ADR) — короткий документ, фиксирующий решение «внедряем Feast / откладываем / используем lightweight alternative» с аргументами.
Умение писать ADR — навык инженера, не только архитектора. Этот урок — шаблон для вашего capstone и реальной работы.
Основные идеи
Что такое ADR. 1–2 страницы в repo docs/adr/NNNN-feature-store.md:
- Context — ситуация и проблема.
- Decision — что выбрали.
- Consequences — плюсы, минусы, follow-up.
- Status — proposed / accepted / superseded.
Формат из модуля 2.2.3 (ADR/RFC); здесь — конкретный кейс Feature Store.
Критерии оценки «нужен ли FS».
| Критерий | Вес | Вопрос |
|----------|-----|--------|
| Online inference | Высокий | Есть ли p95 < 500 ms API с фичами? |
| Количество моделей / reuse | Высокий | >2 моделей на одних entity? |
| Train/serve skew риск | Высокий | Одни фичи в Spark train и Redis serve? |
| Команда и зрелость | Средний | Есть ли platform support для Redis/Feast? |
| Regulatory / lineage | Средний | Нужен audit trail фич? |
| Data volume / complexity | Средний | Point-in-time joins нетривиальны? |
Scoring: много «да» на высокий вес → FS оправдан.
Варианты решения.
Option A — Full Feast (online + offline).
- Плюсы: skew minimized, catalog, PIT joins.
- Минусы: ops Redis, materialization SLA, learning curve.
Option B — Shared feature library + versioned Parquet only.
- Python package
ml_featuresимпортируется в Spark job и inference container. - Offline: Parquet snapshots; online: precomputed subset in Redis без Feast registry.
- Плюсы: проще для MVP.
- Минусы: manual PIT joins; catalog слабый; drift в library versions.
Option C — Отложить FS, batch-only scoring.
- SQL warehouse + nightly scores.
- Плюсы: минимум moving parts.
- Минусы: не масштабируется на online ML.
Option D — Managed FS (cloud).
- SageMaker FS, Vertex Feature Store — если уже в облаке vendor.
- В MDP учебный кластер — обычно Option A или B.
Триггеры пересмотра ADR.
- Запуск второй online модели на
customer_id. - Incident train/serve skew.
- Compliance audit запросил lineage фич.
Связь с Google Rules of ML.
- Rule #32: Re-use code between training and serving → аргумент за FS или shared library.
- Rule #36: Look for distribution changes → мониторинг фич (с FS или без).
- Rule #43: Simple model first → не усложнять FS до product-market fit модели.
Как это выглядит на практике
Пример ADR (фрагмент) для capstone «Churn scoring»:
# ADR-0007: Feature Store для churn ML
## Status
Accepted
## Context
- Online REST `/predict`, p95 target 200 ms.
- 12 features: 8 batch (T-1), 4 near-real-time from Kafka.
- Команда: 2 MLE, platform provides Redis.
- Second model (upsell) planned Q3 on same customers.
## Decision
Adopt Feast with Redis online store and Parquet offline on MinIO.
## Consequences
+ Single definitions for 12 features; materialize daily + streaming partial update.
+ ClearML train uses get_historical_features.
- Ops: new Argo cron, Redis backup, on-call for materialization failures.
- Team training: 2 workshops on Feast concepts.
## Alternatives considered
- Option B rejected: 4 streaming features make manual sync error-prone.
- Option C rejected: product requires online scoring.
Review process. ADR в MR → platform + DS review → merge → link в Jira epic.
Для учебного проекта с одной batch моделью часто достаточно Option B с явным планом «migrate to Feast when upsell model starts».
Что сделать после занятия
- [ ] Заполните scoring table для capstone (6 критериев → да/нет).
- [ ] Напишите черновик ADR на 1 страницу: Context + Decision + one Consequence.
- [ ] Укажите trigger, при котором вы пересмотрите решение через 6 месяцев.