This page introduces the fundamental abstractions and objects that form the foundation of Feast. These concepts are essential for understanding how to define, register, and serve features using Feast's feature store.
For detailed information about:
Feast's object model consists of several key abstractions that work together to define, store, and serve features. The following diagram shows the primary classes and their relationships in the codebase.
Sources: sdk/python/feast/feature_store.py105-220 sdk/python/feast/repo_config.py253-319 sdk/python/feast/infra/provider.py49-62
The core objects that users define to describe their features:
| Object | Class Name | Purpose | Key Attributes |
|---|---|---|---|
| Project | Project | Top-level namespace for organizing feature definitions | name, description |
| Entity | Entity | Primary key used to identify feature rows | name, join_keys, description |
| DataSource | DataSource (abstract base) | Defines where raw feature data is stored | name, timestamp_field, created_timestamp_column |
| Field | Field | Schema definition for a single feature or entity column | name, dtype, description, tags |
| FeatureView | FeatureView | Defines a set of features with their source and materialization settings | name, entities, schema, source, ttl, online |
| OnDemandFeatureView | OnDemandFeatureView | Defines features computed on-the-fly from other features | name, sources, schema, transformation |
| StreamFeatureView | StreamFeatureView | Defines features from streaming data sources | name, entities, schema, source, stream_source |
| FeatureService | FeatureService | Groups features for versioning and serving together | name, features, description |
Sources: sdk/python/feast/entity.py sdk/python/feast/data_source.py sdk/python/feast/field.py sdk/python/feast/feature_view.py sdk/python/feast/on_demand_feature_view.py sdk/python/feast/stream_feature_view.py sdk/python/feast/feature_service.py
The FeatureStore class is the primary interface for interacting with Feast. It provides methods for:
apply())get_historical_features())get_online_features())materialize(), materialize_incremental())Sources: sdk/python/feast/feature_store.py105-270 sdk/python/feast/feature_store.py944-1098 sdk/python/feast/feature_store.py1380-1636 sdk/python/feast/feature_store.py1638-1868 sdk/python/feast/feature_store.py2039-2216
The FeatureStore uses lazy initialization for its core components to optimize startup performance:
Sources: sdk/python/feast/feature_store.py124-170 sdk/python/feast/feature_store.py206-254
Feast is configured through a RepoConfig object, typically loaded from a feature_store.yaml file. The configuration defines:
Sources: sdk/python/feast/repo_config.py253-493 sdk/python/feast/repo_config.py136-184
The configuration system uses type strings to dynamically load implementation classes:
| Config Type | Class Mapping Dictionary | Example Value | Resolved Class |
|---|---|---|---|
| Registry | REGISTRY_CLASS_FOR_TYPE | "sql" | feast.infra.registry.sql.SqlRegistry |
| Online Store | ONLINE_STORE_CLASS_FOR_TYPE | "sqlite" | feast.infra.online_stores.sqlite.SqliteOnlineStore |
| Offline Store | OFFLINE_STORE_CLASS_FOR_TYPE | "bigquery" | feast.infra.offline_stores.bigquery.BigQueryOfflineStore |
| Batch Engine | BATCH_ENGINE_CLASS_FOR_TYPE | "local" | feast.infra.compute_engines.local.compute.LocalComputeEngine |
Sources: sdk/python/feast/repo_config.py39-107
The Registry stores all feature definitions and metadata. It acts as a central catalog that:
Sources: sdk/python/feast/infra/registry/base_registry.py sdk/python/feast/infra/registry/registry.py90 sdk/python/feast/infra/registry/sql.py86
The registry implements caching to reduce latency and load on the backing store:
Sources: sdk/python/feast/feature_store.py273-289 sdk/python/feast/repo_config.py150-160
The Provider interface orchestrates interactions between the offline store, online store, and compute engines. It abstracts infrastructure operations like:
online_write_batch())online_read())get_historical_features())materialize_single_feature_view())Sources: sdk/python/feast/infra/provider.py49-531 sdk/python/feast/infra/passthrough_provider.py58-130
Sources: sdk/python/feast/infra/provider.py533-542 sdk/python/feast/infra/provider.py41-46
Features in Feast go through several stages from definition to serving:
Sources: sdk/python/feast/feature_store.py944-1098 sdk/python/feast/feature_store.py644-726 sdk/python/feast/feature_store.py2039-2216
The apply() method performs several steps to register features:
Sources: sdk/python/feast/feature_store.py944-1098 sdk/python/feast/feature_store.py637-643 sdk/python/feast/feature_store.py665-726 sdk/python/feast/feature_store.py795-880 sdk/python/feast/feature_store.py882-929
Data sources define where feature data originates, while feature views define how to serve that data:
Sources: sdk/python/feast/data_source.py sdk/python/feast/feature_view.py71 sdk/python/feast/stream_feature_view.py34 sdk/python/feast/on_demand_feature_view.py85
Feast abstracts storage operations through two primary interfaces:
Sources: sdk/python/feast/infra/offline_stores/offline_store.py
Sources: sdk/python/feast/infra/online_stores/online_store.py35-193 sdk/python/feast/infra/online_stores/sqlite.py117 sdk/python/feast/infra/online_stores/milvus_online_store/milvus.py106
Feast uses entity keys to identify feature rows in the online store. Entity keys are serialized using protocol buffers:
The serialization version controls the format:
Sources: sdk/python/feast/infra/key_encoding_utils.py sdk/python/feast/repo_config.py298-305
Feast has a strongly-typed system for feature values:
Sources: protos/feast/types/Value.proto sdk/python/feast/type_map.py sdk/python/feast/types.py
FeatureService objects group features together for versioning and serving:
Sources: sdk/python/feast/feature_service.py sdk/python/feast/feature_view_projection.py
Feast's core concepts work together to provide a complete feature store solution:
feature_store.yamlThese abstractions allow Feast to support multiple storage backends, compute engines, and deployment patterns while maintaining a consistent API for users.
For more detailed information about specific components, see the child pages listed at the beginning of this document.
Refresh this wiki
This wiki was recently refreshed. Please wait 3 days to refresh again.