Overview

Relevant source files

Purpose and Scope

This page provides a high-level introduction to Feast, an open-source feature store for machine learning. It explains the core problems Feast solves, the fundamental architecture, and key abstractions that enable feature management for both training and serving. For detailed system architecture, see System Architecture. For setup instructions, see Getting Started and CLI.

Sources: README.md26-38 docs/getting-started/quickstart.md4-14

What is Feast?

Feast (Feature Store) is a system for managing and serving machine learning features across the full ML lifecycle. It provides a unified interface to:

Define features in Python as reusable, versioned objects
Generate training datasets with point-in-time correct historical feature values
Materialize features from batch sources to low-latency online stores
Serve features for real-time model inference via HTTP/gRPC APIs
Ingest streaming features via push APIs for real-time updates

The central entry point is the FeatureStore class sdk/python/feast/feature_store.py106-117 which orchestrates all operations.

Sources: sdk/python/feast/feature_store.py106-267 README.md29-36

Core Problems Solved

Feast addresses three critical challenges in production ML systems:

Problem	Feast Solution
Training-Serving Skew	Point-in-time joins ensure historical feature values match what models saw during training. The same feature definitions power both offline (training) and online (serving) paths.
Online Feature Availability	Materialization jobs precompute and load features into low-latency online stores (Redis, DynamoDB, PostgreSQL, etc.) at scheduled intervals.
Feature Reuse & Versioning	A centralized `Registry` stores all feature definitions. `FeatureService` objects version the exact features used by each model.

The get_historical_features() method sdk/python/feast/feature_store.py1585-1733 implements point-in-time correctness, while materialize() sdk/python/feast/feature_store.py1811-1943 handles the offline-to-online data flow.

Sources: README.md32-36 docs/getting-started/quickstart.md44-59 sdk/python/feast/feature_store.py1585-1943

Key Components

Component Details:

Component	File	Purpose
`FeatureStore`	feature_store.py106	Central orchestrator for all feature operations
`RepoConfig`	repo_config.py251	Configuration loaded from `feature_store.yaml`
`Registry`	infra/registry/base_registry.py	Metadata catalog for feature definitions
`Provider`	infra/provider.py49	Abstraction layer for infrastructure operations
`OfflineStore`	infra/offline_stores/offline_store.py	Interface for historical feature retrieval
`OnlineStore`	infra/online_stores/online_store.py35	Interface for low-latency feature serving
`Entity`	entity.py	Primary keys used for joining features
`FeatureView`	feature_view.py	Schema and source for a set of features
`OnDemandFeatureView`	on_demand_feature_view.py	Real-time feature transformations
`FeatureService`	feature_service.py	Versioned grouping of features for a model

Sources: sdk/python/feast/feature_store.py106-267 sdk/python/feast/repo_config.py251-605 sdk/python/feast/infra/provider.py49-67

Feature Lifecycle

Key Methods:

feast apply: repo_operations.py432-459 → apply_total() registers feature definitions to the registry
get_historical_features(): feature_store.py1585-1733 performs point-in-time joins for training data
materialize(): feature_store.py1811-1943 copies features from offline to online stores
get_online_features(): feature_store.py2107-2312 retrieves latest features for inference
push(): feature_store.py2705-2948 ingests streaming features to online/offline stores

Sources: sdk/python/feast/feature_store.py1585-2948 sdk/python/feast/repo_operations.py432-459 sdk/python/feast/feature_server.py388-480

Core Abstractions

FeatureStore Class

The FeatureStore class is the primary API entry point. It is initialized with a path to a feature_store.yaml configuration file:

Key responsibilities:

Lazy initialization: Registry and provider are loaded on-demand feature_store.py206-220
Configuration management: Loads RepoConfig from YAML feature_store.py155-162
Operation orchestration: Delegates to provider and stores feature_store.py250-259

Sources: sdk/python/feast/feature_store.py106-267

Provider Pattern

The Provider interface infra/provider.py49-67 abstracts infrastructure operations. The default PassthroughProvider infra/passthrough_provider.py58-90 delegates to configured stores:

Operation	Provider Method	Delegates To
Historical retrieval	`get_historical_features()`	`OfflineStore.get_historical_features()`
Online read	`online_read()`	`OnlineStore.online_read()`
Materialization	`materialize_single_feature_view()`	`BatchEngine` + `OnlineStore`
Infrastructure updates	`update_infra()`	`OnlineStore.update()`

Sources: sdk/python/feast/infra/provider.py49-426 sdk/python/feast/infra/passthrough_provider.py58-316

Registry Architecture

The Registry stores feature metadata and materialization history. Three implementations exist:

The registry type is configured in feature_store.yaml:

Sources: sdk/python/feast/infra/registry/registry.py sdk/python/feast/infra/registry/sql.py sdk/python/feast/repo_config.py39-44

Store Selection

Feast uses type-to-class mappings to resolve store implementations:

This enables declarative configuration where changing type: 'redis' to type: 'postgres' swaps implementations without code changes repo_config.py493-527

Sources: sdk/python/feast/repo_config.py89-105 sdk/python/feast/repo_config.py493-527

Feature Definition Pattern

Features are defined declaratively using Python objects:

Running feast apply repo_operations.py432-459 parses these definitions using parse_repo() repo_operations.py114-220 and registers them to the registry via apply_total_with_repo_instance() repo_operations.py338-394

Sources: docs/getting-started/quickstart.md144-183 sdk/python/feast/repo_operations.py114-220 sdk/python/feast/repo_operations.py338-394

Configuration Structure

Feast configuration lives in feature_store.yaml:

The RepoConfig class repo_config.py251-605 validates and loads this configuration:

Field	Type	Purpose
`project`	`str`	Unique project identifier repo_config.py254-257
`registry`	`RegistryConfig`	Registry connection details repo_config.py267-272
`provider`	`str`	Infrastructure provider (local/gcp/aws) repo_config.py264-265
`online_store`	`OnlineStoreConfig`	Online store configuration repo_config.py275-276
`offline_store`	`OfflineStoreConfig`	Offline store configuration repo_config.py281-282
`batch_engine`	`BatchEngineConfig`	Materialization engine repo_config.py284-285

Sources: sdk/python/feast/repo_config.py251-605 docs/getting-started/quickstart.md108-117

Deployment Modes

Feast supports multiple deployment patterns:

Local Development

Offline Store: File/Parquet with DaskOfflineStore infra/offline_stores/dask.py
Online Store: SQLite infra/online_stores/sqlite.py103-148
Registry: Local file infra/registry/registry.py

Production Deployment

Offline Store: BigQuery, Snowflake, Redshift, or Spark
Online Store: Redis, DynamoDB, PostgreSQL, or Bigtable
Registry: SQL database or Snowflake infra/registry/sql.py
Feature Server: HTTP server running get_app() feature_server.py211-321
Orchestration: Kubernetes with Feast Operator infra/feast-operator/README.md1-5

The feature server exposes REST endpoints:

POST /get-online-features feature_server.py323-351
POST /push feature_server.py388-480
POST /materialize feature_server.py530-552

Sources: sdk/python/feast/feature_server.py211-552 infra/feast-operator/README.md1-5 docs/how-to-guides/running-feast-in-production.md8-20

Type System

Feast defines a canonical type system in Protocol Buffers protos/feast/types/Value.proto with bidirectional conversions to external systems:

The type_map.py module type_map.py provides conversion functions between these type systems, enabling heterogeneous data pipelines (e.g., BigQuery → Redis, Snowflake → PostgreSQL).

Sources: sdk/python/feast/type_map.py protos/feast/types/Value.proto

Next Steps

For detailed architectural information, see System Architecture.

To set up Feast and run your first feature pipeline, see Getting Started and CLI.

To contribute to Feast development, see Contributing and Development Setup.

For specific component documentation:

Feature definitions: Feature Views and Services
Data sources: Data Sources
Storage backends: Offline Stores, Online Stores
Feature serving: Python Feature Server

Sources: README.md244-251 docs/SUMMARY.md9-45