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

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 месяцев.

ADR: нужен ли Feature Store