Progettare MLOps sul Lakehouse

Qui in Databricks, abbiamo aiutato migliaia di clienti a portare il Machine Learning (ML) in produzione. Shell ha oltre 160 progetti AI attivi che consentono di risparmiare milioni di dollari; Comcast gestisce facilmente centinaia di modelli di machine learning con MLflow; e molti altri hanno sviluppato soluzioni di successo basate sul ML.

Prima di lavorare con noi, molti clienti faticavano a portare il ML in produzione, e per un valido motivo: le Machine Learning Operations (MLOps) sono complesse. Le MLOps comportano la gestione congiunta di codice (DevOps), dati (DataOps) e modelli (ModelOps) nel loro percorso verso la produzione. La sfida più comune e complessa che abbiamo riscontrato è il divario tra dati e ML, spesso suddivisi tra strumenti e team scarsamente collegati.

Per superare questa sfida, Databricks Machine Learning si basa sull'architettura Lakehouse per estenderne i vantaggi principali (semplicità e apertura) alle MLOps.

La nostra piattaforma semplifica il ML definendo un flusso di lavoro data-centric che unisce le best practice di DevOps, DataOps e ModelOps. Le pipeline di machine learning sono in ultima analisi pipeline di dati, in cui i dati passano attraverso diverse figure professionali. I data engineer acquisiscono e preparano i dati; i data scientist creano modelli a partire dai dati; gli ML engineer monitorano le metriche dei modelli; e i business analyst esaminano le previsioni. Databricks semplifica il machine learning in produzione consentendo a questi team di dati di collaborare e gestire questa grande quantità di dati su un'unica piattaforma, anziché in silos isolati. Ad esempio, il nostro Feature Store consente di portare in produzione modelli e feature in modo congiunto: i data scientist creano modelli "consapevoli" delle feature di cui hanno bisogno, in modo che gli ML engineer possano distribuire i modelli con processi più semplici.

L'approccio di Databricks alle MLOps si basa su standard aperti a livello di settore. Per DevOps, ci integriamo con strumenti Git e CI/CD. Per DataOps, ci basiamo su Delta Lake e sul lakehouse, l'architettura de facto per l'elaborazione dei dati aperta e performante. Per ModelOps, ci basiamo su MLflow, lo strumento open source più diffuso per la gestione dei modelli. Questa base in formati aperti e API consente ai nostri clienti di adattare la nostra piattaforma alle loro diverse esigenze. Ad esempio, i clienti che centralizzano la gestione dei modelli attorno alla nostra offerta MLflow possono utilizzare il nostro servizio di model serving integrato o altre soluzioni, a seconda delle loro esigenze.

Siamo entusiasti di condividere la nostra architettura MLOps in questo post del blog. Esamineremo le sfide della gestione congiunta di DevOps + DataOps + ModelOps, offriremo una panoramica della nostra soluzione e descriveremo la nostra architettura di riferimento. Per approfondire, scarica The Big Book of MLOps e segui i talk sulle MLOps al prossimo Data+AI Summit 2022.

Gestione congiunta di codice, dati e modelli

Le MLOps sono un insieme di processi e automazioni per gestire codice, dati e modelli al fine di raggiungere i due obiettivi di prestazioni stabili ed efficienza a lungo termine nei sistemi ML. In breve, MLOps = DevOps + DataOps + ModelOps.

Sviluppo, staging e produzione

Nel loro percorso verso applicazioni rivolte al business o ai clienti, gli asset ML (codice, dati e modelli) attraversano una serie di fasi. Devono essere sviluppati (fase di "sviluppo"), testati (fase di "staging") e distribuiti (fase di "produzione"). Questo lavoro viene svolto all'interno di ambienti di esecuzione come i workspace di Databricks.

Tutto ciò che è stato menzionato sopra (ambienti di esecuzione, codice, dati e modelli) è suddiviso in dev, staging e prod. Queste divisioni possono essere intese in termini di garanzie di qualità e controllo degli accessi. Gli asset in fase di sviluppo possono essere più ampiamente accessibili ma non hanno garanzie di qualità. Gli asset in produzione sono generalmente critici per il business, con le massime garanzie di test e qualità, ma con severi controlli su chi può modificarli.

Sfide principali

La serie di requisiti sopra descritta può facilmente esplodere in complessità: come gestire codice, dati e modelli tra sviluppo, test e produzione, su più team, con complicazioni come i controlli degli accessi e molteplici tecnologie in gioco? Abbiamo osservato che questa complessità porta ad alcune sfide chiave.

Processi operativi
Le idee di DevOps non si traducono direttamente in MLOps. In DevOps, esiste una stretta corrispondenza tra ambienti di esecuzione, codice e dati; ad esempio, l'ambiente di produzione esegue solo codice a livello di produzione e produce solo dati a livello di produzione. I modelli di ML complicano la situazione, poiché le fasi del ciclo di vita del modello e del codice spesso operano in modo asincrono. Potresti voler rilasciare una nuova versione del modello prima di rilasciare una modifica al codice, e viceversa. Considera i seguenti scenari:

• Per rilevare transazioni fraudolente, sviluppi una pipeline di ML che riaddestra un modello settimanalmente. Aggiorni il codice trimestralmente, ma ogni settimana un nuovo modello viene automaticamente addestrato, testato e spostato in produzione. In questo scenario, il ciclo di vita del modello è più veloce del ciclo di vita del codice.
• Per classificare i documenti utilizzando reti neurali di grandi dimensioni, l'addestramento e la distribuzione del modello sono spesso un processo una tantum a causa dei costi. Ma poiché i sistemi a valle cambiano periodicamente, aggiorni il codice di serving e monitoraggio di conseguenza. In questo scenario, il ciclo di vita del codice è più veloce del ciclo di vita del modello.

Collaborazione e gestione
Le MLOps devono bilanciare l'esigenza dei data scientist di avere flessibilità e visibilità per sviluppare e mantenere i modelli con l'esigenza contrastante degli ML engineer di avere il controllo sui sistemi di produzione. I data scientist devono eseguire il loro codice sui dati di produzione e vedere log, modelli e altri risultati dai sistemi di produzione. Gli ML engineer devono limitare l'accesso ai sistemi di produzione per mantenere la stabilità e, talvolta, per preservare la privacy dei dati. Soddisfare queste esigenze diventa ancora più difficile quando la piattaforma è composta da più tecnologie disgiunte che non condividono un unico modello di controllo degli accessi.

Integrazione e personalizzazione
Molti strumenti per il ML non sono progettati per essere aperti; ad esempio, alcuni strumenti di ML esportano modelli solo in formati black-box come i file JAR. Molti strumenti di dati non sono progettati per il ML; ad esempio, i data warehouse richiedono l'esportazione dei dati verso strumenti di ML, aumentando i costi di storage e i problemi di governance. Quando questi strumenti non si basano su formati aperti e API, è impossibile integrare them in una piattaforma unificata.

Semplificare le MLOps con il Lakehouse

Per soddisfare i requisiti delle MLOps, Databricks ha basato il proprio approccio sull'architettura Lakehouse. I lakehouse uniscono le funzionalità dei data lake e dei data warehouse in un'unica architettura, in cui questa semplificazione è resa possibile dall'uso di formati aperti e API che supportano entrambi i tipi di carichi di lavoro di dati. Analogamente, per le MLOps, offriamo un'architettura più semplice perché sviluppiamo le MLOps attorno a standard di dati aperti.

Prima di entrare nei dettagli del nostro approccio architetturale, lo spiegheremo a un livello generale ed evidenzieremo i suoi vantaggi principali.

Processi operativi
Il nostro approccio estende le idee di DevOps al ML, definendo una semantica chiara per ciò che significa "passare in produzione" per codice, dati e modelli. Gli strumenti DevOps e i processi CI/CD esistenti possono essere riutilizzati per gestire il codice per le pipeline di ML. Il calcolo delle feature, l'inferenza e altre pipeline di dati seguono lo stesso processo di distribuzione del codice di addestramento del modello, semplificando le operazioni. Un servizio dedicato, l'MLflow Model Registry, consente di aggiornare il codice e i modelli in modo indipendente, risolvendo la sfida principale nell'adattare i metodi DevOps al ML.

Collaborazione e gestione
Il nostro approccio si basa su una piattaforma unificata che supporta la data engineering, la data science esplorativa, l'ML in produzione e la business analytics, il tutto supportato da un livello di dati lakehouse condiviso. I dati ML sono gestiti con la stessa architettura lakehouse utilizzata per le altre pipeline di dati, semplificando i passaggi di consegne. I controlli di accesso sugli ambienti di esecuzione, sul codice, sui dati e sui modelli consentono ai team giusti di ottenere i livelli di accesso corretti, semplificando la gestione.

Integrazione e personalizzazione
Il nostro approccio si basa su formati aperti e API: Git e i relativi strumenti di CI/CD, Delta Lake e l'architettura Lakehouse, e MLflow. Codice, dati e modelli sono memorizzati nel tuo account cloud (abbonamento) in formati aperti, supportati da servizi con API aperte. Sebbene l'architettura di riferimento descritta di seguito possa essere interamente implementata all'interno di Databricks, ogni modulo può essere integrato con la tua infrastruttura esistente e personalizzato. Ad esempio, il riaddestramento del modello può essere completamente automatizzato, parzialmente automatizzato o manuale.

Architettura di riferimento per MLOps

Siamo ora pronti a esaminare un'architettura di riferimento per l'implementazione di MLOps sulla piattaforma Databricks Lakehouse. Questa architettura, e Databricks in generale, è indipendente dal cloud (cloud-agnostic) e utilizzabile su uno o più cloud. In quanto tale, si tratta di un'architettura di riferimento pensata per essere adattata alle tue esigenze specifiche. Consulta The Big Book of MLOps per ulteriori approfondimenti sull'architettura e sulle possibili personalizzazioni.

Panoramica

Questa architettura spiega il nostro processo MLOps a un livello generale. Di seguito, descriviamo i componenti chiave dell'architettura e il flusso di lavoro dettagliato per portare le pipeline ML in produzione.

Componenti

Definiamo il nostro approccio in termini di gestione di alcuni asset chiave: ambienti di esecuzione, codice, dati e modelli.

Gli ambienti di esecuzione sono i luoghi in cui i modelli e i dati vengono creati o consumati dal codice. Gli ambienti sono definiti come aree di lavoro Databricks (AWS, Azure, GCP) per lo sviluppo, lo staging e la produzione, con controlli di accesso all'area di lavoro utilizzati per imporre la separazione dei ruoli.
Nel diagramma dell'architettura, le aree blu, rossa e verde rappresentano i tre ambienti.

All'interno degli ambienti, ogni pipeline ML (le caselle piccole nel diagramma) viene eseguita su istanze di calcolo gestite dal nostro servizio Clusters (AWS, Azure, GCP). Questi passaggi possono essere eseguiti manualmente o automatizzati tramite Workflows e Jobs (AWS, Azure, GCP). Ogni passaggio dovrebbe utilizzare per impostazione predefinita un Databricks Runtime per ML con librerie preinstallate (AWS, Azure, GCP), ma può anche utilizzare librerie personalizzate (AWS, Azure, GCP).

Il codice che definisce le pipeline ML è memorizzato in Git per il controllo della versione. Le pipeline ML possono includere la featurizzazione, l'addestramento e il tuning del modello, l'inferenza e il monitoraggio. A un livello generale, "portare l'ML in produzione" significa promuovere il codice dai rami di sviluppo, attraverso il ramo di staging (solitamente `main`), ai rami di rilascio per l'uso in produzione. Questo allineamento con DevOps consente agli utenti di integrare gli strumenti di CI/CD esistenti. Nel diagramma dell'architettura sopra, questo processo di promozione del codice è mostrato in alto.

Durante lo sviluppo delle pipeline ML, i data scientist possono iniziare con i notebook e passare al codice modularizzato in base alle esigenze, lavorando in Databricks o negli IDE. Databricks Repos si integra con il tuo provider git per sincronizzare i notebook e il codice sorgente con le aree di lavoro Databricks (AWS, Azure, GCP). Gli strumenti di sviluppo Databricks ti consentono di connetterti dagli IDE e dai tuoi sistemi di CI/CD esistenti (AWS, Azure, GCP).

I dati sono memorizzati in un'architettura lakehouse, interamente nel tuo account cloud. Le pipeline per la featurizzazione, l'inferenza e il monitoraggio possono essere tutte trattate come pipeline di dati. Ad esempio, il monitoraggio del modello dovrebbe seguire l'architettura medallion di perfezionamento progressivo dei dati, dagli eventi di query grezzi alle tabelle aggregate per le dashboard. Nel diagramma dell'architettura sopra, i dati sono mostrati in basso come dati "Lakehouse" generali, nascondendo la suddivisione in dati a livello di sviluppo, staging e produzione.

Per impostazione predefinita, sia i dati grezzi che le tabelle delle caratteristiche dovrebbero essere memorizzati come tabelle Delta per garantire prestazioni e coerenza. Delta Lake fornisce un livello di archiviazione aperto ed efficiente per dati strutturati e non strutturati, con un Delta Engine ottimizzato in Databricks (AWS, Azure, GCP). Le tabelle del Feature Store sono semplicemente tabelle Delta con metadati aggiuntivi come la lineage (AWS, Azure, GCP). I file e le tabelle grezzi sono soggetti a controlli di accesso che possono essere concessi o limitati in base alle esigenze.

I modelli sono gestiti da MLflow, che consente una gestione uniforme dei modelli da qualsiasi libreria ML, per qualsiasi modalità di distribuzione, sia all'interno che all'esterno di Databricks. Databricks fornisce una versione gestita di MLflow con controlli di accesso, scalabilità fino a milioni di modelli e un superset di API MLflow open source.

In fase di sviluppo, il server di tracciamento MLflow (MLflow Tracking) tiene traccia dei modelli prototipo insieme a snapshot del codice, parametri, metriche e altri metadati (AWS, Azure, GCP). In produzione, lo stesso processo salva una registrazione per garantire la riproducibilità e la governance.

Per il continuous deployment (CD), il Model Registry di MLflow tiene traccia dello stato di distribuzione del modello e si integra con i sistemi CD tramite webhook (AWS, Azure, GCP) e tramite API (AWS, Azure, GCP). Il servizio Model Registry tiene traccia del ciclo di vita dei modelli separatamente da quello del codice. Questo accoppiamento debole tra modelli e codice offre la flessibilità di aggiornare i modelli in produzione senza modifiche al codice, e viceversa. Ad esempio, una pipeline di riaddestramento automatizzata può addestrare un modello aggiornato (un modello di "sviluppo"), testarlo (modello di "staging") e distribuirlo (modello di "produzione"), il tutto all'interno dell'ambiente di produzione.

La tabella seguente riassume la semantica di "sviluppo", "staging" e "produzione" per codice, dati e modelli.

Flusso di lavoro

Dopo aver spiegato i componenti principali dell'architettura, possiamo ora esaminare il flusso di lavoro per portare le pipeline ML dallo sviluppo alla produzione.

Ambiente di sviluppo: i data scientist operano principalmente nell'ambiente di sviluppo, creando il codice per le pipeline ML che può includere il calcolo delle feature, l'addestramento del modello, l'inferenza, il monitoraggio e altro ancora.

1. Creazione del branch di dev: le pipeline nuove o aggiornate vengono prototipate su un branch di sviluppo del progetto Git e sincronizzate con l'area di lavoro Databricks tramite Repos.
2. Analisi esplorativa dei dati (EDA): i data scientist esplorano e analizzano i dati in un processo interattivo e iterativo utilizzando notebook, visualizzazioni e Databricks SQL.
3. Aggiornamento della tabella delle feature: la logica di featurizzazione è incapsulata come una pipeline in grado di leggere dal Feature Store e da altre tabelle Lakehouse e di scrivere nel Feature Store. Le pipeline di feature possono essere gestite separatamente dalle altre pipeline ML, specialmente se appartengono a team diversi.
4. Addestramento del modello e altre pipeline: i data scientist sviluppano queste pipeline su dati di produzione in sola lettura o su dati oscurati o sintetici. In questa architettura di riferimento, le pipeline (non i modelli) vengono promosse verso la produzione; consulta il whitepaper completo per una discussione sulla promozione dei modelli quando necessario.
5. Commit del codice: le pipeline ML nuove o aggiornate vengono sottoposte a commit nel controllo del codice sorgente. Gli aggiornamenti possono interessare una singola pipeline ML o molte contemporaneamente.

Ambiente di staging: gli ingegneri ML gestiscono l'ambiente di staging, in cui vengono testate le pipeline ML.

6. Richiesta di merge (pull request): una richiesta di merge nel branch di staging (solitamente il branch "main") attiva un processo di continuous integration (CI).
7. Unit test (CI): il processo di CI esegue innanzitutto unit test che non interagiscono con i dati o altri servizi.
8. Test di integrazione (CI): il processo di CI esegue quindi test di integrazione più lunghi che testano le pipeline ML in modo congiunto. I test di integrazione che addestrano i modelli possono utilizzare set di dati ridotti o poche iterazioni per una maggiore velocità.
9. Merge: se i test vengono superati, è possibile unire il codice al branch di staging.
10. Creazione del branch di rilascio: quando è pronto, il codice può essere distribuito in produzione creando una release del codice e attivando il sistema CI/CD per aggiornare i job di produzione.

Ambiente di produzione: gli ingegneri ML gestiscono l'ambiente di produzione, in cui vengono distribuite le pipeline ML.

11. Aggiornamento della tabella delle feature: questa pipeline acquisisce nuovi dati di produzione e aggiorna le tabelle del Feature Store di produzione. Può trattarsi di un job batch o in streaming pianificato, attivato o in esecuzione continua.
12. Addestramento del modello: i modelli vengono addestrati sull'intero set di dati di produzione e inviati al Model Registry di MLflow. L'addestramento può essere attivato da modifiche al codice o da job di riaddestramento automatizzati.
13. Continuous Deployment (CD): un processo di CD prende i nuovi modelli (nel Model Registry con "stage=None"), li testa (passando a "stage=Staging") e, in caso di successo, li distribuisce (promuovendoli a "stage=Production"). Il CD può essere implementato utilizzando i webhook del Model Registry e/o il proprio sistema di CD.
14. Inferenza e serving: il modello di produzione del Model Registry può essere distribuito in più modalità: job batch e in streaming per casi d'uso ad alto throughput e serving online per casi d'uso a bassa latenza (API REST).
15. Monitoraggio: per qualsiasi modalità di distribuzione, le query di input e le previsioni del modello vengono registrate nelle tabelle Delta. Da lì, i job possono monitorare la deriva dei dati e del modello (drift), e i dashboard di Databricks SQL possono mostrare lo stato e inviare avvisi. Nell'ambiente di sviluppo, ai data scientist può essere concesso l'accesso a log e metriche per esaminare i problemi di produzione.
16. Riaddestramento: i modelli possono essere riaddestrati sui dati più recenti tramite una semplice pianificazione, oppure i job di monitoraggio possono attivare il riaddestramento.

Implementa la tua architettura MLOps

Speriamo che questo blog ti abbia offerto una panoramica di come un'architettura MLOps incentrata sui dati e basata sul paradigma Lakehouse semplifichi la gestione congiunta di codice, dati e modelli. Questo blog è necessariamente breve e omette molti dettagli. Per iniziare a implementare o migliorare la tua architettura MLOps, ti consigliamo quanto segue:

• Leggi l'eBook completo, che fornisce maggiori dettagli sulle fasi del flusso di lavoro e una discussione su opzioni e personalizzazioni. Scaricalo qui.
• Partecipa alle presentazioni su MLOps del Data+AI Summit 2022 dal 27 al 30 giugno. Tra le sessioni consigliate:
  • Presentazioni di alto livello
    • Keynote di apertura del giorno 2: i cofondatori e i Product Manager condividono la visione e le roadmap più recenti per i progetti open source e Databricks relativi a DS e ML.
    • ML sul Lakehouse: unire dati e ML per accelerare i casi d'uso dell'IA: i Product Manager di Databricks e un cliente offrono una panoramica del machine learning in un'architettura Lakehouse.
  • Approfondimenti di Databricks su MLOps
    • MLOps su Databricks: una guida pratica: gli autori di questo post del blog illustreranno i dettagli della guida dell'eBook e mostreranno una demo del processo MLOps in Databricks.

MLflow Pipelines: accelerare l'MLOps dallo sviluppo alla produzione: gli ingegneri di Databricks approfondiscono quest'ultima innovazione in MLflow.

Abilitare l'ML in produzione con Databricks Feature Store: gli ingegneri di Databricks approfondiscono il feature store.

Clienti che parlano delle loro piattaforme ML

• Creare e scalare prodotti basati sul machine learning nel birrificio più grande del mondo
• Creare un Lakehouse per la data science in DoorDash

Parla con il team del tuo account Databricks, che potrà guidarti in una discussione sui tuoi requisiti, aiutarti ad adattare questa architettura di riferimento ai tuoi progetti e coinvolgere ulteriori risorse necessarie per la formazione e l'implementazione.

Per ulteriori informazioni di base sull'MLOps, consigliamo:

• La necessità di piattaforme ML incentrate sui dati → Questo post spiega in dettaglio l'MLOps e la necessità di un approccio incentrato sui dati, e presenta un esempio concreto di un team di dati che sviluppa una nuova applicazione basata sull'ML.
• Tre principi per la scelta delle piattaforme di machine learning → Questo post è di un livello superiore rispetto a quello attuale. Discute la scelta della tecnologia per le piattaforme ML, fornisce linee guida di alto livello e cita storie di clienti correlate.
• La guida completa ai feature store → I feature store sono un argomento a sé stante. Questa guida offre un approfondimento.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale