Utiliser Azure Databricks pour orchestrer MLOps

Azure Databricks

Idées de solution

Cet article présente une idée de solution. Votre architecte cloud peut s’appuyer sur ces conseils pour visualiser les principaux composants d’une implémentation typique de cette architecture. Utilisez cet article comme point de départ pour concevoir une solution bien conçue qui répond aux exigences spécifiques de votre charge de travail.

Cet article présente une architecture et un processus d’opérations de Machine Learning (MLOps) qui utilisent Azure Databricks. Les scientifiques et ingénieurs données peuvent utiliser ce processus standardisé pour déplacer des modèles et des pipelines Machine Learning de développement en production.

Cette solution peut tirer parti de l’automatisation complète, de la supervision continue et de la collaboration robuste. Par conséquent, il cible le niveau 4 de maturité MLOps. Cette architecture utilise le code de promotion qui génère l’approche du modèle plutôt que l’approche de promotion des modèles . Le code de promotion qui génère l’approche du modèle se concentre sur l’écriture et la gestion du code qui génère des modèles Machine Learning. Les recommandations de cet article incluent des options pour les processus automatisés ou manuels.

Architecture

Téléchargez un fichier Visio de cette architecture.

Flux de travail

Le flux de travail suivant correspond au diagramme précédent. Utilisez les composants de contrôle de code source et de stockage pour gérer et organiser le code et les données.

Contrôle de code : le référentiel de code de ce projet organise les notebooks, les modules et les pipelines. Vous pouvez créer des branches de développement pour tester les mises à jour et les nouveaux modèles. Développez du code dans des notebooks pris en charge par Git ou dans des environnements de développement intégrés (IDEs) qui s’intègrent aux dossiers Git afin de pouvoir vous synchroniser avec vos espaces de travail Azure Databricks. Le contrôle de code source promeut les pipelines Machine Learning de l’environnement de développement, les tests dans l’environnement intermédiaire et le déploiement dans l’environnement de production.

Données de production Lakehouse : en tant que scientifique des données, vous avez un accès en lecture seule aux données de production dans l’environnement de développement. L’environnement de développement peut avoir des données mises en miroir et des données confidentielles modifiées. Vous disposez également d’un accès en lecture et en écriture dans un environnement de stockage de développement pour le développement et l’expérimentation. Nous vous recommandons d’utiliser une architecture lakehouse pour les données dans lesquelles vous stockez des données au format Delta Lake dans Azure Data Lake Storage. Un lakehouse fournit une solution robuste, évolutive et flexible pour la gestion des données. Pour définir des contrôles d’accès, utilisez des contrôles d’accès aux tables.

Le flux de travail principal se compose des environnements suivants.

Développement

Dans l’environnement de développement, vous développez des pipelines Machine Learning.

Effectuez une analyse exploratoire des données (EDA). Explorez les données dans un processus interactif et itératif. Vous risquez de ne pas déployer ce travail en préproduction ou en production. Utilisez des outils tels que Databricks SQL, la commande dbutils.data.summarize et Databricks AutoML.
Développez l’entraînement du modèle et d’autres pipelines d’apprentissage automatique. Développez du code modulaire de pipelines Machine Learning et orchestrez du code via des notebooks Databricks ou un projet MLflow. Dans cette architecture, le pipeline d’apprentissage du modèle lit les données du magasin de fonctionnalités et d’autres tables lakehouse. Le pipeline effectue l’apprentissage et l’ajustement des paramètres et des métriques du modèle de journal vers le serveur de suivi MLflow. L’API du magasin de fonctionnalités journalise le modèle final. Ces journaux incluent le modèle, ses entrées et le code d’entraînement.
Valider le code. Pour promouvoir le flux de travail Machine Learning vers la production, validez le code pour la caractérisation, l’entraînement et d’autres pipelines vers le contrôle de code source. Dans la base de code, placez du code Machine Learning et du code opérationnel dans différents dossiers afin que les membres de l’équipe puissent développer du code en même temps. Le code Machine Learning est du code lié au modèle et aux données. Le code opérationnel est du code lié aux travaux et à l’infrastructure Databricks.

Ce cycle principal d’activités que vous effectuez lorsque vous écrivez et testez du code est appelé processus innerloop. Pour effectuer le processus innerloop pour la phase de développement, utilisez Visual Studio Code (VS Code) en combinaison avec l’interface de ligne de commande du conteneur de développement (CLI) et l’interface CLI Databricks. Vous pouvez écrire le code et effectuer des tests unitaires localement. Vous devez également soumettre, surveiller et analyser les pipelines de modèle à partir de l’environnement de développement local.

Mise en scène

Dans l’environnement intermédiaire, l’infrastructure d’intégration continue (CI) teste les modifications apportées aux pipelines Machine Learning dans un environnement qui imite la production.

Fusionnez une requête. Lorsque vous soumettez une demande de fusion ou un pull request sur la branche intermédiaire (ou principale) du projet dans le système de contrôle de version, un outil d’intégration continue et de livraison continue (CI/CD) tel que Azure DevOps exécute des tests.
Exécutez des tests unitaires et des tests CI. Les tests unitaires s’exécutent dans l’infrastructure CI et les tests d’intégration s’exécutent dans des workflows de bout en bout sur Azure Databricks. Si les tests réussissent, les changements de code sont fusionnés.
Générez une branche de mise en production. Lorsque vous souhaitez déployer les pipelines Machine Learning mis à jour en production, vous pouvez créer une nouvelle version. Un pipeline de déploiement dans l’outil CI/CD redéploie les pipelines mis à jour en tant que nouveaux workflows.

Production

Les ingénieurs Machine Learning gèrent l’environnement de production, où les pipelines Machine Learning servent directement des applications de bout en bout. Les principaux pipelines en production actualisent les tables de caractéristiques, forment et déploient de nouveaux modèles, exécutent l’inférence ou le service, et surveillent les performances des modèles.

Actualisation de la table de fonctionnalités : ce pipeline lit les données, calcule les fonctionnalités et écrit dans les tables de magasin de fonctionnalités. Vous pouvez configurer ce pipeline pour qu’il s’exécute en continu en mode streaming, s’exécuter selon une planification ou s’exécuter sur un déclencheur.
Entraînement du modèle : En production, vous pouvez configurer le pipeline d’entraînement ou de réentraînement du modèle pour qu’il s’exécute sur un événement déclencheur ou un calendrier afin d’entraîner un modèle neuf sur les données de production les plus récentes. Les modèles s’inscrivent automatiquement dans le catalogue Unity.
Évaluation et promotion du modèle : Lorsqu’une nouvelle version de modèle est inscrite, le pipeline CD démarre, qui exécute des tests pour s’assurer que le modèle fonctionne correctement en production. Lorsque le modèle réussit les tests, Unity Catalog suit sa progression via des transitions d’étape de modèle. Les tests incluent des vérifications de conformité, des tests A/B pour comparer le nouveau modèle avec le modèle de production actuel et les tests d’infrastructure. Les tables Lakehouse enregistrent les résultats et les métriques des tests. Vous pouvez éventuellement exiger des déconnexions manuelles avant la transition des modèles vers la production.
Déploiement de modèle : lorsqu’un modèle entre en production, il est déployé pour le scoring ou le service. Les modes de déploiement les plus courants incluent les options suivantes :
- Scoring par lots ou streaming : pour les latences de minutes ou plus longues, le traitement par lots et la diffusion en continu sont les options les plus rentables. Le pipeline de scoring lit les données les plus récentes du magasin de fonctionnalités, charge la dernière version du modèle de production à partir du catalogue Unity et effectue l’inférence dans un travail Databricks. Il peut publier des prédictions sur des tables lakehouse, une connexion JDBC (Java Database Connectivity), des fichiers plats, des files d’attente de messages ou d’autres systèmes en aval.
- Service en ligne (API REST) : pour les cas d’usage à faible latence, vous avez généralement besoin d’un service en ligne. MLflow peut déployer des modèles sur Mosaïque AI Model Serving, les systèmes de service de fournisseurs de cloud et d’autres systèmes. Dans tous les cas, le système de service initialise avec le dernier modèle de production à partir du catalogue Unity. Pour chaque requête, elle extrait les fonctionnalités d’un magasin de fonctionnalités en ligne et effectue des prédictions.
Surveillance : des workflows continus ou périodiques surveillent les données d’entrée et les prédictions de modèle pour les prédictions de dérive, de performances et d’autres métriques. Vous pouvez utiliser le cadre pipelines déclaratifs de Lakeflow pour automatiser la surveillance des pipelines et stocker les métriques dans les tables lakehouse. Databricks SQL, Power BI et d’autres outils peuvent lire ces tables pour créer des tableaux de bord et des alertes. Pour surveiller les métriques d’application, les journaux et l’infrastructure, vous pouvez également intégrer Azure Monitor à Azure Databricks.
Détection de dérive et réentraînement de modèle : cette architecture prend en charge le réentraînement manuel et automatique. Planifiez la réentraînation des travaux pour maintenir les modèles actualisés. Une fois qu’une dérive détectée traverse un seuil préconfiguré que vous avez défini à l’étape de surveillance, les pipelines de réentraînement analysent la dérive et déclenchent la réentraînation. Vous pouvez configurer des pipelines pour démarrer automatiquement, ou vous pouvez recevoir une notification, puis exécuter les pipelines manuellement.

Composants

Une architecture data lakehouse unifie les éléments des lacs de données et des entrepôts de données. Cette architecture utilise un lakehouse pour obtenir des fonctionnalités de gestion et de performances des données que vous trouvez généralement dans les entrepôts de données, mais avec les magasins d’objets flexibles à faible coût que fournissent les lacs de données.

Nous vous recommandons Delta Lake comme format de données open source pour un lakehouse. Dans cette architecture, Delta Lake stocke toutes les données de Machine Learning dans Data Lake Storage et fournit un moteur de requête hautes performances.
MLflow est un projet open source permettant de gérer le cycle de vie machine learning de bout en bout. Dans cette architecture, MLflow effectue le suivi des expériences, gère les versions de modèle et facilite le déploiement de modèles sur différentes plateformes d’inférence. MLflow a les composants suivants :
- La fonctionnalité de suivi dans MLflow est un système permettant de journaliser et de gérer des expériences de Machine Learning. Dans cette architecture, elle enregistre et organise les paramètres, les métriques et les artefacts de modèle pour chaque exécution de l’expérience. Cette fonctionnalité vous permet de comparer les résultats, de reproduire des expériences et d’auditer le développement de modèles.
- Databricks autologging est une fonctionnalité d’automatisation qui étend la journalisation automatique MLflow pour suivre les expériences de Machine Learning en capturant les paramètres de modèle, les métriques, les fichiers et les informations de traçabilité. Dans cette architecture, l'autologging de Databricks garantit un suivi et une reproductibilité cohérents des expériences en enregistrant ces détails automatiquement.
- Un modèle MLflow est un format d’empaquetage standardisé. Dans cette architecture, les modèles MLflow prennent en charge le stockage et le déploiement de modèles sur différentes plateformes de service et d’inférence.
- Unity Catalog est une solution de gouvernance des données qui fournit un contrôle d’accès centralisé, un audit, une traçabilité et des fonctionnalités de découverte des données dans les espaces de travail Azure Databricks. Dans cette architecture, elle régit l’accès, gère la traçabilité et structure les modèles et les données entre les espaces de travail.
- Mosaïque AI Model Service est un service qui héberge des modèles MLflow en tant que points de terminaison REST. Dans cette architecture, elle permet aux modèles Machine Learning déployés de servir des prédictions via des API.
Azure Databricks est une plateforme managée pour l’analytique et le Machine Learning. Dans cette architecture, Azure Databricks s’intègre à la sécurité d’entreprise, fournit une haute disponibilité et connecte MLflow et d’autres composants machine learning pour mlOps de bout en bout.
- Databricks Runtime pour Machine Learning est un environnement préconfiguré qui automatise la création d’un cluster optimisé pour le Machine Learning et préinstalle des bibliothèques de Machine Learning populaires telles que TensorFlow, PyTorch et XGBoost. Il préinstalle également Azure Databricks pour les outils Machine Learning, comme AutoML et les clients de magasin de fonctionnalités. Dans cette architecture, elle fournit des clusters prêts à l’emploi avec des bibliothèques et des outils de Machine Learning populaires.
- Un magasin de fonctionnalités est un référentiel centralisé de fonctionnalités. Dans cette architecture, le magasin de fonctionnalités prend en charge la découverte et le partage des fonctionnalités, et permet d’empêcher l’asymétrie des données entre l’entraînement et l’inférence des modèles.
- Databricks SQL est un entrepôt de données serverless qui s’intègre à différents outils afin de pouvoir créer des requêtes et des tableaux de bord dans vos environnements préférés sans s’ajuster à une nouvelle plateforme. Dans cette architecture, Databricks SQL vous permet d’interroger des données et de créer des tableaux de bord pour l’analyse et la création de rapports.
- Les dossiers Git sont des répertoires d’espace de travail intégrés. Dans cette architecture, les dossiers Git connectent des espaces de travail Azure Databricks à votre fournisseur Git. Cette intégration améliore la collaboration autour des notebooks ou des codes ainsi que l’intégration des IDE.
- Les flux de travail et les travaux permettent d’exécuter du code non interactif dans un cluster Azure Databricks. Dans cette architecture, les flux de travail et les travaux fournissent une automatisation pour la préparation des données, la caractérisation, la formation, l’inférence et la supervision.

Autres solutions

Vous pouvez adapter cette solution à votre infrastructure Azure. Tenez compte des personnalisations suivantes :

Utilisez plusieurs espaces de travail de développement qui partagent un espace de travail de production commun.
Échangez un ou plusieurs composants d’architecture pour votre infrastructure existante. Par exemple, vous pouvez utiliser Azure Data Factory pour orchestrer des travaux Databricks.
Intégrez vos outils CI/CD existants via Git et les API REST Azure Databricks.
Utilisez Microsoft Fabric comme autre service pour les fonctionnalités de Machine Learning. Fabric fournit des charges de travail intégrées pour l’ingénierie des données (lakehouses avec Apache Spark), l’entreposage de données et OneLake pour le stockage unifié.

Détails du scénario

Cette solution offre un processus MLOps robuste qui utilise Azure Databricks. Vous pouvez remplacer tous les éléments de l’architecture afin de pouvoir intégrer d’autres services Azure et services partenaires en fonction des besoins. Cette architecture et cette description sont adaptées à partir du livre électronique The Big Book of MLOps : Second Edition. Le livre électronique explore cette architecture plus en détail.

MLOps permet de réduire le risque d’échecs dans les systèmes Machine Learning et IA et d’améliorer l’efficacité de la collaboration et des outils. Pour une présentation de MLOps et une vue d’ensemble de cette architecture, consultez Architecture MLOps sur le lakehouse.

Utilisez cette architecture pour effectuer les actions suivantes :

Connecter vos parties prenantes aux équipes de Machine Learning et de science des données. Utilisez cette architecture pour incorporer des notebooks et des IDE pour le développement. Les parties prenantes métier peuvent afficher les métriques et les tableaux de bord dans Databricks SQL, dans la même architecture lakehouse.
Concentrez votre infrastructure Machine Learning autour des données. Cette architecture traite les données d’apprentissage automatique comme d’autres données. Les données de Machine Learning incluent des données provenant de l’ingénierie des fonctionnalités, de l’entraînement, de l’inférence et de la supervision. Cette architecture réutilise les outils pour les pipelines de production, les tableaux de bord et d’autres traitements généraux des données pour le traitement des données machine learning.
Implémentez MLOps dans les modules et les pipelines. Comme pour toute application logicielle, utilisez les pipelines et le code modulaires dans cette architecture pour tester des composants individuels et réduire le coût de la refactorisation future.
Automatisez vos processus MLOps en fonction de vos besoins. Dans cette architecture, vous pouvez automatiser les étapes pour améliorer la productivité et réduire le risque d’erreur humaine, mais vous n’avez pas besoin d’automatiser chaque étape. Azure Databricks autorise les processus manuels et d’interface utilisateur, ainsi que les API pour l’automatisation.

Cas d’usage potentiels

Cette architecture s’applique à tous les types de Machine Learning, de Deep Learning et d’analytique avancée. Cette architecture utilise les techniques courantes de Machine Learning et d’IA suivantes :

Apprentissage automatique classique, comme les modèles linéaires, les modèles d'arbres et le boosting
Deep Learning moderne, comme TensorFlow et PyTorch
Analytique personnalisée, comme les statistiques, les méthodes bayésiennes et l’analytique des graphiques

L’architecture prend en charge les petites données sur une seule machine et les données volumineuses à l’aide de ressources accélérées par l’informatique distribuée et l’unité de traitement graphique (GPU). À chaque étape de l’architecture, vous pouvez choisir des ressources de calcul et des bibliothèques pour s’adapter à la taille des données et aux dimensions de problème de votre scénario.

L’architecture s’applique à tous les types de secteurs d’activité et cas d’usage métier. Les clients Azure Databricks qui utilisent cette architecture incluent de petites et grandes organisations dans les secteurs suivants :

Biens de consommation et services de vente au détail
Services financiers
Santé et sciences de la vie
Technologies de l’information

Pour plus d’informations, consultez Les clients Databricks.

Réglage précis du modèle de base dans les flux de travail MLOps

Comme d’autres organisations utilisent des modèles de langage volumineux pour des tâches spécialisées, elles doivent ajouter un réglage précis du modèle de base au processus MLOps. Vous pouvez utiliser Azure Databricks pour affiner les modèles de base avec vos données. Cette fonctionnalité prend en charge les applications personnalisées et un processus MLOps mature. Dans le contexte de l’architecture MLOps de cet article, le réglage s’aligne sur plusieurs bonnes pratiques :

Pipelines et codes modulaires : Les tâches de réglage précis peuvent être encapsulées en tant que composants modulaires dans le pipeline d’apprentissage. Cette structure permet une évaluation isolée et simplifie la refactorisation.
Suivi de l’expérience (exécution de réglage précis) : L’intégration de MLflow journalise chaque exécution de réglage précis avec des paramètres spécifiques comme le nombre d’époques et le taux d’apprentissage, et avec des métriques telles que la perte et l’entropie croisée. Ce processus améliore la reproductibilité, l’auditabilité et la capacité à mesurer les améliorations.
Registre et déploiement de modèles : Les modèles affinés sont automatiquement inscrits dans le catalogue Unity. Cette automatisation prend en charge le déploiement et la gouvernance.
Automatisation et CI/CD : Vous pouvez lancer des travaux de réglage précis via des flux de travail Databricks ou des pipelines CI/CD. Ce processus prend en charge les cycles d’apprentissage continu et d’actualisation du modèle.

Cette approche permet aux équipes de maintenir une maturité MLOps élevée tout en utilisant la flexibilité et la puissance des modèles de base. Pour plus d’informations, consultez affinement du modèle de fondation.

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Principaux auteurs :

Brandon Cowen | Architecte de solution cloud senior
Prabal Deb | Ingénieur logiciel principal

Autres contributeurs :

Rodrigo Rodríguez | Architecte de solution cloud senior, IA &Quantum

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

Commentaires

Cette page a-t-elle été utile ?