Налаштування Feature Store (Feast, Tecton) для керування ознаками
Feature Store вирішує одну з найболючіших проблем production ML: розсинхронізацію ознак між навчанням та інференсом (training-serving skew). Коли інженер за даними обчислює ознаку одним способом у Jupyter, а бекенд-розробник - іншим у production-коді, модель деградує непомітно і причину знайти вкрай складно.
Архітектурні компоненти Feature Store
Будь-який Feature Store складається з двох сховищ:
Offline store — для навчання моделей. Зберігає історичні значення ознак із тимчасовими мітками. Зазвичай це BigQuery, Redshift, Snowflake або Parquet-файли у S3. Підтримує point-in-time correct joins – критично важливо, щоб під час підготовки навчальної вибірки не було data leakage з майбутнього.
Online store - для інференсу в реальному часі. Зберігає лише останні значення ознак із затримкою запиту <10мс. Використовується Redis, DynamoDB, Cassandra чи Bigtable.
Feast: open-source варіант
Feast – найбільш поширений open-source Feature Store. Налаштування включає:
- Визначення джерел даних (BigQuery table, Kafka topic, файли)
- Опис Feature Views у Python-коді:
from feast import FeatureView, Field, FileSource
from feast.types import Float64, Int64
user_stats = FeatureView(
name="user_stats",
entities=["user_id"],
ttl=timedelta(days=7),
schema=[
Field(name="purchase_count_7d", dtype=Int64),
Field(name="avg_order_value", dtype=Float64),
Field(name="days_since_last_purchase", dtype=Int64),
],
source=FileSource(path="s3://bucket/user_stats.parquet"),
)
- Налаштування materialization - процесу синхронізації offline → online store за розкладом
- Інтеграція SDK у код навчання та інференсу
Розклад materialization налаштовується через Airflow, Prefect або вбудований scheduler:
feast materialize-incremental $(date +%Y-%m-%dT%H:%M:%S)
Tecton: enterprise-варіант
Tecton надає керований Feature Store з додатковими можливостями:
- Streaming features - обчислення ознак з Kafka/Kinesis в режимі реального часу з latency <100мс
- On-demand features — обчислення ознак у момент запиту на основі контексту (наприклад, ознаки, що залежать від поточного запиту користувача)
- Автоматичний моніторинг дрифту ознак
- Feature lineage - відстеження, які моделі використовують які ознаки
Типовий use case Tecton: банк, де ознаки для скорингу шахрайства мають обчислюватися з урахуванням останніх 5 хвилин транзакцій у часі.
Процес впровадження
| Тиждень | Завдання |
|---|---|
| 1 | Аудит існуючих ознак, вибір offline/online сховищ |
| 2 | Встановлення та налаштування Feast/Tecton, перший Feature View |
| 3 | Міграція 20-50 ключових ознак, налаштування materialization |
| 4 | Інтеграція в навчальний пайплайн та інференс-сервіс |
| 5-6 | Моніторинг, документація, навчання команди |
Метрики після впровадження
- Training-serving skew: знижується до нуля для мігрованих ознак
- Час підготовки нової навчальної вибірки: з кількох годин до 5-15 хвилин
- Повторне використання ознак між командами: 40-60% ознак нових моделей вже є у store
- Latency одержання ознак для інференсу: p99 < 10мс при використанні Redis online store
Вибір між Feast та Tecton
Feast підходить для команд із власною інфраструктурою, бюджетом на DevOps та вимогою до гнучкості. Tecton – для enterprise-компаній, де критична підтримка streaming features та готовий SLA. Також є Feature Store як частина хмарних платформ: Vertex AI Feature Store (GCP), SageMaker Feature Store (AWS), Databricks Feature Engineering.