Feature Store

Егор Горбань — Data Engineer

Что такое FeatureStore

https://www.featurestore.org/

Hopsworks:

A feature store is a data platform that supports the development and operation of ML systems by managing the storage and efficient querying of feature data. Feature store (…) supports a multitude of write and read workloads, including batch and streaming writes (…).

Feast:

Customizable operational data system that re-uses existing infrastructure to manage and serve ML features to realtime models

Amazon SageMaker:

Storage and data management layer (…) serves as the single source of truth to store, retrieve, remove, track, share, discover, and control access to features.

Начать можно с того что есть замечательный сайт, посвященный featustore’ам. Там собрана информация о разных вендорах, есть теоретические блоки.

Посмотрим как разные компании, разрабатыващие featurestore’ы и представленные на этом сайте, объясняют свою деятельность.

В определениях обычно говорится, что featurestore – это некоторая платформа, которая помогает в разработке и использовании ML-моделей. Дальше начинаются разногласия, потому что некоторые системы заявляют себя как single source-of-truth для данных, другие утверждают что являются прослойкой между источником/хранилищем данных и сервисом с ML-моделью. Какие-то системы помогают только обрабатывать сырые данные, превращая их в фичи, и затем хранить эти фичи, другие же системы предоставляют более интересные возможности, например обработку данных батчами, поддержку стриминга, какие-то даже уходят в некоторое подобие векторных баз данных, позволяющих, например, искать среди сохранённых объектов “наиболее похожий элемент” и так далее.

Определений довольно много, к тому же иногда они противоречат друг другу, поэтому давайте построим общее видение того, что такое feature store и, главное, как он может помочь в вашем проекте.

Data Flow: before

Как вообще зачастую выглядит разработка в ML команде.

Сначала DE и DS разработчики разрабатывают модель и обучают её на имеющихся исторических данных. Тут важно, что эти данные могли как-то предобрабатываться перед попаданием в хранилище, то есть могут отличаться от сырых данных + данные из хранилищ обрабатываются перед передачей в пайплайн обучения модели.

Далее какой-то сервис будет использовать эту модель. Допустим у нас здесь простая ситуация, когда real-service просто отдаёт модели некоторый входящий инпут. Тем не менее, входящие данные могут как-то обрабатываться, также пайплайн может использовать исторические данные, связанные с персоналиями запроса. Эти данные тоже могут требовать обработки.

Дополнительная проблема заключается в том, что этот процесс довольно разобщен: одни разработчики сначала пишут какие-то пайплайны обработки данных в одном репозитории, другие в другом репозитории с нуля пишут пайплайны для обработки сырых данных, в том формате, в котором в сервис приходят запросы, склеивают их как-то с историческими данными, чтобы использовать это всё для inference модели. Если что-то где-то поменяется, например хотя бы формат сырых данных или структура хранилища исторических данных, то сразу в нескольких местах может стать очень больно.

Решение: централизованная обработка features.

hopsworks:

Решение проблемы звучит довольно логично. Всё равно же мы должны использовать одни и те же по формату данные для обучения модели и её инференса, так давайте и преобразовывать и хранить их в одном месте, чтобы в ML-пайплайнах не обращаться отдельно к разным историческим источникам, и не преобразовывать данные отдельно на разных этапах.

Рассмотрим картинку, которая взята с сайта одного из вендоров: hopsworks. Она довольно точно отражает архитектуру фичесторов в общем.

У нас есть два пайплайна: для обучения и инференса модели. Выделим ещё пайплайн для обработки фичей: feature pipeline. Можно сказать что это неотъемлемая часть концепции фичестора. Здесь мы преобразовываем данные из разных источников и кладём их в общий стор, к которому есть доступ у всех участников команды. Мы можем прогнать этот пайплайн на исторических данных для сохранения исторических фичей. Эти исторические фичи мы можем использовать для обучения модели.

Для работы сервиса мы также получим сырые данные и прогоним на них feature пайплайн для приведения их к общему виду, после чего можем использовать модель и получать предикты.

Это довольно облегчает первоначальную картину и помогает разным разработчикам кооперироваться в процессе разработки сервиса с ML-моделью.

Возможности

Позволяет итеративно заполнять store историческими данными и обрабатывать их тем же способом, каким обработаны имеющиеся данные.
Предоставлять историю и контекст для real-time запросов в ML-сервис.
Помогает выбрать необходимый набор фичей для модели (feature selection).
Помогает использовать данные разными моделями (feature reuse).

Рассмотрим преимущества, которые может дать использование featurestore.

Можно заполнять store историческими данными и обрабатывать их тем же способом, каким обработаны данные, уже лежащие в store. Например у нас может быть datalake в котором лежат данные за последние 5 лет. Мы можем взять данные оттуда за последний год, обработать их, положить в feature store, обучить на них модель. Потом мы можем понять, что нам хочется взять ещё больше данных. Тогда не проблема взять данные ещё за один год, прогнать на этих данных пайплайны и положить в featurestore к уже имеющимся данным. Так мы можем повышать точность модели без необходимости каждый раз готовить все данные заново.
Исторические данные, положенные в feature store, помогают также и в инференсе, предоставляя контекст и историю. Например мы можем посмотреть, сколько раз пользователь был на сайте за последнюю неделю, или посчитаем время, прошедшее с последнего визита.
Можно выбрать подмножество необходимых для модели фичей и переиспользовать их в инференесе, то есть данных может храниться больше чем нужно для конкретной модели.
Можно параллельно обучать несколько моделей, на одном и том же наборе фичей или на разных, но относящихся к одной и той же предметной области. Например в процессе разработки, выбирая лучшую модель для текущей задачи; или при feature-selection, или в случае если для разных приложений одной предметной области вообще нужны разные модели: не нужно запускать отдельно пайплайны для обработки пересекающихся множеств сырых данных.

Дополнительные возможности

(больше зависят от вендора)

Валидация и мониторинг фичей.
Обработка данных батчами
Поддержка стриминга данных
Поддержка time series формата данных: можно указать момент времени, и получить для него валидные на тот момент данные.
Определение наиболее похожего элемента (approximate nearest neighbour)

Рассмотрим дополнительные возможности, которые встречаются не во всех фичесторах, но могут быть весьма полезными.

Некоторые сторы позволяют валидировать и мониторить фичи. Это поможет отследить моменты изменения сырых данных, когда данные с тем же именем перестали совпадать по типу с тем что приходило раньше, или если получены какие-то невалидные значения.
Поддержка обработки данных батчами - это полезно например для ускорения подготовки исторических данных или если мы на стороне сервиса напишем некоторую группировку и будем например раз в 10 минут обрабатывать все накопившиеся данные. Сюда же можно отнести поддержку стриминга данных. Это полезно для высоконагруженных систем, которые работают в потоковом формате и где для потоковых данных нужно сразу получать предикт.
Поддержка временных данных, где нам нужно получить фичи с актуальными на какой-то момент времени значениями. То есть в будущем эти фичи могут перезаписываться или вообще удаляться, или могут в этот момент времени ещё не существовать – обработку всех таких случаев может помочь сделать featurestore.
В некоторых случаях featurestore может разрастись даже до некоторого подобия векторных баз данных и может использоваться для нахождения ближайших, то есть наиболее похожих элементов. Это может быть полезно например для построения рекомендательных систем.

Что внутри

Feature Store Architecture (can be):

Offline store: DataLake / Data Warehouse (холодное хранилище)
1. Колоночная база данных
2. С индексированием файлов и партициями по файлам
3. Поддерживает хранение исторических данных для исследования данных, обучения модели.
4. Часто хранит разные версии данных.
Online Store: Low latency, high availability (горячее хранилище)
1. Строковая база данных
2. С индексированием строк по ключу
3. Поддерживает хранение новых данных
4. Хранится только актуальная версия данных.
[Opt] Model registry: хранение моделей и артефактов.

Архитектурно featurestore как правило состоит из двух объектов: это оффлайн и онлайн хранилище. Можно провести аналогию с горячим хранилищем (онлайн) и холодным хранилищем (оффлайн). Иногда сюда ещё относят хранение моделей, но вообще это лучше рассматривать как отдельный компонент. В разных системах архитектура может отличаться, но в общем она примерно такая.

Offline store предназначен для хранения исторических объектов, где потенциально не требуется low-latency, эти данные например можно использовать для исследования, обучения модели. Обычно это колоночная база данных на нескольких файлах, разделенная по ключу партицирования, с поддержкой индексирования файлов чтобы ускорить поиск и просматривать не все файлы, а только те где искомые данные действительно могут находиться.

Online store предназначен для хранения новых фичей, на которых потенциально может понадобиться инференс. Со временем неактуальные данные могут переходить в offline store.

Например для обеспечения поддержки временных данных, а также для предоставления истории изменений, при изменении данных они обычно не затираются, а дублируются: старая версия кладётся в offline store с соответствующей временной пометкой, когда эти данные перестали быть актуальными, а потом только уже обновляется строка в online store.

Предостережение

Для хранения сырых данных лучше использовать отдельное хранилище с высокой надежностью.

С поддержкой бэкапов и репликации
С ограниченным доступом на запись

Отдельно хочется предостеречь вас от заманчивой мысли использовать только feature store в качестве хранения данных. Каким бы хорошим он ни был, для хранения исторических продуктовых данных лучше перестраховаться и использовать более проверенные методы. В частности обычно используют базы с поддержкой репликации и несколькими уровнями бэкапа.

Также доступ на запись в продуктовые БД должен довольно строго контролироваться, чтобы данные не могли случайно или намеренно замениться, удалиться и т.п., что как раз может произойти во время прогона тестовых пайплайнов для заполнения feature store. Лучше хранить сырые данные в специальной БД и использовать коннекты к этим источникам для наполнения данных для feature store

Дополнительные концепты

Feature group

Концепт семантического объединения данных.

Подмножество фичей, связанных общей семантикой (и возможно временем)
Feature Group vs Set of Features
Например
- (a1, a2, a3), (b1, b2), (c1, c2, c3, c4) - 3 feature groups
- {a1, a2, c1, c3, c4} - set of features
Первичный ключ
- для новых данных – entity_id
- для исторических – (entity_id, timestamp)

Feature group мы уже неявно использовали, когда говорили что один feature store может использоваться разными моделями, но стоит проговорить отдельно

Feature group - это множество фичей, связанных общей семантикой, и возможно временем. В feature store так или иначе используются связанные между собой данные, например данные о поведении пользователя во время посещения сайта, но они могут биться на слабо связанные подмножества, например данные об устройстве пользователя, о его местоположении, о его поведении на странице, и т.п. Такие подмножества и называют feature groups. Можно провести аналогию с отдельными таблицами в нормализованной БД.

Для одних моделей есть смысл использовать данные только одной группы; в то время как другие будут использовать данные сразу нескольких групп, иногда какое-то подмножество объединения несколькоих фичей. Иногда это называют set of features.

То есть мы объединяем группы, выбираем оттуда ещё какие-то фичи с помощью feature-selection, и в итоге у нас получается множество каких-то фичей из нескольких групп: set of features.

Также при исследовании исторических данных нас будет интересовать привязка ко времени, то есть для данных, меняющихся со временем, нужна идентификация не только по ключу, но и с указанием времени, когда эти данные перестали быть актуальными. Тогда для любого момента времени в прошлом, можно будет найти актуальную в тот момент версию данных.

Data transformations

Функции преобразования данных.

model-independent transformations: Feature Pipeline, Inference Pipeline
model-dependent transformations: Training Pipeline, Inference Pipeline
on-demand transformations: Inference Pipeline

Вспомогательная история, которая поможет нам дальше - data transformation (функция преобразования данных)

Выделяют трансформации, зависимые от модели, независимые от модели и вызываемые “по запросу”.
Зависимые от моделей - это например энкодинг данных, который подходит только для конкретной модели.
Независимые - аггрегация, очистка данных, заполнение null-values и т.д.
Трансформации по требованию - это трансформации которые выполняются на live-данных, поступивших с запросом, например вычисляется время прошедшее между этим запросом и предыдущим. Или вычисляется размер скидки в зависимости от стоимости покупки, и т.д. То есть основная особенность - мы не можем их посчитать заранее, они начинают существовать только с возникновением request.

Теперь мы можем понять в каких пайплайнах какие трансформации требуются

В feature пайплайне мы должно сделать все трансформации кроме тех что зависят от модели - логично
В training пайплайне мы должны использовать уже предпосчитанные фичи и нам останется только сделать model-dependent transformation
В inference пайплайне - то есть предсказании на сырых данных нам нужно
1. Обработать их трансформациями по требованию
2. Взять данные для контекста из featurestore (с уже выполненными model-independent преобразованиями)
3. После этого все собранные данные потребуется обработать model-dependent transformation, чтобы привести их к виду тех же данных, что использовались при обучении

Feature reuse

Концепт переиспользования данных.

Основная идея: не делать model transformations в feature pipeline

Problem of online-offline skew

Искажение между обработкой (форматом) реальных данных, приходящих с запросом и обработкой (форматом) исторических данных.

Feature freshness

Концепт актуальности/свежести данных.

Training pipeline
- Проблема: данные используемые для train не самые актуальные
- Возможные решения
  - Для обучения модели используется только последняя версия данных, лежащих в online store.
  - В глобальном смысле: переобучать модели спустя какое-то время.
Inference pipeline
- Проблема: в feature store могут лежать неактуальные значения: feature pipeline ещё не успел отработать на новых данных
- Возможные решения:
  - Выставить лаг и обрабатывать батчами, когда данные в Feature Store точно обновятся
  - Inference на неполных данных
  - Смириться.

В конце поговорим о концепции feature freshness - концепт актуальности данных, который как раз затрагивает проблему онлайн-оффлайн искажения.

Здесь стоит отдельно поговорить про training и inference пайплайны, потому что истории немного отличаются.

Training

Возникает когда данные используемые для обучения не самые актуальные.
Помогает разделение feature store на offline и online store, когда для обучения модели используют только последнюю версию данных, лежащих в online store.
Но есть и более глобальная проблема - модель в целом может устареть из-за того что обучена на неактульных данных - тут может помочь только переобучать модель спустя какое-то время на новых накопившихся за это время данных и исследовать изменения качества модели на свежих данных. Необязательно на новых данных она будет работать лучше, потому что в дело может вступить сезонность и куча других вещей.

Inference

Проблема: в feature store могут лежать неактуальные значения: feature pipeline ещё не успел отработать на новых данных, то есть мы ещё не положили эти фичи, к нам пришел свежий запрос и мы не можем подтянуть все данные необходимые для инференса.
Решений может быть несколько:
1. Если нам не требуется высокая скорость ответа, то мы можем подкопить данные, выставить некоторый лаг когда мы точно будем знать, что данные собрались, и только тогда делать inference
2. Если требуется low latency, то можно попробовать делать inference на неактульных данных, или с отсутствием некоторой части данных - требуется исследование, не повлияет ли это критическим образом на качество модели
3. Иногда лучше искать решение в другом месте - например снизить задержку стриминга: иногда она зависит не от вас. Или вообще смириться, что в существующем бизнес-процессе ML использовать не получится.

Заключение

Feature Store - полезный элемент ML инфраструктуры, который поможет быстро и централизованно обрабатывать сырые данные и упростит работу ML-команды.

В заключение хочется сказать, что Feature Store это довольно полезная штука, которая помогает решать некоторые распространенные проблемы, такие как online-offline-skew, помогает более оперативно и централизованно обрабатывать сырые данные и упрощает работу всей команды.

Может быть вам и не критически нужен какой-то специализированный featurestore инструмент, особенно на ранних стадиях развития проекта, но какая-то подобная структура, хотя бы с реализацией общей идеи, точно не станет лишней.

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