A feature store gives data science teams a shared repository for engineered features that can be used consistently during training and serving.
2
Feast can ingest both batch and streaming data, keep historical snapshots, and provide low-latency online feature retrieval through Redis.
3
Kubeflow can connect feature retrieval, hyperparameter tuning with Katib, model training, serving with KFServing, and monitoring with Prometheus and Grafana in one pipeline.
Summary
Aniruddha Choudhury walks through an end-to-end machine learning system built with Feast, Kubeflow, Kubernetes, Spark, Kafka, Redis, and Google Cloud. He starts with the problem of several data scientists independently collecting, transforming, and scaling the same data. A feature store provides a shared definition of features so teams can reuse them across projects and keep training data aligned with serving data. He then explains Feast's registry, transformations, offline storage, online serving, and monitoring. The demo uses taxi trip data for a classification task, registers entities and feature tables, ingests batch data into Google Cloud Storage, and moves data from offline storage to Redis for online access. The Kubeflow pipeline retrieves historical features, runs Katib hyperparameter trials, trains a model, saves it to a Google Cloud bucket, deploys it for prediction, and exposes metrics through Prometheus and Grafana. The example reaches 58 percent accuracy, while Choudhury says feature engineering could improve the result.
A feature store reduces duplicated feature work across data scientists
Choudhury says teams often spend time repeating data collection, analysis, and feature engineering. Different data scientists may apply different scaling or preprocessing because they have different experience and domain knowledge. This creates inconsistent training data and leaves ML or data engineers maintaining fragmented production datasets. A centralized feature store holds engineered features in a shared repository. Several data scientists can reuse the same features for regression or classification, while serving systems use the same definitions for predictions. Choudhury describes this as maintaining a single source of truth for training and serving.
Feast separates feature storage from the rest of the ML platform
Feast is presented as an open-source feature store rather than a workflow scheduler, data warehouse, feature engineering tool, model serving product, or pipeline orchestrator. It does not replace Airflow, Kubeflow, Spark, pandas, or model serving systems. Its role is to manage feature definitions and provide a shared repository that teams can use across projects. Choudhury says Feast supports batch and streaming ingestion, feature reuse, metadata, and consistent access for training and serving. He also describes support for real-time feature access through cloud connectors and online storage.
The feature store has separate layers for serving, transformation, monitoring, storage, and registry
Choudhury describes five parts of a modern feature store. The serving layer provides low-latency access for predictions. Transformation includes batch, streaming, and on-demand processing. Monitoring tracks measures such as latency, throughput, freshness, availability, and capacity. The registry stores feature definitions and metadata as a shared reference. Storage keeps historical snapshots in systems such as Google Cloud Storage, S3, Snowflake, Redshift, DynamoDB, Redis, or Cassandra. This structure lets the same engineered data support both historical training retrieval and fast online prediction.
Feast keeps offline training data aligned with online prediction data
In the taxi classification example, the data contains driver IDs, timestamps, trip details, payment information, and fare values. Choudhury registers the driver ID as an entity and defines feature tables for trip and fare data. Historical data is saved as snapshots in a Google Cloud bucket, while online data is moved into Redis for fast retrieval. Feast can retrieve historical features with event timestamps for training and online features by entity ID for serving. The training and prediction paths therefore use the same registered feature definitions instead of separately maintained datasets.
Batch and streaming ingestion can feed the same feature system
The demo first loads transformed CSV data and sends it through a batch ingestion path backed by a Spark job on a Google Cloud Dataproc cluster. Feast stores the resulting historical data in a Google Cloud Storage bucket using Parquet snapshots. Choudhury then shows a streaming path using Kafka topics and a Spark job. The Kafka source includes an event timestamp, a creation timestamp, a broker address, a topic, and a schema. Rows are published as streaming events, and the job continues running so new data can reach online features. The two paths support offline retrieval for training and online retrieval for production predictions.
The Kubeflow pipeline is built from separate containerized stages
The pipeline is divided into feature retrieval, Katib hyperparameter tuning, final training, and serving. Each stage uses a Docker image with its Python code and dependencies. The feature retrieval stage reads entity IDs, timestamps, feature names, and storage locations, then asks Feast for historical features through a Spark job. It saves training and test artifacts to a persistent volume. The training stage reads those artifacts, builds a TensorFlow model, writes logs, saves metrics, and uploads model weights to a Google Cloud bucket. Kubeflow's pipeline graph connects these stages with dependency ordering.
Katib searches model configurations before final training
Choudhury configures Katib with a maximum of 24 trials, three parallel trials, and a maximum of three failed trials. The objective is to maximize accuracy, with Bayesian optimization selecting values for learning rate, optimizer, layers, units, and initialization settings. An early-stopping rule can stop trials when accuracy stops improving. Katib reads the training logs and displays the trial results in its interface. In the shown run, the model reaches 58 percent accuracy. The best parameters are passed to a final training stage, which trains the model again and saves it for serving.
Monitoring covers both feature access and model endpoint traffic
The deployed system exposes metrics through Prometheus and Grafana. Choudhury mentions feature-serving measures such as request counts, latency, throughput, memory, concurrency, and availability. He also shows endpoint traffic after sending prediction requests to the KFServing service. The dashboard can show request volume and the pressure on the endpoint. Kubernetes can scale the service, while Grafana provides a view of the health of the feature store and serving layer.
"We are maintaining a centralized repository of feature store which we have scaled and as a feature engineer process data and we have published it into the feature store once that and it can be used across all the projects or across all the data scientists in our team."Aniruddha Choudhury09:28
Who should watch
You are choosing between a feature store and a collection of ad hoc tables, notebooks, and preprocessing scripts for training and serving.
Your team wants a concrete example of combining Feast with Kubeflow, Spark, Kafka, Redis, and Google Cloud.
You need to connect hyperparameter tuning, model deployment, endpoint prediction, and operational metrics in a Kubernetes-based ML system.
