Apache Spark MLlib et suivi MLflow automatisé

important

Cette documentation a été retirée et pourrait 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é de MLlib est déprécié sur les clusters qui exécutent Databricks Runtime 13.1 ML et versions supérieures, et il est désactivé par default sur les clusters exécutant Databricks Runtime 10.2 ML et versions supérieures. Utilisez plutôt le log automatique MLflow PySpark ML en appelant mlflow.pyspark.ml.autolog(), qui est activé par default avec Databricks Autologging.

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

MLflow est une plateforme open source pour la gestion du cycle de vie de bout en bout du machine learning. MLflow prend en charge le suivi du réglage des modèles de machine learning en Python, R et Scala. Pour les notebooks Python uniquement, lesversions et la compatibilité des notes de version de Databricks Runtime et Databricks Runtime for Machine Learning prennent en charge le MLflow Tracking *automatisé* pour le réglage de modèles Apache Spark MLlib.

Avec le suivi MLflow automatisé de MLlib, lorsque vous exécutez du code de réglage qui utilise CrossValidator ou TrainValidationSplit, les hyperparamètres et les métriques d'évaluation sont automatiquement consignés dans MLflow. Sans suivi MLflow automatisé, vous devez effectuer des appels d’API explicites pour consigner dans MLflow.

Gérer les exécutions MLflow

CrossValidator ou TrainValidationSplit enregistrer les résultats d'optimisation sous forme d'exécutions MLflow imbriquées :

• Exécution principale ou parente : les informations pour CrossValidator ou TrainValidationSplit sont journalisées dans l’exécution principale. S’il existe déjà une exécution active, les informations sont enregistrées dans cette exécution 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 consigne des logs et termine l'exécution avant de retourner.
• Exécutions enfants : chaque paramètre d'hyperparamètre testé et la métrique d'évaluation correspondante sont enregistrés dans une exécution enfant sous l'exécution principale.

Lors de l'appel de fit(), Databricks recommande une gestion active des exécutions MLflow ; c'est-à-dire d'encapsuler l'appel à fit() dans une instruction « with mlflow.start_run(): ». Cela garantit que les informations sont enregistrées sous sa propre exécution MLflow principale, et facilite l'enregistrement de tags, de paramètres ou de métriques supplémentaires pour cette exécution.

remarque

Lorsque fit() est appelé plusieurs fois dans le même run MLflow actif, il enregistre ces multiples runs dans le même run principal. Pour résoudre les conflits de noms pour les parameters et les tags MLflow, MLflow ajoute un UUID aux noms en conflit.

Le Notebook Python suivant présente le suivi MLflow automatisé.

Notebook de suivi MLflow automatisé

Ouvrir le notebook dans un nouvel ongletOuvrir dans Databricks

Une fois que vous avez effectué les actions dans la dernière cellule du notebook, votre interface utilisateur MLflow devrait afficher :