4.2. Design a Minimal Feature Store

At its core, every feature record has four essential parts:

Example Table: feature_store

Why This Schema Works:

• It’s simple and extensible.
• It captures time-evolving values.
• It’s entity-aware, so you can join on entity_id for predictions.

💡 Intuition: Think of each row as a “snapshot” of the world for one user at one moment — a perfect time capsule of your training data.

You can build this Feature Store in two main ways:

🧮 Option A: Feast (Feature Store Framework)

Feast is a purpose-built tool for managing offline and online features.

Workflow:

1. Define entities and features in a YAML or Python file.

   from feast import Entity, Feature, FeatureView, Field, FileSource
   from feast.types import Float32
   
   customer = Entity(name="customer_id", join_keys=["customer_id"])
   
   transactions = FileSource(
       path="data/transactions.parquet",
       timestamp_field="event_timestamp",
   )
   
   customer_features = FeatureView(
       name="customer_stats",
       entities=["customer_id"],
       ttl=None,
       schema=[
           Field(name="avg_monthly_spend", dtype=Float32),
           Field(name="last_purchase_gap", dtype=Float32),
       ],
       source=transactions,
   )

2. Materialize features into the online store (e.g., Redis).

3. Fetch features by entity for inference in real-time.

💡 Intuition: Feast acts like a delivery system — packaging features into ready-to-serve meals for your models.

💾 Option B: PostgreSQL / SQLite (Lightweight Custom Store)

You can use a simple SQL table to mimic the same functionality.

CREATE TABLE feature_store (
  feature_name TEXT,
  entity_id TEXT,
  timestamp TIMESTAMP,
  value FLOAT,
  feature_version INT DEFAULT 1,
  PRIMARY KEY (feature_name, entity_id, timestamp, feature_version)
);

Retrieving latest features:

SELECT feature_name, entity_id, value
FROM feature_store
WHERE entity_id = '123'
AND timestamp <= '2025-10-30'
ORDER BY timestamp DESC
LIMIT 1;

💡 Intuition: You don’t need a fancy tool to start — any SQL database can act as your prototype Feature Store if it respects versioning and time.

When your feature logic changes (say you move from 3-month to 6-month averages), you should not overwrite old values. Instead, assign a new version — just like you would for code.

Example:

Why Versioning Matters:

• Old models may depend on old feature definitions.
• You can compare model performance across versions.
• It prevents confusion and accidental overwrites.

💡 Intuition: Think of feature versioning like saving new recipes — you don’t throw away the old one; you just write “v2” in the corner.

Backfilling means populating historical data for a new feature definition.

Example Scenario:

You add a new feature: “average purchase in last 30 days.” Your system should compute this feature for past events too, not just future data.

Strategies:

1. Batch Backfill: Run a historical job on old data to populate missing timestamps.

2. Incremental Backfill: Fill gaps in small intervals (e.g., daily jobs) to reduce load.

3. On-Demand Backfill: Generate features only when a training job needs them — saves compute.

💡 Intuition: Backfilling is like updating your diary — if you forgot to write entries for last week, you go back and fill them in for completeness.

A feature value can be defined as a function of time and version:

When retrieving data for training or inference, we query:

That is, we take the latest available valid value before the event time $t$ (ensuring point-in-time correctness).

• “A Feature Store is just a cache.” No — it’s a versioned, time-aware, consistent data system.

• “You need Feast or Tecton to start.” Not true — you can build a small SQL-based feature store first and scale later.

• “Backfill means overwriting old values.” Incorrect — backfill adds missing historical values, preserving old context.