The following sections introduce the Vertex Feature Store data model and terminology that is used to describe Feature Store resources and components.
Feature Store data model
Feature Store uses a time series data model to store a
series of values for features. This model enables
Feature Store to maintain feature values as they change
over time. Feature Store organizes resources hierarchically
Featurestore -> EntityType -> Feature. You must define and
create these resources before you can ingest data into
As an example, assume that you have the following sample source data from a BigQuery table. This source data is about movies and their features.
Before you can ingest this data into Feature Store, you need to create a featurestore, which is a top-level container for all other resources. In the featurestore, create entity types that group and contain related features. You can then create features that map to features in your source data. The names of the entity type and features can mirror the column header names, but that is not required.
In this example, the
movie_id column header can map to an entity type
genres are features of the
movies entity type. The values in each column map to specific instances of an
entity type or features, which are called entities and feature values.
The timestamp column indicates when the feature values were generated. In the featurestore, the timestamps are an attribute of the feature values, not a separate resource type. If all feature values were generated at the same time, you are not required to have a timestamp column. You can specify the timestamp as part of your ingestion request.
A featurestore is the top-level container for entity types, features, and feature values. Typically, an organization creates one shared featurestore for feature ingestion, serving, and sharing across all teams in the organization. However, in some cases you might choose to create multiple featurestores within the same project to isolate environments. For example, you might have separate featurestores for experimentation, testing, and production.
An entity type is a collection of semantically related features. You define your
own entity types, based on the concepts that are relevant to your use case. For
example, a movie service might have the entity types
which group related features that correspond to movies or customers.
An entity is a particular instance of an entity type. For example,
movie_02 are entities of the
movies entity type. Note that in
a featurestore each entity must have a unique ID and must be of type
A feature is a measurable property or attribute of an entity type. For example,
movies entity type has features such as
track various properties of movies. Features are associated with entity types.
Features must be distinct within a given entity type, but they don't need
to be globally unique. For example, if you use
title for two different entity
types, Feature Store interprets
title as two different
features. When reading feature values, you provide the feature and its entity
type as part of the request.
When you create a feature, you specify its value type such as
STRING. This determines what value types you
can ingest for a particular feature. For more information about the supported
value types, see the
valueType in the
Feature Store captures feature values for a feature at a
specific point in time. In other words, you can have multiple values for a given
entity and feature. For example, the
movie_01 entity can have multiple feature
values for the
average_rating feature. The value can be
4.4 at one time and
4.8 at some later time. Feature Store associates a tuple
identifier with each feature value (
which Feature Store uses to lookup values at serving time.
Feature Store stores discrete values even though time is
continuous. When you request a feature value at time
t, the returned value is
the latest stored value before time
t. For example, if the
Feature Store stores the location information of a car at
110, the location at time
100 is used for requests at all
105). If you require higher
resolution, you can, for example, infer the location between values or increase
the sampling rate of your data.
Feature ingestion is the process of importing feature values computed by your feature engineering jobs into a featurestore. Before you can ingest data, the corresponding entity type and features must be defined in the featurestore. Feature Store offers batch ingestion so that you can do a bulk ingestion of values into a featurestore. For example, your computed source data might live in locations such as BigQuery or Cloud Storage. You can then ingest data from those sources into a featurestore so that feature values can be served in a uniform format from the central featurestore.
For more information, see Batch ingesting feature values.
Feature serving is the process of exporting stored feature values for training or inference. Feature Store offers two methods for serving features: batch and online. Batch serving is for high throughput and serving large volumes of data for offline processing (like for model training or batch predictions). Online serving is for low-latency data retrieval of small batches of data for real-time processing (like for online predictions).
When you retrieve values from a featurestore, the service returns an entity view that contains the feature values that you requested. You can think of an entity view as a projection of the features and values that Feature Store returns from an online or batch serving request:
- For online serving requests, you can get all or a subset of features for a particular entity type.
- For batch serving requests, you can get all or a subset of features for one or more entity types. For example, if features are distributed across multiple entity types, you can retrieve them together in a single request that you can feed to a machine learning or batch prediction request.
Feature Store keeps feature values up to the data retention limit. This limit is based on the timestamp associated with the feature values, not when the values were imported. Values with timestamps that exceed the limit are scheduled for deletion by Feature Store.