Scoring par lots des modèles Python sur Azure

Container Registry
Event Hubs
Machine Learning
Base de données SQL
Stream Analytics

Ce guide d’architecture montre comment créer une solution évolutive pour le scoring par lots de modèles Azure Machine Learning. La solution peut être utilisée comme modèle et appliquée à différents problèmes.

Architecture

Diagramme d’architecture illustrant le scoring par lots des modèles Python sur Azure

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

Workflow

Ce guide d’architecture s’applique à la fois aux données de streaming et statiques, à condition que le processus d’ingestion soit adapté au type de données. Les étapes et composants suivants décrivent l’ingestion de ces deux types de données.

Données de streaming :

  1. Les données de streaming proviennent de capteurs IoT, les nouveaux événements étant diffusés à intervalles fréquents.
  2. Les événements de streaming entrants sont mis en file d’attente à l’aide d’Azure Event Hubs, puis prétraités à l’aide d’Azure Stream Analytics.
    • Azure Event Hubs. Ce service d’ingestion de messages peut recevoir des millions de messages d’événement par seconde. Dans cette architecture, les capteurs envoient un flux de données au hub d’événements.
    • Azure Stream Analytics. Moteur de traitement des événements. Un travail Stream Analytics lit les flux de données provenant du hub d’événements et effectue le traitement des flux.

Données statiques :

  1. Les jeux de données statiques peuvent être stockés sous forme de fichiers dans Azure Data Lake Storage ou sous forme de tableau dans Azure Synapse ou Azure SQL Database.
  2. Azure Data Factory peut être utilisé pour agréger ou prétraiter le jeu de données stocké.

L’architecture restante, après ingestion des données, est égale pour les données de streaming et statiques, et se compose des étapes et composants suivants :

  1. Les données ingérées, agrégées et/ou prétraitées peuvent être stockées en tant que documents dans Azure Data Lake Storage ou sous forme de tableau dans Azure Synapse ou Azure SQL Database. Ces données seront ensuite consommées par Azure Machine Learning.
  2. Azure Machine Learning est utilisé pour l’entraînement, le déploiement et la gestion des modèles Machine Learning à grande échelle. Dans le contexte du scoring par lots, Azure Machine Learning crée un cluster de machines virtuelles avec une option de mise à l’échelle automatique, où les travaux sont exécutés en parallèle à partir de scripts Python.
  3. Les modèles sont déployés en tant que points de terminaison de lots managés, qui sont ensuite utilisés pour effectuer une inférence par lots sur de grands volumes de données sur une période donnée. Les points de terminaison de traitement de lots reçoivent des pointeurs vers les données et exécutent les tâches de façon asynchrone pour traiter les données en parallèle sur les clusters de calcul.
  4. Les résultats de l’inférence peuvent être stockés en tant que documents dans Azure Data Lake Storage ou sous forme de tableau dans Azure Synapse ou Azure SQL Database.
  5. Visualisation : les résultats du modèle stocké peuvent être utilisés via des interfaces utilisateur, telles que des tableaux de bord Power BI, ou via des applications web personnalisées.

Composants

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Performances

Pour les modèles Python standard, il est généralement admis que les processeurs sont suffisants pour gérer la charge de travail. Cette architecture utilise des processeurs. Toutefois, pour les charges de travail Deep Learning, les GPU sont généralement beaucoup plus performants que les UC, dans la mesure où un cluster d’UC important est nécessaire pour obtenir un niveau de performance comparable.

Paralléliser dans les machines virtuelles et les cœurs

Lorsque vous exécutez des processus de scoring de nombreux modèles en mode Batch, le travail doit être mis en parallèle sur les machines virtuelles. Deux approches sont possibles :

  • Créer un cluster plus grand avec des machines virtuelles de faible coût.
  • Créer un cluster plus petit avec des machines virtuelles hautes performances et plus de cœurs disponibles sur chacune.

En général, le scoring des modèles Python standard n’est pas aussi exigeant que celui des modèles de Deep Learning, et un petit cluster doit être en mesure de gérer efficacement un grand nombre de modèles en file d’attente. Vous pouvez accroître le nombre de nœuds de cluster à mesure que les tailles des jeux de données augmentent.

Pour des raisons pratiques, dans ce scénario, une seule tâche de scoring est envoyée dans une étape du pipeline Azure Machine Learning. Il peut cependant être plus efficace d’effectuer le scoring de plusieurs blocs de données dans la même étape de pipeline. Dans ce cas, écrivez un code personnalisé pour lire dans plusieurs jeux de données et exécutez le script de scoring au cours d’une même étape.

Gestion

  • Superviser les travaux. Il est important de superviser la progression des travaux en cours d’exécution. Cependant, superviser un cluster de nœuds actifs peut s’avérer ardu. Pour examiner l’état des nœuds du cluster, utilisez le Portail Azure pour gérer l’espace de travail Machine Learning. Si un nœud est inactif ou si un travail a échoué, vous pouvez consulter les journaux d’activité d’erreurs enregistrés dans Stockage Blob. Ils sont également accessibles dans la section Pipelines. Pour une supervision approfondie, connectez les journaux d’activité à Application Insights, ou exécutez des processus distincts pour interroger l’état du cluster et de ses travaux.
  • Journalisation. Machine Learning journalise tous les stdout/stderr dans le compte de stockage Azure associé. Pour consulter facilement les fichiers journaux, utilisez un outil de navigation dans le stockage comme Explorateur Stockage Azure.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.

Les composants les plus coûteux utilisés dans ce guide d’architecture sont les ressources de calcul. La taille du cluster de calcul peut faire l’objet d’un scale-up ou d’un scale-down en fonction des travaux présents dans la file d’attente. Activez la mise à l’échelle automatique programmatiquement via le SDK Python en modifiant la configuration du provisionnement de la capacité de calcul. Vous pouvez aussi utiliser Azure CLI pour définir les paramètres de mise à l’échelle automatique du cluster.

Pour les tâches qui ne nécessitent pas un traitement immédiat, configurez la formule de mise à l’échelle automatique de sorte que l’état par défaut (minimum) soit un cluster sans nœud. Avec cette configuration, le cluster démarre sans nœud et ne monte en puissance que s’il détecte des tâches dans la file d’attente. Si le processus de scoring par lots ne se produit que quelques fois par jour ou moins, ce paramètre permet de réaliser des économies significatives.

La mise à l’échelle automatique peut ne pas convenir pour les traitements par lots trop rapprochés les uns des autres. Le temps nécessaire au lancement et à l’arrêt d’un cluster ayant aussi un coût, si une charge de travail par lots commence seulement quelques minutes après la fin du travail précédent, il peut être plus rentable de laisser le cluster en fonctionnement entre les travaux. Cette stratégie dépend si les processus de scoring sont planifiés pour s’exécuter très fréquemment (toutes les heures, par exemple) ou moins fréquemment (une fois par mois, par exemple).

Contributeurs

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

Auteurs principaux :

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

Étapes suivantes

Documentation du produit :

Modules Microsoft Learn :