Architecture MLOps sur le Lakehouse

Chez Databricks, nous avons aidé des milliers de clients à mettre en production le Machine Learning (ML). Shell compte plus de 160 projets AI actifs qui permettent d'économiser des millions de dollars ; Comcast gère facilement des centaines de modèles de Machine Learning avec MLflow ; et de nombreux autres ont développé avec succès des solutions basées sur le ML.

Avant de travailler avec nous, de nombreux clients avaient du mal à mettre le ML en production, et ce pour une bonne raison : le Machine Learning Operations (MLOps) est un véritable défi. Le MLOps implique de gérer conjointement le code (DevOps), les données (DataOps) et les modèles (ModelOps) tout au long de leur parcours vers la production. Le défi le plus courant et le plus difficile que nous ayons constaté est le fossé entre les données et le ML, souvent répartis entre des outils et des équipes mal connectés.

Pour relever ce défi, Databricks Machine Learning s'appuie sur l'architecture Lakehouse pour étendre ses principaux avantages (la simplicité et l'ouverture) au MLOps.

Notre plateforme simplifie le ML en définissant un flux de travail centré sur les données qui unifie les meilleures pratiques du DevOps, du DataOps et du ModelOps. Les pipelines de Machine Learning sont avant tout des pipelines de données, où les données passent entre les mains de plusieurs profils. Les ingénieurs de données ingèrent et préparent les données ; les data scientists conçoivent des modèles à partir de ces données ; les ingénieurs ML surveillent les métriques des modèles ; et les analystes métier examinent les prédictions. Databricks simplifie le Machine Learning en production en permettant à ces équipes de données de collaborer et de gérer cette abondance de données sur une plateforme unique, plutôt que dans des silos. Par exemple, notre Feature Store vous permet de mettre en production vos modèles et vos features de manière conjointe : les data scientists créent des modèles qui « savent » de quelles features ils ont besoin, de sorte que les ingénieurs ML peuvent déployer les modèles via des processus simplifiés.

L'approche de Databricks vis-à-vis du MLOps repose sur des standards ouverts et reconnus par l'industrie. Pour le DevOps, nous nous intégrons aux outils Git et CI/CD. Pour le DataOps, nous nous appuyons sur Delta Lake et le lakehouse, l'architecture de fait pour un traitement des données ouvert et performant. Pour le ModelOps, nous nous appuyons sur MLflow, l'outil open source le plus populaire pour la gestion des modèles. Cette base de formats ouverts et d'APIs permet à nos clients d'adapter notre plateforme à leurs diverses exigences. Par exemple, les clients qui centralisent la gestion des modèles autour de notre offre MLflow peuvent utiliser notre solution intégrée de serving de modèles ou d'autres solutions, selon leurs besoins.

Nous sommes ravis de partager notre architecture MLOps dans cet article de blog. Nous y abordons les défis d'une gestion conjointe DevOps + DataOps + ModelOps, présentons notre solution et décrivons notre architecture de référence. Pour aller plus loin, téléchargez The Big Book of MLOps et assistez aux conférences MLOps lors du prochain Data+AI Summit 2022.

Gérer conjointement le code, les données et les modèles

Le MLOps est un ensemble de processus et d'automatisations permettant de gérer le code, les données et les modèles afin d'atteindre deux objectifs : des performances stables et une efficacité à long terme des systèmes de ML. En résumé, MLOps = DevOps + DataOps + ModelOps.

Développement, staging et production

Dans leur parcours vers des applications destinées aux métiers ou aux clients, les actifs de ML (code, données et modèles) passent par une série d'étapes. Ils doivent être développés (étape de « développement »), testés (étape de « staging ») et déployés (étape de « production »). Ce travail est effectué au sein d'environnements d'exécution tels que les espaces de travail Databricks.

Tout ce qui précède (environnements d'exécution, code, données et modèles) est divisé en dev, staging et prod. Ces divisions s'expliquent en termes de garanties de qualité et de contrôle d'accès. Les actifs en cours de développement peuvent être plus largement accessibles, mais ne bénéficient d'aucune garantie de qualité. Les actifs en production sont généralement critiques pour l'entreprise, avec les garanties de test et de qualité les plus élevées, mais avec des contrôles stricts sur les personnes autorisées à les modifier.

Principaux défis

L'ensemble de ces exigences peut facilement devenir extrêmement complexe : comment gérer le code, les données et les modèles, du développement à la production en passant par les tests, au sein de plusieurs équipes, avec des contraintes telles que les contrôles d'accès et la multiplicité des technologies utilisées ? Nous avons constaté que cette complexité entraîne quelques défis majeurs.

Processus opérationnels
Les concepts du DevOps ne se transposent pas directement au MLOps. Dans le DevOps, il existe une correspondance étroite entre les environnements d'exécution, le code et les données ; par exemple, l'environnement de production n'exécute que du code de niveau production et ne produit que des données de niveau production. Les modèles de ML compliquent la donne, car les phases du cycle de vie des modèles et du code fonctionnent souvent de manière asynchrone. Vous pouvez vouloir déployer une nouvelle version de modèle avant de déployer une modification de code, et inversement. Prenons les scénarios suivants :

• Pour détecter les transactions frauduleuses, vous développez un pipeline de ML qui réentraîne un modèle chaque semaine. Vous mettez à jour le code chaque trimestre, mais chaque semaine, un nouveau modèle est automatiquement entraîné, testé et mis en production. Dans ce scénario, le cycle de vie du modèle est plus rapide que celui du code.
• Pour classer des documents à l'aide de grands réseaux de neurones, l'entraînement et le déploiement du modèle ne se font souvent qu'une seule fois en raison du coût. Mais comme les systèmes en aval changent périodiquement, vous mettez à jour le code de serving et de surveillance en conséquence. Dans ce scénario, le cycle de vie du code est plus rapide que celui du modèle.

Collaboration et gestion
Le MLOps doit concilier le besoin de flexibilité et de visibilité des data scientists pour développer et maintenir des modèles avec le besoin contradictoire des ingénieurs ML de contrôler les systèmes de production. Les data scientists doivent exécuter leur code sur des données de production et voir les journaux (logs), les modèles et d'autres résultats des systèmes de production. Les ingénieurs ML doivent limiter l'accès aux systèmes de production pour maintenir la stabilité et parfois préserver la confidentialité des données. Répondre à ces besoins devient encore plus difficile lorsque la plateforme est constituée d'un assemblage de plusieurs technologies disjointes qui ne partagent pas un modèle unique de contrôle d'accès.

Intégration et personnalisation
De nombreux outils de ML ne sont pas conçus pour être ouverts ; par exemple, certains outils de ML exportent des modèles uniquement dans des formats « boîte noire » tels que des fichiers JAR. De nombreux outils de données ne sont pas conçus pour le ML ; par exemple, les data warehouses nécessitent d'exporter les données vers des outils de ML, ce qui augmente les coûts de stockage et complique la gouvernance. Lorsque ces composants ne reposent pas sur des formats ouverts et des APIs, il est impossible de les intégrer dans une plateforme unifiée.

Simplifier le MLOps grâce au Lakehouse

Pour répondre aux exigences du MLOps, Databricks a construit son approche sur l'architecture Lakehouse. Les lakehouses unifient les capacités des data lakes et des data warehouses sous une architecture unique, cette simplification étant rendue possible par l'utilisation de formats ouverts et d'APIs qui alimentent ces deux types de charges de travail de données. De la même manière, pour le MLOps, nous proposons une architecture plus simple car nous construisons le MLOps autour de standards de données ouverts.

Avant de plonger dans les détails de notre approche architecturale, nous l'expliquons dans ses grandes lignes et en soulignons les principaux avantages.

Processus opérationnels
Notre approche étend les concepts du DevOps au ML, en définissant une sémantique claire de ce que signifie « la mise en production » pour le code, les données et les modèles. Les outils DevOps et les processus CI/CD existants peuvent être réutilisés pour gérer le code des pipelines de ML. Le calcul des features, l'inférence et les autres pipelines de données suivent le même processus de déploiement que le code d'entraînement des modèles, ce qui simplifie les opérations. Un service dédié (le Model Registry de MLflow) permet de mettre à jour le code et les modèles de manière indépendante, résolvant ainsi le défi majeur de l'adaptation des méthodes DevOps au ML.

Collaboration et gestion
Notre approche repose sur une plateforme unifiée qui prend en charge l'ingénierie des données, la science des données exploratoire, le ML en production et l'analyse décisionnelle, le tout reposant sur une couche de données lakehouse partagée. Les données de ML sont gérées sous la même architecture lakehouse que celle utilisée pour les autres pipelines de données, ce qui simplifie les transitions. Les contrôles d'accès sur les environnements d'exécution, le code, les données et les modèles permettent aux bonnes équipes de disposer des niveaux d'accès appropriés, simplifiant ainsi la gestion.

Intégration et personnalisation
Notre approche repose sur des formats ouverts et des API : Git et les outils de CI/CD associés, Delta Lake et l'architecture Lakehouse, ainsi que MLflow. Le code, les données et les modèles sont stockés dans votre compte cloud (abonnement) dans des formats ouverts, soutenus par des services dotés d'API ouvertes. Bien que l'architecture de référence décrite ci-dessous puisse être entièrement implémentée au sein de Databricks, chaque module peut être intégré à votre infrastructure existante et personnalisé. Pour exemple, le réentraînement des modèles peut être entièrement automatisé, partiellement automatisé ou manuel.

Architecture de référence pour le MLOps

Nous sommes maintenant prêts à examiner une architecture de référence pour implémenter le MLOps sur la plateforme Databricks Lakehouse. Cette architecture — et Databricks en général — est indépendante du cloud (cloud-agnostic), utilisable sur un ou plusieurs clouds. En tant que telle, il s'agit d'une architecture de référence destinée à être adaptée à vos besoins spécifiques. Reportez-vous à The Big Book of MLOps pour en savoir plus sur l'architecture et les personnalisations possibles.

Présentation générale

Cette architecture explique notre processus MLOps à un niveau global. Ci-dessous, nous décrivons les composants clés de l'architecture et le flux de travail étape par étape pour passer les pipelines de ML en production.

Composants

Nous définissons notre approche en termes de gestion de quelques actifs clés : les environnements d'exécution, le code, les données et les modèles.

Les environnements d'exécution sont les endroits où les modèles et les données sont créés ou consommés par le code. Les environnements sont définis comme des espaces de travail Databricks (AWS, Azure, GCP) pour le développement, le staging et la production, avec des contrôles d'accès aux espaces de travail utilisés pour appliquer la séparation des rôles.
Dans le schéma d'architecture, les zones bleue, rouge et verte représentent les trois environnements.

Au sein des environnements, chaque pipeline de ML (les petites cases du schéma) s'exécute sur des instances de calcul gérées par notre service Clusters (AWS, Azure, GCP). Ces étapes peuvent être exécutées manuellement ou automatisées via Workflows et Jobs (AWS, Azure, GCP). Chaque étape doit par défaut utiliser un Databricks Runtime pour le ML avec des bibliothèques préinstallées (AWS, Azure, GCP), mais elle peut également utiliser des bibliothèques personnalisées (AWS, Azure, GCP).

Le code définissant les pipelines de ML est stocké dans Git pour le contrôle de version. Les pipelines de ML peuvent inclure la création de caractéristiques (featurization), l'entraînement et le réglage des modèles, l'inférence et la surveillance. À un niveau global, « passer le ML en production » signifie promouvoir le code depuis les branches de développement, en passant par la branche de staging (généralement `main`), jusqu'aux branches de publication pour l'utilisation en production. Cet alignement avec DevOps permet aux utilisateurs d'intégrer leurs outils de CI/CD existants. Dans le schéma d'architecture ci-dessus, ce processus de promotion du code est illustré en haut.

Lors du développement de pipelines de ML, les data scientists peuvent commencer par des notebooks et passer à du code modularisé selon les besoins, en travaillant dans Databricks ou dans des IDE. Databricks Repos s'intègre à votre fournisseur Git pour synchroniser les notebooks et le code source avec les espaces de travail Databricks (AWS, Azure, GCP). Les outils de développement Databricks vous permettent de vous connecter à partir d'IDE et de vos systèmes de CI/CD existants (AWS, Azure, GCP).

Les données sont stockées dans une architecture lakehouse, le tout dans votre compte cloud. Les pipelines pour la création de caractéristiques, l'inférence et la surveillance peuvent tous être traités comme des pipelines de données. Pour exemple, la surveillance des modèles doit suivre l'architecture médaillon de raffinement progressif des données, depuis les événements de requête bruts jusqu'aux tables agrégées pour les tableaux de bord. Dans le schéma d'architecture ci-dessus, les données sont représentées en bas comme des données « Lakehouse » générales, masquant la division en données de niveau développement, staging et production.

Par défaut, les données brutes et les tables de caractéristiques (feature tables) doivent être stockées sous forme de tables Delta pour garantir les performances et la cohérence. Delta Lake fournit une couche de stockage ouverte et efficace pour les données structurées et non structurées, avec un Delta Engine optimisé dans Databricks (AWS, Azure, GCP). Les tables du Feature Store sont simplement des tables Delta dotées de métadonnées supplémentaires telles que la traçabilité (lineage) (AWS, Azure, GCP). Les fichiers bruts et les tables sont soumis à un contrôle d'accès qui peut être accordé ou restreint selon les besoins.

Les modèles sont gérés par MLflow, ce qui permet une gestion uniforme des modèles à partir de n'importe quelle bibliothèque de ML, pour n'importe quel mode de déploiement, que ce soit au sein ou en dehors de Databricks. Databricks fournit une version gérée de MLflow avec des contrôles d'accès, une évolutivité jusqu'à des millions de modèles et un sur-ensemble d'API MLflow open source.

En développement, le serveur MLflow Tracking suit les prototypes de modèles ainsi que les instantanés de code, les paramètres, les métriques et d'autres métadonnées (AWS, Azure, GCP). En production, le même processus enregistre un historique pour garantir la reproductibilité et la gouvernance.

Pour le déploiement continu (CD), le MLflow Model Registry suit l'état de déploiement des modèles et s'intègre aux systèmes de CD via des webhooks (AWS, Azure, GCP) et via des API (AWS, Azure, GCP). Le service Model Registry suit le cycle de vie des modèles indépendamment de celui du code. Ce couplage lâche entre les modèles et le code offre la flexibilité nécessaire pour mettre à jour les modèles en production sans modifier le code, et vice versa. Par exemple, un pipeline de réentraînement automatisé peut entraîner un modèle mis à jour (un modèle de « développement »), le tester (modèle de « staging ») et le déployer (modèle de « production »), le tout au sein de l'environnement de production.

Le tableau ci-dessous résume la sémantique de « développement », « staging » et « production » pour le code, les données et les modèles.

Workflow

Les principaux composants de l'architecture ayant été expliqués ci-dessus, nous pouvons maintenant passer en revue le workflow permettant de faire passer les pipelines de ML du développement à la production.

Environnement de développement : les data scientists travaillent principalement dans l'environnement de développement, en créant le code des pipelines de ML, ce qui peut inclure le calcul des caractéristiques, l'entraînement des modèles, l'inférence, la surveillance, et bien plus encore.

1. Créer une branche de dev : les pipelines nouveaux ou mis à jour sont prototypés sur une branche de développement du projet Git et synchronisés avec l'espace de travail Databricks via Repos.
2. Analyse exploratoire des données (EDA) : les data scientists explorent et analysent les données dans un processus interactif et itératif à l'aide de notebooks, de visualisations et de Databricks SQL.
3. Actualisation de la table de caractéristiques : la logique de featurisation est encapsulée sous forme de pipeline qui peut lire à partir du Feature Store et d'autres tables du Lakehouse, et qui écrit dans le Feature Store. Les pipelines de caractéristiques peuvent être gérés séparément des autres pipelines de ML, en particulier s'ils appartiennent à des équipes distinctes.
4. Entraînement des modèles et autres pipelines : les data scientists développent ces pipelines soit sur des données de production en lecture seule, soit sur des données masquées ou synthétiques. Dans cette architecture de référence, ce sont les pipelines (et non les modèles) qui sont promus vers la production ; consultez le livre blanc complet pour en savoir plus sur la promotion des modèles en cas de besoin.
5. Commit du code : les pipelines de ML nouveaux ou mis à jour sont commités dans le contrôle de code source. Les mises à jour peuvent affecter un seul pipeline de ML ou plusieurs à la fois.

Environnement de staging : les ingénieurs ML sont responsables de l'environnement de staging, où les pipelines de ML sont testés.

6. Demande de fusion (pull request) : une demande de fusion vers la branche de staging (généralement la branche « main ») déclenche un processus d'intégration continue (CI).
7. Tests unitaires (CI) : le processus de CI exécute d'abord des tests unitaires qui n'interagissent pas avec les données ou d'autres services.
8. Tests d'intégration (CI) : le processus de CI exécute ensuite des tests d'intégration plus longs qui testent les pipelines de ML conjointement. Les tests d'intégration qui entraînent des modèles peuvent utiliser un petit volume de données ou peu d'itérations pour plus de rapidité.
9. Fusion (merge) : si les tests réussissent, le code peut être fusionné dans la branche de staging.
10. Création d'une branche de release : une fois prêt, le code peut être déployé en production en créant une release de code et en déclenchant le système de CI/CD pour mettre à jour les tâches de production.

Environnement de production : les ingénieurs ML sont responsables de l'environnement de production, où les pipelines de ML sont déployés.

11. Actualisation de la table de caractéristiques : ce pipeline ingère de nouvelles données de production et actualise les tables du Feature Store de production. Il peut s'agir d'une tâche par lots (batch) ou en continu (streaming) planifiée, déclenchée ou exécutée en continu.
12. Entraînement des modèles : les modèles sont entraînés sur l'ensemble des données de production et envoyés vers le MLflow Model Registry. L'entraînement peut être déclenché par des modifications de code ou par des tâches de réentraînement automatisées.
13. Déploiement continu (CD) : un processus de CD prend les nouveaux modèles (dans le Model Registry « stage=None »), les teste (en passant par « stage=Staging ») et, en cas de succès, les déploie (en les promouvant à « stage=Production »). Le CD peut être implémenté à l'aide des webhooks du Model Registry et/ou de votre propre système de CD.
14. Inférence et service (serving) : le modèle de production du Model Registry peut être déployé selon plusieurs modes : des tâches en batch et en streaming pour les cas d'usage à haut débit, et le service en ligne (serving) pour les cas d'usage à faible latence (API REST).
15. Surveillance : quel que soit le mode de déploiement, les requêtes d'entrée et les prédictions du modèle sont enregistrées dans des tables Delta. À partir de là, des tâches peuvent surveiller la dérive des données et des modèles (drift), et les tableaux de bord Databricks SQL peuvent afficher l'état et envoyer des alertes. Dans l'environnement de développement, les data scientists peuvent obtenir un accès aux journaux (logs) et aux métriques pour étudier les problèmes de production.
16. Réentraînement : les modèles peuvent être réentraînés sur les dernières données via une planification simple, ou des tâches de surveillance peuvent déclencher le réentraînement.

Implémenter votre architecture MLOps

Nous espérons que cet article de blog vous a donné un aperçu de la manière dont une architecture MLOps centrée sur les données et basée sur le paradigme du Lakehouse simplifie la gestion conjointe du code, des données et des modèles. Cet article est nécessairement court et omet de nombreux détails. Pour commencer à implémenter ou à améliorer votre architecture MLOps, nous vous recommandons ce qui suit :

• Lisez l'eBook complet, qui fournit plus de détails sur les étapes du workflow et présente les options et la personnalisation. Téléchargez-le ici.
• Participez aux présentations sur le MLOps lors du Data+AI Summit 2022 du 27 au 30 juin. Parmi les incontournables :
  • Présentations de haut niveau
    • Keynotes d'ouverture du jour 2 : les cofondateurs et les chefs de produit partagent la vision et les feuilles de route les plus récentes pour les projets open source et Databricks autour de la DS et du ML.
    • Le ML sur le Lakehouse : associer les données et le ML pour accélérer les cas d'usage de l'IA : les chefs de produit Databricks et un client présentent le machine learning dans une architecture Lakehouse.
  • Analyses approfondies de Databricks sur le MLOps
    • Le MLOps sur Databricks : guide pratique : les auteurs de cet article de blog détailleront les conseils de l'eBook et feront une démonstration du processus MLOps dans Databricks.
    • MLflow Pipelines : accélérer le MLOps du développement à la production : les ingénieurs de Databricks analysent en détail cette dernière innovation de MLflow.
    • Activer le ML en production avec Databricks Feature Store : les ingénieurs de Databricks analysent en détail le Feature Store.
  • Des clients parlent de leurs plateformes de ML
    • Créer et faire évoluer des produits basés sur le Machine Learning dans la plus grande brasserie du monde
    • Créer un Lakehouse pour la Data Science chez DoorDash
• Discutez avec votre équipe de compte Databricks, qui pourra vous guider dans l'analyse de vos besoins, vous aider à adapter cette architecture de référence à vos projets et mobiliser des ressources supplémentaires si nécessaire pour la formation et la mise en œuvre.

Pour en savoir plus sur le MLOps, nous vous recommandons :

• Le besoin de plateformes de ML centrées sur les données → Cet article explique plus en détail le MLOps et la nécessité d'une approche centrée sur les données, et présente un exemple concret d'équipe data développant une nouvelle application basée sur le ML.
• Trois principes pour choisir des plateformes de Machine Learning → Cet article se situe à un niveau plus général que l'article actuel. Il aborde le choix des technologies pour les plateformes de ML, donne des directives générales et cite des témoignages de clients associés.
• Le guide complet des Feature Stores → Les Feature Stores constituent un sujet à part entière. Ce guide l'explore en profondeur.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original