Databricks supports sharing feature tables across multiple workspaces. For example, from your own workspace, you can create, write to, or read from a feature table in a centralized feature store. This is useful when multiple teams share access to feature tables or when your organization has multiple workspaces to handle different stages of development.
For a centralized feature store, Databricks recommends that you designate a single workspace to store all feature store metadata, and create accounts for each user who needs access to the feature store.
If your teams are also sharing models across workspaces, you may choose to dedicate the same centralized workspace for both feature tables and models, or you could specify different centralized workspaces for each.
Access to the centralized feature store is controlled by tokens. Each user or script that needs access creates a personal access token in the centralized feature store and copies that token into the secret manager of their local workspace. Each API request sent to the centralized feature store workspace must include the access token; the Feature Store client provides a simple mechanism to specify the secrets to be used when performing cross-workspace operations.
As a security best practice, when authenticating with automated tools, systems, scripts, and apps, Databricks recommends you use access tokens belonging to service principals instead of workspace users. For more information, see Service principals for Databricks automation.
Using a feature store across workspaces requires:
In the feature store workspace, create an access token.
In the local workspace, create secrets to store the access token and the remote workspace information:
Create a secret scope:
databricks secrets create-scope --scope <scope>.
Pick a unique name for the target workspace, shown here as
<prefix>. Then create three secrets with the specified key names:
databricks secrets put --scope <scope> --key <prefix>-host: Enter the hostname of the feature store workspace. For example,
databricks secrets put --scope <scope> --key <prefix>-token: Enter the access token from the feature store workspace.
databricks secrets put --scope <scope> --key <prefix>-workspace-id: Enter the workspace ID for the feature store workspace which can be found in the URL of any page.
You may want to share the secret scope with other users, since there is a limit on the number of secret scopes per workspace.
Based on the secret scope and name prefix you created for the remote feature store workspace, you can construct a feature store URI of the form:
feature_store_uri = f'databricks://<scope>:<prefix>'
Then, specify the URI explicitly when you instantiate a
fs = FeatureStoreClient(feature_store_uri=feature_store_uri)
Before you create feature tables in the remote feature store, you must create a database to store them. The database must exist in the shared DBFS location.
For example, to create a database
recommender in the shared location
/mnt/shared, use the following command:
%sql CREATE DATABASE IF NOT EXISTS recommender LOCATION '/mnt/shared'
The API to create a feature table in a remote feature store depends on the Databricks runtime version you are using.
fs = FeatureStoreClient(feature_store_uri=f'databricks://<scope>:<prefix>') fs.create_table( name='recommender.customer_features', primary_keys='customer_id', schema=customer_features_df.schema, description='Customer-keyed features' )
fs = FeatureStoreClient(feature_store_uri=f'databricks://<scope>:<prefix>') fs.create_feature_table( name='recommender.customer_features', keys='customer_id', schema=customer_features_df.schema, description='Customer-keyed features' )
For examples of other Feature Store methods, see Example notebook.
You can read a feature table in the remote feature store with the
FeatureStoreClient.read_table method by first setting the
fs = FeatureStoreClient(feature_store_uri=f'databricks://<scope>:<prefix>') customer_features_df = fs.read_table( name='recommender.customer_features', )
Other helper methods for accessing the feature table are also supported:
fs.read_table() fs.get_feature_table() # in Databricks Runtime 10.1 ML and below fs.get_table() # in Databricks Runtime 10.2 ML and above fs.write_table() fs.publish_table() fs.create_training_set()
In addition to specifying a remote feature store URI, you may also specify a remote model registry URI to share models across workspaces.
To specify a remote model registry for model logging or scoring, you can use a model registry URI to instantiate a FeatureStoreClient.
fs = FeatureStoreClient(model_registry_uri=f'databricks://<scope>:<prefix>') customer_features_df = fs.log_model( model, "recommendation_model", flavor=mlflow.sklearn, training_set=training_set, registered_model_name="recommendation_model" )
model_registry_uri, you can train a model using any local or remote feature table, and then register the model in any local or remote model registry.
fs = FeatureStoreClient( feature_store_uri=f'databricks://<scope>:<prefix>', model_registry_uri=f'databricks://<scope>:<prefix>' )