In this lesson, we will define feature store terminology and concepts. A feature store is a top-level container for your features and their values. When you set up a feature store, permitted users can add and share their features without additional engineering support. Users can define features and then ingest or import feature values from various data sources. 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, movies and users that group related features that correspond to movies or customers. An entity is an instance of an entity type. For example, movie_01 and movie_02 are entities of the movies entity type. In a feature store, each entity must have a unique ID and must be of type STRING. When you retrieve values from a feature store, the surface 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 a batch serving requests. 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. Simply stated, a feature is a value that is passed as an input to a model. Note also that feature store can store scalars and arrays and/or tensors. Essentially, a feature describes some entity. For example, age of user, price of product, or category of webpage. Feature store captures feature values for a feature at specific point in time. In other words, you can have multiple values for a given entity and feature. For example, the movie underscore 01 entity can have multiple feature values for the average underscore rating feature. The value can be 4.4 at onetime and 4.8 at some later time. Feature store associates a tuple identifier with each feature value, entity underscore ID, feature underscore ID, and timestamp, which it then uses to look up values at surfing time. The timestamp column indicates when the feature values were generated. In the feature store, 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. Feature store keeps feature values up to the data retention limit. This limit is based on a timestamp associated with the feature values, not when the values were imported. Let's examine an entity view that shows a list of five features for the entities type budget in the feature store HelloWorld. When you create a feature, you specify its value type, such as Boolean array, double array, or string. This value determines what value types you can ingest for a particular feature. This entity view also shows the count per feature, missing values, the mean, standard deviation, the number of zeros present for each feature, and the mean, median, and max values for each feature. These two columns are associated with the entity underscore ID field, which is a string. This column shows the graphical distribution of values per feature. There is a one-to-many relationship between an entity and a feature. In this Vertex AI example, there is one entity type called budget. But here, many values are associated with the entity type. Feature ingestion is the process of importing feature values computed by your feature engineering jobs into a feature store. Before you can ingest data, the corresponding entity type and features must be defined in the feature store. Feature store offers batch ingestion so that you can do a bulk ingestion of values into a feature store. For example, your computed source data might live in locations such as big query or Cloud storage. You can then ingest data from those sources into a feature store so that feature values can be served in a unified format. 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 surfing 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 from real-time processing, like for online predictions.
