What you will be able to do
- Create an online store, publish a feature table to it, and choose between the TRIGGERED, CONTINUOUS and SNAPSHOT publish modes
- Delete online tables correctly with the Databricks SDK
- Define on-demand features with FeatureFunction and log models so the features are computed the same way in training and serving
- Build a FeatureSpec and serve it from a Feature Serving endpoint
1.Provisioning an online feature store
Offline Delta feature tables are fine for training, but real-time applications need millisecond lookups. Databricks Online Feature Stores run on Databricks Lakebase and serve two main use cases: Feature Serving endpoints for applications such as fraud detection or recommendations, and automatic feature lookup for models behind Model Serving endpoints. They require Databricks Runtime 16.4 LTS ML or above, or serverless compute, and databricks-feature-engineering>=0.13.0.
fe.create_online_store(
name="my-online-store", # maximum of 63 bytes
capacity="CU_2" # Valid options: "CU_1", "CU_2", "CU_4", "CU_8"
)An online store is managed, highly available infrastructure that you pay for while it exists. Delete stores you only created for development and testing. You can resize a store with fe.update_online_store and add read_replica_count replicas to spread read traffic under high concurrency. Disabling high availability breaks connectivity for the serving endpoints that read from the store. To change it safely, use a blue/green rollout: create a new store, publish to it, point new endpoints at it, validate, and then retire the old store and endpoints.
Checkpoint 1 of 6· Put it in order
Put the blue/green steps for changing high-availability settings in order
- 1.Create a new online store with the target configuration
- 2.Validate the connection between the new store and the new endpoints
- 3.Point new serving endpoints to the new store
- 4.Publish the feature tables to the new store
- 5.Turn off the old endpoints and online store
The new store has to hold the data and be verified before the old path is shut down. That way the connected endpoints are never disrupted.
“Disabling high availability on an online store breaks connectivity for Feature Serving or Model Serving endpoints that read from the store.”Source: docs.databricks.com
Sources1
2.Publishing feature tables and managing online tables
Once the store reaches the AVAILABLE state, publish_table does three things: it creates the online table, syncs the data into it, and sets up the infrastructure that keeps the two in sync. A table published without a time series designation keeps every row with no deduplication. That suits only exact-match lookups on a string key, not as-of queries. Before any publish, the source table needs a primary key constraint and non-nullable primary key columns. The TRIGGERED and CONTINUOUS modes also require Change Data Feed to be enabled.
online_store = fe.get_online_store(name="my-online-store")
# Publish the feature table to the online store
fe.publish_table(
online_store=online_store,
source_table_name="catalog_name.schema_name.feature_table_name",
# for online_table_name, the catalog name, schema name, and table name each are limited to a maximum of 63 bytes
online_table_name="catalog_name.schema_name.online_feature_table_name",
# `publish_mode` argument is optional and defaults to "TRIGGERED" mode if not specified
)Checkpoint 2 of 6· Match them up
Match each publish_mode to its behaviour
Tap a term, then the definition that fits it.
publish_mode replaced the older streaming parameter. For TRIGGERED, a scheduled Lakeflow Job that reruns publish_table keeps the online table fresh.
“Default. Incrementally updates the online table with changes from the offline table using the API or on a schedule.”Source: docs.databricks.com
To remove an online table, the Databricks SDK is the only recommended route. Running DROP TABLE in SQL, or deleting the synced table through the SDK, removes the Unity Catalog entry but leaves the data in the underlying database storage.
from databricks.sdk import WorkspaceClient
w = WorkspaceClient()
w.feature_store.delete_online_table(online_table_name="catalog_name.schema_name.online_feature_table_name")Checkpoint 3 of 6· Exam question
A team is registering a new feature table for customer lifetime value features that will later support point-in-time joins. Using `FeatureEngineeringClient`, which call correctly creates this table?
Correct answer: A — `fe.create_table(name="main.ml.customer_ltv_features", primary_keys=["customer_id"], timestamp_keys=["event_ts"], df=features_df, schema=features_df.schema)`, registering a Unity Catalog Delta table with the keys later lookups need.
- A. `create_table` is the call that registers a feature table with Feature Engineering, and supplying `primary_keys`, `timestamp_keys`, and either `df` or `schema` is what makes the table usable for later point-in-time `FeatureLookup` calls.
- B. Feature Engineering does not infer a DataFrame or schema from notebook context; `create_table` needs an explicit `df` or `schema` argument to know the table's structure, so this call would fail rather than silently infer it.
- C. A plain `saveAsTable` call produces an ordinary Delta table that Feature Engineering does not recognize as a feature table; it must be registered through `create_table` to be usable with `FeatureLookup` or `create_training_set`.
- D. `write_table` upserts into an already-registered feature table and does not implicitly create one; calling it before `create_table` on a nonexistent table does not produce a usable feature table.
Sources1
3.On-demand features with FeatureFunction
Some feature values cannot be precomputed because they depend on inputs that arrive with the request. Databricks computes these on-demand features at inference time with Python UDFs registered in Unity Catalog. This needs a Unity Catalog workspace and Databricks Runtime 13.3 LTS ML or above. You can create the UDF with DatabricksFunctionClient.create_python_function or with SQL CREATE FUNCTION ... LANGUAGE PYTHON. During training, you pass a FeatureFunction in feature_lookups. Its input_bindings map the UDF's parameters to columns, which can be request inputs or values looked up by a FeatureLookup.
Consistency between training and serving depends on how you log the model. Log it with the Feature Engineering client's log_model, passing the training_set. The packaged model then evaluates the same UDF in both places: score_batch computes on-demand features for batch scoring, and Model Serving runs the UDF on every scoring request.
Checkpoint 4 of 6· Fill the gap
Which method packages the model so on-demand features are evaluated automatically at inference?
import mlflow
mlflow.set_registry_uri("databricks-uc")
fe. ? (
model=model,
artifact_path="main.default.model",
flavor=mlflow.sklearn,
training_set=training_set,
registered_model_name="main.default.recommender_model"
)fe.log_model stores the feature metadata, including the FeatureFunction, alongside the model. Plain mlflow logging does not.
Source: docs.databricks.comTwo production details. First, a missing lookup key reaches the UDF differently in each environment: None under score_batch and float("nan") under online serving. A robust UDF checks for both. Second, any package the UDF imports must be listed in extra_pip_requirements when you log the model. The UDF's own ENVIRONMENT clause applies only to offline SQL execution.
Sources2
4.Serving features through a FeatureSpec endpoint
Models served on Model Serving look up and transform their features automatically. Feature Serving covers the other consumers: models deployed outside Databricks, RAG applications, or any application that needs features from Unity Catalog. It serves both precomputed and on-demand features through a single interface. The unit you serve is a FeatureSpec, a set of FeatureLookups and FeatureFunctions that is stored in Unity Catalog. Any table a FeatureSpec references must already be published to an online store.
features = [
# Lookup column `average_yearly_spend` and `country` from a table in UC by the input `user_id`.
FeatureLookup(
table_name="main.default.customer_profile",
lookup_key="user_id",
feature_names=["average_yearly_spend", "country"]
),
# Calculate a new feature called `spending_gap` - the difference between `ytd_spend` and `average_yearly_spend`.
FeatureFunction(
udf_name="main.default.difference",
output_name="spending_gap",
# Bind the function parameter with input from other features or from request.
# The function calculates num_1 - num_2.
input_bindings={"num_1": "ytd_spend", "num_2": "average_yearly_spend"},
),
]You register the list with fe.create_feature_spec(name=..., features=features). If a UDF imports packages, add extra_pip_requirements to the spec (databricks-feature-engineering 0.17.0 or above). This covers UDFs in upstream features too. default_values on a FeatureLookup fills in values for missing keys, and if you renamed outputs with rename_outputs, the defaults must use the new names. Once the spec exists, you can create the endpoint through the UI, the REST API, fe.create_feature_serving_endpoint, or the Databricks SDK. The SDK route requires databricks-sdk 0.18.0 or above.
workspace = WorkspaceClient()
# Create endpoint
workspace.serving_endpoints.create(
name="my-serving-endpoint",
config = EndpointCoreConfigInput(
served_entities=[
ServedEntityInput(
entity_name="main.default.customer_features",
scale_to_zero_enabled=True,
workload_size="Small"
)
]
)
)Checkpoint 5 of 6· Check yourself
A FeatureSpec's UDF imports NumPy, and the UDF was created with NumPy in its ENVIRONMENT clause. The Feature Serving endpoint fails to deploy. What is the fix?
The ENVIRONMENT clause only covers offline SQL execution. Feature Serving installs only the packages declared on the FeatureSpec, plus MLflow and databricks-feature-lookup.
“Declare every package needed by the UDFs, including UDFs in upstream features, in the feature spec's requirements.”Source: docs.databricks.com
Checkpoint 6 of 6· Exam question
A retail team wants nightly refreshed features without a data engineer manually rerunning a notebook. They already have a Delta table with primary keys registered via `FeatureEngineeringClient.create_table`. What should they do to automate ongoing feature computation?
Correct answer: A — Schedule a Lakeflow Job that runs the feature-computation notebook nightly and calls `fe.write_table(df=updated_features, name=table_name, mode="merge")` to upsert new rows into the table.
- A. A scheduled job that calls `write_table` with `mode="merge"` is the standard pattern for automated, repeatable feature computation: the job runs on a fixed cadence and upserts fresh rows without any manual step.
- B. `delta.autoOptimize.autoCompact` controls file compaction for storage efficiency and has nothing to do with scheduling feature recomputation; it does not trigger any recomputation of feature values.
- C. Broad write privileges reintroduce the manual, unreliable process the team is trying to eliminate, since it still depends on a person remembering to run something rather than an automated schedule.
- D. `cloudFiles.schemaEvolutionMode` is an Auto Loader ingestion setting for handling changing source schemas; it does not compute or refresh feature values and is unrelated to scheduling a recurring pipeline.
Sources3
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Change Data Feed is only needed for CONTINUOUS publishing, because TRIGGERED is just a scheduled batch copy.Why is that wrong?
TRIGGERED and CONTINUOUS both need CDF on the source table. Only SNAPSHOT, a full one-time copy, does not.
Covered in Publishing feature tables and managing online tables
2.DROP TABLE on the online table cleans it up completely.Why is that wrong?
DROP TABLE leaves the data in database storage. Use w.feature_store.delete_online_table from the Databricks SDK instead.
Covered in Publishing feature tables and managing online tables
3.A UDF's ENVIRONMENT clause makes its dependencies available wherever the on-demand feature runs.Why is that wrong?
The clause applies to offline SQL only. For models, declare dependencies with extra_pip_requirements in log_model; for Feature Serving, declare them on the FeatureSpec.
Covered in On-demand features with FeatureFunction
Practise it for real
Stand up an online store, publish a feature table to it, and tear it down cleanly
1.Run %pip install databricks-feature-engineering>=0.13.0 and dbutils.library.restartPython() on DBR 16.4 LTS ML or serverless, then call fe.create_online_store(name="my-online-store", capacity="CU_1")
Why: Online stores require this runtime and client version
You should see: fe.get_online_store(name="my-online-store") eventually reports state AVAILABLE
2.Run ALTER TABLE ... SET TBLPROPERTIES ('delta.enableChangeDataFeed' = 'true') and ALTER COLUMN <pk> SET NOT NULL on your feature table
Why: The default TRIGGERED publish mode needs CDF and non-nullable primary keys
You should see: Both statements succeed without errors
3.Call fe.publish_table with the store, source_table_name and online_table_name, leaving publish_mode at its default
Why: This creates the online table, syncs it, and sets up incremental sync
You should see: The returned object includes a pipeline id that you can schedule for later updates
4.Call WorkspaceClient().feature_store.delete_online_table(online_table_name=...), then delete the store
Why: This is the only method that removes the table from both Unity Catalog and the database, and deleting the store stops costs
You should see: The online table no longer appears in Catalog Explorer
Stuck? Get a nudge
If publish fails, check CDF and primary-key nullability on the source table first.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Online Feature Stores provide low-latency access to feature data at a high scale while maintaining consistency with your offline feature tables”
↩︎ Provisioning an online feature store“To manage costs, delete online stores when not in use for development and testing.”
↩︎ Provisioning an online feature store“Non-nullable primary keys: Primary key columns cannot contain NULL values”
↩︎ Publishing feature tables and managing online tables“do not delete the table from underlying database storage”
↩︎ Publishing feature tables and managing online tables“Change Data Feed enabled: Required for the CONTINUOUS and TRIGGERED publish modes.”
↩︎ Exam trap 1“This is the only recommended method for deleting an online table.”
↩︎ Exam trap 2“Disabling high availability on an online store breaks connectivity for Feature Serving or Model Serving endpoints that read from the store.”
↩︎ Checkpoint“Only the latest feature values for each entity ID are available in the online store for real-time applications.”
↩︎ Prediction“Default. Incrementally updates the online table with changes from the offline table using the API or on a schedule.”
↩︎ Checkpoint - 2.
“Use them when feature values are not known ahead of time and depend on request-time inputs.”
↩︎ On-demand features with FeatureFunction“When you serve a model with Model Serving, the model automatically uses the Python UDF to compute on-demand features for each scoring request.”
↩︎ On-demand features with FeatureFunction“It does not copy those dependencies into the online serving environment.”
↩︎ Exam trap 3 - 3.https://docs.databricks.com/aws/en/machine-learning/feature-store/feature-function-servingOfficial docs
“Databricks Feature Serving provides a single interface that serves pre-materialized and on-demand features.”
↩︎ Serving features through a FeatureSpec endpoint“The tables specified in a FeatureSpec must be published to an online feature store or a third-party online store.”
↩︎ Serving features through a FeatureSpec endpoint“Declare every package needed by the UDFs, including UDFs in upstream features, in the feature spec's requirements.”
↩︎ Checkpoint