Feast provides historical features for model training and online features for real-time inference.
2
The workshop joins loan records with credit history and ZIP code data using entity keys such as date of birth, Social Security number, and ZIP code.
3
Feast uses an offline store for historical data and materializes feature views into an online store for serving predictions.
Summary
Felix Wang introduces Feast through a real-time credit-scoring tutorial running on AWS. The example trains a model to decide whether a loan should be approved, then uses the model for inference. Historical loan, credit-history, and ZIP code data are stored in Redshift. Feast retrieves the correct historical features for training by joining records through entity keys and timestamps. The feature repository defines entities, data sources, and feature views. Feast then provisions online infrastructure in DynamoDB and materializes the feature views from Redshift. During inference, the application sends a loan request and Feast retrieves the same feature values the model used during training. The workshop also shows practical setup details with Terraform, S3, IAM, and a Feast YAML configuration. Felix encounters an S3 region mismatch during materialization, corrects the staging bucket, and completes the model run.
Feast connects training features with online inference features
Felix frames the workshop around two stages of a credit-scoring model. During training, Feast supplies historical feature data. During inference, it supplies online, real-time features. The example uses Redshift for historical data and materializes those features into DynamoDB for retrieval at prediction time. The model receives information about a loan request, including ZIP code and credit history, and returns a binary approval or rejection decision. The same feature definitions are used across both stages, so the features available during inference match those used to train the model.
The example repository contains infrastructure, model code, and a feature repository
The repository includes Terraform files for setting up AWS infrastructure, installation requirements, a main run file, the model implementation, and a Feast feature repository. The run file loads historical data, trains a model with data from Redshift, and performs inference on a loan request. The model initializes a feature store, calls Feast to obtain training features, and calls get online features during inference. The feature repository's YAML file names the project, registry, and AWS provider, with additional configuration filled in during setup.
Entity keys determine which feature rows are joined to each loan
The training data comes from loan records and is augmented with credit-history and ZIP code feature tables. The credit-history rows are identified by date of birth and Social Security number. ZIP code rows are identified by ZIP code. These values form the join keys when Feast builds the training data. A loan record can therefore be enriched with fields such as credit card, mortgage, student loan, and vehicle loan information, along with ZIP code details such as city, state, and location type.
A Feast feature repository defines entities, data sources, and feature views
After the AWS infrastructure is created, Felix configures the Feast repository with the Redshift cluster identifier, an S3 staging location, and an IAM role. The features.py file defines the ZIP code entity, its data source and feature view, and corresponding objects for credit history. Feast registers these definitions and deploys the infrastructure needed for online retrieval. Felix explains that each feature view needs infrastructure in DynamoDB because the application will need those features for real-time inference.
Materialization moves feature views from the offline store into the online store
Felix runs Feast materialization for the ZIP code and credit-history feature views. The command copies the historical feature data from Redshift into DynamoDB, where the application can retrieve it during inference. The first attempt fails because the S3 staging bucket is in a different region from the Redshift cluster. Felix changes the staging location to a bucket in the correct region, then reruns the operation successfully. The issue comes from configuration rather than from the feature definitions themselves.
Historical feature retrieval enriches an entity data frame for training
For training, the model passes its loan records to Feast as an entity data frame and requests the ZIP code and credit-history features. Feast uses the entity values in each row to find matching records in the historical feature tables. Felix shows that the resulting data frame contains the original loan columns plus the requested feature columns. This gives the model a joined training table without requiring the application code to manually assemble each feature source.
Online feature retrieval gives inference the features used during training
At inference time, the application starts with a single loan request. Feast's get online features call retrieves the ZIP code and credit-history values needed by the trained model. Felix compares the request with the returned feature vector and shows that the vector contains the same types of fields used during training. The ZIP code information and credit-history values are therefore available when the model makes its approval or rejection prediction.
"You can take some entity data frame which has some initial training data and then you can add a whole bunch of other data, feature data, onto it."Felix Wang26:42
Who should watch
You are evaluating Feast and want to understand how its offline and online stores fit into a model workflow.
Your training data comes from several feature tables, and you need a concrete example of joining them through entity keys.
You want to see the AWS setup and configuration involved in materializing Feast feature views before serving predictions.
