Codebase Structure
Let's examine the Feast codebase. This analysis is accurate as of Feast 0.23.
The Python SDK lives in sdk/python/feast. The majority of Feast logic lives in these Python files:
The core Feast objects (, , , etc.) are defined in their respective Python files, such as entity.py, feature_view.py, and data_source.py.
The FeatureStore class is defined in feature_store.py and the associated configuration object (the Python representation of the feature_store.yaml file) are defined in repo_config.py.
The CLI and other core feature store logic are defined in cli.py and repo_operations.py.
The type system that is used to manage conversion between Feast types and external typing systems is managed in type_map.py.
The Python feature server (the server that is started through the feast serve command) is defined in feature_server.py.
There are also several important submodules:
infra/ contains all the infrastructure components, such as the provider, offline store, online store, batch materialization engine, and registry.
dqm/ covers data quality monitoring, such as the dataset profiler.
Of these submodules, infra/ is the most important. It contains the interfaces for the , , , , and , as well as all of their individual implementations.
The tests for the Python SDK are contained in sdk/python/tests. For more details, see this of the test suite.
Example flow: feast apply
Let's walk through how feast apply works by tracking its execution across the codebase.
All CLI commands are in cli.py. Most of these commands are backed by methods in repo_operations.py. The feast apply command triggers apply_total_command, which then calls apply_total in repo_operations.py.
At this point, the feast apply command is complete.
Example flow: feast materialize
Let's walk through how feast materialize works by tracking its execution across the codebase.
The feast materialize command triggers materialize_command in cli.py, which then calls FeatureStore.materialize from feature_store.py.
This then calls Provider.materialize_single_feature_view
Example flow: get_historical_features
Let's walk through how get_historical_features works by tracking its execution across the codebase.
We start with FeatureStore.get_historical_features in feature_store.py. This method does some internal preparation, and then delegates the actual execution to the underlying provider by calling Provider.get_historical_features, which can be found in infra/provider.py.
As with feast apply, the provider is most likely backed by the passthrough provider, in which case
The java/ directory contains the Java serving component. See for more details on how the repo is structured.
Go feature server
The go/ directory contains the Go feature server. Most of the files here have logic to help with reading features from the online store. Within go/, the internal/feast/ directory contains most of the core logic:
onlineserving/ covers the core serving logic.
model/ contains the implementations of the Feast objects (entity, feature view, etc.).
Feast uses to store serialized versions of the core Feast objects. The protobuf definitions are stored in protos/feast.
The consists of the serialized representations of the Feast objects.
Typically, changes being made to the Feast objects require changes to their corresponding protobuf representations. The usual best practices for making changes to protobufs should be followed ensure backwards and forwards compatibility.
The ui/ directory contains the Web UI. See for more details on the structure of the Web UI.