Feast Setup Guide

This guide takes you from an empty machine to a working feature store serving

the AcmeCorp retail-risk features shipped in this package. It assumes Python

3.9+ and basic comfort with the command line.

1. Install

Feast is modular: you install the framework plus the extras for the stores you

use. For the default config in feature_repo/feature_store.yaml (Redis online,

file offline) you need:

python -m venv .venv && source .venv/bin/activate
pip install "feast[redis]" pandas pyarrow

For a zero-infrastructure local run, you can skip Redis entirely and use the

SQLite online store (see step 4). Other common extras: feast[aws],

feast[gcp], feast[snowflake], feast[postgres].

2. Understand the layout

feature-store-bootstrap/
  src/feature_store/        importable library (definitions + helpers)
    definitions.py          entities, sources, batch feature views, services
    transformations.py      pure feature logic + on-demand feature views
    ingestion.py            materialize / push helpers
    retrieval.py            training + serving retrieval helpers
    registry.py             apply / describe / teardown helpers
  feature_repo/
    feature_store.yaml      the project config Feast reads
    example_repo.py         the file `feast apply` scans (imports the library)
    data/                   parquet fixtures + registry.db (created on first run)

The split between src/feature_store/ (a tested library) and feature_repo/

(a thin Feast entry point) is deliberate. Feature logic lives in version-

controlled, unit-tested Python; the repo file just imports and re-exports it so

Feast can discover the objects. As your feature set grows past a single file,

this scales far better than one monolithic example_repo.py.

3. The configuration file, line by line

feature_store.yaml has five things Feast must know:

entity_key_serialization_version: 2 should always be set on new projects --

it is a more compact online-store key encoding. Do not change it on an existing

project, as it would invalidate already-materialized keys.

4. Local run without Redis

Edit feature_repo/feature_store.yaml, comment the redis block, and uncomment

the SQLite alternative:

online_store:
  type: sqlite
  path: data/online_store.db

SQLite is single-process and slow under load -- perfect for development and CI,

never for production serving.

5. Apply the registry

apply is idempotent: it diffs your definitions against the registry and

creates/updates/deletes objects to match. Run it from the repo directory:

cd feature_repo
feast apply

You should see Feast create the entities, feature views, on-demand view, and the

two feature services. Equivalently, from Python:

from feast import FeatureStore
from feature_store.registry import RegistryManager

store = FeatureStore(repo_path="feature_repo")
RegistryManager(store).apply()        # registers everything
RegistryManager(store).describe()     # prints what is now in the registry

6. Materialize features into the online store

Materialization copies feature values from the offline store into the online

store so they can be served in milliseconds.

# One-off backfill of an explicit window:
feast materialize 2024-01-01T00:00:00 2024-01-08T00:00:00

# Scheduled top-up since the last run (the cron-friendly command):
feast materialize-incremental $(date -u +"%Y-%m-%dT%H:%M:%S")

In Python, prefer the helpers in ingestion.py -- they add logging and return

an IngestionStats you can emit to your metrics system:

from feature_store.ingestion import materialize_window, materialize_incremental

materialize_window(store, days=7)          # explicit backfill
materialize_incremental(store)             # scheduled top-up

7. Keep the online store fresh between runs

Scheduled materialization has a built-in lag equal to your cron interval. For

features that must be near-real-time (transaction velocity, for example), stream

updates through the PushSource:

from feature_store.ingestion import push_micro_batch

push_micro_batch(store, "customer_txn_push_source", fresh_df, mode="online")

mode="online_and_offline" also appends to the offline store so the pushed

value is available for future training joins -- use it when the streamed

aggregate should become part of the historical record.

8. Schedule it in production

A minimal production cadence:

• Nightly: feast materialize-incremental for slowly-changing views

(profiles, merchant stats) via Airflow / Cron / GitHub Actions.

• Continuous: a stream consumer calling push_micro_batch for fast-moving

aggregates.

• On every merge to main: feast apply in CI so registry changes ship with

code. Pin the Feast version in requirements.txt so apply behaviour is

reproducible.

9. Troubleshooting

With apply, materialize, and serve working, move on to

feature-engineering-patterns.md for how to design features that stay correct

in production.