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 surveillance continue et de la collaboration robuste, et cible donc un 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.
Workflow
Le workflow 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 le passage d’informations d’identification d’ID Microsoft Entra ou les contrôles d’accès à la table.
Les environnements suivants comprennent le flux de travail principal.
Développement
Dans l’environnement de développement, vous développez des pipelines Machine Learning.
Effectuer une analyse exploratoire des données (EDA) : explorez les données dans un processus itératif interactif. 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 de modèle et d’autres pipelines machine learning : 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.
Code de validation : 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 en combinaison avec l’interface CLI du conteneur de développement 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.
Staging
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.
Fusionner une demande : lorsque vous envoyez une demande de fusion ou une demande de tirage (pull) sur la branche intermédiaire (principale) du projet dans le contrôle de code source, un outil d’intégration continue et de livraison continue (CI/CD) comme Azure DevOps exécute des tests.
Exécuter 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.
Créer 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 de modèle pour qu’il s’exécute sur un déclencheur ou une planification pour entraîner un nouveau modèle 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 se déclenche, qui exécute des tests pour s’assurer que le modèle s’exécute 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 sont les suivants :
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 l’infrastructure Delta Live Tables 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 qu’ils se déclenchent automatiquement, ou vous pouvez recevoir une notification, puis exécuter manuellement les pipelines.
Composants
Une architecture data lakehouse unifie les éléments des lacs de données et des entrepôts de données. Utilisez un lakehouse pour obtenir des fonctionnalités de gestion et de performances des données généralement trouvées dans les entrepôts de données, mais avec les magasins d’objets flexibles à faible coût que proposent les lacs de données.
- Delta Lake est le format de données open source recommandé pour un lakehouse. Azure Databricks stocke les données dans Data Lake Storage et fournit un moteur de requête à hautes performances.
MLflow est un projet open source qui permet de gérer le cycle de vie du machine learning de bout en bout. MLflow a les composants suivants :
La fonctionnalité de suivi effectue le suivi des expériences, afin de pouvoir enregistrer et comparer des paramètres, des métriques et des artefacts de modèle.
- Databricks autologging étend la journalisation automatique MLflow pour suivre les expériences machine learning et journalise automatiquement les paramètres du modèle, les métriques, les fichiers et les informations de traçabilité.
Le modèle MLflow est un format que vous pouvez utiliser pour stocker et déployer des modèles à partir de n’importe quelle bibliothèque Machine Learning sur différentes plateformes de service de modèle et d’inférence.
Unity Catalog fournit des fonctionnalités centralisées de contrôle d’accès, d’audit, de traçabilité et de découverte des données dans les espaces de travail Azure Databricks.
Mosaïque AI Model Service héberge des modèles MLflow en tant que points de terminaison REST.
Azure Databricks fournit un service MLflow managé qui dispose de fonctionnalités de sécurité d’entreprise, de haute disponibilité et d’intégrations avec d’autres fonctionnalités d’espace de travail Azure Databricks.
Databricks Runtime pour Machine Learning automatise la création d’un cluster optimisé pour le Machine Learning et préinstalle les 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.
Un magasin de fonctionnalités est un référentiel centralisé de fonctionnalités. Utilisez le magasin de fonctionnalités pour découvrir et partager des fonctionnalités et empêcher l’asymétrie des données entre l’apprentissage du modèle et l’inférence.
Databricks SQL s’intègre à divers outils pour pouvoir créer des requêtes et des tableaux de bord dans vos environnements favoris sans s’ajuster à une nouvelle plateforme.
Les dossiers Git fournissent une intégration à votre fournisseur Git dans l’espace de travail Azure Databricks, ce qui améliore l’intégration du notebook ou du code et de l’IDE.
Les workflows et travaux permettent d’exécuter du code non interactif dans un cluster Azure Databricks. Pour le Machine Learning, les travaux fournissent une automatisation pour la préparation des données, la caractérisation, l’apprentissage, 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 ou Azure Synapse Analytics comme autres services pour les fonctionnalités de Machine Learning.
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 du livre électronique The Big Book of MLOps. 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 améliore 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 :
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.
Rendez votre infrastructure de Machine Learning centrée sur les 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 permet d’avoir une interface utilisateur et des processus manuels en plus des 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. Les techniques courantes de Machine Learning et d’IA dans cette architecture sont les suivantes :
- Machine Learning classique, comme les modèles linéaires, les modèles basés sur des arborescences et le renforcement (boosting).
- Deep Learning moderne, comme TensorFlow et PyTorch.
- Analytique personnalisée, comme les statistiques, les méthodes bayésiennes et l’analytique de graphe.
L’architecture prend en charge les petites données (machine unique) et les données volumineuses (calcul distribué et accélération GPU). Dans chaque phase de l’architecture, vous pouvez choisir des ressources de calcul et des bibliothèques pour s’adapter aux dimensions des données et des problèmes 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 obtenir des exemples, consultez les clients Databricks.
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Principaux auteurs :
- Brandon Cowen | Architecte de solution cloud senior
- Prabal Deb | Ingénieur logiciel principal
Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.