Apache Spark MLlib et suivi MLflow automatisé

Important

Cette documentation a été mise hors service et peut ne pas être mise à jour. Les produits, services ou technologies mentionnés dans ce contenu ne sont plus pris en charge.

Remarque

Le suivi MLflow automatisé MLlib est déconseillé sur les clusters qui exécutent Databricks Runtime 10.1 ML et versions ultérieures, et il est désactivé par défaut sur les clusters exécutant Databricks Runtime 10.2 ML et versions ultérieures. Utilisez plutôt MLflow PySpark ML autologging en appelant mlflow.pyspark.ml.autolog(), qui est activé par défaut avec Databricks Autologging.

Pour utiliser l'ancien suivi MLlib automatisé MLflow dans Databricks Runtime 10.2 ML ou supérieur, activez-le en définissant les configurations Sparkspark.databricks.mlflow.trackMLlib.enabled true et spark.databricks.mlflow.autologging.enabled false.

MLflow est une plateforme open source qui permet de gérer le cycle de vie du machine learning de bout en bout. MLflow prend en charge le suivi pour Machine Learning le paramétrage du modèle dans Python, R et Scala. Pour les notebooks Python uniquement, les Notes de publication sur les versions et la compatibilité de Databricks Runtime et Databricks Runtime pour le Machine Learning prennent en charge le suivi automatisé de MLflow pour le réglage des modèles Apache Spark MLlib.

Avec le suivi MLflow automatisé MLlib, lorsque vous exécutez le code de paramétrage qui utilise CrossValidator ou TrainValidationSplit , les hyperparamètres et les métriques d’évaluation sont automatiquement enregistrés dans MLflow. Sans le suivi de MLflow automatisé, vous devez effectuer des appels d’API explicites pour la connexion à MLflow.

Gérer les exécutions de MLflow

CrossValidator ou TrainValidationSplit les résultats du paramétrage des journaux en tant qu’exécutions MLflow imbriquées :

• Exécution principale ou parente : les informations pour CrossValidator ou TrainValidationSplit sont enregistrées dans la série de tests principale. Si une exécution active existe déjà, les informations sont consignées dans cette série active et l’exécution active n’est pas arrêtée. S’il n’y a pas d’exécution active, MLflow crée une nouvelle exécution, y enregistre des journaux et met fin à l’exécution avant de retourner.
• Exécutions enfants : chaque paramètre d’hyperparamètre testé et la mesure d’évaluation correspondante sont journalisés dans une exécution enfant sous l’exécution principale.

Lors de l’appel de fit(), Azure Databricks recommande la gestion active MLflow Run, c’est-à-dire encapsuler l’appel à fit() l’intérieur d’une instruction « with mlflow.start_run(): ». Cela permet de s’assurer que les informations sont consignées dans le cadre de leur propre exécution principale MLflow, et de faciliter la journalisation des balises, des paramètres ou des métriques supplémentaires sur cette exécution.

Notes

Lorsque fit() est appelé plusieurs fois au cours de la même exécution de MLflow active, il journalise ces exécutions multiples dans la même exécution principale. Pour résoudre les conflits de noms pour les balises et les paramètres MLflow, MLflow ajoute un UUID aux noms avec conflits.

Le Notebook python suivant montre le suivi MLflow automatisé.

Carnet de suivi automatisé de MLflow

Obtenir le notebook

Une fois que vous avez effectué les actions dans la dernière cellule du bloc-notes, votre interface utilisateur MLflow doit afficher :