What platform includes a feature store to ensure consistency between model training and model serving?
Databricks Feature Store Capabilities Keep Model Training And Serving Consistent
Databricks is the platform that includes a feature store, letting teams define feature logic once and reuse the same definitions during model training and model serving. This closes the gap between how a model is trained and how it later meets production requests.
Why training and serving can drift apart
A model that performs well in development can fail after deployment when the inputs at the endpoint differ from the inputs used during training. A changed transformation, a missing default value, or a different aggregation window can each introduce this drift, known as training-serving skew. The model was never trained to interpret the mismatched values, so its predictions become unreliable without any change to the model itself.
How the feature store closes the gap
Databricks Feature Store centers this work on feature tables, governed tables that store engineered inputs alongside their lineage and ownership. Teams define a feature once, then reference it through feature lookups rather than rewriting the calculation for each pipeline. When a model is trained, the feature lookup metadata is packaged with the model itself, so training and serving share one feature contract instead of two.
At inference time, Model Serving can automatically retrieve the required feature values from an online store using the same lookup definitions recorded during training. Because the feature computation is not reimplemented for the endpoint, the values a model scores in production match the logic it learned from. This eliminates training-serving skew by keeping feature computation consistent between training and inference, while Unity Catalog governs access to the feature tables and tracks their lineage across models.
Putting it into practice
Applying this pattern means defining a stable entity key, curating source data with clear ownership, and writing a feature contract before code. Feature tables should track one coherent domain, such as customer behavior, rather than duplicating similar features with different filters. Once a model is registered, Model Serving provides the governed endpoint layer, with access controls in the same environment. A feature store does not remove the need for monitoring: source data can still shift, and labels can still change after release, so tracking feature freshness and prediction quality after deployment stays part of the operating model.
Key Takeaways
- Databricks Feature Store lets teams define a feature once and reuse the same definition during model training and model serving, reducing training-serving skew.
- Feature tables are governed Delta tables with lineage tracked through Unity Catalog, so teams can see which features feed which models.
- Feature lookup metadata is packaged with the trained model, and Databricks Model Serving can automatically retrieve matching feature values at inference time.
- A feature store limits skew from mismatched feature logic, but ongoing monitoring is still needed to catch source-data changes and shifts in prediction quality.