Migrer les traces d'expérimentation vers Unity Catalog
Databricks recommande de stocker les traces dans les tables Unity Catalog Delta. Si vous avez des traces existantes stockées dans une Experimentation MLflow, leur migration vers Unity Catalog est le chemin recommandé : cela supprime les limites de stockage des traces, fournit des contrôles d'accès précis grâce à la gouvernance Unity Catalog, et rend les traces interrogeables depuis les Notebooks, SQL, Genie, les tableaux de bord AI/BI et tout outil basé sur Spark.
La migration copie les traces, les étendues, les évaluations, les étiquettes et les métadonnées de l'expérimentation source vers les tables Unity Catalog. L'expérimentation source n'est pas modifiée.
Si vous partez de zéro et n'avez pas de traces existantes à migrer, consultez Enregistrer des traces dans Unity Catalog pour configurer une nouvelle expérimentation afin d'écrire des traces directement dans Unity Catalog.
La migration ne copie pas les traces archivées ou supprimées, les enregistrements de datasets, les sessions d'étiquetage, les exécutions ou les entités non liées aux traces.
Prérequis
-
Un Workspace compatible avec Unity Catalog.
-
Un cluster Databricks exécutant Databricks Runtime 15.3 ou une version ultérieure.
-
Le package Python
databricks-agents:Bashpip install "databricks-agents>=1.10.1" -
Les autorisations suivantes :
- Accès en lecture à l'expérimentation source.
USE_CATALOG,USE_SCHEMAetMODIFYsur le catalogue et le schéma de destination.
Étape 1 : Créer une Experimentation de destination
La destination est une nouvelle expérimentation MLflow liée à un emplacement de trace Unity Catalog.
L'emplacement de la trace est un chemin en trois parties (catalog.schema.table_prefix). Le préfixe de table est appliqué aux quatre tables Delta qui sous-tendent l'expérimentation :
<prefix>_otel_spans<prefix>_otel_annotations<prefix>_otel_logs<prefix>_otel_metrics
Exécutez ce qui suit pour créer l'expérience de destination. Pour tous les détails de configuration, consultez Configuration : Créer une Experimentation avec un emplacement de trace Unity Catalog.
import mlflow
from mlflow.entities.trace_location import UnityCatalog
experiment = mlflow.set_experiment(
experiment_name="/Workspace/Users/<user>/<experiment_name>",
trace_location=UnityCatalog(
catalog_name="<destination_catalog>",
schema_name="<destination_schema>",
table_prefix="<table_prefix>",
),
)
print(f"Destination experiment ID: {experiment.experiment_id}")
Enregistrez l'ID d'Experimentation imprimé par le code ci-dessus. Vous l'utilisez dans les deux étapes suivantes : dans l'étape 2 pour pointer vos notebooks, Jobs et modèles déployés vers la nouvelle Experimentation basée sur Unity Catalog, et dans l'étape 3 comme ID d'Experimentation de destination pour la commande de migration.
Vous pouvez ingérer quelques traces de test dans la nouvelle expérimentation pour vérifier que le traçage Unity Catalog fonctionne pour votre workflow avant de continuer. Consultez Logs traces dans les tables Unity Catalog pour des exemples.
Étape 2 : Basculez la journalisation des traces et arrêtez les écritures vers l'expérimentation source.
Avant d’exécuter la migration, redirigez la journalisation de trace vers l’Experimentation de destination créée à l’étape 1 et arrêtez les écritures vers l’Experimentation source. Cela garantit que de nouvelles traces sont écrites dans les tables de destination et qu'aucune trace n'est perdue pendant l'exécution de la migration.
-
Arrêter toutes les écritures vers l'expérience source. Toute trace écrite dans l'expérience source pendant la migration pourrait ne pas être copiée. Vérifiez qu'aucun notebook, job ou modèle déployé n'enregistre activement dans l'expérience source.
-
Remplacez tout appel
set_experimentexistant qui pointe vers l'expérimentation source par un appel qui pointe vers l'expérimentation de destination, soit par nom, soit par ID :Pythonimport mlflow
# By experiment name
mlflow.set_experiment(
experiment_name="/Workspace/Users/<user>/<destination_experiment_name>",
)
# Or by experiment ID
mlflow.set_experiment(experiment_id="<destination_experiment_id>")
L'emplacement de la trace peut également être configuré par d'autres mécanismes, tels que les variables d'environnement MLFLOW_EXPERIMENT_NAME et MLFLOW_EXPERIMENT_ID, qui sont utilisées par les applications déployées, les services conteneurisés, les configurations des Endpoint de diffusion de modèles et les configurations d'IDE ou de développement local. Pour plus de détails sur la configuration des destinations de traces en production, consultez Traces des agents déployés sur Databricks et Traces des agents déployés en dehors de Databricks.
Étape 3 : Exécuter la migration
Dans un notebook Databricks sur le cluster, exécutez les éléments suivants :
from databricks.migrations.migrate_traces_to_uc import run
run(
source_experiment_id="<source_experiment_id>",
target_experiment_id="<destination_experiment_id>",
)
Remplacez les espaces réservés :
<source_experiment_id>: L'ID d'expérimentation de votre experimentation existante qui contient les traces que vous souhaitez migrer.<destination_experiment_id>: L'ID d'Experimentation de l'Experimentation prise en charge par Unity Catalog, créée à l'étape 1.
La migration est idempotente. S'il est interrompu (par exemple, en raison d'un délai d'expiration du cluster), vous pouvez réexécuter la même commande en toute sécurité. La migration reprend automatiquement là où elle s'est arrêtée. Les lignes déjà migrées sont ignorées.
Pour migrer uniquement les traces créées après une heure spécifique, transmettez le paramètre start_time_ms (millisecondes d'époque). La migration ingérera toutes les traces dont l’heure de la requête est égale ou postérieure au timestamp spécifié, en ignorant celles qui ont déjà été migrées.
import time
from databricks.migrations.migrate_traces_to_uc import run
one_week_ago_ms = int((time.time() - 7 * 24 * 60 * 60) * 1000)
run(
source_experiment_id="<source_experiment_id>",
target_experiment_id="<destination_experiment_id>",
start_time_ms=one_week_ago_ms, # Only migrate traces from the last 7 days
)
Une fois la migration terminée, vos traces sont disponibles dans la nouvelle Experimentation de destination. L'expérimentation source n'est pas modifiée par la migration et peut être conservée comme sauvegarde.