Orchestrer MLOps à l’aide d’Azure Databricks

Cet article présente une architecture et un processus d’opérations de Machine Learning (MLOps) qui utilisent Azure Databricks. Ce processus définit un moyen standardisé de déplacer des modèles et des pipelines Machine Learning du développement vers la production, avec des options permettant d’inclure des processus automatisés et manuels.

Architecture

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

Workflow

Cette solution offre un processus MLOps robuste qui utilise Azure Databricks. Tous les éléments de l’architecture sont enfichables. Vous pouvez donc intégrer d’autres services Azure et tiers à travers l’architecture en fonction de vos besoins. Cette architecture et cette description sont adaptées du livre électronique The Big Book of MLOps. Ce livre électronique explore plus en détail l’architecture décrite ici.

• Contrôle de code : le référentiel de code de ce projet organise les notebooks, les modules et les pipelines. Les scientifiques des données créent des branches de développement pour tester les mises à jour et les nouveaux modèles. Le code est développé dans des notebooks ou dans des IDE, soutenus par Git, avec l’intégration de Databricks Repos pour la synchronisation avec vos espaces de travail Azure Databricks. Le contrôle de code source favorise les pipelines Machine Learning à partir du développement, puis à la phase intermédiaire (pour les tests) et à la production (pour le déploiement).

• Lakehouse - Données de production : les scientifiques des données travaillent dans l’environnement de développement, où ils ont un accès en lecture seule aux données de production. (Vous pouvez également mettre en miroir ou modifier les données.) Ils ont également accès en lecture/écriture à un environnement de stockage de développement pour le développement et l’expérimentation. Nous recommandons une architecture Lakehouse pour les données, où les données sont stockées dans Azure Data Lake Storage au format Delta Lake. Les contrôles d’accès sont définis à l’aide du passage des informations d’identification Microsoft Entra ou de contrôles d’accès aux tables.

Développement

Dans l’environnement de développement, les scientifiques des données et les ingénieurs développent des pipelines Machine Learning.

1. Analyse exploratoire des données (EDA) : les scientifiques des données explorent les données dans un processus itératif interactif. Ce travail ad hoc peut ne pas être déployé en préproduction ou en production. Les outils peuvent inclure Databricks SQL, dbutils.data.summarize et AutoML.

2. Formation de modèleset autres pipelines de Machine Learning : Les pipelines de Machine Learning sont développés sous forme de code modulaire dans des notebooks et/ou des IDE. Par exemple, le pipeline de formation de modèle lit les données du Magasin de caractéristiques et d’autres tables Lakehouse. Paramètres et métriques du modèle de journal de formation et de paramétrage sur le serveur de suivi MLflow. L’API Magasin de caractéristiques enregistre le modèle final. Ces journaux relient le modèle, ses entrées et le code de formation.

3. Code de validation : pour promouvoir le workflow Machine Learning en production, le scientifique des données valide le code pour la caractérisation, la formation et d’autres pipelines vers le contrôle de code source.

Staging

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

4. Requête de fusion : lorsqu’une requête de fusion (ou de tirage) est envoyée 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.

5. Tests unitaires et CI : les tests unitaires s’exécutent dans l’infrastructure CI et les tests d’intégration exécutent des workflows de bout en bout sur Azure Databricks. Si les tests réussissent, les changements de code sont fusionnés.

6. Créer une branche de mise en production : lorsque les ingénieurs Machine Learning sont prêts à déployer les pipelines Machine Learning mis à jour en production, ils peuvent 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.

7. Actualisation de la table de caractéristiques : ce pipeline lit les données, calcule les caractéristiques et écrit dans les tables du Magasin de caractéristiques. Il s’exécute en continu en mode diffusion en continu, suit une planification ou est déclenché.

8. Formation du modèle : En production, le pipeline de formation ou de reformation du modèle est déclenché ou planifié pour former un modèle nouveau sur les dernières données de production. Les modèles sont inscrits dans le Registre de modèles MLflow.

9. Déploiement continu : l’inscription de nouvelles versions de modèle déclenche le pipeline CD, qui exécute des tests pour s’assurer que le modèle fonctionnera bien en production. À mesure que le modèle réussit des tests, sa progression est suivie dans le Registre de modèles via des transitions de phase de modèle. Les webhooks de Registre peuvent être utilisés pour l’automatisation. Les tests peuvent inclure des vérifications de conformité, des tests A/B pour comparer le nouveau modèle avec le modèle de production actuel et des tests d’infrastructure. Les résultats et les métriques de test sont enregistrés dans des tables Lakehouse. Vous pouvez éventuellement exiger des déconnexions manuelles avant la transition des modèles vers la production.

10. Déploiement de modèle : quand 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 lot ou en continu : Pour les latences de quelques minutes ou plus, 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 caractéristiques, charge la dernière version du modèle de production à partir du Registre de modèles et effectue une inférence dans un travail Databricks. Il peut publier des prédictions dans 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’utilisation à faible latence, un service en ligne est généralement nécessaire. MLflow peut déployer des modèles sur MLflow Model Serving sur Azure Databricks, des systèmes de service de fournisseurs cloud et d’autres systèmes. Dans tous les cas, le système de service est initialisé avec le dernier modèle de production à partir du Registre de modèles. Pour chaque requête, il récupère les caractéristiques d’un magasin de caractéristiques en ligne, score les données et retourne des prédictions.

11. 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. Les tables dynamiques Delta peuvent simplifier l’automatisation des pipelines de supervision, en stockant les métriques dans des tables Lakehouse. Databricks SQL, Power BI et d’autres outils peuvent lire ces tables pour créer des tableaux de bord et des alertes.

12. Reformation : cette architecture prend en charge la reformation manuelle et automatique. Les travaux de reformation planifiés sont le moyen le plus simple de maintenir des modèles à jour.

Composants

• Data Lakehouse. Une architecture Lakehouse unifie les meilleurs éléments des lacs de données et des entrepôts de données, fournissant la gestion et les performances des données généralement trouvées dans les entrepôts de données avec les magasins d’objets flexibles à faible coût offerts par les lacs de données.
  • Delta Lake est le choix recommandé pour un format de données à source ouverte 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. Voici ses principaux composants :
  • Tracking vous permet d’effectuer le suivi des expériences pour enregistrer et comparer les paramètres et les résultats.
    • Databricks Autologging étend la journalisation automatique de MLflow pour suivre les expériences de Machine Learning, en enregistrant automatiquement les paramètres des modèles, les métriques, les fichiers et les informations de traçabilité.
  • MLFlow Model vous permet de stocker et de déployer des modèles à partir de n’importe quelle bibliothèque de Machine Learning vers diverses plateformes de service de modèles et d’inférence.
  • Model Registry fournit un magasin de modèles centralisé pour gérer les transitions entre les niveaux du cycle de vie des modèles, du développement à la production.
  • Model Serving vous permet d’héberger les modèles MLflow en tant que points de terminaison REST.
• Azure Databricks. Azure Databricks fournit un service MLflow géré avec des fonctions de sécurité d’entreprise, une haute disponibilité et des intégrations avec d’autres fonctions de l’espace de travail Azure Databricks.
  • Databricks Runtime pour le Machine Learning automatise la création d’un cluster optimisé pour le Machine Learning, préinstallant les bibliothèques d’apprentissage automatique populaires telles que TensorFlow, PyTorch et XGBoost en plus d’Azure Databricks pour les outils Machine Learning tels que les clients AutoML et Magasin de caractéristiques.
  • Le Magasin de caractéristiques est un référentiel centralisé de fonctionnalités. Cela rend possible le partage et la découverte des fonctionnalités, et permet d’éviter l’asymétrie des données entre la formation et l’inférence des données.
  • Databricks SQL. Databricks SQL offre une expérience simple pour les requêtes SQL sur les données Lakehouse et pour les visualisations, les tableaux de bord et les alertes.
  • Databricks Repos fournit une intégration avec votre fournisseur Git dans l’espace de travail Azure Databricks, simplifiant le développement collaboratif de notebooks ou de code et l’intégration aux 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. Les personnalisations courantes sont les suivantes :

• Plusieurs espaces de travail de développement qui partagent un espace de travail de production commun.
• Échange d’un ou plusieurs composants d’architecture pour votre infrastructure existante. Par exemple, vous pouvez utiliser Azure Data Factory pour orchestrer des travaux Databricks.
• Intégration à vos outils CI/CD existants via des API REST Git et Azure Databricks.

Détails du scénario

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 Architecte MLOps sur le Lakehouse.

À l’aide de cette architecture, vous pouvez :

• Connecter vos parties prenantes aux équipes de Machine Learning et de science des données. Cette architecture permet aux scientifiques des données d’utiliser des notebooks et des IDE pour le développement. Cela permet aux parties prenantes de l’entreprise d’afficher les métriques et les tableaux de bord dans Databricks SQL, le tout dans la même architecture Lakehouse.
• Rendez votre infrastructure de Machine Learning centrée sur les données. Cette architecture traite les données de Machine Learning (données issues de l’ingénierie des caractéristiques, de la formation, de l’inférence et de la supervision) comme toutes les autres données. Elle réutilise les outils pour les pipelines de production, les tableaux de bord et d’autres traitements de données généraux pour le traitement des données de Machine Learning.
• Implémentez MLOps dans les modules et les pipelines. Comme pour toute application logicielle, les pipelines et le code modulaires de cette architecture permettent de tester des composants individuels et de 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 toutes les étapes n’ont pas à être automatisées. 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 /IA utilisées 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). À chaque étape de l’architecture, vous pouvez choisir des ressources de calcul et des bibliothèques pour s’adapter à vos dimensions de données et de problèmes.

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 et des architectures similaires incluent de petites et grandes organisations dans des secteurs comme les 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 le site web Databricks.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

• Brandon Cowen | Architecte de solution cloud senior

Autre contributeur :

• Mick Alberts | Rédacteur technique

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

Étapes suivantes

• The Big Book of MLOps
• Besoin de plateformes ML centrées sur les données (introduction à MLOps)
• Démarrage rapide de Databricks Machine Learning dans le produit
• Tutoriels de 10 minutes : Bien démarrer avec le Machine Learning dans Azure Databricks
• Documentation Databricks Machine Learning
• Ressources et pages produit de Databricks Machine Learning
• MLOps sur Databricks : Guide pratique
• Automatisation du cycle de vie ML avec Databricks Machine Learning
• MLOps sur Azure Databricks avec MLflow
• Machine Learning Engineering for the Real World
• Automatiser votre pipeline Machine Learning
• Databricks Academy
• Projet GitHub Databricks Academy
• Glossaire MLOps
• Trois principes de sélection des plateformes Machine Learning
• Qu’est-ce qu’un Lakehouse ?
• Page d’accueil de Delta Lake
• Ingérer des données dans le lakehouse Azure Databricks
• Clusters
• Bibliothèques
• Documentation de MLflow
• Guide d’Azure Databricks MLflow
• Partager des modèles dans des espaces de travail
• Notebooks
• Outils et conseils de développement
• Déployer des modèles MLflow sur des points de terminaison en ligne dans Azure Machine Learning
• Déployer sur Azure Kubernetes Service (AKS)

Ressources associées

• Framework des opérations MLOps pour améliorer le cycle de vie du machine learning avec Azure Machine Learning
• MLOps v2
• Modèle de maturité MLOps