Partager des tables de caractéristiques entre espaces de travail (hérité)

Important

• Cette documentation a été mise hors service et peut ne pas être mise à jour.
• Databricks vous recommande d’utiliser l’ingénierie de caractéristiques dans Unity Catalog pour partager des tables de fonctionnalités entre les espaces de travail. L'approche décrite dans cet article est obsolète.

Azure Databricks prend en charge le partage de tables de caractéristiques entre plusieurs espaces de travail. Par exemple, à partir de votre propre espace de travail, vous pouvez créer une table de caractéristiques dans un magasin de caractéristiques centralisé et y effectuer des opérations d’écriture et de lecture. Cela est utile quand plusieurs équipes partagent l’accès aux tables de caractéristiques ou que votre organisation dispose de plusieurs espaces de travail pour gérer différentes phases de développement.

Pour un magasin de caractéristiques centralisé, Databricks recommande de désigner un espace de travail unique pour le stockage de toutes les métadonnées du magasin de caractéristiques et de créer des comptes pour chaque utilisateur qui a besoin d’accéder au magasin de caractéristiques.

Si vos équipes partagent également des modèles entre les espaces de travail, vous pouvez choisir de dédier le même espace de travail centralisé pour les modèles et les tables de caractéristiques, ou vous pouvez spécifier différents espaces de travail centralisés pour chacun.

L’accès au magasin de caractéristiques centralisé est contrôlé par des jetons. Chaque utilisateur ou script nécessitant un accès crée un jeton d’accès personnel dans le magasin de caractéristiques centralisé et copie ce jeton dans le gestionnaire de secret de son espace de travail local. Chaque demande d’API envoyée à l’espace de travail du magasin de caractéristiques centralisé doit inclure le jeton d’accès. Le client du magasin de caractéristiques fournit un mécanisme simple pour spécifier les secrets à utiliser lors de l’exécution d’opérations inter-espaces de travail.

Notes

En guise de bonne pratique de sécurité, quand vous vous authentifiez avec des outils, systèmes, scripts et applications automatisés, Databricks recommande d’utiliser des jetons d’accès personnels appartenant à des principaux de service et non des utilisateurs de l’espace de travail. Si vous souhaitez créer des jetons d’accès pour des principaux de service, consultez la section Gérer les jetons d’accès personnels pour un principal de service.

Spécifications

L’utilisation d’un magasin de caractéristiques entre des espaces de travail nécessite :

• Client du Magasin de fonctionnalités v0.3.6 et versions ultérieures.
• Les deux espaces de travail doivent avoir accès aux données de caractéristiques brutes. Ils doivent partager le même metastore Hive externe et avoir accès au même stockage DBFS.
• Si les listes d’accès IP sont activées, les adresses IP des espaces de travail doivent se trouver sur les listes d’accès.

Configurer le jeton d’API pour un registre distant

Dans cette section, « Espace de travail B » fait référence à l’espace de travail du magasin de caractéristiques centralisé ou distant.

1. Dans l’espace de travail B, créez un jeton d’accès.
2. Dans l’espace de travail local, créez des secrets pour stocker le jeton d’accès et les informations relatives à l’espace de travail B :
   1. Créez une étendue de secrets : databricks secrets create-scope --scope <scope>.
   2. Sélectionnez un identificateur unique pour l’espace de travail B, illustré ici sous la forme <prefix>. Ensuite, créez trois secrets avec les noms de clé spécifiés :

      • databricks secrets put --scope <scope> --key <prefix>-host : entrez le nom d’hôte de l’espace de travail B. Utilisez les commandes Python suivantes pour obtenir le nom d’hôte d’un espace de travail :

        import mlflow
        
        host_url = mlflow.utils.databricks_utils.get_webapp_url()
        host_url
        

      • databricks secrets put --scope <scope> --key <prefix>-token : entrez le jeton d’accès à partir de l’espace de travail B.

      • databricks secrets put --scope <scope> --key <prefix>-workspace-id : entrez l’ID d’espace de travail de l’espace de travail B qui se trouve dans l’URL de n’importe quelle page.

Notes

Vous pouvez partager l’étendue de secrets avec d’autres utilisateurs, car il existe une limite quant au nombre d’étendues de secrets par espace de travail.

Spécifier un magasin de caractéristiques distant

En fonction de l’étendue de secrets et du préfixe de nom que vous avez créés pour l’espace de travail du magasin de caractéristiques distant, vous pouvez construire un URI de magasin de caractéristiques sous la forme suivante :

feature_store_uri = f'databricks://<scope>:<prefix>'

Ensuite, spécifiez l’URI explicitement quand vous instanciez un FeatureStoreClient :

fs = FeatureStoreClient(feature_store_uri=feature_store_uri)

Créer une base de données pour les tables de caractéristiques dans l’emplacement DBFS partagé

Avant de créer des tables de fonctionnalités dans le magasin de fonctionnalités distant, vous devez créer une base de données pour les stocker. La base de données doit exister à l’emplacement de DBFS partagé.

Par exemple, pour créer une base de données recommender à l’emplacement partagé /mnt/shared, utilisez la commande suivante :

%sql CREATE DATABASE IF NOT EXISTS recommender LOCATION '/mnt/shared'

Créer une table de caractéristiques dans le magasin de caractéristiques distant

L’API permettant de créer une table de caractéristiques dans un magasin de caractéristiques distant dépend de la version du runtime Databricks que vous utilisez.

V0.3.6 et versions ultérieures

Utilisez l’API FeatureStoreClient.create_table :

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'
)

V0.3.5 et versions antérieures

Utilisez l’API FeatureStoreClient.create_feature_table :

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'
)

Pour obtenir des exemples d’autres méthodes du magasin de fonctionnalités, consultez Exemple de notebooks : Partager des tables de caractéristiques entre espaces de travail.

Utiliser une table de caractéristiques à partir du magasin de caractéristiques distant

Vous pouvez lire une table de caractéristiques dans le magasin de caractéristiques distant avec la méthode FeatureStoreClient.read_table en définissant d’abord le feature_store_uri :

fs = FeatureStoreClient(feature_store_uri=f'databricks://<scope>:<prefix>')
customer_features_df = fs.read_table(
  name='recommender.customer_features',
)

D’autres méthodes d’assistance pour accéder à la table de caractéristiques sont également prises en charge :

fs.read_table()
fs.get_feature_table() # in v0.3.5 and below
fs.get_table() # in v0.3.6 and above
fs.write_table()
fs.publish_table()
fs.create_training_set()

Utiliser un registre de modèles distant

Outre la spécification d’un URI de magasin de caractéristiques distant, vous pouvez spécifier un URI de registre de modèles distant pour partager des modèles entre les espaces de travail.

Pour spécifier un registre de modèles distant pour la journalisation ou le scoring de modèle, vous pouvez utiliser un URI de registre de modèles afin d’instancier un client de magasin de caractéristiques (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"
)

En utilisant feature_store_uri et model_registry_uri, vous pouvez entraîner un modèle avec une table de caractéristiques locale ou distante, puis enregistrer le modèle dans un registre de modèles local ou distant.

fs = FeatureStoreClient(
    feature_store_uri=f'databricks://<scope>:<prefix>',
    model_registry_uri=f'databricks://<scope>:<prefix>'
)

Exemple de notebook : partager des tables de fonctionnalités entre des espaces de travail

Le notebook suivant montre comment se servir d’un magasin de fonctionnalités centralisé.

Exemple de notebook de magasin de caractéristiques centralisé

Obtenir le notebook