Search…
Feature repository
Feast users use Feast to manage two important sets of configuration:
  • Configuration about how to run Feast on your infrastructure
  • Feature definitions
With Feast, the above configuration can be written declaratively and stored as code in a central location. This central location is called a feature repository. 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, deploy, and manage your feature store.

What is a feature repository?

A feature repository consists of:
  • A collection of Python files containing feature declarations.
  • A feature_store.yaml file containing infrastructural configuration.
  • A .feastignore file containing paths in the feature repository to ignore.
Typically, users store their feature repositories in a Git repository, especially when working in teams. However, using Git is not a requirement.

Structure of a feature repository

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 .feastignore file.
  • 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:
1
$ tree -a
2
.
3
├── data
4
│ └── driver_stats.parquet
5
├── driver_features.py
6
├── feature_store.yaml
7
└── .feastignore
8
9
1 directory, 4 files
Copied!
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 feature_store.yaml configuration file

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.yaml
1
project: my_feature_repo_1
2
registry: data/metadata.db
3
provider: local
4
online_store:
5
path: data/online_store.db
Copied!
The feature_store.yaml file configures how the feature store should run. See feature_store.yaml for more details.

The .feastignore file

This file contains paths that should be ignored when running feast apply. An example .feastignore is shown below:
.feastignore
1
# Ignore virtual environment
2
venv
3
4
# Ignore a specific Python file
5
scripts/foo.py
6
7
# Ignore all Python files directly under scripts directory
8
scripts/*.py
9
10
# Ignore all "foo.py" anywhere under scripts directory
11
scripts/**/foo.py
Copied!
See .feastignore for more details.

Feature definitions

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.py
1
from datetime import timedelta
2
3
from feast import BigQuerySource, Entity, Feature, FeatureView, Field, ValueType
4
from feast.types import Float32, String
5
6
driver_locations_source = BigQuerySource(
7
table_ref="rh_prod.ride_hailing_co.drivers",
8
timestamp_field="event_timestamp",
9
created_timestamp_column="created_timestamp",
10
)
11
12
driver = Entity(
13
name="driver",
14
value_type=ValueType.INT64,
15
description="driver id",
16
)
17
18
driver_locations = FeatureView(
19
name="driver_locations",
20
entities=["driver"],
21
ttl=timedelta(days=1),
22
schema=[
23
Field(name="lat", dtype=Float32),
24
Field(name="lon", dtype=String),
25
],
26
source=driver_locations_source,
27
)
Copied!
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.

Next steps