Procedure consigliate per i progetti di data science con l'analisi su scala cloud in Azure

È consigliabile usare l'analisi su scala cloud in Microsoft Azure per rendere operativi i progetti di data science.

Sviluppare un modello

Sviluppare un modello che aggrega un set di servizi per i progetti di data science. Usare un modello che aggrega un set di servizi per garantire la coerenza tra i vari casi d'uso dei team di data science. È consigliabile sviluppare un progetto coerente sotto forma di repository di modelli. È possibile usare questo repository per vari progetti di data science all'interno dell'organizzazione per ridurre i tempi di distribuzione.

Linee guida per i modelli di data science

Sviluppare un modello di data science per l'organizzazione con le linee guida seguenti:

• Sviluppare un set di modelli di infrastruttura come codice (IaC) per distribuire un'area di lavoro di Azure Machine Learning. Includere risorse come un insieme di credenziali delle chiavi, un account di archiviazione, un registro contenitori e Application Insights.

• Includere la configurazione di archivi dati e destinazioni di calcolo in questi modelli, ad esempio istanze di calcolo, cluster di calcolo e Azure Databricks.

Procedura consigliate per la distribuzione

In tempo reale

• Includere una distribuzione di Azure Data Factory o Azure Synapse nei modelli e in Servizi cognitivi di Azure.
• I modelli devono fornire tutti gli strumenti necessari per eseguire la fase di esplorazione di data science e l'operazionalizzazione iniziale del modello.

Considerazioni per una configurazione iniziale

In alcuni casi, i data scientist dell'organizzazione potrebbero richiedere un ambiente per un'analisi rapida in base alle esigenze. Questa situazione è comune quando un progetto di data science non è configurato formalmente. Ad esempio, un project manager, un codice di costo o un centro di costo che potrebbe essere necessario per l'addebito incrociato in Azure potrebbe non essere presente perché l'elemento mancante richiede l'approvazione. Gli utenti dell'organizzazione o del team potrebbero dover accedere a un ambiente di data science per comprendere i dati ed eventualmente valutare la fattibilità di un progetto. Inoltre, alcuni progetti potrebbero non richiedere un ambiente di data science completo a causa del numero ridotto di prodotti dati.

In altri casi, potrebbe essere necessario un progetto di data science completo, dotato di ambiente dedicato, gestione del progetto, codice di costo e centro di costo. I progetti di data science completi sono utili per più membri del team che vogliono collaborare, condividere i risultati e dover rendere operativi i modelli al termine della fase di esplorazione.

Processo di configurazione

I modelli devono essere distribuiti in base al progetto dopo la configurazione. Ogni progetto deve ricevere almeno due istanze per separare gli ambienti di sviluppo e produzione. Nell'ambiente di produzione, nessun utente deve avere accesso e tutto deve essere distribuito tramite pipeline di sviluppo continuo o di sviluppo continuo e un'entità servizio. Questi principi dell'ambiente di produzione sono importanti perché Azure Machine Learning non fornisce un modello granulare di controllo degli accessi in base al ruolo all'interno di un'area di lavoro. Non è possibile limitare l'accesso degli utenti a un set specifico di esperimenti, endpoint o pipeline.

Gli stessi diritti di accesso si applicano in genere a tipi diversi di artefatti. È importante separare lo sviluppo dall'ambiente di produzione per impedire l'eliminazione di pipeline o endpoint di produzione all'interno di un'area di lavoro. Oltre al modello, è necessario creare un processo per offrire ai team dei prodotti dati la possibilità di richiedere nuovi ambienti.

È consigliabile configurare diversi servizi di intelligenza artificiale come Servizi cognitivi di Azure per ogni progetto. Configurando diversi servizi di intelligenza artificiale in base al progetto, le distribuzioni vengono eseguite per ogni gruppo di risorse del prodotto dati. Questo criterio crea una netta separazione dal punto di vista dell'accesso ai dati e riduce il rischio di accesso non autorizzato ai dati da parte dei team sbagliati.

Scenario di streaming

Per i casi d'uso in tempo reale e di streaming, le distribuzioni devono essere testate in un servizio Azure Kubernetes (servizio Azure Kubernetes) ridotto. I test possono essere effettuati nell'ambiente di sviluppo per risparmiare sui costi prima della distribuzione nel servizio Azure Kubernetes o nel Servizio app di Azure per i contenitori dell'ambiente di produzione. È consigliabile eseguire semplici test di input e output per assicurarsi che i servizi rispondano come previsto.

Successivamente, è possibile distribuire i modelli nel servizio desiderato. Questa destinazione di calcolo della distribuzione è l'unica disponibile a livello generale e consigliata per i carichi di lavoro di produzione in un cluster del servizio Azure Kubernetes. Questo passaggio è maggiormente necessario se è richiesto il supporto di FPGA (Field Programmable Gate Array) o GPU (Graphical Processing Unit). Altre opzioni di distribuzione native che supportano questi requisiti hardware non sono attualmente disponibili in Azure Machine Learning.

Azure Machine Learning richiede il mapping uno-a-uno ai cluster del servizio Azure Kubernetes. Ogni nuova connessione a un'area di lavoro di Azure Machine Learning interrompe la connessione precedente tra il servizio Azure Kubernetes e Azure Machine Learning. Dopo aver mitigato questa limitazione, è consigliabile distribuire i cluster centrali del servizio Azure Kubernetes come risorse condivise e collegarli alle rispettive aree di lavoro.

Se è necessario eseguire test di stress prima di spostare un modello nel servizio Azure Kubernetes dell'ambiente di produzione, occorre ospitare un'altra istanza centrale di test del servizio Azure Kubernetes. L'ambiente di test deve fornire la stessa risorsa di calcolo dell'ambiente di produzione per garantire che i risultati siano il più simili possibile all'ambiente di produzione.

Scenario batch

Non tutti i casi d'uso richiedono distribuzioni del cluster del servizio Azure Kubernetes. Un caso d'uso non richiede una distribuzione del cluster del servizio Azure Kubernetes se gli importi di dati di grandi dimensioni richiedono l'assegnazione di punteggi regolarmente o sono basati su un evento. Ad esempio, grandi quantità di dati possono essere basate su quando i dati si eliminano in un account di archiviazione specifico. Per la distribuzione durante questi tipi di scenari è consigliabile usare le pipeline di Azure Machine Learning e i cluster di elaborazione di Azure Machine Learning. Queste pipeline devono essere orchestrate ed eseguite in Data Factory.

Identificare le risorse di calcolo appropriate

Prima di distribuire un modello in Azure Machine Learning in un servizio Azure Kubernetes, l'utente deve specificare le risorse come CPU, RAM e GPU che è necessario allocare per il rispettivo modello. La definizione di questi parametri può essere un processo complesso e noioso. È necessario eseguire test di stress con configurazioni diverse per identificare un buon set di parametri. È possibile semplificare questo processo con la funzionalità Profiling modelli in Azure Machine Learning, un processo a esecuzione prolungata che testa diverse combinazioni di allocazione delle risorse e usa una latenza identificata e un tempo di round trip (RTT) identificato per consigliare una combinazione ottimale. Queste informazioni possono essere utili per la distribuzione effettiva del modello nel servizio Azure Kubernetes.

Per aggiornare in modo sicuro i modelli in Azure Machine Learning, i team devono usare la funzionalità di implementazione controllata (anteprima) per ridurre al minimo i tempi di inattività e mantenere coerente l'endpoint REST del modello.

Procedure consigliate e flusso di lavoro per MLOps

Includere codice di esempio nei repository di data science

È possibile semplificare e accelerare i progetti di data science se i team hanno determinati artefatti e procedure consigliate. È consigliabile creare artefatti che tutti i team di data science possono usare durante l'uso con Azure Machine Learning e i rispettivi strumenti dell'ambiente del prodotto dati. I data e i tecnici di Machine Learning devono creare e fornire gli artefatti.

Questi artefatti devono includere:

• Notebook di esempio che illustrano come:

  • Caricare, montare e usare prodotti dati.
  • Registrare metriche e parametri.
  • Inviare processi di training ai cluster di elaborazione.

• Artefatti necessari per l'operazionalizzazione:

  • Esempi di pipeline di Azure Machine Learning
  • Esempi di Azure Pipelines
  • Altri script necessari per eseguire le pipeline

• Documentazione

Usare artefatti ben progettati per operazionalizzare le pipeline

Gli artefatti possono velocizzare le fasi di esplorazione e operazionalizzazione dei progetti di data science. Una strategia di forking di DevOps può consentire di dimensionare questi artefatti in tutti i progetti. Poiché questa configurazione promuove l'uso di Git, gli utenti e il processo di automazione generale possono trarre vantaggio dagli artefatti forniti.

Le pipeline di esempio non funzionano per ogni progetto, ma possono essere usate come baseline. È possibile modificare le pipeline di esempio per i progetti. Una pipeline deve includere gli aspetti più rilevanti di ogni progetto. Ad esempio, una pipeline può fare riferimento a una destinazione di calcolo, fare riferimento a prodotti dati di riferimento, definire parametri, definire gli input e definire i passaggi di esecuzione. Lo stesso processo deve essere eseguito per Azure Pipelines. Anche Azure Pipelines deve usare l'SDK o l'interfaccia della riga di comando di Azure Machine Learning.

Le pipeline devono illustrare come:

• Connettersi a un'area di lavoro dall'interno di una pipeline DevOps.
• Controllare se è disponibile l'ambiente di calcolo richiesto.
• Inviare un processo.
• Registrare e distribuire un modello.

Gli artefatti non sono adatti a tutti i progetti per tutto il tempo e potrebbero richiedere la personalizzazione, ma avere una base può velocizzare l'operazionalizzazione e la distribuzione di un progetto.

Strutturare il repository MLOps

Potrebbero verificarsi situazioni in cui gli utenti perdono traccia della posizione in cui possono trovare e archiviare gli artefatti. Per evitare queste situazioni, è necessario richiedere più tempo per comunicare e costruire una struttura di cartelle di primo livello per il repository standard. Tutti i progetti devono seguire la struttura di cartelle.

La struttura di cartelle di primo livello proposta per un repository MLOps (operazioni di Machine Learning) è illustrata nel diagramma seguente:

Gli scopi seguenti si applicano a ogni cartella nel repository:

Passaggio successivo

Prodotti dati di analisi su scala cloud in Azure