← Back to all products

Feature Store Bootstrap

$39

Feature store patterns using Feast, feature engineering pipelines, and offline/online serving configurations.

📁 17 files🏷 v1.0.0
JSONMarkdownPythonYAMLAWSGCPRedis

📄 Product Preview

Try the interactive reader and demo tools below, or get the full product with all content unlocked.

📖 Interactive Reader (Free Preview) ⚙ Try Demo Tools 📦 Download Free Sample

📁 File Structure 17 files

feature-store-bootstrap/ ├── LICENSE ├── README.md ├── examples/ │ ├── materialize_and_serve.py │ └── training_dataset.py ├── feature_repo/ │ ├── example_repo.py │ └── feature_store.yaml ├── guides/ │ ├── feast-setup.md │ └── feature-engineering-patterns.md ├── src/ │ └── feature_store/ │ ├── __init__.py │ ├── definitions.py │ ├── ingestion.py │ ├── registry.py │ ├── retrieval.py │ └── transformations.py └── tests/ ├── test_definitions.py └── test_retrieval.py

📖 Documentation Preview README excerpt

Feature Store Bootstrap

A production-shaped [Feast](https://feast.dev) feature store you can read,

run, and adapt in an afternoon. It ships a complete, tested feature repository

for an anonymised retail-risk domain ("AcmeCorp") -- entities, batch and

streaming sources, on-demand transformations, and two feature services (a

real-time fraud model and a batch churn model) -- plus a small,

unit-tested helper library that wraps the Feast read/write APIs the way a real

team would.

This is not a hello-world. The feature logic is separated from the Feast

wrappers so it has real test coverage, the helpers are dependency-injected so

they test without a running store, and the guides explain the why behind

point-in-time correctness, train/serve skew, TTLs, and push-vs-batch ingestion.

Features

  • Complete Feast repository -- 2 entities, 3 batch feature views, a request

source, a push source, an on-demand feature view, and 2 feature services.

  • A reusable helper library (src/feature_store/) for ingestion, retrieval,

and registry management -- not just inline repo code.

  • Point-in-time correct training retrieval driven by a FeatureService so

training and serving never drift.

  • Streaming + batch ingestion via materialize_* and a PushSource.
  • On-demand (request-time) features with the maths factored into pure,

unit-tested functions.

  • Two runnable examples that generate their own data and run end to end.
  • Two test suites -- most tests run with just pytest (no Feast needed)

thanks to dependency injection; the rest importorskip their dependency.

  • Two in-depth guides: setup and feature-engineering patterns.

Prerequisites

  • Python 3.9+
  • feast 0.30+ (pip install "feast[redis]")
  • pandas and pyarrow (for the parquet examples)
  • Redis for the online store *(optional -- the config includes a zero-install

SQLite alternative)*


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

Quick Start


# 1. Apply the feature definitions to a fresh registry.
cd feature_repo
feast apply

# 2. Run the full write + serve example (generates sample data, materializes,
#    pushes a streaming update, and serves both feature services).
cd ..
python examples/materialize_and_serve.py

# 3. Build a point-in-time correct training set for the churn model.
python examples/training_dataset.py

... continues with setup instructions, usage examples, and more.

📄 Code Sample .py preview

src/feature_store/definitions.py """Feast feature definitions for the AcmeCorp retail-risk domain. This module is the single source of truth for the *declarative* objects that Feast tracks in its registry: entities, data sources, batch feature views, a request source, and feature services that are composed purely from batch features. On-demand (request-time) feature views and the feature services that depend on them live in :mod:`feature_store.transformations` so that this module stays free of circular imports. The domain is an anonymised e-commerce business ("AcmeCorp"). We track two entities -- ``customer`` and ``merchant`` -- and engineer features that two downstream models consume: * a **fraud-detection** model that scores a transaction in real time, and * a **churn** model that scores a customer in a nightly batch job. Every object defined here is a real ``feast`` object and can be applied to a registry with ``feast apply`` (see ``feature_repo/example_repo.py``) or programmatically via :func:`feature_store.registry.RegistryManager.apply`. Reference: https://docs.feast.dev/getting-started/concepts """ from __future__ import annotations from datetime import timedelta from feast import ( Entity, FeatureService, FeatureView, Field, FileSource, PushSource, RequestSource, ) from feast.types import Bool, Float64, Int64, String # --------------------------------------------------------------------------- # Project-wide conventions # --------------------------------------------------------------------------- # Keeping these as module-level constants means a feature view's freshness SLA # is declared once and reused, rather than sprinkling ``timedelta(...)`` magic # numbers across the file. TTL controls how far back Feast will look for a row # when serving online features; pick it to match how often the source updates. PROFILE_TTL = timedelta(days=90) # Profile rows change slowly. TXN_STATS_TTL = timedelta(days=3) # Rolling aggregates must stay fresh. MERCHANT_TTL = timedelta(days=7) # A relative ``data/`` directory keeps the example self-contained. In # ... 183 more lines ...
Buy Now — $39 Back to Products