Feature stores: Feast (Gojek) and Feathr (LinkedIn)

01 · CONTEXT

Why a feature store

In ML, a feature is a signal about a domain entity. In the GO-JEK example, the entity is the driver and one of the features is the daily count of completed trips; several features together form a model's input.

The Feast announcement points out that, in large teams and environments, feature maintenance and serving can diverge greatly across projects. Typical challenges include features rebuilt many times instead of reused, different definitions from one team to another, difficulty serving up-to-date values that mix batch and streaming data, and inconsistency between training and serving.

On LinkedIn's side, the cost of building and maintaining data pipelines of features was borne redundantly by many teams, because each one tended to have its own. Without a common abstraction, there was no uniform naming of features across models, no uniform type system, and no uniform way to deploy and serve them in production.

02 · FEAST AT GO-JEK

A warehouse for history and a database for the recent value

Feast was developed jointly by GO-JEK and Google Cloud as a centralized platform to standardize the definition, storage, and access of features, for both training and serving. It ingests batch and streaming data and maintains two kinds of storage: a warehouse for history and bancos of serving for the latest values.

1. Batch and streaming sources feed a unified ingestion, which manages both kinds of data.

2. Ingestion writes to the feature warehouse, with the history, and to the serving database, with the latest values.

3. For training, the Python SDK generates training datasets from the feature warehouse.

4. With the model deployed, a client library queries the Serving API, designed for low-latency access to the latest values.

5. Both sides query features with the same set of identifiers.

According to the announcement, it is this unified ingestion that provides consistency between training and serving, and the same identifiers are valid in the warehouse and in the serving API. A central store also makes it possible to build a base of features reusable across projects, and the platform works as a bridge between data engineering and ML.

03 · FEATHR AT LINKEDIN

Features imported by name

Feathr is the feature store that LinkedIn built to simplify ML feature management and that was released as open source. It offers a common namespace for defining features and a common platform for computing, serving, and accessing them by name, separating two roles: producers define and register, consumers import.

For the consumer, the text's analogy is a package management tool: they list the names of the features they want to import and Feathr abstracts how they are obtained and computed. On the producer side, features are defined from raw sources, including time series, or from other already-defined features.

1. The producer defines the feature from raw data or other features and registers it in the common namespace.

2. The consumer in the training flow lists by name the features they want to import into their model.

3. For training, the registered definitions are reapplied over historical time series and the features are joined to the labels in a time-correct way.

4. For inference, the features are pre-materialized and deployed to online stores, for low-latency serving.

LinkedIn reports that it deployed Feathr across dozens of applications, such as Search, Feed, and Ads. According to the text, some of the largest ML projects that replaced their own pipelines with Feathr cut the engineering time to add and experiment with features from weeks to days, and Feathr was up to 50% faster than the pipelines it replaced. Job search and recommendation systems, which had trouble sharing features, began to share them easily.

04 · TECHNICAL CORE

Point-in-time and train-serving skew

A feature pipeline needs to gather time-sensitive data from several sources and join the features to the training labels in a time-correct way, so-called point-in-time. In Feathr, this comes from reapplying the registered definitions over historical time series, to compute each feature at specific points in time while generating the training data.

To avoid skew between training and serving, which the LinkedIn text calls training-serving skew, feature pipelines need to ensure that features are prepared the same way in the training and inference contexts. The Feast announcement describes how the inconsistency arises: training needs historical data, production models need the latest values, and inconsistencies appear when data is siloed in independent systems that require separate tools.

1. Training needs access to historical data to build the dataset.

2. Serving, in turn, needs the latest values.

3. In this design, each path has its own tool; when data is siloed in independent systems that require separate tools, inconsistencies appear.

05 · COMPARISON

Feast and Feathr side by side

Both projects tackle the same problem of ML in production: offering a single point to define, compute, and serve each feature, reducing the need for each team to maintain its own pipelines.