Condividi tramite


Apache Spark MLlib e rilevamento automatizzato di MLflow

Importante

Questa documentazione è stata ritirata e potrebbe non essere aggiornata. Il prodotto, il servizio o la tecnologia citati in questo contenuto non sono più supportati.

Nota

Il rilevamento automatizzato di MLflow per MLib è obsoleto nei cluster che eseguono Databricks Runtime 10.1 ML e nelle versioni successive ed è disabilitato per impostazione predefinita nei cluster che eseguono Databricks Runtime 10.2 ML e nelle versioni successive. Usare invece MLflow PySpark ML autologging chiamando mlflow.pyspark.ml.autolog(), il quale è abilitato per impostazione predefinita con Databricks Autologging.

Per usare il vecchio rilevamento automatizzato di MLFlow per MLib di in Databricks Runtime 10.2 ML o nelle versioni successive, abilitarlo impostando le configurazioni Sparkspark.databricks.mlflow.trackMLlib.enabled true e spark.databricks.mlflow.autologging.enabled false.

MLflow è una piattaforma open source per la gestione del ciclo di vita end-to-end di Machine Learning. MLflow supporta il rilevamento per l'ottimizzazione dei modelli di Machine Learning in Python, R e Scala. Solo per i notebook Python, le note di rilascio e la compatibilità delle versioni di Databricks Runtime e Databricks Runtime per Machine Learning supportano il rilevamento automatico di MLflow per l’ottimizzazione dei modelli di Apache Spark MLlib.

Con il rilevamento automatico di MLflow per MLlib, quando si esegue del codice di ottimizzazione che utilizza CrossValidator o TrainValidationSplit, gli iperparametri e le metriche di valutazione vengono automaticamente registrati in MLflow. Senza il rilevamento automatizzato di MLflow, è necessario effettuare chiamate API esplicite per accedere a MLflow.

Gestire le esecuzioni di MLflow

CrossValidator o TrainValidationSplit registrano i risultati dell'ottimizzazione come esecuzioni annidate di MLflow:

  • Esecuzione principale o genitore: le informazioni per CrossValidator o TrainValidationSplit vengono registrate nell'esecuzione principale. Se è già presente un'esecuzione attiva, le informazioni vengono registrate ed essa non viene arrestata. Se non c'è nessuna esecuzione attiva, MLflow crea una nuova esecuzione, la registra e poi termina l'esecuzione prima di restituire il controllo.
  • Esecuzioni figlie: Ogni impostazione di iperparametro testata e la metrica di valutazione corrispondente sono registrate in un'esecuzione figlia sotto l'esecuzione principale.

Quando si chiama fit(), Azure Databricks consiglia la gestione di esecuzione MLflow attiva, ovvero eseguire il wrapping della chiamata a fit() all'interno di un'istruzione "with mlflow.start_run():". Questo garantisce che le informazioni siano registrate sotto la propria esecuzione principale di MLflow e facilita la registrazione di tag, parametri o metriche aggiuntive a quella esecuzione.

Nota

Quando fit() viene chiamata più volte all'interno della stessa esecuzione attiva di MLflow, queste chiamate vengono registrate tutte sotto la stessa esecuzione principale. Per risolvere i conflitti di nomi per i parametri e i tag di MLflow, MLflow aggiunge un UUID ai nomi con conflitti.

Il seguente notebook Python illustra il rilevamento automatizzato di MLflow.

Notebook di rilevamento automatizzato di MLflow

Ottenere il notebook

Dopo aver eseguito le azioni nell'ultima cella del notebook, dovrebbe venir visualizzata l'interfaccia utente di MLflow:

Demo MLlib-MLflow