Skip to content

Feature Views#

A feature view is a logical view over (or interface to) a set of features that may come from different feature groups. You create a feature view by selecting features, starting from a root feature group and following foreign keys to join in features from other feature groups. When the feature view has a label for supervised learning, the root feature group is the label feature group, the one feature group that holds the labels. Features are reachable by graph traversal: any feature group joined to the root can, in turn, have foreign keys to further feature groups whose features you can also select. A feature view does not have a primary key of its own; it has serving keys, the foreign keys of its label feature group, which you provide to retrieve feature vectors. In the illustration below, we can see that features are joined together from the two feature groups: seller_delivery_time_monthly and the seller_reviews_quarterly. You can also see that features in the feature view inherit not only the feature type from their feature groups, but also whether they are the primary key and/or the event_time. The image also includes transformation functions that are applied to individual features. Transformation functions are a part of the feature types included in the feature view. That is, a feature in a feature view is not only defined by its data type (int, string, etc) or its feature type (categorical, numerical, embedding), but also by its transformation.

seller_delivery_time_monthly Name Type Role seller_id bigint primary key event_time timestamp event time deliver_hrs double feature seller_reviews_quarterly Name Type Role seller_id bigint primary key event_time timestamp event time review_score double feature transform min_max_scaler transform standard_scaler join on seller_id seller_delivery_time_monthly_feature_view feature view Name Type Role Transformation seller_id bigint serving key event_time timestamp event time avg_deliver_time_hrs double numerical min_max_scaler avg_review_score double numerical standard_scaler seller_id event_time 88 3.4

Feature views can also include:

  • the label for the supervised ML problem
  • transformation functions that should be applied to specified features consistently between training and serving
  • the ability to create training data
  • the ability to retrieve a feature vector with the most recent feature values

In the flow chart below, we can see the decisions that can be taken when creating (1) a feature view, and (2) creating training data with the feature view.

product_feature_group label feature group · root order_weekly_feature_group join fv = fs.create_feature_view( name="product_sales", query=query, labels=["sales"], transformation_functions=[normalize], ) product_sales_feature_view one definition · two uses OFFLINE batch · training data fv.create_train_validation_test_split( validation_size=0.1, test_size=0.1, extra_filter=category == "perfumes", ) normalize(44) → 0.78 fit on training-set stats product_sales_training_data_v1 sold_prev_week = 0.78 (normalized) ONLINE real-time · serving vec = fv.get_feature_vector( entry={"product_id": 222}, ) # serving key · filter not applied normalize(44) → 0.78 same stats · init_serving(v1) product_sales_feature_vector categoryperfumes named’odour sold_prev_week0.78

We can see here how the feature view is a representation for a model in the feature store - the same feature view is used to retrieve feature vectors for operational model that was created with training data from this feature view. As such, you can see that the most common use case for creating a feature view is to define the features that will be used in a model. In this way, feature views enable features from different feature groups to be reused across different models, and if features are stored untransformed in feature groups, they become even more reusable, as different feature views can apply different transformations to the same feature.