You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 8011550
Browse filesBrowse the repository at this point in the historyBrowse files
For latency-critical online serving, you can enable **pre-computed feature vectors** on a feature service. When `precompute_online=True`, Feast stores all of the service's features for each entity as a single serialized blob in the online store. At read time, this reduces the number of store reads from O(N feature views) to O(1), regardless of how many feature views the service spans.
58
+
59
+
```python
60
+
# A feature service with pre-computed vectors enabled
After running `feast apply`, the pre-computed vectors are automatically built and refreshed whenever you run `feast materialize` or `feast materialize-incremental`. Feast detects which feature services have `precompute_online=True` and rebuilds their vectors for every affected entity after the per-feature-view writes complete. Vectors are also refreshed automatically on `feast push`.
69
+
70
+
{% hint style="info" %}
71
+
`precompute_online` is **opt-in** — it defaults to `False`. When enabled, the pre-computed path is used exclusively for that service; there is no silent fallback to per-feature-view reads. If vectors are missing or stale, the server raises an error, making problems visible immediately.
72
+
{% endhint %}
73
+
74
+
{% hint style="warning" %}
75
+
`precompute_online` is not compatible with on-demand feature views (ODFVs) that have `write_to_online_store=False`. ODFVs with `write_to_online_store=True` are supported since their values are materialized.
76
+
{% endhint %}
77
+
78
+
See the [performance tuning guide](../../how-to-guides/online-server-performance-tuning.md#pre-computed-feature-vectors) for benchmarks and detailed configuration.
79
+
55
80
Retrieving from the online store with a feature service
Copy file name to clipboardExpand all lines: docs/how-to-guides/online-server-performance-tuning.md
+43-1Lines changed: 43 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -35,10 +35,12 @@ When the server processes a `get_online_features()` call, it groups the requeste
35
35
**Redis exception:** The Redis online store overrides `get_online_features()` to batch all `HMGET` commands across every feature view into a **single pipeline execution**. Because all feature views for the same entity share one Redis hash key, the number of Redis round trips is always **1**, regardless of how many feature views the request touches. This means the "fewer feature views" guideline is less critical for Redis than for other stores — but consolidating feature views still reduces serialization and protobuf overhead at the application layer.
36
36
{% endhint %}
37
37
38
-
### Feature services are free
38
+
### Feature services are free (and can be faster)
39
39
40
40
A [Feature Service](../getting-started/concepts/feature-retrieval.md) is a named collection of feature references — it's a convenience grouping, not a separate storage or execution unit. Using a feature service adds only a registry lookup (cached) compared to listing features individually. There is no performance penalty for using feature services, and they are the recommended way to define stable, versioned feature sets for production models.
41
41
42
+
For latency-critical services, feature services also unlock **pre-computed feature vectors** (`precompute_online=True`), which reduce store reads from O(N feature views) to O(1). See the [Pre-computed feature vectors](#pre-computed-feature-vectors) section below for details and benchmarks.
43
+
42
44
### ODFV overhead is additive
43
45
44
46
Regular feature views incur only **store read** cost. On-demand feature views add **CPU-bound transformation** cost on top:
@@ -83,6 +85,45 @@ Requesting just `combined_score` triggers reads from **both** `driver_stats_fv`
83
85
84
86
---
85
87
88
+
## Pre-computed feature vectors
89
+
90
+
When a `get_online_features()` request touches multiple feature views, the server issues a separate store read per feature view. For services spanning 5–15+ feature views, this fan-out dominates latency — even with Redis pipeline batching, the protobuf deserialization and response-building overhead grows linearly with the number of views.
91
+
92
+
**Pre-computed feature vectors** solve this by storing all of a feature service's features for each entity as a single serialized blob. At read time, the server fetches one blob per entity instead of N reads per feature view, reducing the operation to O(1).
93
+
94
+
### How it works
95
+
96
+
1.**Define** a feature service with `precompute_online=True`:
97
+
98
+
```python
99
+
benchmark_service = FeatureService(
100
+
name="benchmark_customer_service",
101
+
features=[
102
+
customer_demographics_fv,
103
+
customer_behavioral_profile,
104
+
transaction_7d_aggregations,
105
+
transaction_30d_aggregations,
106
+
transaction_90d_patterns,
107
+
atm_usage_30d,
108
+
],
109
+
precompute_online=True,
110
+
)
111
+
```
112
+
113
+
2.**Apply** the feature service: `feast apply`
114
+
3.**Materialize** as usual — vectors are built automatically: `feast materialize-incremental $(date -u +"%Y-%m-%dT%H:%M:%S")`
115
+
4.**Read** features as usual — the server automatically uses the pre-computed path:
- [feature_store.yaml reference](../reference/feature-repository/feature-store-yaml.md) — Full configuration reference including `materialization` options
0 commit comments