Apache Spark MLlib und automatisierte MLflow-Nachverfolgung

Wichtig

Diese Dokumentation wurde eingestellt und wird unter Umständen nicht aktualisiert. Die in diesem Inhalt erwähnten Produkte, Dienste oder Technologien werden nicht mehr unterstützt.

Hinweis

Die automatisierte MLflow-Nachverfolgung von MLlib ist für Cluster, die Databricks Runtime 10.1 ML und höher ausführen, veraltet und standardmäßig auf Clustern deaktiviert, die Databricks Runtime 10.2 ML und höher ausführen. Verwenden Sie stattdessen MLflow PySpark ML-Autologging, indem Sie mlflow.pyspark.ml.autolog() aufrufen, was mit Databricks Autologging standardmäßig aktiviert ist.

Wenn Sie die alte automatisierte MLflow-Nachverfolgung von MLlib in Databricks Runtime 10.2 ML oder höher verwenden möchten, müssen Sie die Spark-Konfigurationen spark.databricks.mlflow.trackMLlib.enabled true und spark.databricks.mlflow.autologging.enabled false festlegen, um sie zu aktivieren.

MLflow ist eine Open-Source-Plattform für die Verwaltung des gesamten Machine Learning-Lebenszyklus. MLflow unterstützt die Nachverfolgung für die Machine Learning-Modelloptimierung in Python, R und Scala. Nur für Python-Notebooks unterstützen Versionshinweise zu Databricks Runtime-Versionen und -Kompatibilität und Databricks Runtime für Machine Learning die automatisierteMLflow-Nachverfolgung für die Apache Spark MLlib-Modelloptimierung.

Bei der automatisierten MLflow-Nachverfolgung von MLlib werden Hyperparameter und Auswertungsmetriken automatisch in MLflow protokolliert, wenn Sie Optimierungscode ausführen, der CrossValidator oder TrainValidationSplit verwendet. Ohne automatisierte MLflow-Nachverfolgung müssen Sie explizite API-Aufrufe zum Protokollieren an MLflow durchführen.

Verwalten von MLflow-Ausführungen

CrossValidator- oder TrainValidationSplit-Protokolloptimierungsergebnisse bei verschachtelten MLflow-Ausführungen:

• Haupt- oder übergeordnete Ausführung: Die Informationen für CrossValidator oder TrainValidationSplit werden in der Hauptausführung protokolliert. Wenn bereits eine aktive Ausführung vorhanden ist, werden Informationen in dieser aktiven Ausführung protokolliert, die aktive Ausführung wird nicht beendet. Wenn keine aktive Ausführung vorhanden ist, erstellt MLflow eine neue Ausführung, protokolliert sie und beendet die Ausführung vor der Rückgabe.
• Untergeordnete Ausführungen: Jede getestete Hyperparametereinstellung mitsamt entsprechender Auswertungsmetrik werden in einer untergeordneten Ausführung der jeweiligen Hauptausführung protokolliert.

Beim Aufrufen von fit() empfiehlt Azure Databricks eine aktive MLflow-Ausführungsverwaltung, d. h. den Aufruf von fit() in eine „with mlflow.start_run():“-Anweisung einzuschließen. Dadurch wird sichergestellt, dass die Informationen als eigene MLflow-Hauptausführung protokolliert werden, und es ist einfacher, zusätzliche Tags, Parameter oder Metriken für diese Ausführung zu protokollieren.

Hinweis

Wenn fit() mehrmals innerhalb derselben aktiven MLflow-Ausführung aufgerufen wird, werden diese mehreren Ausführungen in derselben Hauptausführung protokolliert. Um Namenskonflikte für MLflow-Parameter und -Tags zu lösen, fügt MLflow Namen mit Konflikten eine UUID hinzu.

Das folgende Python-Notebook veranschaulicht die automatisierte MLflow-Nachverfolgung.

Notebook: Automatisierte MLflow-Nachverfolgung

Notebook abrufen

Nachdem Sie die Aktionen in der letzten Zelle des Notebooks ausgeführt haben, sollte die MLflow-Benutzeroberfläche Folgendes anzeigen: