Feature Stores: A Hierarchy of Needs

eugeneyan

eugeneyan

Начать здесь Статьи Выступления Прототипирование Обо мне

Feature Stores: A Hierarchy of Needs

Feature Stores: иерархия потребностей

[ teardown machinelearning engineering 🔥 ] · 19 min read

[ teardown machinelearning engineering 🔥 ] · 19 мин чтения

Feature stores have gotten a lot of attention lately. In December 2020, Amazon Web Services released its SageMaker Feature Store. Last month, Splice Machine, a big data platform, launched its own feature store too. Datanami even went as far as to call 2021 the year of the feature store (quoting Tecton.ai’s co-founder).

Feature stores в последнее время привлекают много внимания. В декабре 2020 года Amazon Web Services выпустила SageMaker Feature Store. В прошлом месяце компания Splice Machine, платформа для больших данных, тоже запустила собственное feature store. Издание Datanami даже назвало 2021 год годом feature store (цитируя сооснователя Tecton.ai).

It turns out that managing features, in our experience, is one of the biggest bottlenecks in productizing your ML models. — Uber

По нашему опыту, управление признаками — одно из самых серьёзных узких мест при выводе ML-моделей в продакшен. — Uber

Features (and labels) are the inputs for machine learning models. In a regression equation, labels are the dependent variable, features are independent variables. In a table, labels are the column we try to predict, features are the other columns (though we usually drop IDs).

Признаки (и метки) — это входные данные для моделей машинного обучения. В уравнении регрессии метки — это зависимая переменная, признаки — независимые переменные. В таблице метки — это столбец, который мы пытаемся предсказать, а признаки — остальные столбцы (хотя ID обычно отбрасываем).

What is a feature store? Well, it depends on who you ask. Some articles define it simply as “the central place to store curated features”. Others say it helps you “build features once; plug them anywhere” or “deploy models 100x faster”. There’s a wide range of definitions and I think it’s because what a feature store is depends on what you need.

Что такое feature store? Это зависит от того, кого вы спросите. В одних статьях это определяют просто как «центральное место для хранения подготовленных признаков». В других говорят, что он помогает «создать признаки один раз и использовать их где угодно» или «разворачивать модели в 100 раз быстрее». Определений много, и я думаю, дело в том, что чем является feature store, зависит от того, что вам нужно.

To learn more about feature stores and the needs they address, I dug into tech/blogs from companies. Unsurprisingly, I found myself organizing feature store features (haha) into a hierarchy of needs (inspired by Maslow). We’ll go over an overview of the feature store hierarchy of needs before discussing how companies have met those needs at each level.

Чтобы лучше разобраться с feature stores и потребностями, которые они закрывают, я изучил технические блоги компаний. Неудивительно, что я начал систематизировать возможности feature store (вот так каламбур) в виде иерархии потребностей (вдохновлённой Маслоу). Сначала мы рассмотрим общий обзор иерархии потребностей feature store, а затем обсудим, как компании удовлетворяют эти потребности на каждом уровне.

Иерархия потребностей Feature Store Доступ: сокращение дублирования и поощрение переиспользования Serving: использование признаков в реальном времени Целостность: создание корректных офлайн- и онлайн-признаков Удобство: сделать использование максимально простым Автопилот: автоматизация всего, что можно

This post is now available in Mandarin thanks to Yik San!

Эта статья теперь доступна на китайском благодаря Yik San!

The feature store hierarchy of needs

Иерархия потребностей feature store

Maslow’s Hierarchy of Needs is a motivational theory in psychology. It suggests that there are five tiers of human needs and is often shown as hierarchical levels within a pyramid. The largest, most fundamental needs at the bottom must be satisfied before individuals become motivated to higher-level needs.

Иерархия потребностей Маслоу — мотивационная теория в психологии. Она предполагает пять уровней человеческих потребностей и часто изображается как иерархия в виде пирамиды. Самые крупные и базовые потребности у основания должны быть удовлетворены до того, как человек становится мотивирован стремиться к потребностям более высокого уровня.

Maslow's hierarchy of needs as a pyramid, with more basic needs at the base. (source)

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

Physiological needs: These are biological requirements for survival, such as air, water, food, shelter, etc. The human body cannot function optimally without satisfying these needs. Maslow considered these needs the most important as other needs are secondary until these needs are met.

Физиологические потребности: это биологические требования для выживания — воздух, вода, еда, кров и т. д. Человеческий организм не может функционировать оптимально без удовлетворения этих потребностей. Маслоу считал их самыми важными, поскольку остальные потребности вторичны, пока эти не удовлетворены.

Safety needs: Once physiological needs are met, the need for security and safety gains importance. Such needs include physical safety, health, economic safety, employment, law and order, social stability, etc. They are usually fulfilled by family, society, and government.

Потребности в безопасности: как только физиологические потребности удовлетворены, на первый план выходит потребность в безопасности и защищённости. Сюда входят физическая безопасность, здоровье, экономическая безопасность, занятость, законность и порядок, социальная стабильность и т. д. Обычно они обеспечиваются семьёй, обществом и государством.

Belongingness and love needs: This level of needs is interpersonal and involves a sense of belonging and acceptable among social groups. Such groups include co-workers, religious groups, professional organizations, sports clubs, and online communities. It can also involve smaller social connections such as family, confidants, and mentors.

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

Esteem needs: These are based on ability or achievement, and can be classified into two categories. The “lower” version is the need for respect from others, such as status, recognition, and reputation. The “higher” version is the need for self-respect, master, and achievement.

Потребности в уважении: они основаны на способностях или достижениях и делятся на две категории. «Низшая» версия — потребность в уважении со стороны других: статус, признание, репутация. «Высшая» версия — потребность в самоуважении, мастерстве и достижениях.

Self-actualization needs: This is the highest level in Maslow’s hierarchy and refers to the realization of one’s full potential, to be the most that one can be. Different people perceive this need differently. For example, a person might have a strong desire to become an ideal parent, while others may express such needs economically, academically, or athletically. It can also be expressed creatively, via inventions, art, and writing.

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

I think feature stores can be organized as a hierarchy of needs too. Some needs are more pressing than others (e.g., access to data, serving features in production). These essential needs have to be fulfilled before higher needs are considered.

Я думаю, что feature stores тоже можно организовать как иерархию потребностей. Некоторые потребности более насущны, чем другие (например, доступ к данным, serving признаков в продакшене). Эти базовые потребности должны быть удовлетворены до того, как имеет смысл думать о более высоких уровнях.

Feature Store Hierarchy of Needs

Иерархия потребностей Feature Store

At the base, we have access needs. This includes access to feature information and data, transparency, and lineage. Transparency lets users view the logic and code creating the features while lineage lets them trace upstream sources. Together, they make it easier to find, share, and reuse features, minimizing duplicate work.

В основании — потребности доступа. Сюда входят доступ к информации о признаках и самим данным, прозрачность и lineage. Прозрачность позволяет пользователям видеть логику и код, создающие признаки, а lineage — отслеживать источники выше по цепочке. Вместе они упрощают поиск, обмен и переиспользование признаков, минимизируя дублирование работы.

Previously, ML practitioners at Airbnb spent roughly 60% of their time on collecting and writing transformations for machine learning tasks. — Airbnb

Раньше ML-практики в Airbnb тратили примерно 60% своего времени на сбор данных и написание трансформаций для ML-задач. — Airbnb

Next, we have serving needs. Here, the key need is to use the features in production, usually at high throughput and low latency (i.e., not SQL queries). Other needs include the ability to integrate with existing offline feature stores so features can be synced from offline to online feature stores (e.g., Redis). It can also include the ability to perform real-time feature transformations within the feature store itself.

Дальше — потребности serving. Здесь ключевая задача — использовать признаки в продакшене, обычно при высокой пропускной способности и низкой задержке (то есть не SQL-запросами). Другие потребности — возможность интеграции с существующими офлайн-хранилищами признаков, чтобы синхронизировать признаки из офлайн- в онлайн-хранилища (например, Redis). Сюда же может входить возможность выполнять трансформации признаков в реальном времени внутри самого feature store.

Data scientists would typically implement features in individual silos, then hand over their code to a data engineering team to reimplement production-ready pipelines. This process of reimplementing pipelines can add months to a project and requires complex coordination between teams. — GoJek

Data scientists обычно реализовывали признаки в изолированных контурах, а затем передавали свой код команде дата-инженеров для повторной реализации production-ready пайплайнов. Этот процесс может добавлять к проекту месяцы и требует сложной координации между командами. — GoJek

Once lower needs are met, we can turn to integrity needs. Here, the prevalent need is minimizing train-serve skew. This means ensuring consistency between the features during training, and the features used as input when calling the model in production. Another common need is point-in-time correctness (aka time travel). This ensures that historical features and labels used in offline training and evaluation don’t have data leaks.

Когда нижние уровни закрыты, можно переходить к потребностям целостности. Здесь главная задача — минимизировать train-serve skew. Это означает обеспечение согласованности между признаками во время обучения и признаками, подаваемыми на вход модели в продакшене. Другая частая потребность — point-in-time correctness (она же time travel). Она гарантирует, что исторические признаки и метки, используемые в офлайн-обучении и оценке, не содержат утечек данных.

A lot of training is done in an offline way, and serving often happens, at least at Uber, in real-time environments. It is absolutely important to make sure that the data that you’re using in real-time, at serving time, matches the data that is used at training. — Uber

Большая часть обучения происходит офлайн, а serving часто, по крайней мере в Uber, идёт в режиме реального времени. Принципиально важно убедиться, что данные, которые вы используете в реальном времени при serving, совпадают с данными, использованными при обучении. — Uber

Beyond that, we have convenience needs. The feature store needs to be easy and quick to use for data practitioners to adopt and realize the productivity gains. Such needs include having simple, intuitive APIs that can be used for training and serving, as well as interactivity to allow for faster development and debugging.

Дальше идут потребности удобства. Feature store должен быть простым и быстрым в использовании, чтобы дата-практики его приняли и получили прирост продуктивности. Сюда входят простые интуитивные API, которые можно использовать как для обучения, так и для serving, а также интерактивность для ускорения разработки и отладки.

But remember, we are a platform, not an engineering team… How can we provide a tool for (users) so that we can give this power back to them, so that they can, without help from us, do all this work by themselves? — Uber

Но помните: мы платформа, а не инженерная команда… Как нам дать пользователям инструмент, который вернёт им эту мощь, чтобы они могли без нашей помощи делать всё это самостоятельно? — Uber

Finally, we have autopilot needs. These are needs to automate tedious work such as backfilling features, monitoring and alerts on feature distributions, etc. Some companies have implemented solutions to address these needs, but they are not widespread across the material I’ve researched.

Наконец, на вершине — потребности автопилота. Это потребности автоматизировать рутинную работу: backfill признаков, мониторинг и алерты по распределениям признаков и т. д. Некоторые компании реализовали решения для этих задач, но в материалах, которые я изучил, такое не сильно распространено.

Backfilling is a major bottleneck when you’re iterating on your training set ideas. Efficiently computing new training sets is a huge deal for speeding up your data scientist workflow. —Airbnb

Backfilling — серьёзное узкое место, когда вы итеративно дорабатываете идеи для тренировочного набора. Эффективное вычисление новых обучающих наборов сильно ускоряет работу data scientist. — Airbnb

Not all organizations will require all levels of needs though most teams can benefit from meeting the first two levels (access and serving) and part of the third (minimizing train-serve skew). The extent of each need may also vary. Organizations with fewer online ML use cases may have less demanding serving needs relative to DoorDash (i.e., millions of requests per second). Models and features that update intraday may have tricker needs for point-in-time correctness.

Не всем организациям нужны все уровни потребностей, хотя большинство команд получат пользу от первых двух уровней (доступ и serving) и части третьего (минимизация train-serve skew). Глубина каждой потребности тоже может варьироваться. Организации с меньшим числом онлайн ML use-cases могут иметь менее требовательные нужды по serving по сравнению с DoorDash (миллионы запросов в секунду). Модели и признаки, обновляющиеся в течение дня, могут иметь более сложные требования к point-in-time correctness.

Now that we have an understanding of the various levels of needs, let’s take a look at how companies have built feature stores to address them.

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

Parts of the feature store hierarchy of needs are borrowed from the product evolution model in The Innovator’s Dilemma. It is also called the buying hierarchy by its creators, Windermere Associates of San Francisco, California.

Части иерархии потребностей feature store позаимствованы из модели эволюции продукта в книге The Innovator's Dilemma. Её также называют buying hierarchy по имени создателей, Windermere Associates из Сан-Франциско, Калифорния.

Competition evolves along Functionality, Reliability, Convenience, and Price

Конкуренция эволюционирует по осям функциональности, надёжности, удобства и цены

Functionality: When no available product meets the functionality requirement of the market, the basis of competition is on functionality. Can it do what other competitors cannot?

Функциональность: когда ни один доступный продукт не удовлетворяет требованиям рынка по функциональности, конкуренция идёт за неё. Может ли он делать то, что не могут конкуренты?

Reliability: When two or more products credibly satisfy the demand for functionality, customers will then choose products based on reliability. Can it deliver consistent quality?

Надёжность: когда два или более продукта правдоподобно закрывают спрос на функциональность, клиенты выбирают по надёжности. Может ли продукт стабильно обеспечивать одно и то же качество?

Convenience: When multiple products more than satisfy the reliability demanded by the market, customers will then choose products based on convenience. Which is easier and/or quicker?

Удобство: когда несколько продуктов более чем удовлетворяют требования рынка к надёжности, клиенты выбирают по удобству. Что проще и/или быстрее?

Price: Finally, when multiple products fully satisfy the market demand for convenience, the basis of competition shifts to price. Which is cheaper?

Цена: наконец, когда несколько продуктов полностью удовлетворяют спрос на удобство, конкуренция смещается к цене. Что дешевле?

Access: Reducing duplication & encouraging reusability

Доступ: сокращение дублирования и поощрение переиспользования

What happens if access to feature information and data is low? Here’s a common experience across several companies:

Что происходит, если доступ к информации о признаках и данным затруднён? Вот типичный опыт нескольких компаний:

Разные команды по нескольку раз создавали один и тот же признак, иногда до 10 разных версий одного и того же. Строились дублирующиеся пайплайны для концептуально похожих признаков, что приводило к лишним усилиям и расходам ресурсов (compute, storage). Сложно получать согласованные результаты, потому что модели использовали разные версии одного признака. Как следствие — более медленные итерации и разработка у команд data science и ML.

Features representing the same business concepts are being redeveloped many times, when existing work from other teams could have been reused. — GoJek

Признаки, представляющие одни и те же бизнес-понятия, переразрабатываются по многу раз, тогда как уже существующую работу других команд можно было бы переиспользовать. — GoJek

To address this, GoJek built Feast, a feature store that acts as the interface between data engineers and scientists, and ML practitioners. Data engineers and scientists create features and contribute them to the feature store. Then, ML practitioners consume these ready-made features, saving time by not having to create their own features.

Чтобы решить эту проблему, GoJek построила Feast — feature store, который служит интерфейсом между дата-инженерами и сайентистами с одной стороны и ML-практиками с другой. Дата-инженеры и сайентисты создают признаки и контрибьютят их в feature store. Затем ML-практики потребляют эти готовые признаки, экономя время за счёт того, что им не приходится создавать свои.

(Not sure how I feel about this productivity gain, given my preference for data scientists to be more end-to-end. Nonetheless, this spilt between data engineering and machine learning might have been an artifact of how GoJek’s data team was structured, with the data engineering team mostly situated in India while the ML team was mostly in Singapore. Thus, Feast served as an interface for both teams to collaborate on.)

(Не уверен, как я отношусь к такому приросту продуктивности, учитывая моё предпочтение, чтобы data scientists работали более end-to-end. Тем не менее, это разделение между дата-инжинирингом и ML могло быть артефактом структуры дата-команды GoJek: команда дата-инженеров находилась преимущественно в Индии, а ML-команда — преимущественно в Сингапуре. Так что Feast выступил интерфейсом для совместной работы.)

Similarly, Uber built their Palette feature store to encourage the sharing—and reuse—of features in a single location. Various teams across Uber could contribute features to, and use features from, Palette. For Uber, this minimized duplicate work, made ML outcomes more consistent, and accelerates the ML process.

Аналогично, Uber построила свой feature store Palette, чтобы поощрять обмен признаками — и их переиспользование — в одном месте. Разные команды Uber могут контрибьютить признаки в Palette и использовать их оттуда. Для Uber это сократило дублирование работы, сделало результаты ML более согласованными и ускорило ML-процесс.

To make features easy to find and use, it’ll also need aspects of data discoverability (though it can also be argued that this is a convenience need). I didn’t come across much discussion on data discoverability in the context of feature stores, but I suspect it’ll be very similar to what I’ve previously written about open-sourced data discovery platforms.

Чтобы признаки было легко находить и использовать, нужны и аспекты data discoverability (хотя можно утверждать, что это потребность удобства). Я не встретил много обсуждений data discoverability в контексте feature stores, но подозреваю, что они будут очень похожи на то, что я ранее писал об open-source платформах для data discovery.

At this level, the feature store mostly serves as a store, albeit a very useful one that contains crowd-sourced/curated features that ML practitioners can just plug-and-play. Nonetheless, it’s not much different from a data warehouse. What distinguishes feature stores (from data warehouses) is their ability to meet the second level of the hierarchy of needs—serving.

На этом уровне feature store в основном выполняет роль хранилища, пусть и очень полезного, содержащего краудсорсенные/курируемые признаки, которые ML-практики могут просто подключать. Тем не менее, это не сильно отличается от хранилища данных. Что отличает feature stores от хранилищ данных — это способность закрывать второй уровень иерархии потребностей, serving.

Serving: Using features in real-time environments

Serving: использование признаков в реальном времени

When training machine learning models, we usually train them offline with batch data. Then, when serving these models online, the same features need to be available in real-time. Here’s where teams stumble—how do we serve those features in production, at high throughput and low latency?

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

When shipping tabular-based models, we kept finding that many of the features we would input into a model while training it were not readily available in our production infrastructure. — Monzo Bank

При выпуске моделей на табличных данных мы постоянно обнаруживали, что многие признаки, которые подавались в модель при обучении, недоступны в нашей продакшен-инфраструктуре. — Monzo Bank

For Monzo Bank, the features were available in their analytics stack, which was used for training models, but not in their production stack, which was used for serving. To solve this, they took a lean approach by automating the synchronization of features from their analytics store (BigQuery) to their production store (Cassandra).

В Monzo Bank признаки были доступны в аналитическом стеке, который использовался для обучения, но не в продакшен-стеке, который использовался для serving. Чтобы это решить, они применили lean-подход, автоматизировав синхронизацию признаков из аналитического хранилища (BigQuery) в продакшен-хранилище (Cassandra).

Сначала к SQL-запросам, создающим таблицы признаков в аналитическом стеке, добавляются теги. Эти таблицы обновляются с дневным/часовым интервалом. Go-сервис feature store проверяет схему этих таблиц (например, присутствуют ли обязательные столбцы вроде subject_type и subject_id?). Наконец, cron-задача проверяет обновлённые таблицы признаков и синхронизирует их из BigQuery в Cassandra через staging-зону в Google Cloud Storage.

Uber’s Palette adopts a similar dual-store approach. The offline store (Hive) saves feature snapshots and is mainly used by training jobs. The online store (Cassandra) serves the same features in real-time. Features not available in Cassandra are generated online via Flink before being saved to Cassandra. Data between both stores are synchronized. New features added in Hive are automatically copied to Cassandra; real-time features added to Cassandra are ETL-ed to Hive.

Palette от Uber использует похожий подход с двумя хранилищами. Офлайн-хранилище (Hive) сохраняет снимки признаков и в основном используется для обучения. Онлайн-хранилище (Cassandra) обслуживает те же признаки в реальном времени. Признаки, отсутствующие в Cassandra, генерируются онлайн через Flink и затем сохраняются в Cassandra. Данные между двумя хранилищами синхронизированы. Новые признаки, добавленные в Hive, автоматически копируются в Cassandra; признаки реального времени, добавленные в Cassandra, ETL-ятся в Hive.

Creating batch (left) and real-time (right) features, and synchronizing between stores (source)

Создание батчевых (слева) и реал-тайм (справа) признаков и синхронизация между хранилищами (источник)

DoorDash took addressing serving needs to the extreme with their Gigascale feature store. Here are the demanding technical requirements they had:

DoorDash довела закрытие потребностей serving до крайности со своим Gigascale feature store. Вот их жёсткие технические требования:

Хранит миллиарды записей в персистентном масштабируемом хранилище: у DoorDash миллионы сущностей (пользователи, мерчанты, блюда), что даёт миллиарды пар «признак-значение». Масштабируется до миллионов запросов в секунду (QPS): feature store используется во множестве задач, включая ранжирование магазинов, в котором десятки признаков и более 1 млн предсказаний в секунду. С учётом всех моделей в продакшене feature store получает до 10+ млн QPS. Обновляется ежедневно через быстрые батчевые записи: большинство признаков обновляется раз в сутки, а признаки реального времени (например, среднее время доставки магазина за скользящее 20-минутное окно) обновляются равномерно в течение дня.

To build this feature store, DoorDash benchmarked several key-value stores—Redis, Cassandra, CockroachDB, ScyllaDB, and YugabyteDB—before sticking with Redis. More details on their benchmarking process and optimizing Redis in their excellent write-up.

Чтобы построить этот feature store, DoorDash прогнала бенчмарки нескольких key-value хранилищ — Redis, Cassandra, CockroachDB, ScyllaDB и YugabyteDB — и в итоге остановилась на Redis. Подробности процесса бенчмаркинга и оптимизации Redis есть в их превосходной статье.

Another approach is to compute features in real-time. This is how Alibaba serves real-time recommendations, where their Alibaba Basic Feature Server computes statistical features on user interactions (e.g., clicks, likes, purchases) in real-time. These features are then used for candidate generation. More about real-time recsys in a previous post.

Другой подход — вычислять признаки в реальном времени. Так Alibaba обслуживает рекомендации реального времени: их Alibaba Basic Feature Server считает статистические признаки по пользовательским взаимодействиям (клики, лайки, покупки) в реальном времени. Эти признаки затем используются для генерации кандидатов. Подробнее о real-time recsys — в предыдущей статье.

Integrity: Creating correct offline and online features

Целостность: создание корректных офлайн- и онлайн-признаков

With serving needs met, we turn to integrity needs. There are two main pain points here:

Когда потребности serving закрыты, переходим к потребностям целостности. Тут две основные боли:

Сложность создания point-in-time корректных признаков для симуляции продакшена; ошибка тут приводит к утечкам данных. Несогласованность между признаками, используемыми при обучении и при serving, что приводит к субоптимальной работе модели в продакшене.

To address the first problem, Netflix built distributed time-travel. It takes snapshots of their offline and online data. These snapshots cover various contexts such as member type, device, time of day, etc.

Чтобы решить первую проблему, Netflix построил распределённый time-travel. Он делает снимки офлайн- и онлайн-данных. Эти снимки покрывают разные контексты: тип подписки, устройство, время суток и т. д.

Creating snapshots from offline stores and online micro services (source)

Создание снимков из офлайн-хранилищ и онлайн-микросервисов (источник)

However, creating snapshots for every context is expensive. Thus, they perform stratified sampling on attributes such as viewing patterns, device type, time spent on device, region, etc. These samples provide a good distribution of data to train and validate their models on. The sampling is done via Spark and snapshots are stored in S3.

Однако делать снимки для каждого контекста дорого. Поэтому они применяют стратифицированное сэмплирование по атрибутам вроде паттернов просмотра, типа устройства, времени, проведённого на устройстве, региона и т. д. Эти выборки дают хорошее распределение данных для обучения и валидации моделей. Сэмплирование выполняется через Spark, а снимки хранятся в S3.

A similar process snapshots online data from their hundreds of microservices. These microservices provide data such as viewing history, personalized viewing queues, and predicted ratings. Spark parallelizes the calls to Prana which fetches the data from various microservices. Similarly, the snapshots are stored in S3 via Parquet format.

Аналогичный процесс снимает онлайн-данные с сотен микросервисов. Эти микросервисы предоставляют такие данные, как история просмотров, персонализированные очереди просмотра и предсказанные оценки. Spark параллелизует вызовы Prana, который забирает данные из разных микросервисов. Снимки также хранятся в S3 в формате Parquet.

To solve the second pain point of train-serve skew, GoJek adopted Apache Beam as their data processing pipeline. Data from batch and streaming sources (e.g., BigQuery, Kafka) are ingested via Beam into offline and online stores (e.g., BigQuery, Redis). A unified API (to access historical and online data) minimizes the need to rewrite feature pipelines for the serving environment and thus accidentally introducing train-serve skew.

Чтобы решить вторую боль — train-serve skew — GoJek взяла Apache Beam в качестве пайплайна обработки данных. Данные из батч- и стрим-источников (BigQuery, Kafka) принимаются через Beam в офлайн- и онлайн-хранилища (BigQuery, Redis). Единый API (для доступа к историческим и онлайн-данным) минимизирует необходимость переписывать пайплайны признаков под среду serving и тем самым случайно вносить train-serve skew.

GoJek's Feast ingesting features via Apache Beam (source)

Feast от GoJek принимает признаки через Apache Beam (источник)

Netflix addressed this via shared feature encoders. Though they have different pipelines for offline (Spark) and online feature generation, both pipelines use the same feature encoders (i.e., same classes, libraries, and data formats). This ensures that feature generation is consistent across training and serving environments.

Netflix решает это через общие feature encoders. Хотя у них разные пайплайны для офлайн- (Spark) и онлайн-генерации признаков, оба пайплайна используют одни и те же feature encoders (одни классы, библиотеки, форматы данных). Это гарантирует согласованность генерации признаков между обучением и serving.

Netflix uses the same encoders for offline and online feature generation (source)

Netflix использует одни и те же encoders для офлайн- и онлайн-генерации признаков (источник)

We’ve also seen how Uber approached this by keeping their offline (Hive) and online (Cassandra) feature stores in sync. New features in either store are copied to the other store, ensuring consistency between data used for training and serving.

Мы также видели, как Uber подошёл к этому, держа офлайн- (Hive) и онлайн- (Cassandra) хранилища признаков синхронизированными. Новые признаки в любом из хранилищ копируются в другое, что обеспечивает согласованность между данными для обучения и serving.

We also need monitoring to ensure the integrity of features:

Также нужен мониторинг, чтобы обеспечить целостность признаков:

Когда признаки обновлялись в последний раз? Корректны ли схемы? Сместилось ли распределение данных? Выполняем ли мы требования к serving (пропускная способность, задержка)?

To allow data scientists to visually inspect features for integrity, Airbnb’s Zipline includes a UI that shows the distribution of features, correlations between features and labels, and performs clustering analysis (not sure what this clustering analysis is on though).

Чтобы data scientists могли визуально проверять признаки на целостность, Zipline от Airbnb включает UI, показывающий распределение признаков, корреляции между признаками и метками и выполняющий кластерный анализ (правда, не уверен, на чём именно этот кластерный анализ).

Similarly, Uber built Data Quality Monitor. It provides users with data quality scores daily, as well as alerts when anomalies are detected. It does this by:

Аналогично, Uber построил Data Quality Monitor. Он ежедневно даёт пользователям оценки качества данных, а также алерты при обнаружении аномалий. Работает он так:

Считаются метрики по признакам (среднее, медиана, максимум, минимум для числовых; число уникальных и пропущенных значений для категориальных). Затем строится многомерный временной ряд по этим метрикам (и применяется PCA для извлечения главных компонент). Наконец, по главным компонентам строится временной ряд. Если текущее измерение не совпадает с прогнозом на один шаг вперёд, оно классифицируется как аномалия.

Data quality scores over time, and when incidents occur (source)

Оценки качества данных во времени и моменты инцидентов (источник)

Convenience: Making it as easy to use as possible

Удобство: сделать использование максимально простым

I didn’t come across much content on convenience (or pain points) in the context of feature stores. Nonetheless, as practitioners, it’s important for our tools and platforms to be easy to use (e.g., PyTorch vs TensorFlow).

Я не нашёл много материалов про удобство (и про боли с ним) в контексте feature stores. Тем не менее, как практикам, нам важно, чтобы инструменты и платформы были простыми в использовании (например, PyTorch против TensorFlow).

The best example I found comes from GoJek. They provide unified SDKs in Python, Java, and Go to simplify retrieving features from both offline and online stores. The API lets you use nearly identical code to get_batch_features() and get_online_features(), easing the transition between offline to online feature engineering.

Лучший пример, который я нашёл, — от GoJek. Они предоставляют единые SDK на Python, Java и Go для упрощения получения признаков как из офлайн-, так и из онлайн-хранилищ. API позволяет писать практически идентичный код для get_batch_features() и get_online_features(), упрощая переход от офлайн- к онлайн-feature engineering.

customer_features = ['credit_score', 'balance', 'total_purchases', 'last_active'] historical_features_df = feast.get_historical_features(customer_ids, customer_features) model = ml.fit(historical_features_df) # pseudo code online_features = feast.get_online_features(customer_ids, customer_features) prediction = model.predict(online_features)

customer_features = ['credit_score', 'balance', 'total_purchases', 'last_active'] historical_features_df = feast.get_historical_features(customer_ids, customer_features) model = ml.fit(historical_features_df) # pseudo code online_features = feast.get_online_features(customer_ids, customer_features) prediction = model.predict(online_features)

For time-travel, Netflix provides simple APIs so data scientists can create point-in-time correct features and labels. Here’s an example of fetching a snapshot of viewing history for the movie OUTATIME.

Для time-travel Netflix предоставляет простые API, чтобы data scientists могли создавать point-in-time корректные признаки и метки. Вот пример получения снимка истории просмотров для фильма OUTATIME.

val snapshot = new SnapshotDataManager(sqlContext) .withTimestamp(1445470140000L) .withContextID(OUTATIME) .getViewingHistory

val snapshot = new SnapshotDataManager(sqlContext) .withTimestamp(1445470140000L) .withContextID(OUTATIME) .getViewingHistory

Building on this snapshot, users can perform time-travel to create features—for training and validation—by providing the following:

Опираясь на этот снимок, пользователи могут выполнять time-travel и создавать признаки для обучения и валидации, указав следующее:

Context: где, когда и как используется модель (страна, устройство, профиль участника, фильм, время); ключевой компонент тут — время. Items: элементы для скоринга/ранжирования (фильмы, рекомендательные slates, поисковые сущности). Labels: целевые значения для supervised learning (клик, просмотр, минуты просмотра). Для unsupervised learning не требуются. Feature encoder: как объединить данные контекста и элемента в признаки, например feature-crosses (страна-фильм, userID-фильм) и другие комбинации.

Uber also provided a detailed example of how they extended the Spark Transformer (no, that that NLP transformer) and built a domain-specific language (DSL) for feature retrieval and transformation. This is done via two abstractions:

Uber также привёл подробный пример того, как они расширили Spark Transformer (нет, не тот NLP-трансформер) и построили предметно-ориентированный язык (DSL) для получения и трансформации признаков. Это сделано через две абстракции:

Transformer: несмотря на название, в основном используется для получения признаков. Estimator: не для обучения моделей, как у Spark's Estimator, а в основном для создания признаков.

Here’s an example of how to get features for a restaurant. First, we retrieve features from batch and real-time feature stores, as well as properties (likely from fact tables). These features are: number of meals, preparation time, latitude, and longitude.

Вот пример, как получить признаки для ресторана. Сначала достаём признаки из батч- и реал-тайм хранилищ, а также свойства (вероятно, из таблиц фактов). Эти признаки: число блюд, время приготовления, широта и долгота.

tx_p1 = PaletteTransformer([ "@palette:restaurant:realtime_feature:nMeal:r_id", "@palette:restaurant:batch_feature:preptime:r_id", "@palette:restaurant:property:lat:r_id", "@palette:restaurant:property:log:r_id", ])

tx_p1 = PaletteTransformer([ "@palette:restaurant:realtime_feature:nMeal:r_id", "@palette:restaurant:batch_feature:preptime:r_id", "@palette:restaurant:property:lat:r_id", "@palette:restaurant:property:log:r_id", ])

With the latitude and longitude, we can get the restaurant’s region ID via an estimator.

По широте и долготе через estimator можно получить ID региона ресторана.

es_dsl1 = DSLEstimator(lambdas=[ ["region_id", "regionId(@palette:restaurant:property:lat:r_id, @palette:restaurant:property:log:r_id)"] ])

es_dsl1 = DSLEstimator(lambdas=[ ["region_id", "regionId(@palette:restaurant:property:lat:r_id, @palette:restaurant:property:log:r_id)"] ])

With the region ID feature, we can get features on how busy the region is.

По ID региона можно получить признаки того, насколько регион загружен.

tx_p2 = PaletteTransformer([ "@palette:region:service_feature:nBusy:region_id" ])

tx_p2 = PaletteTransformer([ "@palette:region:service_feature:nBusy:region_id" ])

Finally, we perform additional feature processing such as imputing preparation time with the mean value and converting features into numerics.

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

es_dsl2 = DSLEstimator(lambdas=[ ["prepTime": nFill(nVal("@palette:restaurant:batch_feature:prepTime:r_id"), avg("@palette:restaurant:batch_featuer:prepTime:r_id"))], ["nMeal": nVal("@palette:restaurant:realtime_feature:nMean:r_id")], ["nOrder": nVal("@basis:nOrder")], ["nBusy": nVal("@palette:region:service_feature:nBusy:region_id")] ])

es_dsl2 = DSLEstimator(lambdas=[ ["prepTime": nFill(nVal("@palette:restaurant:batch_feature:prepTime:r_id"), avg("@palette:restaurant:batch_featuer:prepTime:r_id"))], ["nMeal": nVal("@palette:restaurant:realtime_feature:nMean:r_id")], ["nOrder": nVal("@basis:nOrder")], ["nBusy": nVal("@palette:region:service_feature:nBusy:region_id")] ])

This DSL provides an abstraction layer for easy feature retrieval and transformation, if users operate within its boundaries. Nonetheless, I wonder how easy it is to validate the DSL without actually running it, as well as the ability to extend the DSL and perform custom feature engineering.

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

Autopilot: Automating as much as we can

Автопилот: автоматизация всего, что можно

At the top, we have autopilot needs. Not meeting these needs may mean your data scientists have to spend time on tedious, manual work—it’s not a blocker for using ML in production, though it can reduce development effort and operations cost. While some companies shared about addressing these needs, it’s not widespread in industry (yet).

На вершине — потребности автопилота. Если их не закрыть, data scientists будут тратить время на рутинную ручную работу — это не блокер для ML в продакшене, но может уменьшить трудозатраты на разработку и операционные расходы. Хотя некоторые компании рассказывали, как закрывают эти потребности, в индустрии это (пока) не сильно распространено.

Airbnb noticed that backfilling was a bottleneck when their data scientists iterated on ML experiments. Thus, Zipline includes a feature to backfill features automatically. A simple UI is provided where data scientists could define new features, specify the start and end dates, and how many processes to parallelize the backfill for. These features would then be added to their existing training feature set via an Airflow pipeline.

Airbnb заметили, что backfill — узкое место, когда их data scientists итеративно ставят ML-эксперименты. Поэтому Zipline включает функцию автоматического backfill признаков. Предусмотрен простой UI, где data scientists могут определить новые признаки, указать даты начала и конца, а также сколько процессов параллелить под backfill. Эти признаки затем добавляются в существующий обучающий набор через Airflow-пайплайн.

Airbnb's UI for backfilling and the Airflow DAG it creates (source)

UI Airbnb для backfill и Airflow DAG, который он создаёт (источник)

Other ways to meet autopilot needs include:

Другие способы закрыть потребности автопилота:

Metacat от Netflix даёт метрики для анализа стоимости и занимаемого места. Это упрощает управление таблицами признаков (и удаление неиспользуемых), экономя расходы. Data Quality Monitor от Uber с автоматическим обнаружением аномалий и уведомлениями по метрикам качества данных, а также ежедневными оценками качества. Эксперименты Uber с автоматическим отбором признаков. Идея — позволить пользователям искать признаки по меткам, которые они пытаются предсказать. Palette затем предложит признаки, которые коррелируют с метками или влияют на них.

Conclusion: It depends on what you need

Заключение: всё зависит от того, что вам нужно

I hope it’s clearer what a feature store is. If we’re starting from ground zero, maybe all we need is access and serving, and a dash of integrity. If we’re building our own at big tech co, we’ll probably want to consider convenience and autopilot relatively early. Did I miss anything? Please reach out @eugeneyan!

Надеюсь, теперь понятнее, что такое feature store. Если мы начинаем с нуля, возможно, всё, что нам нужно — это доступ и serving, плюс щепотка целостности. Если строим своё в big tech, то удобство и автопилот стоит учитывать достаточно рано. Что-то упустил? Пишите @eugeneyan!

Looking to get started with a feature store? Feast is a great option to consider. It meets the needs of access and serving, and its consistent API makes it easy to use similar code for training and serving. Best of all, it’s open-sourced (read: free). Let me know how it goes!

Хотите попробовать feature store? Feast — отличный вариант. Он закрывает потребности доступа и serving, а его согласованный API позволяет использовать похожий код для обучения и serving. И самое главное — он open-source (читай: бесплатный). Дайте знать, как пойдёт!

What I learned about feature stores as a hierarchy of needs

• Access: Information, data
• Serving: Real-time in prod
• Integrity: Correct train/serve data
• Convenience: Easy & quick to use
• Autopilot: Automate all the things

Did I miss anything?https://t.co/gkax6cXhe4

Что я узнал о feature stores как иерархии потребностей• Доступ: информация, данные• Serving: реальное время в проде• Целостность: корректные train/serve данные• Удобство: легко и быстро использовать• Автопилот: автоматизировать всё подрядЧто-то упустил? https://t.co/gkax6cXhe4— Eugene Yan (@eugeneyan) 24 февраля 2021

References

Источники

Introducing Feast: An Open Source Feature Store for Machine Learning Feast: Bridging ML Models and Data Michelangelo Palette: A Feature Engineering Platform at Uber Monitoring Data Quality at Scale with Statistical Modeling Zipline: Airbnb's Machine Learning Data Management Platform Distributed Time Travel for Feature Generation Fact Store at Scale for Netflix Recommendations Metacat: Making Big Data Discoverable and Meaningful at Netflix Building a Scalable Feature Store with Redis, Binary Serialization, and Compression The Architecture That Powers Twitter's Feature Store Building the Activity Graph, Part 2 (Feature Storage Section) Typed AI features for LinkedIn's Feed Accelerating Machine Learning with the Feature Store Service Managing ML Models @ Scale - Intuit's ML Platform

Thanks to Yang Xinyi, Willem Pienaar, David Golden, Shawn Wang, and Sky Chin for reading drafts of this.

Спасибо Yang Xinyi, Willem Pienaar, David Golden, Shawn Wang и Sky Chin за чтение черновиков.

If you found this useful, please cite this write-up as:

Если статья показалась полезной, пожалуйста, цитируйте её так:

Yan, Ziyou. (Feb 2021). Feature Stores: A Hierarchy of Needs. eugeneyan.com. https://eugeneyan.com/writing/feature-stores/.

Yan, Ziyou. (Feb 2021). Feature Stores: A Hierarchy of Needs. eugeneyan.com. https://eugeneyan.com/writing/feature-stores/.

or

или

@article{yan2021feature, title = {Feature Stores: A Hierarchy of Needs}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2021}, month = {Feb}, url = {https://eugeneyan.com/writing/feature-stores/} }

@article{yan2021feature, title = {Feature Stores: A Hierarchy of Needs}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2021}, month = {Feb}, url = {https://eugeneyan.com/writing/feature-stores/} }

Join 11,800+ readers getting updates on machine learning, RecSys, LLMs, and engineering.

К 11 800+ читателям присоединяйтесь и получайте обновления по machine learning, RecSys, LLM и инженерии.