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
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, ValueType
4
​
5
driver_locations_source = BigQuerySource(
6
table_ref="rh_prod.ride_hailing_co.drivers",
7
event_timestamp_column="event_timestamp",
8
created_timestamp_column="created_timestamp",
9
)
10
​
11
driver = Entity(
12
name="driver",
13
value_type=ValueType.INT64,
14
description="driver id",
15
)
16
​
17
driver_locations = FeatureView(
18
name="driver_locations",
19
entities=["driver"],
20
ttl=timedelta(days=1),
21
features=[
22
Feature(name="lat", dtype=ValueType.FLOAT),
23
Feature(name="lon", dtype=ValueType.STRING),
24
],
25
batch_source=driver_locations_source,
26
)
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.