Usare Azure Databricks per orchestrare MLOps

Questo articolo fornisce un'architettura e un processo di machine learning operations (MLOps) che usa Azure Databricks. I data scientist e i tecnici possono usare questo processo standardizzato per spostare modelli e pipeline di Machine Learning dallo sviluppo alla produzione.

Questa soluzione può sfruttare l'automazione completa, il monitoraggio continuo e una solida collaborazione e quindi ha come obiettivo un livello 4 di maturità MLOps. Questa architettura usa il codice di promozione che genera l'approccio del modello anziché l'approccio di promozione dei modelli . Il codice di promozione che genera l'approccio del modello è incentrato sulla scrittura e sulla gestione del codice che genera modelli di Machine Learning. Le raccomandazioni contenute in questo articolo includono opzioni per processi automatizzati o manuali.

Architettura

Scaricare un file di Visio di questa architettura.

Workflow

Il flusso di lavoro seguente corrisponde al diagramma precedente. Usare il controllo del codice sorgente e i componenti di archiviazione per gestire e organizzare codice e dati.

Controllo del codice sorgente: il repository di codice del progetto organizza i notebook, i moduli e le pipeline. È possibile creare rami di sviluppo per testare gli aggiornamenti e i nuovi modelli. Sviluppare codice in notebook supportati da Git o ambienti di sviluppo integrato (IDE) che si integrano con le cartelle Git in modo da poter eseguire la sincronizzazione con le aree di lavoro di Azure Databricks. Il controllo del codice sorgente promuove le pipeline di Machine Learning dall'ambiente di sviluppo, il test nell'ambiente di gestione temporanea e la distribuzione nell'ambiente di produzione.

Dati di produzione di Lakehouse: in qualità di data scientist, si ha accesso in sola lettura ai dati di produzione nell'ambiente di sviluppo. L'ambiente di sviluppo può disporre di dati con mirroring e di dati riservati. È anche disponibile l'accesso in lettura e scrittura in un ambiente di archiviazione di sviluppo per lo sviluppo e la sperimentazione. È consigliabile usare un'architettura lakehouse per i dati in cui archiviare i dati in formato Delta Lake in Azure Data Lake Storage. Una lakehouse offre una soluzione affidabile, scalabile e flessibile per la gestione dei dati. Per definire i controlli di accesso, usare il pass-through delle credenziali dell'ID Di Microsoft Entra o i controlli di accesso alle tabelle.

Gli ambienti seguenti comprendono il flusso di lavoro principale.

Sviluppo

Nell'ambiente di sviluppo si sviluppano pipeline di Machine Learning.

1. Eseguire l'analisi esplorativa dei dati (EDA): esplorare i dati in un processo interattivo iterativo. È possibile che questo lavoro non venga distribuito nella gestione temporanea o nell'ambiente di produzione. Usare strumenti come Databricks SQL, il comando dbutils.data.summarize e Databricks AutoML.

2. Sviluppare il training del modello e altre pipeline di Machine Learning: sviluppare pipeline di Machine Learning modulari e orchestrare il codice tramite notebook di Databricks o un progetto MLFlow. In questa architettura, la pipeline di training del modello legge i dati dall'archivio delle funzionalità e da altre tabelle lakehouse. La pipeline esegue il training e ottimizza i parametri e le metriche del modello di log nel server di rilevamento MLflow. L'API dell'archivio delle funzionalità registra il modello finale. Questi log includono il modello, i relativi input e il codice di training.

3. Commit del codice: per promuovere il flusso di lavoro di Machine Learning verso l'ambiente di produzione, eseguire il commit del codice per la definizione delle caratteristiche, il training e altre pipeline nel controllo del codice sorgente. Nella codebase inserire codice di Machine Learning e codice operativo in cartelle diverse in modo che i membri del team possano sviluppare codice contemporaneamente. Il codice di Machine Learning è codice correlato al modello e ai dati. Il codice operativo è il codice correlato ai processi e all'infrastruttura di Databricks.

Questo ciclo principale di attività che si esegue quando si scrive e si testa il codice viene definito processo innerloop. Per eseguire il processo innerloop per la fase di sviluppo, usare Visual Studio Code in combinazione con l'interfaccia della riga di comando del contenitore di sviluppo e l'interfaccia della riga di comando di Databricks. È possibile scrivere il codice ed eseguire unit test in locale. È anche necessario inviare, monitorare e analizzare le pipeline del modello dall'ambiente di sviluppo locale.

Staging

Nell'ambiente di gestione temporanea, l'infrastruttura di integrazione continua (CI) testa le modifiche alle pipeline di Machine Learning in un ambiente che simula la produzione.

4. Unire una richiesta: quando si invia una richiesta di merge o una richiesta pull sul ramo di gestione temporanea (principale) del progetto nel controllo del codice sorgente, uno strumento di integrazione continua e recapito continuo (CI/CD) come Azure DevOps esegue test.

5. Eseguire unit test e test CI: gli unit test vengono eseguiti nell'infrastruttura CI e i test di integrazione vengono eseguiti nei flussi di lavoro end-to-end in Azure Databricks. Se i test vengono superati, il codice cambia unione.

6. Creare un ramo di versione: quando si vogliono distribuire le pipeline di Machine Learning aggiornate nell'ambiente di produzione, è possibile creare una nuova versione. Una pipeline di distribuzione nello strumento CI/CD ridistribuisce le pipeline aggiornate come nuovi flussi di lavoro.

Produzione

I tecnici di Machine Learning gestiscono l'ambiente di produzione, in cui le pipeline di Machine Learning servono direttamente le applicazioni finali. Le pipeline principali nelle tabelle delle funzionalità di aggiornamento di produzione, eseguire il training e distribuire nuovi modelli, eseguire l'inferenza o gestire e monitorare le prestazioni del modello.

7. Aggiornamento della tabella delle funzionalità: questa pipeline legge i dati, le funzionalità di calcolo e le scritture nelle tabelle dell'archivio funzionalità. È possibile configurare questa pipeline per l'esecuzione continua in modalità di streaming, l'esecuzione in base a una pianificazione o l'esecuzione in un trigger.

8. Training del modello: nell'ambiente di produzione è possibile configurare il training del modello o ripetere il training della pipeline per l'esecuzione in un trigger o in una pianificazione per eseguire il training di un nuovo modello sui dati di produzione più recenti. I modelli vengono registrati automaticamente nel catalogo unity.

9. Valutazione e promozione del modello: quando viene registrata una nuova versione del modello, la pipeline cd esegue i test per garantire che il modello funzioni correttamente nell'ambiente di produzione. Quando il modello supera i test, Unity Catalog tiene traccia dello stato di avanzamento tramite transizioni di fase del modello. I test includono controlli di conformità, test A/B per confrontare il nuovo modello con il modello di produzione corrente e i test dell'infrastruttura. Le tabelle Lakehouse registrano i risultati e le metriche dei test. Facoltativamente, è possibile richiedere l'accesso manuale prima che i modelli passino alla produzione.

10. Distribuzione del modello: quando un modello entra in produzione, viene distribuito per l'assegnazione dei punteggi o la gestione. Le modalità di distribuzione più comuni includono:

    • Assegnazione dei punteggi batch o di streaming: per latenze di minuti o più lunghi, batch e streaming sono le opzioni più convenienti. La pipeline di assegnazione dei punteggi legge i dati più recenti dall'archivio funzionalità, carica la versione più recente del modello di produzione da Unity Catalog ed esegue l'inferenza in un processo di Databricks. Può pubblicare stime in tabelle lakehouse, una connessione JDBC (Java Database Connectivity), file flat, code di messaggi o altri sistemi downstream.

    • Servizio online (API REST): per i casi d'uso a bassa latenza, in genere è necessaria una gestione online. MLflow può distribuire modelli in Mosaic AI Model Serving, cloud provider di servizi e altri sistemi. In tutti i casi, il sistema di gestione viene inizializzato con il modello di produzione più recente del catalogo unity. Per ogni richiesta, recupera le funzionalità da un archivio funzionalità online e effettua stime.

11. Monitoraggio: i flussi di lavoro continui o periodici monitorano i dati di input e le stime del modello per le deviazioni, le prestazioni e altre metriche. È possibile usare il framework Tabelle live Delta per automatizzare il monitoraggio per le pipeline e archiviare le metriche nelle tabelle lakehouse. Databricks SQL, Power BI e altri strumenti possono leggere da tali tabelle per creare dashboard e avvisi. Per monitorare le metriche, i log e l'infrastruttura delle applicazioni, è anche possibile integrare Monitoraggio di Azure con Azure Databricks.

12. Rilevamento della deriva e ripetizione del training del modello: questa architettura supporta sia il training manuale che quello automatico. Pianificare i processi di ripetizione del training per mantenere aggiornati i modelli. Dopo che una deriva rilevata supera una soglia preconfigurata impostata nel passaggio di monitoraggio, le pipeline di ripetizione del training analizzano la deriva e attivano la ripetizione del training. È possibile configurare le pipeline per l'attivazione automatica oppure ricevere una notifica e quindi eseguire manualmente le pipeline.

Componenti

• Un'architettura data lakehouse unifica gli elementi dei data lake e dei data warehouse. Usare un lakehouse per ottenere funzionalità di gestione dei dati e prestazioni che si trovano in genere nei data warehouse, ma con gli archivi oggetti flessibili a basso costo offerti dai data lake.

  • Delta Lake è il formato di dati open source consigliato per una lakehouse. Azure Databricks archivia i dati in Data Lake Storage e offre un motore di query ad alte prestazioni.

• MLflow è un progetto open source per la gestione del ciclo di vita end-to-end di Machine Learning. MLflow include i componenti seguenti:

  • La funzionalità di rilevamento tiene traccia degli esperimenti, in modo da poter registrare e confrontare parametri, metriche e artefatti del modello.

    • Il rilevamento automatico di Databricks estende la registrazione automatica di MLflow per tenere traccia degli esperimenti di Machine Learning e registra automaticamente parametri del modello, metriche, file e informazioni di derivazione.

  • Il modello MLflow è un formato che è possibile usare per archiviare e distribuire modelli da qualsiasi libreria di Machine Learning a diverse piattaforme di inferenza e di gestione dei modelli.

  • Unity Catalog offre funzionalità centralizzate di controllo, controllo, derivazione e individuazione dei dati nelle aree di lavoro di Azure Databricks.

  • Mosaic AI Model Serving ospita modelli MLflow come endpoint REST.

• Azure Databricks offre un servizio MLflow gestito con funzionalità di sicurezza aziendali, disponibilità elevata e integrazioni con altre funzionalità dell'area di lavoro di Azure Databricks.

  • Databricks Runtime per Machine Learning automatizza la creazione di un cluster ottimizzato per l'apprendimento automatico e preinstalla le librerie di Machine Learning più diffuse come TensorFlow, PyTorch e XGBoost. Preinstalla anche Azure Databricks per gli strumenti di Machine Learning, ad esempio AutoML e i client dell'archivio funzionalità.

  • Un archivio funzionalità è un repository centralizzato di funzionalità. Usare l'archivio funzionalità per individuare e condividere le funzionalità e prevenire l'asimmetria dei dati tra il training del modello e l'inferenza.

  • Databricks SQL si integra con un'ampia gamma di strumenti in modo da poter creare query e dashboard negli ambienti preferiti senza adattarsi a una nuova piattaforma.

  • Le cartelle Git offrono l'integrazione con il provider Git nell'area di lavoro di Azure Databricks, migliorando la collaborazione tra notebook o codice e l'integrazione dell'IDE.

  • I flussi di lavoro e i processi consentono di eseguire codice non interattivo in un cluster Azure Databricks. Per l'apprendimento automatico, i processi offrono automazione per la preparazione dei dati, la definizione delle caratteristiche, il training, l'inferenza e il monitoraggio.

Alternative

È possibile personalizzare questa soluzione per l'infrastruttura di Azure. Considerare le personalizzazioni seguenti:

• Usare più aree di lavoro di sviluppo che condividono un'area di lavoro di produzione comune.

• Scambiare uno o più componenti dell'architettura per l'infrastruttura esistente. Ad esempio, è possibile usare Azure Data Factory per orchestrare i processi di Databricks.

• Eseguire l'integrazione con gli strumenti CI/CD esistenti tramite Git e le API REST di Azure Databricks.

• Usare Microsoft Fabric o Azure Synapse Analytics come servizi alternativi per le funzionalità di Machine Learning.

Dettagli dello scenario

Questa soluzione offre un processo MLOps affidabile che usa Azure Databricks. È possibile sostituire tutti gli elementi nell'architettura, in modo da poter integrare altri servizi di Azure e servizi partner in base alle esigenze. Questa architettura e descrizione sono adattate dal e-book The Big Book of MLOps. L'e-book esplora questa architettura in modo più dettagliato.

MLOps consente di ridurre il rischio di errori nei sistemi di Machine Learning e intelligenza artificiale e migliora l'efficienza della collaborazione e degli strumenti. Per un'introduzione a MLOps e una panoramica di questa architettura, vedere Architect MLOps on the lakehouse (Architettura MLOps nel lakehouse).

Usare questa architettura per:

• Connettere gli stakeholder aziendali ai team di Machine Learning e data science. Usare questa architettura per incorporare notebook e IDE per lo sviluppo. Gli stakeholder aziendali possono visualizzare metriche e dashboard in Databricks SQL, tutti all'interno della stessa architettura lakehouse.

• Rendere l'infrastruttura di Machine Learning incentrata sui dati. Questa architettura gestisce i dati di Machine Learning come altri dati. I dati di Machine Learning includono dati di progettazione delle funzionalità, training, inferenza e monitoraggio. Questa architettura riutilizza gli strumenti per pipeline di produzione, dashboard e altre elaborazioni generali dei dati per l'elaborazione dei dati di Machine Learning.

• Implementare MLOps in moduli e pipeline. Come per qualsiasi applicazione software, usare le pipeline modularizzate e il codice in questa architettura per testare i singoli componenti e ridurre il costo del refactoring futuro.

• Automatizzare i processi MLOps in base alle esigenze. In questa architettura è possibile automatizzare i passaggi per migliorare la produttività e ridurre il rischio di errori umani, ma non è necessario automatizzare ogni passaggio. Azure Databricks consente l'interfaccia utente e i processi manuali oltre alle API per l'automazione.

Potenziali casi d'uso

Questa architettura si applica a tutti i tipi di Machine Learning, Deep Learning e analisi avanzata. Le tecniche comuni di Machine Learning e intelligenza artificiale in questa architettura includono:

• Machine Learning classico, ad esempio modelli lineari, modelli basati su albero e boosting.
• Apprendimento profondo moderno, come TensorFlow e PyTorch.
• Analisi personalizzata, ad esempio statistiche, metodi Bayesian e analisi del grafo.

L'architettura supporta sia dati di piccole dimensioni (singolo computer) che dati di grandi dimensioni (calcolo distribuito e con accelerazione GPU). In ogni fase dell'architettura è possibile scegliere risorse di calcolo e librerie per adattarsi ai dati e alle dimensioni dei problemi dello scenario.

L'architettura si applica a tutti i tipi di settori e casi d'uso aziendali. I clienti di Azure Databricks che usano questa architettura includono organizzazioni di piccole e grandi dimensioni nei settori seguenti:

• Beni di consumo e servizi di vendita al dettaglio
• Servizi finanziari
• Servizi sanitari e scienze biologiche
• Tecnologia dell'informazione

Per esempi, vedere Clienti di Databricks.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

• Brandon Cowen | Senior Cloud Solution Architect
• Prabal Deb | Principal Software Engineer

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

• Intelligenza artificiale e Machine Learning in Databricks
• Pagina e risorse del prodotto di Machine Learning di Databricks

Risorse correlate

• Modello di maturità di MLOps
• MLOps v2