Registry

The Feast feature registry is a central catalog of all feature definitions and their related metadata. Feast uses the registry to store all applied Feast objects (e.g. Feature views, entities, etc). It allows data scientists to search, discover, and collaborate on new features. The registry exposes methods to apply, list, retrieve and delete these objects, and is an abstraction with multiple implementations.

Feast comes with built-in file-based and sql-based registry implementations. By default, Feast uses a file-based registry, which stores the protobuf representation of the registry as a serialized file in the local file system. For more details on which registries are supported, please see Registries.

Updating the registry

We recommend users store their Feast feature definitions in a version controlled repository, which then via CI/CD automatically stays synced with the registry. Users will often also want multiple registries to correspond to different environments (e.g. dev vs staging vs prod), with staging and production registries with locked down write access since they can impact real user traffic. See Running Feast in Production for details on how to set this up.

Deleting objects from the registry

circle-exclamation

Using the CLI

The simplest way to delete objects is using the feast delete command:

# Delete any Feast object by name
feast delete my_feature_view
feast delete my_entity
feast delete my_feature_service

See the CLI documentation for more details.

Using the Python SDK

To delete objects programmatically, use the explicit delete methods provided by the FeatureStore class:

Deleting feature views

Deleting feature services

Deleting entities, data sources, and other objects

For entities, data sources, and other registry objects, you can use the registry methods directly:

circle-info

When using feast apply via the CLI, you can also use the objects_to_delete parameter with partial=False to delete objects as part of the apply operation. However, this is less common and typically used in automated deployment scenarios.

Accessing the registry from clients

Users can specify the registry through a feature_store.yaml config file, or programmatically. We often see teams preferring the programmatic approach because it makes notebook driven development very easy:

Option 1: programmatically specifying the registry

Option 2: specifying the registry in the project's feature_store.yaml file

Instantiating a FeatureStore object can then point to this:

circle-info

The file-based feature registry is a Protobuf representationarrow-up-right of Feast metadata. This Protobuf file can be read programmatically from other programming languages, but no compatibility guarantees are made on the internal structure of the registry.

Last updated

Was this helpful?