How to Use Feast's Feature Service API for Model Serving

Feast's Feature Service API lets you bundle features from multiple views into a single named object that can be retrieved in one call during model serving, ensuring consistent feature sets between training and inference.

The Feature Service API in Feast (feast-dev/feast) provides a declarative way to group related features for model serving. By defining a FeatureService object in your feature repository, you create a versioned contract that maps to specific columns across one or more feature views, enabling low-latency retrieval via the Python SDK or the standalone feature server.

What Is the Feature Service API?

A Feature Service is a logical grouping of feature view projections. Rather than passing raw feature references to your model serving code, you define a service that encapsulates exactly the features your model expects.

Key characteristics:

• Projection-based: Each service contains references to specific columns (projections) from one or more FeatureView objects.
• Schema inference: If a feature view lacks an explicit schema, the service can infer required features during the feast apply phase via the infer_features method.
• Dual-mode: The same service definition works for both offline training (historical joins) and online serving (real-time inference).

The core implementation resides in sdk/python/feast/feature_service.py, where the FeatureService class stores projections and performs inference logic.

How the Feature Service API Is Implemented

Feast exposes feature services through multiple interfaces:

Registry REST API

The registry server provides REST endpoints for service discovery, defined in sdk/python/feast/api/registry/rest/feature_services.py:

• GET /feature_services – Lists all services with optional filtering by name, tags, or feature view.
• GET /feature_services/{name} – Retrieves a specific service, including a rendered Python code snippet for easy reuse.

Client SDK

The FeatureStore class in sdk/python/feast/feature_store.py provides the primary interface:

• get_feature_service(name) – Fetches the service definition from the registry.
• get_online_features(features=service, ...) – Accepts a FeatureService instance instead of a raw feature list.

Serving Layer

The standalone feature server (sdk/python/feast/feature_server.py) and the underlying gRPC service (protos/feast/serving/ServingService.proto) resolve service names at request time, expanding them into constituent feature references before querying the online store.

Defining a Feature Service for Model Serving

To use the Feature Service API in production, first define the service in your feature repository.

Step 1: Create the Service Definition

In feature_repo.py, instantiate FeatureService with a list of feature view projections:

from datetime import timedelta
from feast import Entity, FeatureView, FeatureService, FileSource, Field, ValueType

# Define entity and source

driver = Entity(name="driver_id", description="driver identifier")

driver_stats_source = FileSource(
    path="data/driver_stats.parquet",
    timestamp_field="event_timestamp",
    created_timestamp_column="created",
)

# Define the feature view

driver_stats_fv = FeatureView(
    name="driver_stats",
    entities=[driver],
    ttl=timedelta(days=1),
    source=driver_stats_source,
    schema=[
        Field(name="daily_trips", dtype=ValueType.INT64),
        Field(name="average_speed", dtype=ValueType.FLOAT),
    ],
)

# Group specific features into a service for model serving

driver_service = FeatureService(
    name="driver_service",
    features=[driver_stats_fv[["daily_trips", "average_speed"]]],
)

Step 2: Apply the Configuration

Run feast apply to register the service. This triggers FeatureService.infer_features in sdk/python/feast/feature_service.py, which resolves the projection against the concrete feature view schema.

feast apply

Retrieving Features via the Feature Service API

Once registered, retrieve features using the service object or name.

Method 1: Python SDK

Fetch the service from the registry and pass it to get_online_features:

from feast import FeatureStore

store = FeatureStore(repo_path="path/to/feature_repo")

# Retrieve the service definition

svc = store.get_feature_service("driver_service")

# Request features for inference

entity_rows = [{"driver_id": 123}]
response = store.get_online_features(
    entity_rows=entity_rows,
    features=svc,  # Pass the FeatureService object

    full_feature_names=True,
)

# Convert to dictionary for model input

feature_dict = response.to_dict()

Method 2: Standalone Feature Server

For production serving, run the Feast feature server and query via HTTP:

feast feature-server start \
  --project=my_project \
  --host=0.0.0.0 \
  --port=6565

Then query using the service name:

import requests
import json

payload = {
    "features": ["driver_service"],  # Service name as string

    "entities": [{"driver_id": 123}]
}

response = requests.post(
    "http://localhost:6565/get-online-features",
    json=payload,
    timeout=5
)

features = json.loads(response.text)

The server expands "driver_service" into its constituent feature references (driver_stats:daily_trips, driver_stats:average_speed) before querying the online store, ensuring low-latency retrieval while keeping your model code decoupled from the underlying feature view topology.

Summary

• The Feature Service API groups feature view projections into a single, versioned object for consistent retrieval.
• Define services in Python using FeatureService, then apply with feast apply to register them in sdk/python/feast/feature_service.py.
• Retrieve features via FeatureStore.get_online_features by passing the service object, or query the standalone feature server using the service name.
• This approach decouples model serving code from underlying feature view schemas, ensuring training-serving consistency.

Frequently Asked Questions

What is the difference between a Feature View and a Feature Service?

A Feature View defines a logical grouping of features based on a data source and entity keys, typically corresponding to a specific table or stream. A Feature Service is a higher-level abstraction that selects specific columns (projections) from one or more Feature Views to create a curated feature set for a specific model or use case. While a Feature View manages the data pipeline and storage, a Feature Service manages the serving contract.

Can I use the same Feature Service for both training and serving?

Yes. The Feature Service API is designed for dual-mode usage. When passed to get_historical_features, it retrieves point-in-time correct feature values for model training. When passed to get_online_features or queried via the feature server, it retrieves the latest values for real-time inference. This ensures that the exact same feature set is used in both contexts, preventing training-serving skew.

How does the Feature Service API handle schema evolution?

When you run feast apply, the FeatureService.infer_features method in sdk/python/feast/feature_service.py resolves the feature projections against the concrete schemas of the underlying Feature Views. If a Feature View schema changes (e.g., a new column is added), the service definition remains valid as long as the projected columns still exist. To add new features to a service, simply update the projection list in the Python definition and re-run feast apply.

What latency can I expect when using the Feature Service API for online serving?

The Feature Service API itself introduces negligible overhead. When using get_online_features with a Feature Service object, the client expands the service into a list of feature references before sending a single batch request to the online store. When using the standalone feature server (feast feature-server start), the server performs this expansion internally. In both cases, the online store (e.g., Redis, DynamoDB, Bigtable) is queried in a single batch operation, typically achieving p99 latencies under 10-20ms depending on your infrastructure.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}