Feast manages two important sets of configuration: feature definitions, and configuration about how to run the feature store. With Feast, this configuration can be written declaratively and stored as code in a central location. This central location is called a feature repository, and it's essentially just a directory that contains some code files.
The feature repository is the declarative source of truth for what the desired state of a feature store should be. The Feast CLI uses the feature repository to configure your infrastructure, e.g., migrate tables.
A feature repository consists of:
A collection of Python files containing feature declarations.
feature_store.yaml file containing infrastructural configuration.
.feastignore file containing paths in the feature repository to ignore.
The structure of a feature repository is as follows:
The root of the repository should contain a
feature_store.yaml file and may contain a
The repository should contain Python files that contain feature definitions.
The repository can contain other files as well, including documentation and potentially data files.
An example structure of a feature repository is shown below:
$ tree -a.├── data│ └── driver_stats.parquet├── driver_features.py├── feature_store.yaml└── .feastignore1 directory, 4 files
A couple of things to note about the feature repository:
Feast reads all Python files recursively when
feast apply is ran, including subdirectories, even if they don't contain feature definitions.
It's recommended to add
.feastignore and add paths to all imperative scripts if you need to store them inside the feature registry.
The configuration for a feature store is stored in a file named
feature_store.yaml , which must be located at the root of a feature repository. An example
feature_store.yaml file is shown below:
feature_store.yamlproject: my_feature_repo_1registry: data/metadata.dbprovider: localonline_store:path: data/online_store.db
feature_store.yaml file configures how the feature store should run. See feature_store.yaml for more details.
This file contains paths that should be ignored when running
feast apply. An example
.feastignore is shown below:
.feastignore# Ignore virtual environmentvenv# Ignore a specific Python filescripts/foo.py# Ignore all Python files directly under scripts directoryscripts/*.py# Ignore all "foo.py" anywhere under scripts directoryscripts/**/foo.py
See .feastignore for more details.
A feature repository can also contain one or more Python files that contain feature definitions. An example feature definition file is shown below:
driver_features.pyfrom datetime import timedeltafrom feast import BigQuerySource, Entity, Feature, FeatureView, ValueTypedriver_locations_source = BigQuerySource(table_ref="rh_prod.ride_hailing_co.drivers",event_timestamp_column="event_timestamp",created_timestamp_column="created_timestamp",)driver = Entity(name="driver",value_type=ValueType.INT64,description="driver id",)driver_locations = FeatureView(name="driver_locations",entities=["driver"],ttl=timedelta(days=1),features=[Feature(name="lat", dtype=ValueType.FLOAT),Feature(name="lon", dtype=ValueType.STRING),],input=driver_locations_source,)
To declare new feature definitions, just add code to the feature repository, either in existing files or in a new file. For more information on how to define features, see Feature Views.
See Create a feature repository to get started with an example feature repository.