L'image principale de cet article a été générée par de HackerNoon via l'invite "des robots regardant des ordinateurs". le générateur d'images AI Les charges de travail (ML) nécessitent une infrastructure efficace pour produire des résultats rapides. La formation de modèles repose fortement sur de grands ensembles de données. L'acheminement de ces données du stockage vers le cluster d'apprentissage est la première étape de tout flux de travail ML, ce qui a un impact significatif sur l'efficacité de l'apprentissage du modèle. d'apprentissage automatique Les ingénieurs des plates-formes de données et d'IA se préoccupent depuis longtemps de la gestion des données en gardant ces questions à l'esprit : : comment rendre les données de formation accessibles lorsque les données proviennent de plusieurs sources et que les données sont stockées à distance ? Accessibilité des données : comment gérer les données comme un pipeline qui sert en continu les données dans le flux de travail de formation sans attendre ? Pipelining de données comment obtenir à la fois une faible latence des métadonnées et un débit de données élevé pour occuper le GPU ? Performances et utilisation du GPU : Cet article présente une nouvelle solution d'orchestration des données pour les pipelines d'apprentissage automatique de bout en bout qui répond aux questions ci-dessus. Je décrirai les défis et les pièges courants, puis proposerai une nouvelle technique, l'orchestration des données, pour optimiser le pipeline de données pour l'apprentissage automatique. Défis de données courants de la formation de modèles Un pipeline d'apprentissage automatique de bout en bout est une séquence d'étapes allant du prétraitement et du nettoyage des données à la formation du modèle et à l'inférence. La formation est la partie la plus cruciale et la plus gourmande en ressources de l'ensemble du flux de travail. Le schéma suivant montre un pipeline ML typique. Cela commence par la collecte de données, puis vient la préparation des données et enfin la formation du modèle. Pendant la phase de collecte de données, il faut généralement beaucoup de temps aux ingénieurs de la plate-forme de données pour rendre les données accessibles aux ingénieurs de données, qui doivent préparer les données pour que les data scientists construisent et itèrent des modèles. Pendant la phase de formation, des volumes de données sans précédent sont traités pour assurer l'alimentation continue des données vers les GPU qui génèrent des modèles. Il est impératif que les données soient gérées pour prendre en charge la complexité du ML et son architecture exécutable. Dans le pipeline de données, chaque étape présente ses propres défis techniques. Défi de la collecte de données – les données sont partout La formation bénéficie de grands ensembles de données, il est donc crucial de collecter des données à partir de toutes les sources pertinentes. Il n'est plus possible de combiner toutes les données dans une source monolithique lorsque les données résident dans des lacs de données, des entrepôts de données et des magasins d'objets, que ce soit sur site, dans le cloud ou répartis sur plusieurs emplacements géographiques. Avec les silos de données, l'accès à distance sur le réseau entraîne inévitablement une latence. Comment rendre les données accessibles tout en maintenant les performances souhaitées est un défi de taille. Défi de préparation des données - préparation des données sérialisées La préparation des données commence par l'ingestion des données de la phase de collecte et comprend le nettoyage, l'ETL et la transformation avant de fournir les données pour former le modèle. Si cette phase est considérée isolément, le pipeline de données est sérialisé et du temps supplémentaire est perdu en attendant les données préparées pour le cluster de formation. Par conséquent, les ingénieurs de plate-forme doivent trouver comment créer un pipeline de données parallélisé et permettre à la fois un partage efficace des données et un stockage efficace des résultats intermédiaires. Défi de formation de modèle – E/S liées à un processeur graphique sous-utilisé La formation de modèles nécessite le traitement de centaines de téraoctets de données, souvent un nombre considérable de petits fichiers tels que des images et des fichiers audio. La formation implique des itérations qui nécessitent des époques pour s'exécuter plusieurs fois, ce qui rend l'accès fréquent aux données. Il faut occuper le GPU en l'alimentant constamment en données. Il n'est pas facile d'optimiser les E/S et de maintenir le débit requis par le GPU. Approches traditionnelles et pièges courants Avant de parler de différentes solutions, mettons en place un scénario simplifié, comme illustré dans le schéma ci-dessous. Ici, nous nous entraînons dans le cloud à l'aide d'un cluster GPU avec plusieurs nœuds exécutant TensorFlow en tant que framework ML. Les données prétraitées sont stockées dans Amazon S3. En général, il existe deux approches pour transmettre ces données au cluster de formation. Nous en discuterons ensuite. Approche 1 : Dupliquer les données dans le stockage local Dans la première approche, l'intégralité de l'ensemble de données est répliqué du stockage distant vers le stockage local de chaque serveur pour la formation, comme indiqué ci-dessous. Par conséquent, la localité des données est garantie et les tâches de formation lisent l'entrée à partir de local au lieu de la récupérer à partir du stockage distant. Du point de vue du pipeline de données et des E/S, cette approche fournit le débit d'E/S le plus élevé puisque toutes les données sont locales. Les GPU seront occupés sauf au début puisque la formation doit attendre que les données soient entièrement copiées du stockage d'objets vers le cluster de formation. Néanmoins, cette approche ne convient pas à toutes les situations. Tout d'abord, l'ensemble de données doit tenir dans le stockage local agrégé. À mesure que la taille de l'ensemble de données d'entrée augmente, le processus de copie des données devient plus long et plus sujet aux erreurs, prenant plus de temps avec des ressources GPU gaspillées. Deuxièmement, la copie d'une grande quantité de données sur chaque machine d'entraînement crée une pression importante sur le système de stockage et le réseau. Dans les situations où les données d'entrée changent souvent, la synchronisation des données peut être très complexe. Enfin, la création manuelle de copies des données prend du temps et est sujette aux erreurs, car il est difficile de synchroniser les données sur le stockage en nuage avec les données de formation. Approche 2 : accéder directement au stockage dans le cloud Une autre approche courante consiste à connecter directement la formation à l'ensemble de données cible sur le stockage distant, comme indiqué ci-dessous. Avec cette approche, la taille de l'ensemble de données n'est pas un problème, comme avec la solution précédente. Mais il fait face à plusieurs nouveaux défis. Premièrement, du point de vue des E/S et du pipeline, les données sont traitées en série. Toutes les opérations d'accès aux données doivent passer par le réseau entre le stockage d'objets et le cluster de formation, ce qui fait des E/S un goulot d'étranglement. En conséquence, les GPU passent des cycles à attendre car le débit d'E/S est limité par le réseau. Deuxièmement, lorsque l'échelle de formation est importante, tous les nœuds de formation accèdent simultanément au même ensemble de données à partir du même stockage distant, ce qui ajoute une pression énorme sur le système de stockage. Le stockage deviendra probablement encombré en raison d'un accès hautement simultané, ce qui entraînera une faible utilisation du GPU. Troisièmement, si l'ensemble de données se compose d'un grand nombre de petits fichiers, les demandes d'accès aux métadonnées représenteront une grande partie des demandes de données. Par conséquent, la récupération directe des métadonnées d'un grand nombre de fichiers ou de répertoires à partir du magasin d'objets devient le goulot d'étranglement des performances et augmente le coût d'exploitation des métadonnées. Approche recommandée – orchestrez vos données Pour relever ces défis et écueils, nous devons repenser les architectures de plate-forme de données lorsqu'il s'agit d'E/S dans le pipeline d'apprentissage automatique. Ici, je recommande une nouvelle approche, l'orchestration des données, pour accélérer le pipeline ML de bout en bout. Les technologies d'orchestration des données font abstraction de l'accès aux données sur les systèmes de stockage, virtualisent toutes les données et présentent les données via des API standardisées et un espace de noms global aux applications pilotées par les données. Unifier les silos de données en utilisant l'abstraction Au lieu de copier et de déplacer des données, laissez-les là où elles se trouvent, qu'elles soient sur site ou dans le cloud. L'orchestration des données peut aider à résumer les données pour créer une vue unifiée. Cela réduira considérablement la complexité de la phase de collecte des données. Étant donné que l'orchestration des données peut déjà s'intégrer aux systèmes de stockage, les infrastructures d'apprentissage automatique n'ont besoin d'interagir qu'avec une seule plate-forme d'orchestration des données pour accéder aux données à partir de n'importe quel stockage connecté. Par conséquent, la formation peut être effectuée sur toutes les données de n'importe quelle source, ce qui améliore la qualité du modèle. Il n'est pas nécessaire de déplacer manuellement les données vers une source centrale. Tous les frameworks de calcul, y compris Spark, Presto, PyTorch et , peuvent accéder aux données sans se soucier de leur emplacement. TensorFlow Utiliser la mise en cache distribuée pour la localité des données Au lieu de dupliquer l'intégralité de l'ensemble de données sur chaque machine, je recommande de mettre en œuvre une mise en cache distribuée, où les données peuvent être réparties uniformément sur le cluster. La mise en cache distribuée est particulièrement avantageuse lorsque l'ensemble de données d'apprentissage est beaucoup plus volumineux que la capacité de stockage d'un seul nœud. Cela aide également lorsque les données sont distantes car les données sont mises en cache localement. La formation ML devient plus rapide et plus rentable car il n'y a pas d'E/S réseau lors de l'accès aux données. La figure ci-dessus montre un magasin d'objets où toutes les données de formation sont stockées, et deux fichiers pour représenter l'ensemble de données (/path1/file1 et /path2/file2). Plutôt que de stocker tous les blocs de fichiers sur chaque machine d'entraînement, les blocs seront répartis sur plusieurs machines. Pour éviter la perte de données et améliorer la simultanéité de lecture, chaque bloc peut être stocké sur plusieurs serveurs simultanément. Optimisez le partage de données dans le pipeline Il existe un degré élevé de chevauchement entre les lectures et les écritures de données effectuées par une tâche de formation ML, à la fois au sein et entre les tâches. Le partage de données peut garantir que toutes les infrastructures de calcul ont accès aux données précédemment mises en cache pour les charges de travail de lecture et d'écriture pour l'étape suivante. Par exemple, si vous utilisez Spark pour ETL dans l'étape de préparation des données, le partage des données peut garantir que les données de sortie sont mises en cache et disponibles pour les étapes futures. Grâce au partage de données, l'ensemble du pipeline de données bénéficie de meilleures performances de bout en bout. Orchestrez le pipeline de données en parallélisant le préchargement, la mise en cache et la formation des données Nous orchestrons le pipeline de données en mettant en œuvre le préchargement et la mise en cache à la demande. L'image ci-dessous montre que le chargement des données à partir de la source avec la mise en cache des données peut être effectué en parallèle avec la tâche d'entraînement proprement dite. Par conséquent, la formation bénéficie d'un débit de données élevé lors de l'accès aux données sans qu'il soit nécessaire d'attendre de mettre en cache les données complètes avant la formation. Bien qu'il y ait une certaine latence d'E/S au début, le temps d'attente diminuera car les données sont déjà chargées dans le cache. Grâce à cette approche, vous pouvez chevaucher les étapes. Le chargement des données du stockage d'objets vers le cluster de formation, la mise en cache, le chargement des données à la demande dans la formation et la formation peuvent tous être effectués en parallèle, ce qui accélère considérablement l'ensemble du processus. Comparons la nouvelle approche recommandée avec les deux approches traditionnelles. En orchestrant les données à travers les étapes d'un pipeline d'apprentissage automatique, nous éliminons l'exécution en série et les inefficacités associées lorsque les données circulent d'une étape à la suivante. Cela entraînera à son tour un taux d'utilisation élevé du GPU. Dupliquer les données dans le stockage local Accéder directement au stockage cloud Orchestration des données Localité des données ✓ ✓ Aucune limitation de la taille du jeu de données ✓ ✓ Pas besoin de copier manuellement toutes les données avant l'entraînement ✓ ✓ ✓ La cohérence des données est assurée ✓ ✓ L'utilisation du GPU est élevée ✓ ✓ Comment orchestrer les données pour vos charges de travail ML Utilisons comme exemple ici pour vous montrer comment utiliser l'orchestration des données. Encore une fois, nous utiliserons le même scénario simplifié. Pour planifier des tâches TensorFlow, vous pouvez soit utiliser Kubernetes, soit utiliser des services de cloud public. Alluxio L'utilisation d'Alluxio pour orchestrer l'apprentissage automatique et l'apprentissage profond comprend généralement trois étapes : Déployez Alluxio sur le cluster de formation. Montez Alluxio en tant que dossier local pour les tâches de formation. Chargez des données à partir de dossiers locaux (sauvegardés par Alluxio) à l'aide d'un script de formation. Les données de différents systèmes de stockage sont accessibles via Alluxio immédiatement après le montage et peuvent être consultées de manière transparente via les scripts de référence sans modifier TensorFlow. Cela simplifie considérablement le développement d'applications, qui autrement nécessiteraient l'intégration de chaque système de stockage particulier ainsi que les configurations des informations d'identification. Vous pouvez suivre le guide pour exécuter la reconnaissance d'image en utilisant Alluxio avec TensorFlow. ici Comme il n'existe pas d'approche unique, il est préférable d'utiliser l'orchestration des données dans les scénarios suivants : Vous avez besoin d'une formation distribuée. Il existe une grande quantité de données d'apprentissage (10 To ou plus), surtout s'il y a beaucoup de petits fichiers et d'images dans les données d'apprentissage. Vos ressources GPU ne sont pas suffisamment occupées par les E/S réseau. Votre pipeline utilise de nombreuses sources de données et plusieurs infrastructures de formation/de calcul. Le stockage sous-jacent doit être stable pendant que vous traitez des demandes de formation supplémentaires. Le même jeu de données est utilisé par plusieurs nœuds ou tâches d'entraînement. À mesure que les techniques d'apprentissage automatique continueront d'évoluer et que les cadres effectueront des tâches plus complexes, nos méthodes de gestion du pipeline de données s'amélioreront également. En étendant l'orchestration des données au pipeline de données, vous pouvez améliorer l'efficacité et l'utilisation des ressources pour votre pipeline de formation de bout en bout. . Réimprimé avec permission. © IDG Communications, Inc., 2022. Tous droits réservés. https://www.infoworld.com/article/3651453/orchestrating-data-for-machine-learning-pipelines.html
