Biblioteka MLlib platformy Apache Spark i zautomatyzowane śledzenie narzędzia MLflow

Ważne

Ta dokumentacja została wycofana i może nie zostać zaktualizowana. Produkty, usługi lub technologie wymienione w tej zawartości nie są już obsługiwane.

Uwaga

Zautomatyzowane śledzenie MLflow MLlib jest przestarzałe w klastrach z uruchomionym środowiskiem Databricks Runtime 10.1 ML lub nowszym i jest domyślnie wyłączone w klastrach z uruchomionym środowiskiem Databricks Runtime 10.2 ML i nowszym. Zamiast tego użyj automatycznego rejestrowania uczenia maszynowego MLflow PySpark, wywołując mlflow.pyspark.ml.autolog()funkcję , która jest domyślnie włączona w przypadku automatycznego rejestrowania usługi Databricks.

Aby użyć starego zautomatyzowanego śledzenia MLflow MLlib w środowisku Databricks Runtime 10.2 ML lub nowszym, włącz go, ustawiając konfiguracje platformy spark.databricks.mlflow.trackMLlib.enabled true Spark i spark.databricks.mlflow.autologging.enabled false.

MLflow to platforma typu „open source” umożliwiająca zarządzanie całym cyklem życia uczenia maszynowego. Rozwiązanie MLflow obsługuje śledzenie dostrajania modelu uczenia maszynowego w językach Python, R i Scala. Tylko w przypadku notesów języka Python wersje informacji o wersji środowiska Databricks Runtime oraz zgodność i środowisko Databricks Runtime dla uczenia maszynowego obsługują zautomatyzowane śledzenie MLflow dla dostrajania modelu MLlib platformy Apache Spark.

W przypadku zautomatyzowanego śledzenia MLflow MLlib podczas uruchamiania kodu dostrajania, który używa CrossValidator parametrów lub TrainValidationSplit, hiperparametrów i metryk oceny są automatycznie rejestrowane w MLflow. Bez zautomatyzowanego śledzenia MLflow należy wykonać jawne wywołania interfejsu API w celu zalogowania się do biblioteki MLflow.

Zarządzanie przebiegami MLflow

CrossValidator lub TrainValidationSplit wyniki dostrajania dzienników jako zagnieżdżone przebiegi MLflow:

• Uruchomienie główne lub nadrzędne: informacje dotyczące CrossValidator lub TrainValidationSplit są rejestrowane w głównym uruchomieniu. Jeśli istnieje już aktywny przebieg, informacje są rejestrowane w tym aktywnym przebiegu, a aktywne uruchomienie nie zostanie zatrzymane. Jeśli nie ma aktywnego przebiegu, narzędzie MLflow tworzy nowy przebieg, rejestruje je i kończy przebieg przed zwróceniem.
• Przebiegi podrzędne: każde przetestowane ustawienie hiperparametru i odpowiednia metryka oceny są rejestrowane w podrzędnym przebiegu w ramach głównego przebiegu.

Podczas wywoływania polecenia fit()usługa Azure Databricks zaleca aktywne zarządzanie uruchamianiem MLflow, czyli zawijanie wywołania do fit() wewnątrz instrukcji "with mlflow.start_run():". Dzięki temu informacje są rejestrowane w ramach własnego głównego przebiegu platformy MLflow i ułatwiają rejestrowanie dodatkowych tagów, parametrów lub metryk do tego uruchomienia.

Uwaga

Gdy fit() jest wywoływany wiele razy w ramach tego samego aktywnego przebiegu MLflow, rejestruje te wiele uruchomień do tego samego głównego uruchomienia. Aby rozwiązać konflikty nazw dla parametrów i tagów MLflow, MLflow dołącza identyfikator UUID do nazw z konfliktami.

Poniższy notes języka Python przedstawia zautomatyzowane śledzenie biblioteki MLflow.

Notes zautomatyzowanego śledzenia MLflow

Pobierz notes

Po wykonaniu akcji w ostatniej komórce w notesie powinien zostać wyświetlony interfejs użytkownika platformy MLflow: