Modifica

Condividi tramite

Orchestrare MLOps usando Azure Databricks

Azure Databricks

Idee per le soluzioni

Questo articolo descrive un'idea di soluzione. L'architetto cloud può usare queste linee guida per visualizzare i componenti principali per un'implementazione tipica di questa architettura. Usare questo articolo come punto di partenza per progettare una soluzione ben progettata in linea con i requisiti specifici del carico di lavoro.

Questo articolo fornisce un'architettura e un processo di machine learning operations (MLOps) che usa Azure Databricks. Questo processo definisce un modo standardizzato per spostare modelli e pipeline di Machine Learning dallo sviluppo alla produzione, con opzioni per includere processi automatizzati e manuali.

Architettura

Diagramma che mostra una soluzione per l'uso di Azure Databricks per MLOps.

Scaricare un file di Visio di questa architettura.

Workflow

Questa soluzione offre un processo MLOps affidabile che usa Azure Databricks. Tutti gli elementi dell'architettura sono collegabili, quindi è possibile integrare altri servizi di Azure e di terze parti in tutta l'architettura in base alle esigenze. Questa architettura e descrizione sono adattate dal e-book The Big Book of MLOps. Questo e-book esplora l'architettura descritta qui in modo più dettagliato.

  • Controllo del codice sorgente: il repository di codice del progetto organizza i notebook, i moduli e le pipeline. I data scientist creano rami di sviluppo per testare gli aggiornamenti e i nuovi modelli. Il codice viene sviluppato in notebook o in IDE, supportato da Git, con l'integrazione di Databricks Repos per la sincronizzazione con le aree di lavoro di Azure Databricks. Il controllo del codice sorgente promuove le pipeline di Machine Learning dallo sviluppo, tramite la gestione temporanea (per i test), alla produzione (per la distribuzione).

  • Lakehouse - Dati di produzione: i data scientist lavorano nell'ambiente di sviluppo, in cui hanno accesso in sola lettura ai dati di produzione. In alternativa, è possibile eseguire il mirroring o la modifica dei dati. Hanno anche accesso in lettura/scrittura a un ambiente di archiviazione di sviluppo per lo sviluppo e la sperimentazione. È consigliabile un'architettura Lakehouse per i dati, in cui i dati vengono archiviati in Azure Data Lake Storage in formato Delta Lake . I controlli di accesso vengono definiti con il pass-through delle credenziali di Microsoft Entra o i controlli di accesso alle tabelle.

Sviluppo

Nell'ambiente di sviluppo, data scientist e ingegneri sviluppano pipeline di Machine Learning.

  1. Analisi esplorativa dei dati (EDA): i data scientist esplorano i dati in un processo interattivo iterativo. Questo lavoro ad hoc potrebbe non essere distribuito nella gestione temporanea o nell'ambiente di produzione. Gli strumenti possono includere Databricks SQL, dbutils.data.summarizee AutoML.

  2. Training del modello e altre pipeline di Machine Learning: le pipeline di Machine Learning vengono sviluppate come codice modulare in notebook o IDE. Ad esempio, la pipeline di training del modello legge i dati da Feature Store e da altre tabelle Lakehouse. Parametri e metriche del modello di log di training e ottimizzazione nel server di rilevamento MLflow. L'API di Feature Store registra il modello finale. Questi log collegano 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, il data scientist esegue il commit del codice per la definizione delle caratteristiche, il training e altre pipeline al controllo del codice sorgente.

Staging

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

  1. Richiesta di merge: quando viene inviata una richiesta di merge (o pull) sul ramo di staging (main) del progetto nel controllo del codice sorgente, uno strumento di integrazione continua e recapito continuo (CI/CD) come Azure DevOps esegue test.

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

  3. Creare un ramo di versione: quando i tecnici di Machine Learning sono pronti per distribuire le pipeline di Machine Learning aggiornate nell'ambiente di produzione, possono 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.

  1. Aggiornamento della tabella delle funzionalità: questa pipeline legge i dati, le funzionalità di calcolo e le scritture nelle tabelle di Feature Store . Viene eseguito in modo continuo in modalità di streaming, viene eseguito in base a una pianificazione o viene attivato.

  2. Training del modello: nell'ambiente di produzione, il training del modello o la pipeline di ripetizione del training viene attivato o pianificato per eseguire il training di un nuovo modello sui dati di produzione più recenti. I modelli vengono registrati nel Registro modelli MLflow.

  3. Distribuzione continua: la registrazione di nuove versioni del modello attiva la pipeline cd, che esegue i test per garantire che il modello funzioni correttamente nell'ambiente di produzione. Man mano che il modello supera i test, lo stato viene rilevato nel Registro modelli tramite transizioni di fase del modello. I webhook del Registro di sistema possono essere usati per l'automazione. I test possono includere controlli di conformità, test A/B per confrontare il nuovo modello con il modello di produzione corrente e i test dell'infrastruttura. I risultati dei test e le metriche vengono registrati nelle tabelle Lakehouse. Facoltativamente, è possibile richiedere la disconnettemento manuale prima che i modelli vengano passati all'ambiente di produzione.

  4. 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 sono:

    • 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 dal Registro modelli 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, la gestione online è in genere necessaria. MLflow può distribuire modelli in MLflow Model Serving in Azure Databricks, cloud provider di servizi e altri sistemi. In tutti i casi, il sistema di gestione viene inizializzato con il modello di produzione più recente dal Registro modelli. Per ogni richiesta, recupera le funzionalità da un Feature Store online e effettua stime.

  5. 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. Le tabelle live delta possono semplificare l'automazione delle pipeline di monitoraggio, archiviando le metriche nelle tabelle Lakehouse. Databricks SQL, Power BI e altri strumenti possono leggere da tali tabelle per creare dashboard e avvisi.

  6. Ripetizione del training: questa architettura supporta il training manuale e automatico. I processi di ripetizione del training pianificati sono il modo più semplice per mantenere aggiornati i modelli.

Componenti

  • Data Lakehouse. Un'architettura Lakehouse unifica i migliori elementi dei data lake e dei data warehouse, offrendo in genere la gestione dei dati e le prestazioni disponibili nei data warehouse con gli archivi oggetti flessibili a basso costo offerti dai data lake.
    • Delta Lake è la scelta consigliata per un formato di dati open source per un 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 di Machine Learning end-to-end. Questi sono i componenti principali:
    • Il rilevamento consente di tenere traccia degli esperimenti per registrare e confrontare parametri, metriche e artefatti del modello.
      • Databricks Autologging estende la registrazione automatica di MLflow per tenere traccia degli esperimenti di Machine Learning, registrando automaticamente parametri del modello, metriche, file e informazioni di derivazione.
    • Il modello MLflow consente di archiviare e distribuire modelli da qualsiasi libreria di Machine Learning a diverse piattaforme di gestione e inferenza del modello.
    • Il Registro modelli offre un archivio modelli centralizzato per la gestione delle transizioni della fase del ciclo di vita del modello da sviluppo a produzione.
    • Model Serving consente di ospitare modelli MLflow come endpoint REST.
  • Azure Databricks. 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.

Alternative

È possibile personalizzare questa soluzione per l'infrastruttura di Azure. Le personalizzazioni comuni includono:

  • Più aree di lavoro di sviluppo che condividono un'area di lavoro di produzione comune.
  • Scambio di uno o più componenti dell'architettura per l'infrastruttura esistente. Ad esempio, è possibile usare Azure Data Factory per orchestrare i processi di Databricks.
  • Integrazione con gli strumenti CI/CD esistenti tramite Git e le API REST di Azure Databricks.

Dettagli dello scenario

MLOps consente di ridurre il rischio di errori nei sistemi di Machine Learning e intelligenza artificiale e di migliorare l'efficienza della collaborazione e degli strumenti. Per un'introduzione a MLOps e una panoramica di questa architettura, vedere Architettura di MLOps in Lakehouse.

Usando questa architettura, è possibile:

  • Connettere gli stakeholder aziendali ai team di Machine Learning e data science. Questa architettura consente ai data scientist di usare notebook e IDE per lo sviluppo. Consente agli stakeholder aziendali di 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 (dati di progettazione delle funzionalità, training, inferenza e monitoraggio) esattamente come altri dati. 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, le pipeline modularizzate e il codice in questa architettura consentono di testare 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 tutti i passaggi devono essere automatizzati. 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/intelligenza artificiale usate in questa architettura includono:

  • Machine Learning classico, ad esempio modelli lineari, modelli basati su albero e boosting.
  • Deep Learning moderno, ad esempio 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.

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

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

Per esempi, vedere il sito Web di Databricks.

Collaboratori

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

Autore principale:

Altro collaboratore:

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

Passaggi successivi