What you will be able to do
- Describe what the offline feature store holds and which workloads read from it
- Describe what an online feature table is, what backs it and why it exists
- Identify which store batch inference and real-time inference each read from
- Recognise which feature tables cannot be published online and where third-party online stores fit
Key concept
Offline vs online feature store — The offline store is your Delta feature tables in Unity Catalog, used for discovery, training and batch scoring. The online store is a low-latency copy of those tables, published for real-time serving. Which store gets read depends on whether inference is batch or real-time.
1.The offline store: Delta tables for discovery, training and batch scoring
Every feature in Databricks Feature Store starts life in the offline store. With Unity Catalog enabled, any Delta table that has a primary key constraint can act as a feature table. You can build it with Databricks SQL, the Python FeatureEngineeringClient or Lakeflow pipelines, and you address it with the usual three-level name <catalog-name>.<schema-name>.<table-name>. The glossary sets out what this store is for: the offline store "is used for feature discovery, model training, and batch inference. It contains feature tables materialized as Delta tables."
Each of those jobs works in bulk. Discovery means browsing and governing tables in Unity Catalog. Training joins whole feature tables to a label DataFrame. Batch inference scores large sets of new rows in one pass. None of them needs one row back in milliseconds, so ordinary Delta storage handles them well. Your own pipelines keep the offline table current, with batch writes or Structured Streaming, and Databricks recommends a scheduled job that refreshes feature tables regularly, for example once a day.
Checkpoint 1 of 6· Check yourself
Which set of workloads is the offline feature store used for?
The offline store holds feature tables as Delta tables and serves discovery, training and batch inference. Low-latency real-time serving is the online store's job.
“The offline feature store is used for feature discovery, model training, and batch inference.”Source: docs.databricks.com
The offline store is built for bulk workloads: discovery, training and batch inference. Real-time applications need low-latency lookups of single entities at high scale. Databricks provides that through a separate store, the Online Feature Store, which is covered next.
2.The online store: a low-latency published copy
The Databricks Online Feature Store is a high-performance, scalable store for serving feature data to online applications and real-time models. It runs on Databricks Lakebase, and it "provides low-latency access to feature data at a high scale while maintaining governance, lineage, and consistency with your offline feature tables." You don't write features into it directly. You *publish* Unity Catalog tables into it, either as a sync or by streaming feature tables from the offline store to the online store. The online table is therefore a copy of an offline table, kept in sync with it, rather than a second place where features are defined.
| Aspect | Offline feature tables | Online feature tables |
|---|---|---|
| Storage | Feature tables materialized as Delta tables in Unity Catalog | Databricks Online Feature Store powered by Lakebase (third-party online stores are also supported) |
| Used for | Feature discovery, model training, batch inference | Serving features to online applications and real-time ML models |
| How data gets in | Your feature pipelines write to them (batch or streaming) | Published (or streamed) from offline feature tables |
| Read at inference | Batch inference: values joined with new data before scoring | Real-time inference: values retrieved from the online store |
| Governance | Unity Catalog Delta tables with a primary key | Unity Catalog entities that track lineage to the source tables |
Checkpoint 2 of 6· Match them up
Match each workload to the feature store that serves it
Tap a term, then the definition that fits it.
Training, discovery and batch inference are offline workloads. Real-time inference reads published features from the online store.
“The offline feature store is used for feature discovery, model training, and batch inference.”Source: docs.databricks.com
Sources1
3.Which store each inference path reads
When you log a model with FeatureEngineeringClient.log_model, the model keeps references to the features it was trained on. At inference the caller sends only the primary key, for example user_id, and the model fetches the feature values it needs. Where those values come from depends on how you score. "In batch inference, feature values are retrieved from the offline store and joined with new data prior to scoring. In real-time inference, feature values are retrieved from the online store."
On the real-time path, a model serving endpoint "automatically uses the entity IDs in the request data to look up pre-computed features from the online store". It finds the right online tables through Unity Catalog, which resolves lineage from the served model back to its training features. The docs describe this as automatic with no setup required. When a scoring request arrives, Model Serving retrieves the published feature values, so predictions always use the most recent ones. A model trained on offline tables can therefore serve in real time without code changes, provided its features have been published.
Checkpoint 3 of 6· Put it in order
Put the typical Feature Store workflow in order, from raw features to real-time scoring
- 1.Publish the features to an online feature store
- 2.Register the model in Model Registry
- 3.Train and log a model using the feature table
- 4.The serving endpoint looks up pre-computed features from the online store using entity IDs in the request
- 5.Create a Delta table in Unity Catalog that has a primary key
The offline table comes first and feeds training. Publishing to the online store happens only for real-time serving, and the endpoint then reads from that published copy.
“For real-time serving use cases, publish the features to an online feature store.”Source: docs.databricks.com
Checkpoint 4 of 6· Exam question
A fraud-detection model is deployed to a real-time Model Serving endpoint that must score incoming transactions within tens of milliseconds. The engineering team has an existing offline feature table in Unity Catalog that holds the customer-level features the model needs, but the endpoint currently cannot retrieve those features fast enough at inference time. What should the team do to give the endpoint low-latency access to these features?
Correct answer: B — Publish the offline feature table to an online store with `fe.publish_table` so the endpoint performs low-latency lookups against the Lakebase-backed online copy.
- A. `create_training_set` builds a point-in-time training dataset for model development, not a low-latency lookup path for a live serving endpoint, so it does not solve the latency problem here.
- B. Publishing the feature table to an online store syncs it to Lakebase-backed infrastructure purpose-built for high-throughput, low-latency point lookups, which is exactly what a real-time endpoint needs.
- C. Read replicas improve throughput and availability for a table already present in an online store, but they do not make an unpublished offline table reachable from that store.
- D. Offline Delta tables are optimized for large scan-oriented batch and analytical workloads, not the sub-millisecond point lookups a real-time endpoint requires.
4.What can and cannot be served online
Not every offline feature table can have an online counterpart. Feature tables based on views "can be used for offline model training and evaluation. They cannot be published to online stores." Because they can't be published, features from those tables, and models built on them, cannot be served.
FeatureSpecs follow the same split. A FeatureSpec bundles FeatureLookups and FeatureFunctions into one unit that you can use in training or deploy behind a Feature Serving endpoint. However, "A FeatureSpec always references the offline feature tables, but they must be published to an online store for real-time serving scenarios." Both ways of authoring features, Feature Views and feature tables, produce Unity Catalog-governed features that can be published to the Online Feature Store.
The online store doesn't have to be Databricks'. Feature tables can also be published to third-party stores: Amazon DynamoDB, Amazon Aurora (MySQL-compatible) and Amazon RDS MySQL. Even so, Databricks recommends its own Online Feature Stores for real-time serving. With a third-party store the online copy can be laid out differently from the offline table. For example, the DynamoDB online store keeps primary keys as one combined key in the column _feature_store_internal__primary_keys.
Checkpoint 5 of 6· Check yourself
A team defines a feature table on top of a view and wants to serve a model trained on it from a real-time endpoint. What happens?
View-based feature tables are limited to offline use. A FeatureSpec doesn't get around this, because its offline tables still have to be published for real-time serving.
“Feature tables based on views can be used for offline model training and evaluation. They cannot be published to online stores.”Source: docs.databricks.com
Checkpoint 6 of 6· Exam question
A data scientist is assembling a training set for a churn model using several feature tables joined to historical label events, and each label row must be matched to feature values as they existed at that row's timestamp to avoid leaking future information. Which approach correctly builds this training set?
Correct answer: A — Call `fe.create_training_set` against the offline feature tables with a timestamp lookup key so features are joined as of each label's recorded event time.
- A. `create_training_set` against the offline feature tables with a timestamp lookup key performs the point-in-time join that matches each label to the feature values valid at that moment, preventing label leakage.
- B. An online store only holds the latest materialized values for serving; it is not designed to preserve or expose historical point-in-time state for training joins.
- C. Sync arrival order in a continuously published online store reflects when data was propagated, not the business event timestamp needed for a correct point-in-time join.
- D. The serving endpoint's automatic feature lookup returns the current online value for real-time scoring; it has no mechanism for resolving historical point-in-time training joins.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.A model logged with feature metadata reads from the online store for every kind of inference, including batch scoring.Why is that wrong?
Batch inference reads feature values from the offline store and joins them with the new data. Only real-time inference reads from the online store.
Covered in Which store each inference path reads
2.Any feature table that works for training can also be published online and served.Why is that wrong?
Feature tables based on views are limited to offline training and evaluation. They cannot be published to online stores, so their features cannot be served.
Covered in What can and cannot be served online
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“The offline feature store is used for feature discovery, model training, and batch inference. It contains feature tables materialized as Delta tables.”
↩︎ The offline store: Delta tables for discovery, training and batch scoring“it provides low-latency access to feature data at a high scale while maintaining governance, lineage, and consistency with your offline feature tables”
↩︎ The online store: a low-latency published copy“You can also stream feature tables from the offline store to an online store.”
↩︎ The online store: a low-latency published copy“automatically uses the entity IDs in the request data to look up pre-computed features from the online store”
↩︎ Which store each inference path reads“A FeatureSpec always references the offline feature tables, but they must be published to an online store for real-time serving scenarios.”
↩︎ What can and cannot be served online“In batch inference, feature values are retrieved from the offline store and joined with new data prior to scoring.”
↩︎ Key concept“In real-time inference, feature values are retrieved from the online store.”
↩︎ Exam trap 1“The offline feature store is used for feature discovery, model training, and batch inference.”
↩︎ Checkpoint“These tables are also Unity Catalog entities that natively track lineage to the source tables.”
↩︎ Prediction“The offline feature store is used for feature discovery, model training, and batch inference.”
↩︎ Checkpoint“For real-time serving use cases, publish the features to an online feature store.”
↩︎ Checkpoint - 2.
“In Unity Catalog, any Delta table with a primary key constraint can serve as a feature table.”
↩︎ The offline store: Delta tables for discovery, training and batch scoring“Features from these tables and models based on these features cannot be served.”
↩︎ Exam trap 2“Feature tables based on views can be used for offline model training and evaluation. They cannot be published to online stores.”
↩︎ Checkpoint - 3.
“When a scoring request comes in to the model, Model Serving automatically retrieves the published feature values needed by the model.”
↩︎ Which store each inference path reads - 4.https://docs.databricks.com/aws/en/machine-learning/feature-store/third-party-online-storesOfficial docs
“For real-time serving of feature values, Databricks recommends using Databricks Online Feature Stores.”
↩︎ What can and cannot be served online - 5.
“The DynamoDB online store uses a different schema than the offline store.”
↩︎ What can and cannot be served online