Как Feast наводит порядок в хаосе данных для машинного обучения

Знакомая история: дата-сайентист обучил крутую модель на ноутбуке, используя хитровыдуманные SQL-запросы и кучу CSV-файлов. Но когда приходит время катить это в продакшен, выясняется, что инженер данных не может воспроизвести те же самые признаки (фичи) в реальном времени. В итоге модель в проде видит данные иначе, чем при обучении, и точность летит в пропасть. Эту проблему называют Training-Serving Skew, и именно её пытается решить Feast.

Что это за зверь

Feast — это Feature Store с открытым исходным кодом. Если говорить по-простому, это централизованный склад для ваших данных, подготовленных для ML. Он берет на себя всю грязную работу по хранению, обновлению и выдаче признаков как для обучения моделей (пачками), так и для предсказаний в реальном времени (по одному объекту).

Проект зародился в Gojek и Google Cloud, а сейчас это один из самых популярных инструментов в своей нише. Он не пытается заменить вашу базу данных или Spark-кластер. Напротив, Feast встает «сверху» над существующей инфраструктурой, будь то Postgres, Snowflake или BigQuery, и дает единый интерфейс для работы с данными.

Зачем это нужно разработчику

Главная ценность Feast в том, что он убирает дублирование кода. Вам больше не нужно писать один SQL-запрос для выгрузки истории за год и похожий Python-скрипт для получения тех же данных из Redis в продакшене. Вы описываете фичу один раз, а Feast гарантирует, что она будет выглядеть одинаково везде.

Защита от утечки данных

Одна из самых коварных ошибок в ML — утечка данных из будущего (data leakage). Это когда при формировании обучающей выборки в расчет попадают значения, которые в реальности стали бы известны только после совершения события. Feast решает это через point-in-time joins. Вы передаете список событий с таймстемпами, а система сама «отматывает» состояние признаков на тот конкретный момент времени для каждой строки.

Архитектура без лишних сложностей

В минимальном варианте Feast состоит из нескольких компонентов:

Реестр (Registry): обычный файл или база, где хранятся определения ваших фич.
Offline Store: ваше хранилище исторических данных (S3, BigQuery, Snowflake). Отсюда берутся данные для обучения.
Online Store: быстрая база (Redis, DynamoDB, SQLite) для выдачи фич с низкой задержкой в продакшене.
Feature Server: сервис, который принимает запросы и отдает векторы признаков.

Как это выглядит на практике

Начать работу с Feast проще, чем кажется. После установки через pip и инициализации репозитория, вы описываете свои данные в Python-файлах.

Определение признаков

Вы создаете декларативное описание того, где лежат данные и как их интерпретировать. После этого выполняете команду feast apply, и Feast синхронизирует состояние реестра с инфраструктурой.

Сборка датасета для обучения

Когда нужно обучить модель, вы просто указываете список нужных признаков. Feast сам пойдет в оффлайн-хранилище, сделает все джойны и вернет чистый Pandas DataFrame.

from feast import FeatureStore
import pandas as pd

store = FeatureStore(repo_path=".")

# Ваши целевые события (например, id водителей и время поездки)
entity_df = pd.DataFrame.from_dict({
    "driver_id": [1001, 1002],
    "event_timestamp": [datetime(2021, 4, 12, 10, 59, 42), datetime(2021, 4, 12, 8, 12, 10)]
})

training_df = store.get_historical_features(
    entity_df=entity_df,
    features = [
        'driver_hourly_stats:conv_rate',
        'driver_hourly_stats:acc_rate'
    ],
).to_df()

Использование в продакшене

Для работы в реальном времени данные нужно «материализовать» — перелить из оффлайна в онлайн-хранилище (например, в Redis). Это делается одной командой в терминале или по расписанию. После этого получение фич для предсказания занимает миллисекунды:

feature_vector = store.get_online_features(
    features=['driver_hourly_stats:conv_rate'],
    entity_rows=[{"driver_id": 1001}]
).to_dict()

Что там под капотом

Feast очень гибкий в плане интеграций. Если вы работаете в облаках, он нативно поддерживает BigQuery, Redshift и Snowflake. Для локальной разработки или небольших проектов хватит связки из Parquet-файлов и SQLite.

Интересно, что проект активно смотрит в сторону NLP и векторного поиска. В последних релизах появилась поддержка векторных хранилищ вроде Qdrant и Milvus, что делает Feast полезным не только для классического ML, но и для RAG-систем на базе LLM.

Интерфейс Feast

Кстати, у проекта есть экспериментальный Web UI. Он позволяет визуально просматривать реестр признаков, проверять их актуальность и зависимости. Это сильно упрощает жизнь, когда количество фич в компании переваливает за сотню.

Стоит ли внедрять

Feast — это не «серебряная пуля», и у него есть порог входа. Если у вас одна модель, которая обновляется раз в месяц, Feature Store вам, скорее всего, не нужен. Лишняя сущность в инфраструктуре только добавит головной боли.

Но если вы строите платформу, где работают несколько дата-сайентистов, или если у вас есть критичные к задержкам сервисы (например, антифрод или рекомендательные системы), Feast сэкономит недели разработки. Он наводит порядок в коммуникации между инженерами и исследователями данных, превращая хаос из SQL-скриптов в структурированный каталог.

Начать изучение лучше всего с их Quickstart в документации — он позволяет поднять всю систему локально за пять минут без настройки тяжелых баз данных.