Partager via

Meilleures pratiques pour les projets de science des données avec l’analytique à l’échelle du cloud dans Azure

  • Article

Nous vous recommandons d’utiliser ces meilleures pratiques pour utiliser l’analytique à l’échelle du cloud dans Microsoft Azure pour mettre en œuvre des projets de science des données.

Développer un modèle

Développez un modèle qui regroupe un ensemble de services pour vos projets de science des données. Utilisez un modèle qui regroupe un ensemble de services pour assurer la cohérence entre les différents cas d’usage des équipes de science des données. Nous vous recommandons de développer un blueprint cohérent sous la forme d’un référentiel de modèles. Vous pouvez utiliser ce référentiel pour différents projets de science des données au sein de votre entreprise pour réduire les temps de déploiement.

Recommandations en matière de modèles de science des données

Développez un modèle de science des données pour votre organisation avec les instructions suivantes :

  • Développez un ensemble de modèles d’infrastructure en tant que code (IaC) pour déployer un espace de travail Azure Machine Learning. Incluez des ressources telles qu’un coffre de clés, un compte de stockage, un registre de conteneurs et Application Insights.

  • Incluez la configuration des magasins de données et des cibles de calcul dans ces modèles, comme les instances de calcul, les clusters de calcul et Azure Databricks.

Meilleures pratiques de déploiement

En temps réel

  • Incluez un déploiement Azure Data Factory ou Azure Synapse dans des modèles et Azure Cognitive Services.
  • Les modèles doivent fournir tous les outils nécessaires pour exécuter la phase d’exploration de la science des données et l’opérationnalisation initiale du modèle.

Considérations relatives à une configuration initiale

Dans certains cas, les scientifiques des données de votre organisation peuvent nécessiter un environnement pour une analyse rapide si nécessaire. Cette situation est courante lorsqu’un projet de science des données n’est pas officiellement configuré. Par exemple, un responsable de projet, un code de coût ou un centre de coûts qui peut être requis pour la facturation croisée au sein d’Azure peut être manquant, car l’élément manquant a besoin d’approbation. Les utilisateurs de votre organisation ou de votre équipe peuvent avoir besoin d’accéder à un environnement de science des données pour comprendre les données et éventuellement évaluer la faisabilité d’un projet. En outre, certains projets peuvent ne pas nécessiter un environnement de science des données complet en raison du petit nombre de produits de données.

Dans d’autres cas, un projet de science des données complet peut être nécessaire, avec un environnement dédié, la gestion de projet, le code de coût et le centre de coûts. Les projets de science des données complets sont utiles pour plusieurs membres de l’équipe qui souhaitent collaborer, partager des résultats et avoir besoin d’opérationnaliser des modèles une fois la phase d’exploration réussie.

Processus d’installation

Les modèles doivent être déployés par projet une fois qu’ils ont été configurés. Chaque projet doit recevoir au moins deux instances afin de séparer les environnements de développement et de production. Dans l’environnement de production, aucune personne ne doit avoir accès, et tout doit être déployé via des pipelines d’intégration continue ou de développement continu et un principal de service. Ces principes d’environnement de production sont importants, car Azure Machine Learning ne fournit pas de modèle de contrôle d’accès granulaire basé sur les rôles au sein d’un espace de travail. Vous ne pouvez pas limiter l’accès utilisateur à un ensemble spécifique d’expériences, de points de terminaison ou de pipelines.

Les mêmes droits d’accès s’appliquent généralement à différents types d’artefacts. Il est important de séparer le développement de la production pour empêcher la suppression de pipelines de production ou de points de terminaison au sein d’un espace de travail. En plus du modèle, un processus doit être créé pour permettre aux équipes de produits de données de demander de nouveaux environnements.

Nous vous recommandons de configurer différents services IA comme Azure Cognitive Services par projet. En configurant différents services IA par projet, les déploiements se produisent pour chaque groupe de ressources de produit de données. Cette stratégie crée une séparation claire du point de vue de l’accès aux données et atténue le risque d’accès non autorisé aux données par les mauvaises équipes.

Scénario de diffusion en continu

Pour les cas d’utilisation en temps réel et en streaming, les déploiements doivent être testés sur une version réduite du service Azure Kubernetes (AKS). Les tests peuvent se trouver dans l’environnement de développement pour économiser sur les coûts avant de déployer sur AKS de production ou Azure App Service pour conteneurs. Vous devez effectuer des tests d’entrée et de sortie simples pour vous assurer que les services répondent comme prévu.

Ensuite, vous pouvez déployer des modèles sur le service souhaité. Cette cible de calcul de déploiement est la seule qui est généralement disponible et recommandée pour les charges de travail de production dans un cluster AKS. Cette étape est particulièrement nécessaire si une prise en charge GPU (Graphics Processing Unit, unité de traitement graphique) ou FPGA (Field Programmable Gate Array, réseau de portes programmabes in situ) est requise. D’autres options de déploiement natives qui prennent en charge ces exigences matérielles ne sont actuellement pas disponibles dans Azure Machine Learning.

Azure Machine Learning nécessite un mappage un-à-un aux clusters AKS. Chaque nouvelle connexion à un espace de travail Azure Machine Learning interrompt la connexion précédente entre AKS et Azure Machine Learning. Une fois cette limitation atténuée, nous vous recommandons de déployer des clusters AKS centraux en tant que ressources partagées et de les attacher à leurs espaces de travail respectifs.

Une autre instance AKS de test central doit être hébergée si des tests de contrainte doivent être effectués avant de déplacer un modèle vers l’AKS de production. L’environnement de test doit fournir la même ressource de calcul que l’environnement de production pour s’assurer que les résultats sont aussi similaires que possible à l’environnement de production.

Scénario de traitement par lots

Tous les cas d’usage n’ont pas besoin de déploiements de cluster AKS. Un cas d’usage n’a pas besoin d’un déploiement de cluster AKS si de grandes quantités de données nécessitent uniquement un scoring régulièrement ou sont basées sur un événement. Par exemple, de grandes quantités de données peuvent être basées sur le moment où les données tombent dans un compte de stockage spécifique. Les pipelines Azure Machine Learning et les clusters de calcul Azure Machine Learning doivent être utilisés pour le déploiement pendant ces types de scénarios. Ces pipelines doivent être orchestrés et exécutés dans Data Factory.

Identifier les ressources de calcul appropriées

Avant de déployer un modèle dans Azure Machine Learning sur un AKS, l’utilisateur doit spécifier les ressources telles que l’UC, la RAM et le GPU qui doivent être allouées pour le modèle respectif. La définition de ces paramètres peut être un processus complexe et fastidieux. Vous devez effectuer des tests de contrainte avec différentes configurations pour identifier un bon ensemble de paramètres. Vous pouvez simplifier ce processus avec la fonctionnalité Profilage de modèle dans Azure Machine Learning, qui est un travail de longue durée qui teste différentes combinaisons d’allocations de ressources et utilise une latence et un temps d’aller-retour identifiés (RTT) pour recommander une combinaison optimale. Ces informations peuvent aider le déploiement réel du modèle sur AKS.

Pour mettre à jour en toute sécurité les modèles dans Azure Machine Learning, les équipes doivent utiliser la fonctionnalité de déploiement contrôlée (préversion) pour réduire le temps d’arrêt et maintenir la cohérence du point de terminaison REST du modèle.

Bonnes pratiques et workflow pour MLOps

Inclure un exemple de code dans des référentiels de science des données

Vous pouvez simplifier et accélérer les projets de science des données si vos équipes disposent de certains artefacts et bonnes pratiques. Nous vous recommandons de créer des artefacts que toutes les équipes de science des données peuvent utiliser lors de l’utilisation d’Azure Machine Learning et des outils respectifs de l’environnement de produit de données. Les ingénieurs Données et Machine Learning doivent créer et fournir les artefacts.

Ces artefacts doivent inclure :

  • Exemples de cahiers qui illustrent comment :

    • Chargez, montez et utilisez des produits de données.
    • Consigner les métriques et les paramètres.
    • Envoyez des travaux de formation aux clusters de calcul.

  • Artefacts requis pour l’opérationnalisation :

    • Exemples de pipelines Azure Machine Learning
    • Exemples d’Azure Pipelines
    • Autres scripts requis pour exécuter des pipelines

  • Documentation

Utiliser des artefacts bien conçus pour opérationnaliser des pipelines

Les artefacts peuvent accélérer les phases d’exploration et d’opérationnalisation des projets de science des données. Une stratégie de duplication DevOps peut aider à mettre à l’échelle ces artefacts dans tous les projets. Étant donné que cette configuration favorise l’utilisation de Git, les utilisateurs et le processus d’automatisation global peuvent tirer parti des artefacts fournis.

Conseil

Les exemples de pipelines Azure Machine Learning doivent être générés avec le Kit de développement logiciel (SDK) Python ou en fonction du langage YAML. La nouvelle expérience YAML sera plus pérenne, car l’équipe produit Azure Machine Learning travaille actuellement sur un nouveau Software Development Kit (SDK) et une interface en ligne de commande (CLI). L’équipe de produit Azure Machine Learning est confiante que YAML servira de langage de définition pour tous les artefacts dans Azure Machine Learning.

Les exemples de pipelines ne fonctionnent pas d'emblée pour chaque projet, mais ils peuvent être utilisés comme base. Vous pouvez ajuster les exemples de pipelines en fonction des projets. Un pipeline doit inclure les aspects les plus pertinents de chaque projet. Par exemple, un pipeline peut référencer une cible de calcul, référencer des produits de données, définir des paramètres, définir des entrées et définir les étapes d’exécution. Le même processus doit être effectué pour Azure Pipelines. Azure Pipelines doit également utiliser le Kit de développement logiciel (SDK) Azure Machine Learning ou l’interface CLI.

Les pipelines doivent montrer comment :

  • Connectez-vous à un espace de travail à partir d’un pipeline DevOps.
  • Vérifiez si le calcul requis est disponible.
  • Soumettre un travail.
  • Inscrivez et déployez un modèle.

Les artefacts ne conviennent pas à tous les projets tout le temps et peuvent nécessiter une personnalisation, mais avoir une base peut accélérer l’opérationnalisation et le déploiement d’un projet.

Structurer le référentiel MLOps

Vous pouvez avoir des situations où les utilisateurs perdent le suivi de l’emplacement où ils peuvent trouver et stocker des artefacts. Pour éviter ces situations, vous devez demander plus de temps pour communiquer et construire une structure de dossiers de niveau supérieur pour le référentiel standard. Tous les projets doivent suivre la structure des dossiers.

Remarque

Les concepts mentionnés dans cette section peuvent être utilisés dans les environnements Locaux, Amazon Web Services, Palantir et Azure.

La structure de dossiers de niveau supérieur proposée pour un référentiel MLOps (opérations machine learning) est illustrée dans le diagramme suivant :

Diagramme de la structure de référentiel pour MLOps.

Les objectifs suivants s’appliquent à chaque dossier du référentiel :

Dossier Objectif
.cloud Stockez du code et des artefacts spécifiques au cloud dans ce dossier. Les artefacts incluent des fichiers de configuration pour l’espace de travail Azure Machine Learning, notamment les définitions de cible de calcul, les travaux, les modèles inscrits et les points de terminaison.
.ado/.github Stockez des artefacts Azure DevOps ou GitHub tels que des pipelines YAML ou des propriétaires de code dans ce dossier.
code Incluez le code réel développé dans le cadre du projet dans ce dossier. Ce dossier peut contenir des packages Python et certains scripts utilisés pour les étapes respectives du pipeline Machine Learning. Nous vous recommandons de séparer les étapes individuelles qui doivent être effectuées dans ce dossier. Les étapes courantes sont le prétraitement, l'entraînement du modèle et l'enregistrement du modèle . Définissez des dépendances telles que les dépendances Conda, les images Docker ou d’autres pour chaque dossier.
docs Utilisez ce dossier à des fins de documentation. Ce dossier stocke les fichiers et images Markdown pour décrire le projet.
pipelines Stockez les définitions de pipelines Azure Machine Learning dans YAML ou Python dans ce dossier.
tests Écrivez des tests unitaires et d’intégration qui doivent être exécutés pour détecter les bogues et les problèmes au début du projet dans ce dossier.
notebooks Séparez les notebooks Jupyter du projet Python réel avec ce dossier. Chaque individu doit disposer d’un sous-dossier dans ce dossier afin d’y archiver ses notebooks et d’éviter les conflits de fusion Git.

Étape suivante

Produits de données d'analyse à l'échelle du cloud dans Azure