Migrer les workflows et les modèles vers Unity Catalog
Databricks recommande d'utiliser les modèles dans Unity Catalog pour une gouvernance améliorée, un partage facile entre les workspaces et les environnements, et des workflows MLOps plus flexibles. Cette page vous guide à travers la migration des modèles du Workspace Model Registry vers Unity Catalog.
Introduction aux modèles dans Unity Catalog
Models in Unity Catalog étend les avantages de Unity Catalog aux modèles ML, notamment le contrôle d'accès centralisé, l'audit, la traçabilité, ainsi que le partage et la découverte de modèles entre les workspaces. Les modèles dans Unity Catalog offrent également une plus grande flexibilité dans la gestion du cycle de vie des modèles.
Lorsque vous migrez des modèles vers Unity Catalog, certaines étapes du cycle de vie des modèles sont effectuées différemment :
- Les autorisations du Workspace Model Registry sont remplacées par les autorisations Unity Catalog au niveau du compte. Consultez l'Étape 2. Attribuez les autorisations Unity Catalog au modèle.
- Les étapes sont remplacées par des alias et des tags personnalisés. Au lieu de quatre étapes fixes, vous pouvez créer jusqu'à 10 alias personnalisés et réaffectables. Vous pouvez également définir des tags pour étiqueter les modèles. Consultez l'étape 4. Migrer les métadonnées du modèle.
- Les Jobs de déploiement sont utilisés pour faire passer les modèles à travers leur cycle de vie. Voir Étape 6. (Facultatif) Créer un Job de déploiement.
Étape 1. Créez un modèle dans Unity Catalog
Voir Entraîner et enregistrer des modèles compatibles avec Unity Catalog.
Étape 2. Attribuez les autorisations Unity Catalog au modèle
Unity Catalog dispose d'un modèle d'autorisations unifié. Pour savoir comment attribuer des autorisations aux modèles dans Unity Catalog, consultez Contrôler l'accès aux modèles.
Le tableau suivant montre la relation entre les autorisations dans le registre de modèle du Workspace et les privilèges dans Unity Catalog. En plus des privilèges affichés dans le tableau, toutes les actions nécessitent également les privilèges USE CATALOG et USE SCHEMA.
Registre de modèles du Workspace | Unity Catalog | Notes |
|---|---|---|
Peut lire | EXÉCUTER | |
Modification autorisée | CRÉER UNE VERSION DE MODÈLE + APPLIQUER UNE ÉTIQUETTE | Les utilisateurs disposant de ces privilèges ne peuvent pas modifier la description des modèles ou des versions de modèle. |
Peut gérer les versions intermédiaires | APPLIQUER UN TAG + job de déploiement | Dans Unity Catalog, les Jobs de déploiement sont utilisés pour contrôler le mouvement des versions de modèle à travers les étapes du cycle de vie. Pour plus de détails, consultez les Jobs de déploiement MLflow 3. |
Peut gérer les versions de production | APPLIQUER UN TAG + job de déploiement | Dans Unity Catalog, les Jobs de déploiement sont utilisés pour contrôler le mouvement des versions de modèle à travers les étapes du cycle de vie. Pour plus de détails, consultez les Jobs de déploiement MLflow 3. |
Gestion autorisée | Gérer |
Étape 3. Copier les versions du modèle
Pour copier les versions du modèle, utilisez copy_model_version() avec le client MLflow >= 3.4.0.
import mlflow
from mlflow import MlflowClient
# Registry must be set to workspace registry
mlflow.set_registry_uri("databricks")
client = MlflowClient(registry_uri="databricks")
src_model_uri = f"models:/my_wmr_model/1"
uc_migrated_copy = client.copy_model_version(
src_model_uri, "mycatalog.myschema.my_uc_model"
)
Si le modèle de destination n'existe pas dans Unity Catalog, il est créé par cet appel d'API.
Les modèles dans Unity Catalog nécessitent une signature. Si la version du modèle du workspace n'a pas de signature, Databricks vous recommande d'en créer une en suivant les instructions de la documentation MLflow. Une autre alternative consiste à utiliser la variable d'environnement MLFLOW_SKIP_SIGNATURE_CHECK_FOR_UC_REGISTRY_MIGRATION. Cette variable d’environnement est disponible uniquement lorsque vous utilisez copy_model_version() et requiert MLflow version 3.4.0 ou une version ultérieure. Lorsque cette variable d’environnement est définie sur "true", une signature n’est pas requise.
Pour un script que vous pouvez utiliser afin de migrer toutes les versions de modèle d'un modèle de votre Workspace Model Registry vers un modèle Unity Catalog de destination, consultez Migrer les versions de modèle du Workspace Model Registry vers Unity Catalog.
Étape 4. Migrez les métadonnées du modèle
Cette section décrit comment mapper les métadonnées de niveau registre du Workspace aux métadonnées de modèle et de version de modèle Unity Catalog, telles que les étapes, les balises et les descriptions.
Étapes
Le Workspace Model Registry utilisait le concept de « stages », tels que Staging et Production, pour assurer le suivi du cycle de vie des modèles. Vous pourriez rechercher ou appeler des modèles par stade. Dans Unity Catalog, les étapes ont été remplacées par des alias pour appeler un modèle et par des tags pour étiqueter les modèles.
Pour une migration simple des étapes de Workspace Model Registry, vous pouvez utiliser directement « Production » et « Staging » ou tout autre nom d'alias que vous préférez. Dans le Workspace Model Registry, plusieurs versions de modèle pouvaient se trouver au même stade, et la dernière version était appelée lorsque vous faisiez référence à une version de modèle. Dans Unity Catalog, un alias est attribué à une version de modèle unique.
Pour une migration simple des étiquettes d'étape, utilisez des tags pour étiqueter les versions de modèle comme "Production", "Staging" ou "Archived". Vous pouvez également utiliser toute autre étiquette. Pour plus d’informations sur les tags, consultez Tags.
Dans le Workspace Model Registry, le cycle de vie d'une version de modèle était suivi par étape, et une approbation humaine était requise pour une demande de transition. Dans Unity Catalog, le cycle de vie d'une version de modèle est géré par un job de déploiement. Chaque tâche du job de déploiement correspond à une « étape ». Les jobs de déploiement vous permettent de personnaliser le cycle de vie du modèle et de prendre en charge des workflows plus complexes que le Workspace Model Registry. Les jobs de déploiement permettent toujours les approbations humaines. Pour plus de détails, consultez les Jobs de déploiement MLflow 3.
Tags
Dans Unity Catalog, vous créez des balises sur le modèle ou la version du modèle.
Pour rechercher un modèle par tag dans Catalog Explorer, saisissez la clé ou la valeur dans le champ de recherche :
Dans l'Explorateur de catalogues, vous pouvez utiliser les tags uniquement pour rechercher des modèles, et non les versions de modèles. Le client MLflow ne prend pas en charge la recherche de modèles par tags Unity Catalog. Unity Catalog autorise un maximum de 50 tags par objet.
Description et commentaires
Vous pouvez ajouter des descriptions au modèle et à la version du modèle. Unity Catalog offre également la possibilité d'une description du modèle générée par l'IA.
Les modèles dans Unity Catalog n'ont pas d'emplacement correspondant pour les informations affichées dans la section Activités sur la page de version du modèle dans le registre de modèles du Workspace. S'il y a des informations dans cette section que vous souhaitez transférer avec la version du modèle, copiez-les dans la section **Description** de la page de la version du modèle dans Unity Catalog.
Étape 5. Mettre à jour toutes les charges de travail et tous les Endpoint
Après avoir migré les modèles et les versions de modèles vers Unity Catalog, mettez à jour tous les Jobs, Notebooks et autres charges de travail, y compris les Endpoints de diffusion de modèles, afin d’utiliser les versions d’Unity Catalog.
Étape 6. (Facultatif) Créer un Job de déploiement
Un Job de déploiement Trigger automatiquement chaque fois qu’une nouvelle version du modèle est créée et automatise le workflow d’évaluation, d’approbation et de déploiement. Pour plus de détails, consultez les Jobs de déploiement MLflow 3.
Vous pouvez définir des notifications à Trigger lors d'événements tels que la création ou l'approbation d'une version de modèle. Voir Ajouter des notifications à un job.
Si vous aviez configuré des notifications par e-mail pour des événements dans le Workspace Model Registry, migrez-les comme suit :
- Une nouvelle version du modèle a été créée : Configurez un Job de déploiement qui est Trigger lorsqu'une nouvelle version du modèle est créée, et une notification par e-mail lorsque le Job est Trigger.
- Demande de transition d’étape : les demandes de transition d’étape correspondent à des tâches d’approbation. Définissez une notification par e-mail pour le succès ou l’échec de la tâche d’approbation.
- Transitions de stade : les transitions de stade correspondent aux tâches de Job. Définissez une notification par e-mail pour la réussite ou l’échec de la tâche.
- Nouveaux commentaires : Les commentaires ne sont pas pris en charge dans Unity Catalog.
Si vous aviez des webhooks configurés pour les événements, vous pouvez les implémenter dans Unity Catalog en tant que Trigger de Job d'événement de modèle. Les triggers de modèle vous permettent d'automatiser les Lakeflow Jobs en fonction de la création de nouveaux modèles, de versions de modèle ou d'alias de modèle dans Unity Catalog. Les Trigger de modèle sont en aperçu privé. Contactez votre représentant Databricks pour plus d'informations.
Ressources supplémentaires
Les pages ci-dessous décrivent comment migrer les workflows (entraînements de modèles et Jobs d'inférence par batch) du Workspace Model Registry vers Unity Catalog.